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

# Enable local card schemes with Primer

> Learn how to enable local card schemes through co-badged cards using Primer.

## Overview

Primer lets you support **local card schemes through co-badged cards**, without redesigning your checkout or building custom logic.

You keep a single card form.\
Primer handles detection, selection, and routing, while helping you stay compliant with local regulations.

This page explains:

* where co-badged cards are supported in Primer
* which platforms and integrations are compatible
* how to enable co-badged cards in your integration

***

## How Primer supports co-badged cards

At a high level, Primer allows you to:

* detect all card networks available on a card
* define which networks you want to accept
* control network preference and defaults
* let the shopper choose when regulations require it
* pass the selected network to your processor

***

## Primer platform compatibility

The table below shows where co-badged card handling is supported across Primer platforms.

| Platform | Compatibility |
| - | - |
| Web Drop-in | ❌ |
| Web Headless | ✅ |
| Web Primer Checkout (Components) | ✅ |
| iOS Drop-in | ✅ |
| iOS Headless | ✅ |
| Android Drop-in | ✅ |
| Android Headless | ✅ |
| React Native Drop-in | ✅ |
| React Native Headless | ❌ |

***

## Supported integrations and compatibility

The integrations listed below are **fully compatible** with co-badged cards in Primer.

“Fully compatible” means:

* the local card scheme is supported by the processor
* the integration works with Primer’s **agnostic 3DS**
* end-to-end routing and compliance requirements are covered

Other integrations may allow payments via local schemes but are not listed here, as they are **not yet fully compatible with processor-level 3DS flows**.

> [!NOTE]
>
> If you have a question or a project involving local card schemes, contact your Customer Success Manager or reach out to Primer Support.

### Cartes Bancaires (France)

Cartes Bancaires (CB) is the domestic card network in France.

More than **95% of CB cards are co-badged** with Visa or Mastercard.\
This means the same card can be processed on:

* the Cartes Bancaires network, or
* the Visa or Mastercard networks

When processing co-badged cards in the EEA, merchants must allow shoppers to **select the network** they want to use at checkout.

#### Supported integrations

* MONEXT
* Adyen
* Stripe
* Checkout.com
* Payplug

> [!NOTE]
>
> **Monext: 3DS card brand identifier**
>
> When processing 3DS authentication via Monext, the `cardBrand` field in the 3DS authentication data returns `"CB"` for all card types, including Visa and Mastercard. This is expected Monext behavior — in the French payments ecosystem, "CB" is used as a generic identifier covering Cartes Bancaires, Visa, and Mastercard under the co-badging scheme. The actual card network is determined separately during the payment flow and is not affected by this value.

### eftpos (Australia)

eftpos is the domestic debit card network in Australia.

More than **90% of eftpos cards are co-badged** with Visa or Mastercard, which means they can be processed through either network depending on configuration and routing.

> [!NOTE]
>
> Non co-badged eftpos cards (also known as “proprietary eftpos cards”) are only supported for in-person payments and cannot be used for online transactions.

#### Supported integrations

* Worldpay

***

## Process to enable local card schemes

### Step 1 – Enable local schemes with your processor

Before enabling co-badged cards in Primer, make sure that:

* the local card scheme is enabled on your processor account
* the scheme supports **online card payments**
* your merchant account is correctly configured for the relevant region

> [!NOTE]
>
> If the local scheme is not enabled at processor level, Primer cannot reliably route payments to it, which may result in inconsistent scheme routing or failed payments.

### Step 2 – Allow card networks in the client session

Co-badged card behaviour is controlled from the **client session**.

When creating a client session, define which card networks you want to accept using
`orderedAllowedCardNetworks`.

```json theme={"dark"}
// POST /client-session
{
  "paymentMethod": {
    "orderedAllowedCardNetworks": [
      "EFTPOS",
      "VISA",
      "CARTES_BANCAIRES",
      "MASTERCARD"
    ]
  }
}
```

