3-D Secure

The system provides flexible 3-D Secure integration options that let you choose the approach best suited for your use case. Each method handles Strong Customer Authentication (SCA) with varying levels of control and customization. Most integrations automatically handle the device fingerprinting, card enrollment checks, authentication, challenge, and other 3DS nuances. Additionally, the system supports Dynamic 3-D Secure, allowing you to dynamically skip or force 3-D Secure based on anti-fraud decisions, cart items, or any other transaction-level data. To authenticate only when the issuer requires it, add a Flow rule that skips 3-D Secure. Gr4vy still runs 3-D Secure for issuers with a known mandate. The flexible solution offers the following 3-D Secure integration methods.

• Embed automatically detects 3-D Secure for a transaction and handles all the user interactions to complete the transaction.
• Hosted 3DS offers 3-D Secure via the API, allowing capture of card data that then relies on the hosted 3-D Secure to handle the user interaction. This can also be used in combination with Secure Fields.
• Native 3DS provides a fully customizable 3-D Secure experience built directly into your app. Available for web (Secure Fields), iOS (Swift), and Android (Kotlin). Requires merchant account-level 3DS configuration.
• External 3-D Secure data can be passed in to create a card checkout experience including a custom 3-D Secure integration.

Except for External, each method needs 3DS to be set up first. Native 3DS requires a merchant account configuration. If you route transactions to more than one connection, also see 3DS with multiple connections. Whichever method you use, the authentication result follows the same set of values. See Authentication results for the full reference. To control what happens when 3-D Secure can’t complete, see 3-D Secure outcomes.

​

Authentication and capture

3-D Secure authenticates the buyer. It doesn’t capture the payment. The transaction’s intent controls capture. With an intent of authorize, call the capture endpoint once the transaction reaches authorization_succeeded, including after a 3-D Secure redirect or challenge.

​

Store a card with 3-D Secure

3-D Secure runs as part of a transaction. Creating a payment method with the create payment method endpoint doesn’t run 3-D Secure, and neither does storing a card in a checkout session. To authenticate a card when you store it, create a transaction with an amount of 0 and store set to true, for example through Embed or Secure Fields.

​

Failed authentication

When the authentication result is N, the buyer failed authentication or the issuer denied the transaction. Gr4vy declines the transaction without sending it for authorization, so the buyer’s bank shows no failed payment. The buyer can try again or use another card. The exception is N with reason 87, which means the card is excluded from attempts processing. With Attempt 3DS, continue if not enrolled, the transaction continues without 3-D Secure. With Force 3DS, decline if not enrolled, it’s declined. See 3-D Secure outcomes for each case.

​

Issuer-mandated 3-D Secure

Some card issuers require Strong Customer Authentication (SCA) on every transaction, regardless of your own 3-D Secure preferences. This is common for issuers in the European Economic Area (EEA) and the United Kingdom under the Second Payment Services Directive (PSD2). Some issuers in other regions apply equivalent mandates. To reduce authorization declines on these cards, Gr4vy identifies issuers with a known authentication mandate using bank identification number (BIN) data. When the issuer requires authentication, Gr4vy runs 3-D Secure even if a Flow rule would otherwise skip it. The behavior depends on the transaction’s resolved 3-D Secure outcome.

• No rule matches, or no 3-D Secure rule is configured. Gr4vy attempts 3-D Secure. This is unchanged from the standard behavior.
• A rule skips 3-D Secure. For an issuer with a known mandate, Gr4vy overrides the rule and attempts 3-D Secure instead. Cards without a known mandate continue to skip.
• A rule forces 3-D Secure. Gr4vy forces 3-D Secure for all cards. This is unchanged.

When the issuer’s authentication requirement can’t be determined — for example, the BIN isn’t present in the dataset — Gr4vy treats the card as having no mandate and follows your configured behavior. Issuer mandates never override a connection with 3-D Secure turned off: in that case Gr4vy doesn’t run 3-D Secure, even for a mandated issuer. An overridden skip rule is still recorded as having matched, so Authentication Insights continue to reflect the rule that applied.

​

Digital wallets

Gr4vy doesn’t run 3-D Secure for Apple Pay, Paze, and Google Pay device tokens. The wallet authenticates the buyer, and the payment carries a cryptogram instead of a 3-D Secure result. Google Pay can also return a card saved in the buyer’s Google Account (PAN_ONLY) rather than a device token (CRYPTOGRAM_3DS). Gr4vy processes these cards like any other card, so 3-D Secure can apply. See 3-D Secure with Google Pay.

​

Challenge language

The issuer’s access control server (ACS) shows the 3-D Secure challenge and decides which language to use. In browser-based flows, Gr4vy passes the buyer’s browser language to the issuer. Gr4vy’s iOS and Android SDKs don’t set a language. You can’t set the challenge language through the API or the SDKs, and an issuer that doesn’t support the buyer’s language shows the challenge in a language of its choice.