About Powered By Marqeta in Europe

In Europe, your Marqeta offering is tailored to your specific agreement with Marqeta. This offering is specific to the European region and conforms to Powered By Marqeta (PxM) card program configuration, in which Marqeta is the processor but not the program manager. Additional conditions are outlined below.

• Automated Clearing House (ACH) is not required for European issuers.
• Single Message transactions (pindebit) are specific to US issuers and not seen for European issuers.
  • Transactions from European-issued cards are converted to Dual Message when used within the US.
• You handle disputes and chargebacks yourself, not through Marqeta’s API (unless agreed upon otherwise).

​

Card program responsibilities

With Powered By Marqeta in Europe, you and Marqeta share responsibilities throughout the lifetime of your card program. The table below lists the primary tasks related to launching a Powered By card program in Europe.

​

Integration responsibilities

During your integration with Marqeta, you or a third party need(s) to stand-up and build infrastructure to process notifications and interactions with the Marqeta API. The minimum requirements for an integration with Marqeta are outlined below.

• A gateway endpoint that receives Gateway Just-in-Time (JIT) requests and provides responses that approve or decline authorizations within a three-second time window.
• A webhook endpoint that receives and parses all events and responds with a 200 response within five seconds of acknowledging an event receipt. Data sent to the endpoint supports direct reconciliation and ledger management.
• A SSH File Transfer Protocol (SFTP) server that Marqeta’s SSH key can access, which allows Marqeta to place an encrypted settlement file on the server. You must provide a GNU Privacy Guard (GPG) key to complete reconciliation. Settlement files are sent to the server on a daily basis.
• A platform that manages your card program through Marqeta’s APIs, such as card products, velocity controls, and Commando Mode (if applicable).

​

Marqeta API

Each Marqeta customer who enters into an agreement to receive Marqeta’s services can access the API and operate within an individually tailored production environment called a program. The details of interacting with Marqeta’s APIs are outlined below.

• To access the API in production, use the unique base URL for your program.
• To obtain a list of available API endpoints, follow the steps in SDKs to generate your own client library.
• To ensure valid IP addresses can be let through Marqeta’s firewall, you are required to provide Marqeta with integrated IP addresses.
  • In the public or private sandbox environment, you are allowed a maximum of 255 IP addresses.
  • In production, you are allowed a maximum of five IP addresses, and a vulnerability scan is required.
• Marqeta provides you with the credentials for each environment, which are required to interact with Marqeta’s APIs.

​

Marqeta sandbox environment

The Marqeta platform provides you with a production environment and a test environment. The test environment, known as the sandbox, is for simulations. There are two types of sandbox environments available:

• Public sandbox: A single-user environment where you can begin building your program. Public sandbox users are typically potential customers who are evaluating Marqeta as a partner in their application.
• Private sandbox: A multi-user environment where you can integrate your application with the Marqeta platform. Marqeta customers use the private sandbox and its connected microservices to validate their application’s integration, as well as ongoing API changes.

All funds and transactions are simulated in both types of sandbox environments. The sandbox may give you access to features not available in production environments, depending on your integration. A significant difference between the production and sandbox environments is that your production environment communicates with a payment card network. Other notable differences include:

• Simulation endpoints allow you to test various types of card network transactions, such as authorizations, reversals, and clearings. These endpoints are used to simulate scenarios for cards, users, and other objects within the public or private sandbox environments.
• Simulated transactions are in a single chosen currency (no foreign exchange transactions).
• You can simulate the core transaction types in production. Some transaction types can only be tested directly within the production environment.

For more information about the public and private sandbox environments, see Simulations 2.0 — Card Transactions.

​

Marqeta Dashboard

The Marqeta Dashboard provides an interactive user interface for exploring, administering, and managing your card and payment programs. Using the Dashboard, you can manage your users and cards, including tasks such as replacing a card and reporting a card stolen. To access the Marqeta Dashboard, go to app.marqeta.com in your browser. The Marqeta Dashboard contains these main areas of functionality:

• Reports – Explore your production data, aggregate reports, and curate your data to help you make data-driven decisions.
• Card Management – Monitor and manage your card products, catalog, and inventory.
• Customers – Manage users and businesses.
• Control Center – Manage users and roles, and control Commando Mode.

Marqeta designates an admin whose role allows them to administer users within the organization. As an admin, you can:

• Provision users using the same email domain as yourself. External users need to be set up by Marqeta.
• Share the supplements access you have.

​

Marqeta Dashboard – Departments

​

Marqeta Dashboard – Roles and Supplements

​

Roles

​

Supplements

For more information about getting started in the Marqeta Dashboard, see Marqeta Dashboard and Marqeta Dashboard User Management.

​

Users

A user represents a person who uses a physical or virtual Marqeta card. User attributes include name, address, date of birth, phone, and email address for cardholder verification purposes (if applicable for 3DS and Tokenization). There are two types of users: cardholders and businesses.

• Cardholder – A person who uses a Marqeta card (physical or virtual). On the Marqeta platform, a cardholder:
  • Stores user attributes, such as name, address, and date of birth.
  • Stores financial information, such as balances.
  • By default, has a general purpose account (GPA).
• Business – A type of account holder that cannot directly hold cards. A business:
  • Has parent-child relationships with card-holding users.
  • Can monitor and control card use by a specified group of users.
  • Has a GPA.

A user in the SUSPENDED or CLOSED state can transition back to the ACTIVE status. However, they cannot activate cards or transact on already active cards. If you use Just-in-Time (JIT) Funding, you are responsible for managing your own ledger balances. You can use parent-child relationships to facilitate reporting. For more information about your account ledger, see Ledger Management with JIT Funding. You can associate users and businesses with one another by creating parent-child relationships. The following rules apply to parent-child relationships:

