Cartes Bancaires
Last updated: August 7, 2024
Cartes Bancaires (CB) is the predominant card scheme in France. The majority of CB cards are co-branded with either Visa or Mastercard, meaning you can process these cards over either CB or the Visa or Mastercard schemes.
If a charge is declined for technical reasons on the CB scheme, we will automatically retry the charge on Visa's or Mastercard’s schemes. To opt out of this, contact your Account Manager.
European regulation (EU IFR Regulation 2015/751 article 8) mandates merchants and acquirers to follow consumers’ card brand choice for payments made with co-badged cards. For example, cards branded with both Visa and Mastercard and a local scheme such as CB.
In practice, this means that merchants must enable consumers to select their preferred brand in a payment form. This expectation comes from CB guidelines directly. Any merchant accepting CB payments should offer this "choix de la marque" during their checkout process.
If you detect a co-badged card, you must present all supported brands for the customer to choose from. You have two options:
- Use our front-end iframe solution, Frames
- Manage your own front-end solution – contact your Account Manager for a secure file transfer protocol (SFTP) scheme BIN file to identify co-badged cards
To enable scheme choice using Frames, specify schemeChoice: true in the Frames initialization. Once this is configured and Frames detects a co-badged card, it will automatically render the consumer choice of card scheme selection.
Use the following examples as a reference for how to format the configuration:
Enter 5137210000000018 in the Card number field to demo the scheme choice functionality.
Once the customer selects Pay, Frames will tokenize the card, and you will see the preferred_scheme field within the cardTokenized event. The preferred_scheme field honors the selection the user makes on the front end.
If you'd like to render Frames with custom text input, you can specify your own localization settings.
To increase the likelihood of a frictionless transaction, request an exemption in your API request. You can request an exemption for transactions that must be Strong Customer Authentication (SCA) compliant, provided it meets the listed possible exemptions. Read more about exemptions and liability shift.
Use of exemptions must be through authentication for transactions that are in scope for SCA, meaning your payment request must contain the 3ds.enabled field set to true.
If no exemption can be applied, then the challenge_indicator field will be set to no_challenge_requested and liability shift will not be applied.
Information
To simulate different 3D Secure (3DS) authentication flows and results for testing, use the Cartes Bancaires 3DS test cards.
CB does not support the secure_corporate_payment exemption in the authentication flow as they deem it SCA exempt. If this exemption is used in the authentication flow, we'll automatically apply it in the authorization flow instead.
If you are not using Standalone (Sessions) - our standalone Authentication solution - skip to the Request a Payment section.
To select the scheme to process the authentication with, set the source.scheme field to one of the following values: visa, mastercard or cartes_bancaires.
To utilize exemptions, you'll need to submit the corresponding exemption in the challenge_indicator field. If no exemption can be applied, then the value no_challenge_requested will be used instead. If no exemption was applied to the authentication despite a frictionless flow_type, the value none will be returned in the response's exemption.applied field. In this scenario, do not include the 3ds.exemption field when sending the authorization request.
For the full API specification, see the API reference.
post
https://api.checkout.com/sessions
Use the following examples as a reference on how to format the configuration.
If you're using hosted sessions, perform a GET request after the cardholder is redirected to your page. If you're using non-hosted sessions, follow our example integration when performing the GET request.
When the customer has chosen their preferred brand, you must include it in the processing.preferred_scheme field in your payment request.
To utilize exemptions, you'll need to submit the corresponding exemption in the 3ds.exemption field.
Information
To simulate a payment for testing, use the Cartes Bancaires test card.
For the full specification, see our API reference.
post
https://api.checkout.com/payments
If you process recurring transactions or merchant-initiated transactions (MITs), the subsequent MITs must be processed using the same scheme as the initial cardholder-initiated transaction (CIT). You must set the processing.preferred_scheme as the customer-chosen scheme from the initial payment.
If you use Standalone (Sessions) for authentication, you can use our simplified integration and authorize payments by setting "enabled": true and using the identifier from the Standalone (Sessions) API response. Using this integration will also allow you to have a consolidated view that links the authentication to the payment in your Dashboard.
If you are authenticating the transaction prior to requesting a payment:
- the
3ds.enabledfield must be set totrue - the
processing.preferred_schemefield must be set to the scheme that authenticated the payment
Additional 3DS data is required by CB for authorization, as specified by the field names in the following table. If you are using our Standalone (Sessions) authentication product, refer to the Request authentication section, as well as the table.
The eci value is not required by the CB scheme and it may not be present in the ARes (frictionless flow) or RReq (challenge flow) messages. For compatibility reasons, the access control server (ACS) may send it in the ARes message according to other payment schemes, particularly in the case of co-badged cards.
| Field name | Description | Applicable to | Sessions response |
|---|---|---|---|
required | The challenge indicator submitted in 3DS authentication. | Mandatory for CB. |
|
required | The authentication value. | All schemes. |
|
required | Indicates whether the 3DS authentication was challenged or frictionless. | Mandatory for CB. |
|
required | The protocol version for 3DS. | All schemes. |
|
required | The DS transaction ID from 3DS. | All schemes. |
|
conditional | The authentication amount. | Mandatory for CB. |
|
conditional | The authentication date and time, in ISO-8601 format. | Mandatory for CB. |
|
conditional | The exemption applied during a frictionless Fast'R authentication. | Required for CB when Not required for CB when Do not send the |
|
conditional | For 3DS, this is the transaction status of ARes or RReq. | All schemes. Mandatory for CB. |
|
conditional | The IP address that is collected during authentication must be passed in the authorization message for CB transactions. | CB. Include for best performance. |
|
optional | The algorithm used by the Issuer ACS to calculate the authentication cryptogram. This is the AVALGO data returned in CB authentication. | CB. |
|
optional | The Electronic Commerce Indicator returned from authentication. | All schemes. Optional for CB. However, include |
|
optional | The risk score calculated by the Fast'R Directory Server (DS). | CB. |
|
optional | The preferred scheme for co-badged card payment processing. If using third-party authentication before requesting the payment, set the value to the scheme that authenticated the transaction. If left unspecified, this defaults to CB. | CB co-badged card payments. |
|