3DS transactions

3DS (3D Secure) is an authentication protocol that adds an additional layer of verification for card payments. When triggered, it requires the cardholder to confirm their identity with their bank before the payment is authorized.

Frictionless vs. challenge flow

3DS can resolve in one of two ways, depending on the risk assessment performed by the cardholder's bank.

Frictionless flow — the bank approves the payment silently without requiring any action from the customer. The customer is not redirected to the ACS/Issuer. The payment resolves immediately, and the final status is delivered to your ipnUrl. No customer interaction is required.

Challenge flow — the bank requires the customer to verify their identity (for example, via a one-time code, biometric confirmation, or a password). The gateway returns a challenge URL in the payment response. You redirect the customer to that URL to complete the verification.

How to detect which path occurred:

Challenge flow

1. You submit the payment request to POST /payment, including redirectUrl and ipnUrl in the request body.
2. The gateway returns a 3DS challenge URL in the response.
3. You redirect the customer to the 3DS challenge URL.
4. The customer completes the 3DS challenge with their bank.
5. The bank redirects the customer back to the gateway.
6. The gateway redirects the customer to your redirectUrl with an is_approved query parameter.
7. The gateway receives the final result from the payment provider.
8. The gateway sends the final payment status to your ipnUrl via IPN callback.

Interpreting the redirect parameters

The is_approved parameter in your redirectUrl at step 6 gives you an early signal, but it does not represent the final payment status.

📘

Note

Always use the IPN callback as the source of truth for the final payment status. The is_approved redirect parameter is an early indicator only. Do not fulfil orders based on it alone.