Peak trading tests every part of an online checkout, but authentication is the part a merchant controls least. Your 3DS Server, whether you run it or your payment service provider does, depends on the card schemes’ Directory Servers and on the Access Control Server (ACS) of every issuer whose cardholders shop with you. Each has its own capacity, and each can slow down at the worst moment.
Most authentication problems during a sale are not outages of your own systems. They are decisions nobody made in advance: what checkout should do when an authentication response does not arrive, when a challenge times out, or when an issuer cannot authenticate at all. Each of those can be decided in advance and tested before the sale starts.
In Australia, the promotional calendar is tightly packed. Click Frenzy’s official schedule places its 2026 Main Event on 27–30 October, while Black Friday falls on 27 November and Cyber Monday on 30 November. Many retailers now launch Black Friday promotions weeks in advance, extending their campaigns through Cyber Monday and creating a prolonged period of promotional activity.
Why authentication behaves differently under peak load
In EMV 3D Secure (EMV 3DS), a single authentication can involve your checkout, your 3DS Server, a Directory Server (DS) and the issuer’s ACS, and sometimes the cardholder’s banking app or phone for a challenge. Higher volume puts pressure on all of them at once.
During a major sale, a few things usually change at once:
- If a large share of your customers bank with two or three issuers, a slowdown at one of their ACSs affects a meaningful share of checkouts, even when every other component is healthy.
- Issuer risk models see more new customers, larger baskets and first-time devices than usual. Issuers may challenge more often as a result, putting more cardholders through SMS or app-based steps that can themselves be slow.
- Card testing and account takeover attempts are easier to miss when traffic is already high, which matters if your fallback plan lets some transactions through without authentication.
Decide your fallback policy before the event
The EMV 3DS specification standardises the messages and status values each component sends. It does not decide what your checkout should do with an unhelpful result. That is a business decision, and it is far easier to make calmly in October than live on Black Friday. (Our article on the decisions EMV 3DS deliberately leaves out of scope explains why the specification draws this line.)
The table below sets out the scenarios most likely to appear under load and the choices a merchant typically has.
|
Scenario |
What the protocol tells you |
Typical options |
Trade-off to agree |
|
The 3DS Method does not complete in time |
The 3DS Server proceeds without waiting further and indicates that the Method did not complete (10-second limit) |
Proceed with authentication |
The issuer receives less browser data, so a challenge becomes more likely. Do not hold the checkout open waiting. |
|
No authentication response, or an Error message, from the DS or ACS |
Timeout or protocol error rather than an authentication outcome |
1. Retry once 2. Send for authorisation without authentication 3. Ask for another payment method |
Option 2 keeps the sale but fraud liability normally stays with the merchant, and in markets that mandate strong customer authentication the issuer may decline. Option 3 protects against fraud but loses genuine customers. |
|
Authentication could not be performed (transStatus U) |
Reason codes such as 14 (transaction timed out at the ACS) or 22 (ACS technical issue) point to an issuer-side problem |
As above, decided by risk segment |
A spike in U from one issuer usually points to capacity rather than fraud. Avoid blocking that issuer’s cardholders outright if their risk is otherwise low. |
|
Cardholder abandons or times out during a challenge |
Final result arrives in the Results Request with a challenge cancellation indicator, or never arrives |
Offer one retry, or offer an alternative payment method |
Repeated retries frustrate customers and add authentication attempts. Cap retries. |
|
Card number not found in the card range cache |
The 3DS Server cannot route the request to an ACS |
Treat as not enrolled, or refresh card range data and retry later |
A stale cache misroutes genuine customers. Confirm the refresh job before the event rather than relying on this fallback. |
|
Issuer soft-declines an unauthenticated authorisation and asks for authentication |
Scheme-specific authorisation response code |
Authenticate and resubmit |
Only works if checkout can re-enter authentication cleanly. See what a soft decline is and how to respond. |
A single policy for every transaction is rarely right. Most merchants who plan this well segment the decision by order value, product type (instantly delivered digital goods carry more risk than physical goods with a dispatch window), domestic or cross-border card, and new or returning customer. A low-value order from a returning customer might proceed unauthenticated when the ACS is down. A high-value gift card order from a new account probably should not.
Write the policy down, name who can change it during the event, and make sure payments, fraud and finance have all agreed to it. The finance sign-off matters because fraud chargebacks on transactions that went through without authentication will arrive weeks after the sale ends.
Six weeks out: confirm what your authentication stack depends on
Start with an inventory. For each card scheme you accept, confirm:
- which 3DS Server processes your authentications, and who operates it
- which protocol versions are in use for browser and app-based flows
- the expiry dates of the certificates used for Directory Server connections and message signing, so none lapses during the sale period
- expected peak volumes, shared with your PSP or 3DS Server provider so they can plan capacity
Then check card range data. The 3DS Server learns which card ranges are enrolled, and which protocol versions and features each issuer supports, by exchanging Preparation Request and Response messages (PReq and PRes) with each DS. Implementations commonly refresh this cache at least once every 24 hours and no more than once an hour. Confirm the refresh job is running and that it alerts someone when it fails. How card range data shapes 3DS Server reliability covers the mechanics in detail.
Four weeks out: test the failure paths, not only the happy path
A checkout that passes every successful authentication can still fail badly when a component misbehaves. Before the event, test what your checkout actually does in each scenario from the fallback table:
- an ACS that responds slowly or not at all
- an authentication result of U, N or R with each reason code you have chosen to handle differently
- a challenge abandoned part-way, on desktop and on mobile browsers
- a 3DS Method that never completes
- an authorisation soft decline that asks for authentication
Confirm the result matches the policy you agreed, including the message the customer sees. How to build 3DS negative testing into your test plan sets out how to design these cases. If anything in the checkout or 3DS configuration has changed since your last full test, use a scoped regression test rather than assuming the change is isolated.
Check the browser flow under realistic conditions as well: challenge window sizing on small screens (several iframe settings are now requirements) and behaviour when JavaScript is restricted (what happens to 3DS when JavaScript is disabled).
Two weeks out: freeze changes and set monitoring triggers
Agree a change freeze for the checkout and the authentication configuration. It should cover protocol version settings, timeout values, risk or routing rules that decide which transactions go through 3DS, and front-end changes to the payment page. Late changes to any of these are a common source of peak-day incidents.
Then set monitoring triggers. Aggregate success rates hide problems, so break the signals down by issuer, card scheme and channel.
|
Signal |
What it may indicate |
Pre-agreed action |
|
Rise in transStatus U, or reason codes 14 or 22, for one issuer’s card ranges |
That issuer’s ACS is degraded |
Apply the fallback policy for that issuer only; notify your provider |
|
Errors or timeouts across one card scheme |
Directory Server or connectivity problem |
Escalate to your 3DS Server provider; apply scheme-level fallback |
|
Authentication response times rising across many issuers |
Capacity limit on your side or your provider’s |
Escalate immediately; this is the scenario fallback cannot fix |
|
Challenge completion falling for one channel or browser |
Rendering or out-of-band problem |
Check challenge display and OOB flow; consider alternative payment prompt |
|
Authentication requests rising much faster than completed orders |
Possible card testing |
Tighten velocity controls before authentication; review the retry cap |
|
Authorisation declines rising on authenticated transactions |
Authentication data not reaching authorisation correctly |
Check the authentication-to-authorisation hand-off with your acquirer |
During the event
Keep watching individual issuers and schemes, because an aggregate rate can look normal while one ACS is failing. If one ACS degrades, apply the agreed fallback to that issuer’s cards and record when you switched it on and off. That record is what lets finance match later fraud chargebacks to the period when transactions went through without authentication.
Resist changing the policy on instinct. If the pre-agreed thresholds are being met, the policy is doing its job.
After the event
Hold a short review within a fortnight, then a second one once chargebacks have had time to arrive. Useful questions are which issuers degraded and for how long, how many transactions went through on a fallback path, how many of those later produced fraud chargebacks, and whether the retry cap and segment thresholds were set in the right place. Feed the answers into next year’s policy.
Frequently asked questions
Should merchants switch off 3D Secure during a sale to protect conversion?
Rarely as a blanket rule. Switching it off removes the authentication evidence that normally moves fraud liability for authenticated transactions to the issuer, and in markets that mandate strong customer authentication, issuers may decline unauthenticated payments. Fraud attempts also tend to rise with volume. A targeted fallback for specific issuers or segments, agreed in advance, usually serves conversion and risk better.
Does sending a payment for authorisation without authentication keep liability shift?
Generally no. Liability shift attaches to authentication outcomes under each card scheme’s rules. A transaction sent without authentication normally leaves fraud liability with the merchant. Treatment of attempted authentication differs by scheme and market, so confirm the rules with your acquirer.
Who should own the fallback policy?
Payments or ecommerce engineering usually operates it, but fraud and finance should approve it, because the policy decides how much fraud risk the business accepts in exchange for completed sales.
Getting your authentication stack ready
GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs, and merchants, and TestLabs is GPayments’ 3DS testing environment. If you want to review your fallback policy, card range handling, or failure-path testing before the November peak, speak with a GPayments 3DS specialist.