What Is 3D Secure? Authentication, Payment States and Liability

A customer approves a bank-app prompt and returns to checkout. That completes an authentication step, but the merchant still needs the payment’s actual financial outcome. The bank can decline authorisation, a manual capture can remain outstanding, or a network interruption can leave the result temporarily unknown.

Keep these events separate when designing the checkout and support process. Otherwise, a successful challenge can trigger premature fulfilment, or a lost browser response can prompt another charge for an order already paid.

What modern 3D Secure does#

EMV 3-D Secure is a protocol for authenticating cardholders in card-not-present transactions. It lets merchants, payment providers and issuers exchange authentication information. Customers may recognise network branding such as Visa Secure or Mastercard Identity Check.

The issuer assesses the available information. It can complete a frictionless authentication flow or request additional cardholder interaction through a challenge. That interaction may use a bank app, code or another issuer-supported method; not every card or transaction produces the same screen.

Frictionless and challenge flows#

A frictionless result does not mean the issuer did nothing. The assessment can finish without an additional visible customer prompt. A challenge adds an interactive step when the issuer requires it.

An exemption from authentication is different from frictionless authentication. A transaction can proceed under an accepted exemption without the same authentication evidence or liability treatment. Record the actual result supplied by the provider rather than inferring it from whether a modal appeared.

For a challenge, explain that the customer may need to use the issuing bank’s app or complete its prompt. Keep the amount, merchant and return path clear. Avoid adding an unrelated form that asks the customer to send authentication codes to merchant support.

Use supported EMV 3DS rather than a legacy fallback#

Use the provider’s currently supported EMV 3DS integration and confirm the supported versions and market requirements. Do not design a new production fallback around 3DS 1. Visa published a 3DS 1.0.2 sunset and migration notice for its covered markets, and current provider guidance directs legacy integrations toward modern payment flows.

If the issuer or authentication service is unavailable, follow the provider’s permitted treatment for that transaction. Depending on the applicable rules, that may mean requesting another method or declining the attempt. Do not assume that bypassing authentication is permissible whenever a challenge fails.

Apply SCA to the actual market and payment#

Strong Customer Authentication requirements in the EEA and UK do not mean every card payment worldwide must show a challenge. Determine the relevant parties, payment type and regulatory scope with your provider. Some in-scope transactions can use permitted exemptions, while other transactions can be outside scope.

Exemptions and out-of-scope treatment are different concepts. Low-risk exemption requests, properly classified merchant-initiated transactions and other cases have different conditions. Do not classify a customer-present payment as merchant-initiated just to avoid authentication.

An issuer can require authentication even when an exemption was requested. Your checkout must support the resulting customer action. For subscriptions or later off-session charges, obtain the appropriate agreement and payment-method setup, and provide a recovery path when the customer needs to return and authenticate.

Follow the existing payment’s state#

In Stripe’s PaymentIntent example, additional authentication can produce requires_action with a next_action. Complete the action for that existing payment object using the supported integration. A return to the merchant’s page is not by itself evidence that the payment succeeded.

Authentication retry and payment retry are not the same operation. A customer abandoning a prompt can require a resumable authentication experience. An authorisation request that timed out can already have produced a financial effect and needs outcome recovery first.

Worked recovery example#

Assume a customer is paying EUR 120 for one order. The bank-app authentication completes, but the browser loses its connection before the checkout receives a final status.

• Retrieve the original payment using its stored provider reference.
• If the provider confirms success, record the paid order and fulfil once.
• If the provider reports further action, resume the supported flow for that payment.
• If the financial outcome remains unknown, keep the order pending and query again or escalate.
• Create a different financial attempt only when the earlier outcome is resolved and cannot result in duplicate payment.

The EUR 120 is hypothetical. The control is to keep one order linked to its payment attempts. A new idempotency key or a different provider cannot guarantee that the first charge will not complete.

Understand liability shift without overpromising#

3DS can change liability for qualifying fraudulent-card disputes under the relevant card-network and provider rules. Check the recorded authentication result, transmitted data, applicable program and exceptions. Requesting 3DS or displaying a challenge does not itself establish a liability shift.

Successful authentication also does not protect against every dispute reason, such as disputes about delivery or service quality. Exemptions and other non-authenticated outcomes can have different fraud-liability treatment. Use the provider’s actual liability evidence for the transaction and retain the supporting payment records.

Do not replace fulfilment checks or fraud monitoring with a blanket “3DS protected” label. The transaction still needs valid authorisation, the right capture handling and normal customer support.

Keep backend confirmation and fulfilment consistent#

Use verified provider notifications and payment retrieval to reconcile the server-side outcome. Durably record a verified notification before acknowledging intake, then process it with a local transaction that links the event marker to the order update. Repeated notifications must not create a second fulfilment or duplicate ledger effect.

Keep the browser result useful for customer messaging, but let the authoritative payment record determine the order state. If the customer returns later, show the known outcome or resume the existing action rather than creating a new charge from a refreshed page.

Evaluate the checkout with meaningful cases#

• A frictionless outcome with no visible challenge.
• A successful challenge and return to checkout.
• A cancelled or failed authentication step.
• A requested exemption followed by an issuer authentication requirement.
• Authorisation that succeeds but awaits capture.
• A lost response and a repeated provider notification.

Assess those cases in the integration team’s appropriate test process using current provider guidance. This article does not claim a measured conversion or fraud improvement. Measure authentication completion, authorisation, paid orders and disputes separately for comparable traffic; a global benchmark cannot explain a specific checkout failure.

The useful result is a checkout that asks for authentication when required, tells the customer what to do and preserves the financial state afterward. Authentication should support a safe payment flow rather than become a reason to mark an uncertain order paid or charge it again.