marcopolo Online payment
Sign up

Introduction

Co-badged cards are innovative payment solutions that merge multiple payment brands into one card. By integrating global and local schemes into a single card, its acceptance and flexibility increase, greatly boosting convenience for your customers.

Our platform offers effective ways to offer this service, regardless of your chosen integration method(s). Learn in the following chapters how to implement it.

Integration prerequisites

Depending on your integration mode(s), the integration effort may vary, but certain essential prerequisites are universally applicable:

  1. Active Card Scheme Identification - Check which card schemes are active in your account. This ensures you accurately offer all relevant available payment methods to your customers.
  2. Checkout Page Configuration - After identifying the active card schemes, you must offer them on your webshop's checkout page. This ensures your customers can actively choose their preferred payment method for the payment. Before sending a payment request to our platform, make sure that your checkout page allows the selection of both local and international card schemes. This configuration is important to offer a broad spectrum of customer payment preferences, thereby facilitating a more inclusive and efficient payment process.
  3. Familiarise yourself with our integration method guides before diving into co-badging integration options.

Learn in the following chapters how to implement it for any of our integration methods.

Hosted Checkout Page

Standard Integration

The simplest way to integrate co-badging is by sending a standard CreateHostedCheckout request without pre-selecting any payment methods. Our system detects co-badged cards automatically once customers enter their card number on the Hosted Checkout Page. This way, you offer them a choice of global/local schemes activated in your account effortlessly.

This also works with the group card payment methods feature.

Below screenshot illustrates the example view during checkout:

Co-badging cards example during checkout

Optional Integration: Pre-selecting Payment Methods

You can also enable your customers to pre-select card schemes in your webshop environment before redirecting them to the Hosted Checkout Page. To ensure your customers can choose their preferred global/local scheme, make sure to send the CreateHostedCheckout request with the respective cardPaymentMethodSpecificInput.paymentProductId to honour their choice.

For more information regarding how co-badging is managed see our official API reference documentation.

For more information about payment methods, see our Advanced features guide.

Hosted Tokenization Page

The simplest way to integrate co-badging is by sending a standard CreateHostedTokenization request without pre-selecting any payment methods.

Our system automatically detects co-badged cards once customers enter their card number in the <iframe>, offering them a choice of global/local schemes activated in your account.

You can also allow your customers to pre-select card schemes in your webshop environment before displaying the <iframe>. To ensure your customers can choose their preferred global/local scheme, make sure to follow these steps in the checkout process:

  1. Offer all available schemes in your account in your webshop environment.
  2. Send the CreateHostedTokenization request with the respective exclude.products/restrictTo.products to honour their choice.
  • We have optimised the <iframe> template from our GitHub repository to allow your customers to choose easily between local or global brands.
  • In contrast to the Hosted Checkout Page, the Hosted Tokenization Page strictly follows your preselection via exclude.products/restrictTo.products. Once you exclude a specific brand, the <iframe> will not show it even if a card is co-badged accordingly. If a co-badged card is entered in the Hosted Checkout Page, our platform will always offer all available brands. This also applies if you preselect a specific brand via paymentProductId in your CreateHostedCheckout request.

Server-to-server

Depending on the use case, differences apply:

  1. Sending non-tokenised card data
  2. Replacing card data with token/hostedTokenizationId

  1. Sending non-tokenised card data
    CreatePayment request with non-tokenised card data (in property cardPaymentMethodSpecificInput.card) always requires you to include cardPaymentMethodSpecificInput.paymentProductId.
    Hence, to ensure your customers can choose their preferred global/local scheme, make sure to follow these steps in the checkout process:
    1. Offer all available schemes in your account in your webshop environment.
    2. Detect all brands associated with your customer's card by sending a GetIINDetails request to our platform. If a card is co-badged, our platform returns all schemes in array coBrands, including all available paymentProductIds.
    3. Allow your customers to choose between the local/global scheme from coBrands. Send the CreatePayment request with the respective paymentProductId to honour their choice.
  2. Replacing card data with token/hostedTokenizationId
    CreatePayment requests replacing card data with an existing token/hostedTokenizationId do not allow to specify the scheme in paymentProductId retroactively. This is because a token/hotedTokenizationId is always linked to a specific brand.
    Hence, when creating a token/hostedTokenizationId, make sure to link it with your customers' preferred scheme in the respective CreatePayment/CreateHostedTokenization request.

Mobile/Client Integration

Before sending the actual payment request to our platform via the Server API, make sure to follow these steps in the checkout process:

  1. Using GetClientPaymentProducts request, the client app offers all available schemes in your account which your customer's device supports.
  2. Detect all brands associated with your customer's card by sending a GetClientIINdetails request to our platform. If a card is co-badged, our platform returns all schemes in array coBrands, including all available paymentProductIds.
  3. Allow your customers to choose between the local/global scheme from coBrands. Send the encrypted payment data in a CreatePayment request with the respective paymentProductId to honour their choice.
  • Any card that bears the logo of one of the scheme members, such as Visa, is subject to PCI requirements. This includes co-branded cards that display these logos.
  • The BIN range can be a useful indicator to identify cards that are out of PCI scope (e.g., test cards). However, we recommend not to use BIN solely for determining cards that are in scope, especially with the move towards 8-digit BINs. This approach ensures more accurate compliance and security measures are in place.

Was this page helpful?

Do you have any comments?

Thank you for your response.