> ## 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.
</Note>

### 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.
</Note>

### 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.
</Note>

#### 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.
</Note>

### 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.
</Note>

#### 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

<Frame caption="Example of workflow routing based on card network">
  <img src="https://goat-assets.production.core.primer.io/marketing/payment-capabilities/external-docs/co-badged-cards/eftpos-in-workflows.png" />
</Frame>

<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.
</Warning>

***

## 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**

<Frame caption="Native card network selection in Apple Pay">
  <img src="https://goat-assets.production.core.primer.io/marketing/payment-capabilities/external-docs/co-badged-cards/network-selection-apple-pay.png" />
</Frame>

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](/testing/primer-sandbox-processor)
* [Test card payments](/testing/primer-sandbox-processor#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.