Skip to main content
3D Secure (3DS) adds a verification step where customers authenticate with their bank before a payment is authorized. This reduces fraud, lowers chargebacks, and shifts liability to the issuer for authenticated transactions.

Why Use 3DS

The EU requires 3DS for online payments under ’s rules. Even in regions without mandates, 3DS reduces fraud and chargebacks while improving issuer approval rates.

How to Configure 3DS

PayNext uses its own external 3DS2 to generate processor-agnostic cryptograms. This lets you switch processors without re-authenticating customers.

3DS Modes

Set Up 3DS

1

Get acquirer credentials

Request BIN and Acquirer Merchant Identifier (CAID) from your payment processor representative.
2

Configure processor 3DS settings

Go to Dashboard → Integrations → [Processor] → 3DS and add the BIN, CAID, and Country for each network.
3

Enable in workflow

In your workflow, select Authorize payment → Configure and choose your 3D Secure mode.

Customer-Initiated Transactions (CIT)

CIT is the standard 3DS flow — the customer is present and completes authentication (challenge or frictionless) during checkout. The PayNext Web SDK handles this automatically based on your workflow settings. Workflows can trigger 3DS based on metadata, issuer country, currency, and other parameters. Successful CIT authentication is also required if you want to use 3RI for future recurring charges.
Enabling 3DS for Google Pay only affects PAN_ONLY payments — CRYPTOGRAM_3DS already includes 3DS. See Google Pay Card Parameters for details.
Check payment_method.details:
When token_service_provider is "Google", the payment used CRYPTOGRAM_3DS.

Merchant-Initiated Transactions (MIT)

MIT covers recurring charges, subscription renewals, and saved card transactions — the customer is not present and cannot complete a 3DS challenge. PayNext handles these with either MIT exemptions or 3RI.

3RI (3DS Requestor Initiated)

3RI authenticates recurring payments without customer interaction, providing liability shift when successful. It requires 3DS completion on the initial CIT and must meet network 3RI rules (see below).
  • Mastercard (SCA markets): 3RI succeeds only when MIT amount ≤ original CIT amount
  • Mastercard (other markets): Higher amounts often accepted, but varies by issuer
  • Visa: No amount restrictions
If 3RI is declined, PayNext falls back to MIT exemption.

Turn off 3RI for a processor

3RI is on by default for every processor that supports it. You can turn it off for a single processor, for example when that processor’s recurring charges perform better without 3DS.
1

Open the processor's 3DS settings

Go to Dashboard → Integrations → [Processor] → 3DS.
2

Turn off 3RI

Switch off 3DS Requestor Initiated (3RI) and click Save.
With 3RI off, recurring charges on that processor use the MIT exemption: they go out without 3DS and without liability shift. The change applies from the next charge.
  • No BINs required. The 3RI setting works whether or not you added BIN and CAID details for this processor. If you only change the 3RI setting, your 3DS network details stay as they are.
  • Per processor. If a recurring charge moves to another processor, for example after a decline, that processor’s own setting applies.
  • Customer-initiated payments are not affected. 3DS during checkout follows your workflow as before.
  • Not available on every processor. Processors without 3RI support, such as Unlimit and Nuvei, show the setting as off and locked. Check the 3RI Support row on each processor’s page.
  • Admins only. Other team members can see the setting but can’t change it.

Payment Payload

Each payment includes a three_d_secure object with authentication results. If 3DS is skipped, this field is null.

Field Reference

Failures

When 3DS authentication fails, the payment returns three_d_secure.status: "failure" with a status_reason. See Decline Codes for payment-level error handling.

Reference

status_reason explains why authentication failed when status is failure: