3-D Secure Authentication: Payment Outcomes, Liability and Merchant Controls

In a frictionless flow, the issuer’s authentication system can assess the supplied information without asking the cardholder to perform an additional visible action. In a challenge flow, further customer interaction is requested, such as a code or an action in a banking application. A challenge should not be equated automatically with a fraudulent customer.

EMVCo’s challenge documentation explains that the issuer’s Access Control Server can request further checks based on its assessment or relevant mandates. The merchant-side flow then needs to support that interaction and receive the outcome. The reason and available challenge method can vary; it is not a single universal OTP screen. [2]

Design the customer journey around the transition. Explain why the customer is moving to an authentication step, preserve the order context and provide a clear response if they return without completing it. Test the actual mobile and browser paths supported by the provider. A user abandoning an unfamiliar challenge presents a different operational question from an issuer declining an already authenticated payment.

Request the provider’s documented statuses for customer action, processing, failure, authorization, capture and final payment success. Map them to your order states explicitly. Do not treat an authentication callback or a return URL as the only basis for shipping goods or crediting an account.

Stripe’s authentication flow, for example, can require further customer action and then continue to a payment attempt after authentication. Its documentation distinguishes the authentication result from payment status. This is a Stripe implementation example, not a field-level specification for every PSP. [3]

Use the table below to map your provider’s actual states. Define who owns each unresolved status and what should happen after a timeout. If a browser session closes, the backend should still reconcile the provider’s authoritative result. Avoid blindly starting another charge when the first one may already have succeeded; use the provider’s approved retry and idempotency process.

Suppose 1,000 payment attempts enter your authentication flow. Of these, 700 complete without a visible challenge. Another 300 require a challenge, and 240 of those customers complete it. That gives you 940 authenticated attempts.

Now assume 900 of those attempts result in approved payments and 40 are declined. Your challenge-completion rate is 80%: 240 out of 300. Payment approval after authentication is about 95.7%: 900 out of 940. The share of the starting cohort that paid is 90%: 900 out of 1,000.

Each figure answers a different question. If challenge completion falls, investigate that customer journey. If authentication completes but payment declines rise, investigate the later decision. These are example numbers, not a performance benchmark. In your own reporting, define the cohort, period and payment status consistently and account for duplicate or delayed events before comparing results.

Successful authentication can be relevant to eligible fraud-dispute liability, but it does not guarantee liability shift for a particular payment. Stripe expressly describes conditions and exceptions and distinguishes eligible fraud disputes from other reasons such as goods not received. A successful payment event or authentication result alone is not a promise of protection. [3]

Keep the evidence appropriate to the actual complaint. Authentication information can help explain the cardholder-verification stage; it does not prove that the merchant delivered a purchased service, honoured a cancellation or issued a promised refund. Maintain order, delivery and support records separately.

Ask the provider how to identify the relevant authentication data and how it supports dispute handling. Record the payment reference and retain information through approved systems. A sales statement such as all 3DS transactions are protected should be replaced with a precise explanation of the applicable conditions. Do not remove ordinary customer-support or dispute-response procedures because authentication was successful.

A first payment made with the customer present and a later merchant-initiated collection are different events. Ask how the chosen provider sets up the payment method, records the recurring arrangement and handles a later request for customer authentication. Do not assume every renewal can display a challenge immediately while the customer is absent.

For a subscription, link billing state to the customer’s authorization and cancellation state. A retry process should respect that agreement and the provider’s instructions. Where customer action is required, provide an appropriate route to complete it rather than repeatedly sending an unchanged background request.

This is an integration-design checklist, not a universal legal conclusion about exemptions or recurring authentication rules. The applicable treatment depends on the transaction, markets, provider and network requirements. Use current documentation for the exact product and obtain specialist guidance where a regulatory interpretation is needed. Avoid describing non-3DS as a merchant entitlement or promising that an exemption will always be granted.

Include frictionless completion, challenge completion, failed challenge, abandonment, delayed return, issuer decline after authentication and duplicate notification in the test plan. Determine whether each case leaves an unpaid order, an order awaiting reconciliation or a confirmed payment. Assign an owner to the exceptions rather than leaving them in a generic failed bucket.

Test the customer journey on the actual devices and channels you intend to support. Out-of-band authentication may require switching to a banking application and returning. Check what happens if the original browser tab reloads or the session expires. Use provider-approved test tools and scenarios; never simulate live authentication failures by mishandling real customer credentials.

Keep a release checklist that connects the technical test to operational action. Support needs enough context to distinguish a challenge issue from a payment decline. Finance needs stable references for reconciliation. Fulfilment needs a documented payment state. Those three teams can otherwise interpret the same customer screenshot differently and create duplicate charges, unnecessary cancellations or unsupported delivery.

Add an exception record for an order that appears unpaid in the storefront but paid in the provider system. Record the order reference, payment reference, last authoritative status and next reconciliation action. Resolve the financial state before issuing another charge or cancellation. This recommendation is especially useful when a customer closes the challenge window and immediately tries again: the support team should investigate the existing attempt rather than assume the screenshot describes the final backend outcome.

Better authentication data and a clearer challenge journey may improve the operation, but a lower challenge rate alone is not proof of lower risk or better commercial results. Compare paid orders, relevant fraud outcomes, refunds, disputes and customer support alongside stage completion. Use compatible cohorts and note changes in card mix or traffic source.

Avoid claiming a measured improvement unless the data and method support it. A provider’s general statement about fraud reduction is not your business’s before-and-after result. Small samples and simultaneous checkout changes can make causal claims unreliable. Record what changed and what remains an inference.

3DS also does not replace card-data security duties. PCI SSC explains that merchants outsourcing processing still need to clarify shared responsibilities and confirm their validation obligations with the relevant compliance-accepting entity. [4] Keep authentication, account security, data handling and fulfilment controls connected operationally while recognizing that each addresses a different part of the payment lifecycle.