> ## Documentation Index
> Fetch the complete documentation index at: https://funnelfox.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 3DS authentication

> Choose between Adaptive 3DS and Always run 3DS, and require authentication on EEA and UK card payments.

3D Secure (3DS) asks customers to confirm a payment with their bank, for
example with a one-time code. It reduces fraud, but some customers drop off at
the challenge.

Customer-initiated card payments usually have a higher acceptance rate without
3DS. Add it only where the law or the card issuer requires it.

FunnelFox Payments offers two options:

* [Adaptive 3DS](#adaptive-3ds): Runs 3DS only when the
  PSP (Payment Service Provider) declines a payment
  because authentication is required.
* [Always run 3DS](#always-run-3ds): Runs 3DS before every authorization.

## Choose your 3DS setting

Your setting depends on where the card is issued and where your merchant
account is.

The merchant account is the acquirer that authorizes the payment.
Where your company is registered doesn't matter.

| Card issued in | Merchant account in | SCA (Strong Customer Authentication) | Recommended setting |
| - | - | - | - |
| EEA or UK | EEA or UK | Mandatory | Always run 3DS |
| EEA or UK | Outside the EEA and UK (for example, Stripe US or Airwallex SG) | Not mandatory; the issuer decides | Adaptive 3DS |
| Outside the EEA and UK | Any | Not required | Keep your current setting |

SCA is mandatory for customer-initiated payments only when both the card and
the merchant account are in the EEA or the UK. PSD2 sets this rule in the EEA,
and equivalent rules apply in the UK. If your merchant account is elsewhere,
the issuer decides whether to ask for authentication, and Always run 3DS adds a
challenge the issuer didn't ask for.

You pick the setting in the **Authorize payment** block of your Primer workflow:

| Setting | What it does | For EEA and UK cards through an EEA or UK merchant account |
| - | - | - |
| **Always run 3DS** | Authenticates the customer before every authorization | Recommended |
| **Adaptive 3DS** | Authorizes without 3DS first, and runs 3DS only after the issuer declines | Not suitable: authentication isn't upfront |
| **Processor 3DS** | The processor decides on and runs 3DS; Primer doesn't get the result | Works, but you have no visibility or control in Primer |
| **No 3DS** | No authentication | Not suitable: SCA is mandatory. Fine for renewals and network-tokenized wallets |

> [!NOTE]
>
> Renewals are merchant-initiated, so SCA doesn't apply to them. They stay on
> **No 3DS**.

> [!TIP]
>
> In some markets, issuers are used to 3DS, and it can perform better than no
> 3DS. Examples include Brazil, Saudi Arabia and other Gulf countries, India,
> Japan, Turkey, South Africa, Mexico, and parts of Southeast Asia. Results differ
> by merchant, so test 3DS against no 3DS on part of that traffic before
> switching.

## Adaptive 3DS

Adaptive 3DS is disabled by default and runs 3DS only when a payment needs it:

1. FunnelFox Payments attempts the payment without 3DS.
2. If it's approved, the customer pays instantly.
3. If the PSP declines it because authentication is required, FunnelFox
   Payments runs 3DS and retries.
4. The customer completes the challenge, and the payment goes through.

Hard declines, such as a reported stolen card, aren't retried.

> [!NOTE]
>
> Card [payment cascading](https://funnelfox.com/docs/billing/payments-retries.md#payment-cascading) requires
> Adaptive 3DS. The backup processor reuses the 3DS result from the first
> attempt, so the customer doesn't authenticate twice.

## Always run 3DS

Always run 3DS authenticates the customer before every authorization. If
authentication fails, Primer declines the payment, so you don't need extra
blocks after authorization.

Use it only for EEA and UK cards through an EEA or UK merchant account. A
condition in your Primer workflow sends these cards to Always run 3DS, and all
other payments keep their current setting.

## Setup

Both options use the same 3DS profile: the merchant details Primer needs for
each card network. You set it up once.

* **Adaptive 3DS**: Complete steps 0 and 1.
* **Always run 3DS**: Complete all steps.

Steps that don't apply to everyone say when to skip them.

### 0. Prepare Stripe account

Skip this step if you don't process through Stripe, or if your Stripe account
is on IC+ pricing.

Complete this step before you request the profile. The request in step 1
needs your acquirer BIN and MID, and Stripe shares them only with accounts on
IC+ pricing. On standard pricing, choose one option:

1. Switch to IC+ pricing, then continue with step 1.
2. Use a profile from another processor you have, such as Adyen. Ask your
   Solution Manager to make it your default profile. Both processors must use
   the same MCC. Liability shift still applies, but issuers may ask for a
   challenge a bit more often. If you don't have that profile yet, request it
   for that processor in step 1.
3. Keep **Processor 3DS** on Stripe for EEA and UK cards. Stripe handles SCA,
   but you don't see the 3DS result in Primer. Skip the remaining steps for
   Stripe payments.

### 1. Request 3DS profile

Request the profile from your FunnelFox Payments dashboard, or ask your
Solution Manager to request it for you.

> [!NOTE]
>
> The profile request is labeled **Adaptive 3DS**, though you use it for Always
> run 3DS too.

1. Go to the **Payment Features** page.

2. Click **Request** to the right of **Adaptive 3DS**.

![](https://mintcdn.com/funnelfox/6CBITcnEuzL_DGAW/assets/3ds-request.png?fit=max\&auto=format\&n=6CBITcnEuzL_DGAW\&q=85\&s=3d59f200e93ca377c4cb6ac368441911)

3. Complete the form:

* **Primer Organization ID**: Find it in the
  [Primer Dashboard](https://dashboard.primer.io/settings/organisation) under
  **Settings > Organisation**.

* **Processor**: The processor this profile applies to (for example,
  Stripe, Adyen, or Airwallex). For a processor that isn't listed, select
  **Other** and enter its **Processor name**.

* **Merchant Account**: Find it in the
  [Primer Dashboard](https://dashboard.primer.io/integrations) under
  **Integrations > \[processor] > Merchant Account**.

* **Display Name**: Name for the 3DS profile.

* **Merchant Name**: Name shown in the authentication window.

* **Merchant URL**: A bare domain like `example.com` is fine.

* **Country Code**: ISO 3166-1 alpha-2, for example `US`.

* **MCC**: Merchant Category Code, exactly 4 digits, for example `5734`.

* **Card Networks**: Select at least one. For each selected network, enter:
  * **MID**: Processor Merchant Account ID
  * **Acquirer BIN**

![](https://mintcdn.com/funnelfox/6CBITcnEuzL_DGAW/assets/3ds-form.png?fit=max\&auto=format\&n=6CBITcnEuzL_DGAW\&q=85\&s=f1bd2843d5524e22383cdadbfeb36470)

4. Click **Submit Request**.

If you use only Adaptive 3DS, setup is complete after this step.

### 2. Update card workflow

Skip steps 2 to 4 if you use only Adaptive 3DS.

EEA and UK cards go to Always run 3DS, for both trial authorizations and
regular charges. Other cards and renewals stay as they are.

**1. Open your card workflow**

Go to the **Workflows** page in your Primer dashboard, open the workflow for
card payments, and click **Edit workflow**.

![](https://mintcdn.com/funnelfox/BikRBDBNvzjNaqdb/assets/3ds-edit-workflow.png?fit=max\&auto=format\&n=BikRBDBNvzjNaqdb\&q=85\&s=23f5a376e63126efc86187fb8891aae0)

**2. Add the EEA and UK condition**

In the match branch of your customer-initiated condition, insert a
condition on **Issuer country code** with the EEA and UK country list. It
must sit above the free-trial check (**Should auto cancel?** on
`Metadata.ff_auto_cancel`), because the first payment saves the card for
renewals and needs SCA too.

> **EEA and UK country list**
>
> Use the operator **One of** with these 31 codes: the 27 EU countries,
> Iceland, Liechtenstein, Norway, and the United Kingdom.
>
> ```
> AT,BE,BG,HR,CY,CZ,DK,EE,FI,FR,DE,GR,HU,IE,IT,LV,LT,LU,MT,NL,PL,PT,RO,SK,SI,ES,SE,IS,LI,NO,GB
> ```
>
> > [!WARNING]
> >
> > Conditions run top to bottom and stop at the first match. If your
> > workflow already splits by country, for example by tier-1 countries or
> > per-market routing, place the EEA and UK condition above those splits.
> > Otherwise, a broader country group catches EEA cards first.

![](https://mintcdn.com/funnelfox/BikRBDBNvzjNaqdb/assets/3ds-cards-condition-eea.png?fit=max\&auto=format\&n=BikRBDBNvzjNaqdb\&q=85\&s=f3230dab6c28c2e4abda597eb194a6e0)

**3. Add the free-trial check**

In the match branch of the new condition, add a **Should auto cancel?**
condition on `Metadata.ff_auto_cancel`.

![](https://mintcdn.com/funnelfox/BikRBDBNvzjNaqdb/assets/3ds-cards-autocancel.png?fit=max\&auto=format\&n=BikRBDBNvzjNaqdb\&q=85\&s=f09b70dd0445b36ea94b3bfca3260936)

**4. Add two Authorize payment blocks**

Add an **Authorize payment** block to each branch of the free-trial check.
Copy the processor and settings from your existing blocks, and set 3DS to
**Always run 3DS**.

![](https://mintcdn.com/funnelfox/BikRBDBNvzjNaqdb/assets/3ds-cards-authorize-blocks.png?fit=max\&auto=format\&n=BikRBDBNvzjNaqdb\&q=85\&s=4f2e4c5f0ecc9efb4538a44b2604e0e2)

**5. Connect the remaining traffic**

Connect **All other conditions** of the EEA and UK condition to your
existing free-trial check. Leave the renewal branch unchanged.

**6. Save the workflow**

Click **Save**.

### 3. Update Google Pay workflow

Skip this step if you don't accept Google Pay.

Google Pay payments come in two types, and only one needs 3DS:

* **Network-tokenized**: The card is added to Google Wallet on an Android
  device. The payment is authenticated on the device, carries a cryptogram, and
  stays on **No 3DS**.
* **PAN-only**: The card is saved in a Google account, typically used on
  desktop or a non-Android browser. The payment has no authentication, so PSD2
  treats it as a regular card payment.

Only PAN-only payments with EEA and UK cards go to Always run 3DS.

![](https://mintcdn.com/funnelfox/BikRBDBNvzjNaqdb/assets/3ds-google-workflow.png?fit=max\&auto=format\&n=BikRBDBNvzjNaqdb\&q=85\&s=116d1b538a7eb08fce774e56f07b956d)

**1. Open your Google Pay workflow**

Go to the **Workflows** page in your Primer dashboard, open the workflow for
Google Pay, and click **Edit workflow**.

**2. Add the EEA and UK conditions**

In the free-trial branch, find the **Is Network Tokenized** condition. In
its **All other conditions** branch, insert a condition on **Issuer country
code** with the EEA and UK country list. Repeat in the regular-charge
branch.

> **EEA and UK country list**
>
> Use the operator **One of** with these 31 codes: the 27 EU countries,
> Iceland, Liechtenstein, Norway, and the United Kingdom.
>
> ```
> AT,BE,BG,HR,CY,CZ,DK,EE,FI,FR,DE,GR,HU,IE,IT,LV,LT,LU,MT,NL,PL,PT,RO,SK,SI,ES,SE,IS,LI,NO,GB
> ```
>
> > [!WARNING]
> >
> > Conditions run top to bottom and stop at the first match. If your
> > workflow already splits by country, for example by tier-1 countries or
> > per-market routing, place the EEA and UK condition above those splits.
> > Otherwise, a broader country group catches EEA cards first.

![](https://mintcdn.com/funnelfox/BikRBDBNvzjNaqdb/assets/3ds-google-condition-eea.png?fit=max\&auto=format\&n=BikRBDBNvzjNaqdb\&q=85\&s=6c2ccec498939b96d4a339995d15e664)

**3. Add two Authorize payment blocks**

In the match branch of each new condition, add an **Authorize payment**
block. Copy the processor and settings from the existing block in the same
branch, and set 3DS to **Always run 3DS**.

![](https://mintcdn.com/funnelfox/BikRBDBNvzjNaqdb/assets/3ds-google-authorize.png?fit=max\&auto=format\&n=BikRBDBNvzjNaqdb\&q=85\&s=92632dd571582d0f04db8c4543567ccd)

**4. Connect the remaining traffic**

Connect **All other conditions** of each new condition to the existing
**Authorize payment** block in that branch. Leave the network-tokenized and
renewal branches unchanged.

**5. Save the workflow**

Click **Save**.

### 4. Leave Apple Pay workflow unchanged

No action is needed. Customers confirm each Apple Pay payment on their device
with Face ID, Touch ID, or a passcode, and the payment carries a network
cryptogram. Together, these satisfy SCA.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.