Skip to content

3D Secure authentication

US only

3D Secure is currently supported for US-based merchants only. Canada support is coming soon.

Verify that your buyer is the real cardholder before you charge their card.

3D Secure (3DS) is a card authentication protocol that adds a verification step between your buyer and their issuing bank. Before the payment is authorized, the buyer confirms their identity with a one-time passcode, a biometric prompt, or their banking app.

The card networks brand the protocol under their own names: Visa Secure, Mastercard Identity Check, Discover ProtectBuy, and American Express SafeKey. The underlying protocol is the same for all four. Finix supports 3DS2 (EMV 3-D Secure), the current version.

Why use 3D Secure

  • Reduced fraud: The buyer proves their identity to their bank before the payment is authorized, which stops most unauthorized card-not-present payments.
  • Reduced fraud liability: When a payment authenticates successfully, card network rules can shift liability for fraud chargebacks to the issuing bank. 3DS does not prevent disputes — see 3D Secure liability shift for what shift does and does not cover.
  • Regulatory compliance: 3DS is the standard way to meet Strong Customer Authentication requirements, which are mandatory in several regions.

How 3D Secure works

Every Finix-managed 3DS payment begins with a 3D Secure Session, which holds the authentication for a single payment. You create the session before you submit the payment, and then reference it on the resulting Transfer or Authorization. If you authenticate with your own vendor, use the passthrough integration instead.

3DS session pipeline

The issuer decides how much verification each payment needs, so some buyers complete a challenge and others are authenticated in the background without seeing one.

3D Secure Session webhooks

Finix sends a webhook when a session changes state. Subscribe to it and treat it, not the browser, as the record of what happened.

The round trip through the buyer's browser is the part of this flow you don't control. Buyers close the tab mid-challenge, lose connectivity, or never come back. The webhook tells your server how the authentication ended in every one of those cases. For sample event payloads, see 3D Secure Session created and 3D Secure Session updated. For general webhook setup, see Integrating into Webhooks.

Best practices

  • Authenticate the exact amount you charge. If the total changes after you create the session, because of a tip, a shipping choice, or a discount code, create a new session for the new amount. A mismatch downgrades the liability shift even when the payment succeeds.
  • Create the session when the buyer is ready to pay. Sessions expire five minutes after creation. A session that runs out while the buyer is still on the challenge fails with AUTHENTICATION_TIMED_OUT, and the buyer needs a new one.
  • Use each session once. Submitting a second Transfer or Authorization against a session that has already been used returns a 422.
  • Decide what a FAILED session means for you. Finix does not block a payment that references one. Avoid sending authentication data from a failed authentication, because the failure is itself a fraud signal. We recommend creating a new session, asking the buyer for another payment method, or submitting the payment without 3D Secure and accepting that liability stays with you.

Choose your integration

3D Secure using Finix.js

Render the challenge inside your own checkout page.

3D Secure using the Finix API

Send the buyer to a hosted page, with no Finix code in your checkout.

3D Secure Passthrough

Pass authentication values from your own 3D Secure vendor to Finix.

3D Secure Liability Shift

Understand how authentication outcomes determine chargeback liability.