Configure 3DS
Enable 3DS on a connection and place it in the payment strategy.
On this page
Configure 3DS in four layers: eligibility, connection, payment strategy, and shopper experience.
1. Confirm eligibility#
Before changing production configuration:
- Check the connection in the payment gateway catalog.
- Confirm the countries, card networks, currencies, and transaction operations in scope.
- Ask your DEUNA TAM to confirm whether DEUNA-managed 3DS, provider-managed 3DS, or both are available for the connection.
- Confirm whether the issuer challenge can be embedded or requires a top-level redirect.
2. Choose the authentication model#
Your merchant application uses the same pending_3ds and next_action contract for both models. Do not use provider identity to decide how checkout behaves.
Information required for DEUNA-managed 3DS
The exact fields depend on the acquiring connection. Be ready to provide:
| Configuration | Description |
|---|---|
| Merchant identifier | The merchant or affiliation identifier registered with the acquirer. |
| Acquirer BIN | The acquiring bank identifier assigned to the merchant setup, when required. |
| Merchant name and URL | The customer-facing name and secure website URL registered for card acceptance. |
| Merchant category code | The MCC assigned to the merchant account. |
| Country | The merchant country as an ISO 3166-1 alpha-2 code. |
Treat these values as connection configuration. Do not send them from the browser or hard-code them into your client application.
3. Enable 3DS on the connection#
- In DEUNA Admin, open Connections.
- Select the payment gateway used by the strategy.
- Open the connection settings and enable the supported security method.
- Select the agreed 3DS model and complete the requested merchant/acquirer fields.
- Save the connection, then reopen it and verify that 3DS remains active in the target environment.
Connections
Discover and manage payment, wallet, and anti-fraud integrations.
| Connections | Type | Status | Action |
|---|---|---|---|
| Adyen | Payment gateway | Connected | |
| Worldpay | Payment gateway | Connected | |
| PayPal | Payment method | Connected | |
| Mercado Pago | Payment method | Not connected | |
| Riskified | Anti-fraud engine | Not connected |
Connection labels and available fields can differ by provider. The DEUNA capability remains the same: checkout receives a normalized payment state and next action.
4. Apply the payment strategy#
Enabling 3DS on a connection does not by itself define when it should run. In Payment strategies, confirm:
- which card traffic routes through the 3DS-capable connection;
- whether authentication is always requested or selected by strategy rules;
- what happens after authentication succeeds, fails, or cannot be completed;
- whether retry routing preserves a valid authentication result for a compatible next attempt.
Payment strategies
Configure default processing and rules for each payment flow.
Default processing
Configure default processing and rules for each payment flow.
| Rule | Routing | Status | Action |
|---|---|---|---|
| Default processing | Adyen → Worldpay | Active |
Specific rules
Configure default processing and rules for each payment flow.
| Priority | Rule | Conditions | Routing | Status |
|---|---|---|---|---|
| 1 | High-value orders | Amount over USD 100 | Adyen → Worldpay | Active |
See Payment strategies for default, conditional, retry, and risk-routing behavior.
5. Choose the shopper experience#
| Product | Recommended implementation |
|---|---|
| Payment Widget | Let the widget present the supported embedded or redirect challenge and return its lifecycle events. |
| Payment Link | Let the hosted experience present authentication and use the configured return URL. |
| Direct API | Prefer a supported DEUNA SDK initNextAction flow. Otherwise, use the returned challenge URL and honor the required presentation mode. |
| Native app | Open the DEUNA next action in the supported SDK or a secure system web view. Preserve the app return/deep-link path. |
Never assume every issuer page can be embedded. Browser security headers, issuer policy, connection support, and account configuration can require a top-level redirect.
See embedded 3DS experiences
When the issuer and payment connection allow an embedded challenge, the customer can authenticate without leaving the DEUNA payment surface. These examples show the presentation in Payment Link and Payment Widget:
The videos demonstrate the customer presentation, not the payment result. Keep the payment unresolved during authentication and verify its final state through the API or a verified webhook.
6. Production-readiness checklist#
- Test a frictionless result and verify that no unnecessary shopper step appears.
- Test a challenge and verify completion, cancellation, back navigation, and app/browser return behavior.
- Keep
pending_3dsunresolved while the shopper is authenticating. - Handle challenge expiration and a final
denied,cancelled, orexpiredstatus. - Reconcile asynchronous provider changes through the supported DEUNA webhook processing model and the Get order endpoint.
- Make fulfillment depend on a successful final payment status, not on the challenge screen closing.
- Confirm the configured sandbox scenarios with your DEUNA TAM; test behavior can vary by 3DS model and payment connection.
Continue with 3DS purchase flow to implement the API and customer-action lifecycle.