• A user or business can be a parent, but only a user can be a child.
• A parent can have multiple child users, but a child user can only have one parent.

For more details, see Parent-child relationships. For more information about account holders, see Users vs. businesses.

​

Card products

The card products resource represents the behavior and functionality of one or more cards (either physical or virtual). A card product is a fundamental construct of your program. This template controls the attributes and behaviors of all cards generated from it in perpetuity. A card product defines:

• How and where a card can be used.
• Characteristics of a card, including physical and virtual.
• Features of the lifecycle of cards of this card product type.
• How cards created within it are funded for transactions.

To restrict specific cardholders, you can associate authorization and velocity controls for card products.

​

Cards

A card is a payment device that enables a user to conduct transactions at merchants. Cards can be physical or virtual. You can also tokenize physical or virtual cards for use in digital wallets. Cards store multiple pieces of data necessary to complete a transaction, including the following:

• Name – Cardholder’s name.
• Primary Account Number (PAN) – Unique identifier that appears on the front of the card.
• Expiration date – Date when the card expires.
• Card Verification Value (CVV) – Verification number that appears on the back of the card.

Cards are managed at the cardholder level. A card is associated with a specific user and card product to define the behavior and spending limits of the card. A card can be issued in the following form factors (determined by the card product it is assigned to):

• Physical
  • A traditional, plastic card ordered through a third-party provider and shipped to specific address.
    • For making payments at physical points of sale.
    • Must have a shipping address set for either card, user, or card product.
• Virtual
  • A virtual payment card with no physical component and intended for immediate use.
    • Can be used for one-off payments.

A card defines fulfillment and shipping details, such as:

• Shipping address (overrides cardholder address for this card if different from home address of cardholder).
• Shipping method to allow varying speeds of delivery (i.e., overnight, two day, standard).
• Names, logos, and text to be printed on the physical card.

​

Card programs

Card programs come in many different shapes. They typically share traits and similarities across markets and payment sectors, such as lending, travel, and expenses. The program configuration examples below describe the functionality of your card program.

​

Just-in-Time Gateway

Just-in-Time (JIT) Gateway allows you to approve or decline a transaction in real-time. Your system participates in the funding approval process, enabling you to have a high level of control over which transactions are successfully approved. To set up a JIT gateway, you need:

• A funding source configured for JIT Funding. The funding source defines the endpoint on your system where the Marqeta platform sends funding requests.
• A card product configured for JIT Funding associated with the above funding source.

The Marqeta platform and your system exchange these message types:

• JIT requests – Sent by Marqeta and requests permission to authorize a transaction or answer a balance inquiry.
• JIT responses – Sent by your JIT Funding gateway to the Marqeta platform and is in response to a funding request or balance inquiry.
• JIT notifications – Sent by the Marqeta platform to your webhook endpoint and informs you about a transaction outcome.

For more information about setting up Gateway JIT, see Gateway JIT Funding Messages.

​

Webhooks

Webhooks can be used to obtain information about API events as they occur. The Marqeta platform sends notifications to an endpoint, which is hosted in your environment and configured to receive and process the information. The details of webhook-enabled event notifications are outlined below.

• The Marqeta platform reduces the number of event notification messages by sending notifications of the same type in a single message.
• In the case of a messaging failure (i.e., any HTTP code other than 200), the Marqeta platform attempts to resend a notification message 10 times.
  • Exponential backoff increases after each messaging failure, up to an interval of just over 12 days.
• If you receive notifications in a different order than they occurred, you can use the created_time field to determine the correct chronological order.
• In the rare case that you receive the same notification more than once, you can make your event processing idempotent.
  • To support idempotency, each transaction is identified by a unique transaction token and each webhook is identified by a unique event token.

For more information about using webhooks, see About Webhooks and Webhooks.

​

Transactions

A transaction occurs when a cardholder tries to make a payment online or at a physical point of sale. After a transaction funding event occurs, a webhook provides the final outcome of the transaction. A transaction defines:

• The amount to be reflected in the ledger and the funds captured from the cardholder, including the local currency and conversion rate.
• The type of transaction being attempted, whether it is an authorization, an ATM withdrawal, or a balance inquiry.
• The type of cardholder interaction, including e-commerce, point of sale, contactless, CHIP, and PIN.

A transaction includes:

• A token which uniquely identifies the transaction record and can be used to ensure idempotency.
• A transaction type to identify the specific type of transaction, inform you whether or not to accept that type of sale, and prompt your system to complete specific checks.
• A preceding transaction token (where possible) to link to a previously pending transaction and aid reconciliation and cardholder transaction history.

For more information about transactions, see About Transactions and Transactions.

​

Settlement

Settlement is the actual exchange of funds among acquirers and issuers for all transactions that are cleared. Marqeta receives settlement reports from the networks and transmits them to a client-hosted SFTP daily. You can compare these summary reports with Marqeta-provided data to reconcile between Visa, Marqeta, and your ledgers. More settlement characteristics are outlined below.

• With a Powered By card program, you are responsible for network settlement and reconciliation. This consists of receiving reports and webhook data from Marqeta, then comparing that to the amount owed to Visa.
• For both credit and debit, Visa and Marqeta events should match in terms of the number of transactions and transaction amounts.
• Files are delivered in raw format to a client-hosted SFTP location, where you receive encrypted settlement files from Marqeta.
• The network depicts the timing and number of files. However, in all circumstances, these reports are summary-level, providing an overall view of the number of transactions in a given period.
• You should be subscribed to relevant, transaction-level clearing webhooks from Marqeta. The number of received transactions and received files should be the same.