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

ModeWhen to useBehavior
AdaptiveEU/UK merchants, high-risk transactionsRuns 3DS on every payment. Accepts challenge or frictionless outcome.
FrictionlessLow-risk or returning customers, US and other non-PSD2 marketsRequests silent authentication. If approved, liability shifts. If challenge required, 3DS is skipped and payment proceeds without liability shift.
No 3DSRegions without 3DS requirements or adoptionSkips authentication entirely.

​
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.
Payment Type3DS Behavior
CardsPayNext triggers 3DS based on your workflow. Customer authenticates during checkout.
Apple Pay3DS embedded — customer authenticates with biometrics.
Google Pay (CRYPTOGRAM_3DS)3DS embedded — behaves like Apple Pay.
Google Pay (PAN_ONLY)Works like cards. PayNext runs 3DS on the raw card data.
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:
{
  "details": {
    "is_network_tokenized": true,
    "token_service_provider": "Google"
  }
}
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.
MethodLiability shiftRequirement
MIT exemptionNoNone
3RIYes (if authenticated)Successful 3DS on initial CIT

​
3RI (3DS Requester 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).
Payment Type3RI Support
CardsYes (network rules apply)
Apple PayNo — uses MIT exemptions
Google Pay (CRYPTOGRAM_3DS)No — uses MIT exemptions
Google Pay (PAN_ONLY)Yes (same rules as cards)
  • 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.

​
Payment Payload

Each payment includes a three_d_secure object with authentication results. If 3DS is skipped, this field is null. 
{
  "payment": {
    "id": "pay_123",
    "status": "authorized",
    "three_d_secure": {
      "transaction_id": "3d3e244f-9740-48c8-91af-43f4da039c18",
      "version": "2.2.0",
      "authentication_flow": "challenge",
      "electronic_commerce_indicator": {
        "value": "02",
        "result": "fully-authenticated",
        "liability_shift": true
      },
      "status": "success",
      "status_reason": null
    }
  }
}

​
Field Reference

FieldDescriptionValues
transaction_idDirectory server transaction ID3d3e244f-9740-48c8-91af-43f4da039c18
version3DS protocol version2.2.0
authentication_flowHow the customer authenticatedchallenge, frictionless
electronic_commerce_indicator.valueECI from issuer (see Reference)00–07
electronic_commerce_indicator.resultAuthentication resultfully-authenticated, attempted, not-authenticated
electronic_commerce_indicator.liability_shiftWhether liability shifted to issuertrue, false
statusAuthentication statussuccess, failure
status_reasonWhy authentication failed (see Reference)suspected-fraud

​
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:
ValueDescription
failed-authenticationCardholder did not provide correct 3DS details
card-not-enrolledCard is not enrolled in 3DS
suspected-fraudTransaction suspected to be fraudulent
invalid-acquirer-detailsAcquirer details invalid; update external 3DS settings
transaction-cancelled-by-cardholderCardholder cancelled the transaction
unsupported-3ds-version3DS version not supported
challenge-requiredChallenge required but workflow configured as frictionless
authentication-timed-outCustomer abandoned the flow
acs-unavailableAccess Control Server unavailable
directory-server-unavailableDirectory server unavailable
transient-system-failureTransient system failure during authentication
invalid-card-detailsCard details invalid
transaction-not-permittedSession configuration not permitted for this card
protocol-errorProtocol error during 3DS authentication
ECIMeaningLiability shift
00Not authenticatedNo
01Attempted (stand-in) authenticationYes
02Successful authenticationYes
04Data-only authenticationNo
06Transaction exempt from SCANo
07Recurring transaction authenticatedYes (initial only)
ECIMeaningLiability shift
05Successful authenticationYes
06Attempted (stand-in) authenticationYes
07Not authenticatedNo