Card Products in Europe

BIN configuration

There are several activities and actions required to successfully enable a bank identification number (BIN) with both the card network and Marqeta.

• You receive a BIN from the network, typically six or eight digits in length, and the network provides your splits as part of BIN setup.
• Marqeta utilizes a BIN prefix model which allows you to select the first six to nine digits of the primary account number (PAN) specified at the card product level.
  • The BIN prefix must be between six and nine digits in length.
  • You can configure the BIN prefix in the card product using the bin_prefix field.
• It is common for a program to set up multiple card products, usually two per issuing country (one virtual and one physical). This gives you greater control over your cards in certain countries. For example, a BIN prefix of 12345678 issues cards between 1234567800000000 and 1234567899999999.
• For any new BIN prefixes that you want to issue against, you should ensure Marqeta is made aware. Marqeta can then enable them within the platform’s router to allow for transactions. Failure to inform Marqeta may result in successful card issuing but failing transactions.

Card type

There are several properties within a card product that determine the type of card it produces. These are key fields that define your card’s lifecycle and functionality. The key attributes to consider when creating a card product are:

• payment_instrument – Determines whether the card is virtual or physical.
  • The card type is set at the card product level, which in most cases is either VIRTUAL_PAN or PHYSICAL_COMBO.
  • A physical card gets processed with a fulfillment provider and requires a shipping address.
  • A virtual card is created in the Marqeta system to be used online or in a mobile wallet.
  • If you want to issue virtual and physical cards, you need at least two card products.
• card_life_cycle – Determines how your card behaves during its lifetime.
  • Expiration time can be set in days, months, or years. Cards that exceed this date automatically expire. You are responsible for reissuing expired cards.
  • Typically, virtual cards are activated upon issuance to allow virtual cards to be configurable and used immediately.
• bin_prefix – Determines the prefix of the PAN that is issued. This can be between six and 11 digits in length and should be aligned to the network configuration of your BIN. Common setup includes two card products per issuing country: one virtual and one physical.

Note

It is important to discuss shipping method(s) with the card fulfillment provider. Marqeta has several options for shipping methods, such as LOCAL_MAIL, GROUND, TWO_DAY, OVERNIGHT, and INTERNATIONAL. These values represent a certain shipping method with the provider. Marqeta, yourself, and your provider are to come to an agreement on these values during your onboarding.

Card fulfillment (physical cards)

You can carry out your physical card requirements with several Marqeta-integrated card fulfillment providers. Providers have different cut-off times and card requirements. Marqeta platform details are outlined below.

• Marqeta is integrated into several sites with each of the providers, including IDEMIA, NITECREST, and ALLPAY.
  • Marqeta provides you with the configuration for your chosen provider and works with you to meet your chosen provider’s card data requirements.
• Physical cards created on the Marqeta platform are placed into a queue and sent to the card provider once a day. Time changes are based on the chosen provider.
  • Cards that are terminated before they are sent to the provider are voided.
• fulfillment_provider – Determines where Marqeta sends the files. Marqeta informs you of the value to set here to ensure proper delivery to your chosen provider’s fulfillment center.
• package_id – Determines card design and functionality. This can be used to change card appearance and behavior between card products.
• enable_offline_pin – Allows an encrypted PIN to be sent to the card provider for chip personalization. This is required for spending in offline PIN markets, such as the United Kingdom and France, and for use in offline terminals, such as airplanes and toll booths.
• service_code – Sets the card type and functionality to determine how the card will function in different terminal scenarios. You and your card provider decide this together during card personalization, and Marqeta should be aware.
  • It is often 201 or 221 in Europe.

Funding

Funding must be defined during card product setup. Typically, funding is handled through a program gateway, where an external URL approves the funding of a specific transaction in real time. Key funding concepts are outlined below.

• programgateway_funding_source – The customer gateway where funding requests are sent. Details of the JIT gateway funding source will define where the requests will be sent. Once a transaction passes Marqeta’s standard checks, approval decisions are delegated to you.
• funding_source_token – The designated funding source to use. Funding sources are created through an API. They contain a URL, username, and password for connecting to the customer gateway. For API reference information, see Program Funding Sources.
• always_fund – A funding setting for the customer gateway. This setting should always be set to true because it ensures that the full transaction amount is always taken from your program gateway funding source.

Pre-funded and Commando Mode setups are also available in specific use cases.

Transaction controls

The types of transactions that a card can be used for depends on the card product. You need to consider how you would like your cardholders to be able to use their cards. Transaction control options are outlined below.

• poi – Assigns where cards can be used, including:
  • ecommerce – Allows cardholders to perform transactions on e-commerce sites.
  • atm – Allows cardholders to perform transactions at an ATM.
  • other – Applies to all other transactions and determines whether card or cardholder presence is required for transactions.
• require_card_not_present_card_security_code – Enforces the presence of the CVV in an authorization request.
• always_require_pin – Blocks any transaction where PIN is not present. Typically not recommended for most customers because it would force PIN and decline e-commerce transactions.
• allow_gpa_auth – Allows transactions to be authorized using GPA funds. Must always be true to approve transactions within the card product.

Additional controls

You need to consider the following settings to ensure you meet the requirements of your program:

• address_verification – Compares the address provided by the merchant to the address on file. If they do not match, you can choose to validate and respond, or decline. Some merchants send reversals if address verification is not performed; some regions mandate this.
• accepted_countries_token – Determines the list of countries in which a card can perform transactions. Marqeta must abide by OFAC rules. As such, a default list is put in place. You can request additional countries to be added to the list, if needed.
• notification_language – Determines the language for cardholder correspondence. Default language is English.

SCA contactless

In accordance with PSD2 Article 11, contactless payments at Point of Sale are monitored and payments without strong customer authentication (SCA) are blocked after a threshold has been breached. Transactions are declined until SCA is successfully performed and limits counters are reset. PSD2 Mandate requires SCA after specific limits are exceeded. When threshold is breached, PIN is required to reset the SCA counters. Specific contactless digital wallet payments are exempt.
AND

• The individual amount of the contactless transaction does not exceed €50;
• The cumulative amount of previous contactless transactions, from the date SCA was last applied, does not exceed €150;
• The number of consecutive contactless transactions since SCA was last applied does not exceed five.

Digital wallet tokenization

Marqeta can provide tokenization services to provision virtual or physical cards to a mobile wallet. This is treated as a separate project or a second-day requirement for customers. The configuration for tokenization can be enabled on the card product level, pending network setup and configuration. Digital wallet tokenization details are outlined below.

• Tokenization enablement is a simple configuration that can be enabled at any time on the Marqeta platform. It is contingent upon your tokenization project with the network.
• provisioning_controls – A cardholder’s ability to tokenize their physical or virtual card into a mobile wallet. Three types of provisioning which can be independently enabled or disabled: manual, in-app, and card on file. Optionally, you can request step-up verification from Marqeta when there is a mismatch in address verification.
• card_art_id – A unique reference to the card art shown with a tokenized card.

Card products responsibilities

If you offer a Marqeta card program in Europe, there are several responsibilities that you and Marqeta maintain.