/
10 minute read
October 28, 2022

Card Products

Card products responsibilities

Relative to the lifetime of your Marqeta card program in Europe, there are several responsibilities that you and Marqeta maintain. These responsibilities include:

Your Responsibilities Marqeta’s Responsibilities

Create new card products for new products and market launches

Provide technical support for card product configuration

Ensure that bin_prefix matches your network configuration

Maintain and update Office of Foreign Assets Control (OFAC) list in accordance with US regulations

Maintain existing card products

BIN configuration

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

  • You receive a BIN from the network, typically 6 or 8 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 6 to 10 digits of the primary account number (PAN) specified at the card product level.

    • Marqeta allows the BIN prefix to be between 6 and 10 digits in length. This can be configured in the card product with 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 re-issuing 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 6 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.
Sample JSON
Note
The following sample JSON is for illustrative purposes only and may be truncated.
JSON
Copied

Is this helpful?

Yes
No

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 UK 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.

For more information, see Card Products.

Sample JSON
Note
The following sample JSON is for illustrative purposes only and may be truncated.
JSON
Copied

Is this helpful?

Yes
No

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. If configuring for pre-funding or Commando Mode backup, use program_funding_source. For more information, see Commando Mode.

Sample JSON
Note
The following sample JSON is for illustrative purposes only and may be truncated.
JSON
Copied

Is this helpful?

Yes
No

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 ecommerce 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. If the CVV is provided and incorrect, the transaction is declined. Typically recommended to be set to false because, in some instances, merchants send authorization requests without this information. Amazon and Netflix commonly send authorization without this information.

  • always_require_pin – Blocks any transaction where PIN is not present. Typically not recommended for most customers because it would force PIN and decline ecommerce transactions.

  • allow_gpa_auth – Allows transactions to be authorized using GPA funds. Must always be true to approve transactions within the card product.

Note
A card’s settings cannot be changed after it is issued. However, you can reissue a virtual card’s PAN as a physical card.

For more information, see Card Products.

Sample JSON
Note
The following sample JSON is for illustrative purposes only and may be truncated.
JSON
Copied

Is this helpful?

Yes
No

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.

Sample JSON
Note
The following sample JSON is for illustrative purposes only and may be truncated.
JSON
Copied

Is this helpful?

Yes
No

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. Issuers are allowed to not apply SCA if they meet the following conditions:

  • The individual amount of the contactless transaction does not exceed €50.
    AND

  • The cumulative amount of previous contactless transactions, from the date SCA was last applied, does not exceed €150.
    AND

  • The number of consecutive contactless transactions since SCA was last applied does not exceed five.

For more information, see Managing Strong Customer Authentication.

Sample JSON
Note
The following sample JSON is for illustrative purposes only and may be truncated.
JSON
Copied

Is this helpful?

Yes
No

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. This value is provided by the network upon uploading image assets and returned by Marqeta during token requests.

Note
Currently, tokenization card art is only configurable at the card product level. In some cases, it is possible to configure card art at the card level. You and your card fulfillment provider must agree on the specific fields in the card object. Apple requires that virtual cards must match their corresponding physical cards.
Sample JSON
Note
The following sample JSON is for illustrative purposes only and may be truncated.
JSON
Copied

Is this helpful?

Yes
No
Join our developer newsletter