3D Secure
Add issuer authentication to card payments while DEUNA keeps the payment lifecycle consistent.
On this page
3D Secure (3DS) authenticates a cardholder with the issuing bank before a card payment continues. DEUNA makes that authentication part of the same payment flow, whether DEUNA manages the 3DS experience or the selected payment provider supplies its supported 3DS flow.
How a 3DS payment works#
The issuer chooses the authentication experience:
Authentication success is not payment success. It allows authorization to continue. Always evaluate the final payment status after the 3DS step.
Supported 3DS models#
DEUNA-managed 3DS
DEUNA coordinates authentication and passes the result into the payment authorization. This gives merchants one integration and one shopper-action contract across compatible acquiring connections.
Use this model when you want DEUNA to manage the authentication journey and keep the checkout behavior consistent across providers.
Provider-managed 3DS
Some payment providers expose their own 3DS flow through their DEUNA connection. DEUNA normalizes the required customer action into the payment response and continues the payment when authentication finishes.
Support varies by provider, country, card network, and connection configuration. Use the live payment gateway catalog to verify advertised 3DS capabilities, then confirm enablement with your DEUNA Technical Account Manager (TAM).
Where it works#
| Integration | Shopper experience | Merchant responsibility |
|---|---|---|
| Payment Widget | DEUNA presents the challenge inside the supported widget experience or redirect. | Listen for the widget result and confirm the final payment status. |
| Payment Link | DEUNA presents and completes the supported authentication experience. | Configure the return experience and consume the final status or webhook. |
| Direct API | The payment response returns pending_3ds and an authorization_3ds next action when the shopper must act. | Present the next action with a DEUNA SDK or follow the returned URL, then reconcile the final status. |
| Payment Vault | A saved card payment can return the same 3DS next action. | Use initNextAction in a supported SDK or implement the returned action safely. |
Data that improves authentication#
Complete, truthful shopper and device data helps the issuer make a better risk decision and can increase the chance of a frictionless result.
| Data group | Recommended fields |
|---|---|
| Payment | Amount, ISO 4217 currency, card or card token, and merchant reference |
| Shopper | First name, last name, email, and phone number |
| Billing address | Address line, city, postal code, ISO 3166-1 alpha-2 country, and ISO 3166-2 state code when applicable |
| Order | Item description, quantity, amount, and shipping context when available |
| Device | Device/session identifier, IP address, user agent, browser language, screen dimensions, color depth, and time zone |
Do not send placeholders. For the United States, Canada, and China, send a valid ISO 3166-2 subdivision code when the address includes a state or province. Address enrichment may be available for selected account configurations, but the merchant remains responsible for collecting accurate checkout data.
Status and liability guidance#
pending_3dsmeans authentication is incomplete and the payment is unresolved.processedorauthorizedmeans the payment continued successfully after authentication.denied,cancelled, orexpiredmeans the payment did not complete.- A successful authentication can provide fraud-liability benefits, but eligibility depends on the card network, ECI, authentication value, transaction type, market rules, and dispute reason. Do not infer liability shift from the payment status alone.
See Payment Workflow & Statuses for the complete lifecycle and 3DS purchase flow for the API integration.