This configuration:

* defines which card networks are accepted
* defines the default preference order

#### Supported card network identifiers

Use the following identifiers when configuring `orderedAllowedCardNetworks`:
`VISA`, `MASTERCARD`, `AMEX`, `MAESTRO`, `UNIONPAY`, `CARTES_BANCAIRES`, `DANKORT`,\
`EFTPOS`, `DINERS_CLUB`, `DISCOVER`, `ENROUTE`, `ELO`, `HIPER`, `INTERAC`, `JCB`, `MIR`, `OTHER`

> [!NOTE]
>
> Network availability depends on your processor and region.

#### How network preference works

The order of `orderedAllowedCardNetworks` matters.

Primer uses this order to:

* select a **default network** when a card is co-badged
* fall back automatically if the shopper does not make a choice

##### Example

```json theme={"dark"}
["CARTES_BANCAIRES", "VISA", "MASTERCARD"]
```

* CB + Visa card → defaults to Cartes Bancaires
* Visa-only card → uses Visa
* Unsupported card → rejected

If regulations require shopper choice, Primer will always respect the shopper’s final selection.

### Step 3 – Workflow configuration

To ensure payments are routed to the correct processor, you must explicitly configure routing for local schemes in **your card workflow**.

#### How to configure

1. Open **your card workflow**
2. Add a **Condition** node based on **Card network**
3. Configure the condition:
   * Card network **equals** the local scheme you want to route\
     (for example: `EFTPOS`, `CARTES_BANCAIRES`, or `VISA`)
4. On the **true** branch:
   * Add an **Authorize payment** step using a processor that supports this card network
5. On the **else** branch:
   * Keep your existing routing

![](https://goat-assets.production.core.primer.io/marketing/payment-capabilities/external-docs/co-badged-cards/eftpos-in-workflows.png)

Example of workflow routing based on card network

> [!WARNING]
>
> If a local scheme is not explicitly routed to a compatible processor, payments may fall back to another network or fail, depending on processor behaviour.

***

## Apple Pay and Google Pay

The same configuration you apply for card payments **automatically applies to Apple Pay and Google Pay**.

If a local scheme is enabled for cards, it will also be enabled for Apple Pay and Google Pay
when supported by the wallet and the underlying card.

This means:

* no additional frontend work is required
* changes made to the card configuration also affect Apple Pay and Google Pay

However, wallets handle card network selection differently:

* the shopper selects the card **inside the wallet UI**, not in your checkout
* there is **no card network selector** displayed in your checkout for Apple Pay or Google Pay
* the wallet may automatically choose a network on behalf of the shopper
* depending on the wallet and platform, Primer **may or may not receive an explicit network preference**

![](https://goat-assets.production.core.primer.io/marketing/payment-capabilities/external-docs/co-badged-cards/network-selection-apple-pay.png)

Native card network selection in Apple Pay

Primer always processes the payment using the network information provided by the wallet.

If you allow Apple Pay or Google Pay, make sure your **workflows are adapted accordingly** and local schemes are routed to processors that support them.

***

## Testing co-badged cards

Primer provides test cards for some co-badged scenarios through the **Sandbox processor**.

Use the following resources to validate your integration:

* [Primer Sandbox Processor](https://primer.io/docs/testing/primer-sandbox-processor.md)
* [Test card payments](https://primer.io/docs/testing/primer-sandbox-processor.md#test-card-payments)

***

## Common pitfalls

Before going live, make sure that:

* **Local schemes are enabled at processor level**\
  Otherwise, routing may be inconsistent or fail.

* **Your Client Session only advertises supported networks**\
  `orderedAllowedCardNetworks` must match what your processors can handle.

* **Saved (vaulted) cards keep using the originally selected network**\
  The network used for the first transaction is stored with the payment method and cannot be changed later.

* **Recurring payments reuse the initial network choice**\
  MITs and recurring payments must be processed using the same network as the original transaction.


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