15 minute read
December 16, 2022

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.

What You Are Responsible For What Marqeta Is Responsible For
  • Defining Bank Identification Number (BIN) configuration with the card network/scheme

  • Approving and managing the program with the card network/scheme

  • Approving and managing the program with the issuing bank

  • Ensuring program compliance with regional regulations

  • Ensuring program compliance with bank and card network mandates

  • Configuring the customer processing environment

  • Configuring funding methodology

  • Configuring webhooks

  • Issuing and fulfilling cards

  • Managing Know Your Customer (KYC)

  • Managing card inventory and fulfillment providers

  • Managing tokenization with the card network

  • Engaging with the digital wallet providers

  • Reconciling with the card network

  • Monitoring transactions (fraud, anti-money laundering, etc.)

  • Managing disputes

  • Providing access to Marqeta APIs to ensure core functionality for integration

  • Processing card network/scheme events (authorization, clearing, etc.)

  • Processing real-time authorization requests from the network and responding within allotted time to secure successful transactions

  • Processing network clearing events daily and distributing events to webhooks in order to complete ledger events and aid reconciliation

  • Providing Tier II technical support

  • Sending daily card network reporting files to the issuing bank

  • Sending crucial webhooks information to keep your system synced with Marqeta

  • Providing JIT requests to process customer responses into network-specific approval

  • Queuing and transmitting daily card orders to the card vendor

  • Providing Commando Mode solutions when customer JIT fails to improve authorization rates

  • Hosting and configuring a Three-Domain Secure (3DS) authentication platform to secure e-commerce transactions

  • Hosting and configuring a tokenization solution to manage tokens and digital wallet payments

  • Providing access to Marqeta Dashboard to complete core customer service functionalities for cardholders

  • Providing fraud monitoring rules and solutions to enhance risk management

  • Installing and maintaining Marqeta Bank Identification Number (BIN) configuration, enabling BIN ranges to transact on the Marqeta platform as your program grows and scales

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.

Sandbox Environment Transactions Production Environment Transactions
  • authorization (JIT)

  • authorization.advice

  • authorization.clearing

  • authorization.reversal

  • refund

  • authorization.atm.withdrawal (JIT)

  • authorization.clearing.atm.withdrawal

  • authorization.cashback (JIT)

  • authorization.incremental (JIT)

  • balanceinquiry (JIT)

  • authorization.quasi.cash (JIT)

  • authorization.clearing.quasi.cash

  • authorization.reversal.issuerexpiration

  • original.credit.authorization (JIT)

  • original.credit.authorization.clearing

  • refund.authorization (JIT)

  • refund.authorization.clearing

  • refund.authorization.reversal

For more information about the public and private sandbox environments, see Simulating 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

Name Access Granted

Compliance – Processor Only

Edit Users

Edit Businesses

Order Cards

Manage Cards

Customer Service

Edit Users

Edit Businesses

Order Cards

Manage Cards

Manage Digital Wallet Tokens

Search by full card PAN


Edit Users

Edit Businesses

Order Cards

Manage Cards

Business Development
Customer Success
Finance – Other
Finance – Settlement
Human Resources
Product Management
Program Management

Access the app

Marqeta Dashboard - Roles and Supplements


Name Grants


Create Users

Modify Users

Inactivate Users


Cannot Create/Modify Users


Name Enables

Cross Border Fees

View Cross Border Fees in Reports

Currency Conversion Fees

View Currency Conversion Fees in Reports


View Detail Transaction Data in Reports


View Interchange Fees in Reports

Invoke Commando Mode

Invoke Stand-In Processing (Commando Mode)

Personal Identifiable Information (PII)

View PII (SSN, PAN, CVV, and more)

Show Primary Account Number (PAN)

View full card data or PAN (only if PCI certified or exception)

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


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.

Marqeta account balances reside at the account holder level.

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.


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.

Feature Single-Use Virtual Virtual Physical

Card product


One-time use

30-day expiration

Blocks OFAC



4-year expiration

Blocks OFAC



4-year expiration

Blocks OFAC

Offline PIN Capable

Card ordering

Instant virtual presentment

Instant virtual presentment

Instant virtual presentment

Physical card mailed

Card ordering and activation

Activate upon issue

Activate upon issue

Manual activation

Card presentment

Card Not Present transactions

Wallet Payments

Card Not Present transactions

Wallet Payments

Card Not Present transactions

Card Present transactions

Wallet payments

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 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 Gateway JIT setups, see Gateway JIT Funding Messages.


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.

You are allowed four active webhook configurations on the Marqeta platform. This allows you to split out event types if you choose to. Marqeta suggests limiting this configuration and accepting all webhooks, parsing the events you are interested in into a single endpoint.

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


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

Join our developer newsletter