Services & institutional customers
Sections ↑Marqeta supplies a card-issuing technology and processing platform to businesses creating embedded financial products. Its software can configure card products, capture real-time authorisation decisions, initiate funding and manage clearing-related records. It is not a bank: the underlying programme operates with approved issuing-bank and network relationships.[1]
Its JIT funding design can support cards that maintain a zero balance until an authorisation event requires funds. Managed JIT applies customer-defined rules ahead of time; Gateway JIT gives a customer more direct decisioning in the authorisation flow. These modes have different control and availability responsibilities.[2]
Physical cards, virtual cards and network tokens are distinct credentials and operational tasks. Marqeta’s tokenisation offering includes in-app provisioning for digital wallets; not every wallet or card type is automatically available in every country or issuing programme.[5]
Card credentials and products
| Capability | Published scope |
|---|---|
| Physical cards | Card creation, inventory and fulfilment.Source 1 |
| Virtual cards | Digital card credentials for enabled programme uses.Source 4 |
| Network tokens | Wallet provisioning and token lifecycle services.Source 5 |
| Card products | Debit, prepaid and credit programme technology, subject to bank and network approval.Source 1 |
Managed JIT versus Gateway JIT
| Dimension | Managed JIT | Gateway JIT |
|---|---|---|
| Decision logic | Rules configured in advance. | Customer gateway participates in each eligible funding decision.Source 6 |
| Typical control | Predefined amount, merchant and use restrictions. | Current customer-side logic can approve or decline.Source 6 |
| Availability dependency | Marqeta applies the configured rules. | The customer decision endpoint must respond in time.Source 6 |
| Funding concept | Funds are made available when a transaction requires them. | Funds are made available following the gateway decision.Source 6 |
Platforms & integrations
Sections ↑The platform advertises open APIs and webhooks to configure cards, process transaction events and update the customer’s own app or ledger. A company embedding cards still needs to integrate account balances, KYC decisions, customer communications, fraud handling and settlement reconciliation. A real-time authorisation notification is not the same as a final network clearing record.[1]
API and event responsibilities
| Interface | Purpose | Customer-side implication |
|---|---|---|
| Card APIs | Create and configure programme credentials. | Maintain the mapping between user, account and card.Source 1 |
| Spend controls | Apply permitted-use parameters. | Controls need to match programme policy.Source 1 |
| Webhooks | Deliver transaction and lifecycle events. | Record asynchronous events for reconciliation.Source 1 |
| Token provisioning | Connect eligible cards to digital wallets. | Wallet and network approval remain separate.Source 5 |
Gateway decision and fallback modes
| Field | Value | Meaning |
|---|---|---|
| subnetwork | GATEWAY_JIT | Normal customer-gateway decision path.Source 7 |
| subnetwork | MANAGED_JIT | Marqeta-managed decision path, including configured fallback.Source 7 |
| standin_approved_by | COMMANDO_AUTO | Automatic configured fallback after a timeout or error.Source 7 |
| standin_approved_by | COMMANDO_MANUAL | Manually enabled Commando approval.Source 7 |
| standin_approved_by | NETWORK | Network stand-in when the network cannot reach Marqeta.Source 7 |
Marqeta fallback and network stand-in are different
| Event | Meaning |
|---|---|
| Customer gateway unavailable | Commando Mode can handle the customer-side failure if configured.Source 7 |
| Network cannot reach Marqeta | Network stand-in processing is a different path.Source 7 |
| Approval source | Transaction metadata distinguishes the processing route.Source 7 |
| Deferred notifications | Unsent webhook notifications can be delivered after connectivity returns.Source 7 |
Pricing & commercial terms
Sections ↑Marqeta’s public terms place commercial fees in the order form rather than publishing an all-inclusive rate for every card programme. A relevant comparison should separate card creation, physical fulfilment, authorization/processing, programme management, compliance services, settlement and issuer/network charges.[3]
For programme funding, the customer is generally responsible under the described card agreement for funding and settlement. A minimum funding amount may be defined in the order form, and the legal terms describe a seven-day-before-go-live requirement for its deposit. That is not a fixed universal dollar minimum.[3]
Fees and operational risk can change with the bank-partner and card-brand arrangements. Published terms allocate responsibilities for parameters, programme due diligence and permitted use; they also provide for changes tied to certain underlying network costs. Enterprise quotes should retain those contingencies rather than presenting a headline authorization cost as complete.[3]
Published contractual cost allocation
| Item | What the terms establish |
|---|---|
| Fees | Programme fees are specified through the applicable order form.Source 3 |
| Minimum funding | The order form establishes the amount; no universal dollar minimum is published here.Source 3 |
| Funding timing | The cited terms describe depositing the minimum funding amount seven days before go-live.Source 3 |
| Physical fulfilment | Printing and fulfilment charges can arise even for unused cards.Source 3 |
| Network costs | The contract addresses changes connected with underlying network charges.Source 3 |
Implementation & delivery
Sections ↑Timeout handling and ledger consistency
| Situation | Documented consequence |
|---|---|
| Gateway exceeds response window | The timeout guide describes a three-second window and the normal decline path; configured fallback changes the applicable decision path.Source 8Source 7 |
| Late approval at customer endpoint | The customer may have approved locally after the platform timed out.Source 8 |
| Diagnostic evidence | gateway_log.timed_out identifies a timeout in the event record.Source 8 |
| Reconciliation | Use asynchronous transaction information to correct the local ledger rather than relying on the late response alone.Source 8 |
Transaction stages to keep distinct
| Stage | What the record represents |
|---|---|
| Authorisation | A decision and possible hold, not final clearing.Source 1Source 6 |
| Reversal | Changes an earlier authorisation exposure.Source 1 |
| Clearing | Network-presented transaction information.Source 1 |
| Refund or dispute | A separate post-transaction event requiring reconciliation.Source 1 |
Timeout diagnostics depend on fallback mode
| Mode | Expected diagnostic distinction |
|---|---|
| Automatic Commando | gateway_log is present; timed_out can be true or false depending on the failure.Source 7 |
| Manual Commando | No gateway_log because no request was sent to the customer gateway.Source 7 |
| Normal gateway timeout | Use the recorded timeout and asynchronous event to reconcile a late local approval.Source 8 |
Support & contacts
Sections ↑Marqeta’s contract describes service-level and incident-classification concepts. Some published provisions describe when a significant incident triggers a contractual remedy or potential termination right. Those protections depend on the applicable legal terms and are not an assurance of uninterrupted uptime for all clients.[3]
Published contact and documentation routes
Scope Discuss bank partner, geography, programme type and funding model.
Scope Review issuer approvals, funding, support and service-level clauses.
Scope Compare JIT models and authorisation-control boundaries.
Incident evidence by failure type
| Failure | Useful evidence — implementation guidance |
|---|---|
| Gateway timeout | Request time, response time, transaction identifier and timeout flag.Source 8 |
| Unexpected stand-in approval | Commando setting and recorded approval source.Source 7 |
| Missing event | Webhook delivery history and later replayed notification.Source 7 |
| Wallet issue | Card/token status and provisioning stage.Source 5 |
Permissions & service scope
Sections ↑Marqeta expressly states it is not a bank. Its technology helps businesses operate card programmes through bank partners; it does not authorise an unlicensed provider to take deposits or issue consumer credit in every jurisdiction.[1]
The card programme requires separate issuer and network approvals. Under the cited terms, a customer offering cards alongside lending may need a separate approved lending bank or appropriate lending licences; issuing-bank approval can be withdrawn where programme risk or obligations justify it.[3]
Programme responsibility map
| Party | Distinct responsibility |
|---|---|
| Marqeta | Issuing technology, processing and configured services.Source 1 |
| Issuing bank | Approved bank relationship for the card programme.Source 3 |
| Card network | Network rules and programme approval.Source 3 |
| Programme customer | Required funding, disclosures, permitted parameters and agreed operational duties.Source 3 |
| Lending provider | Credit requires the approved lending arrangement or relevant licences.Source 3 |
Operator & evidence
Sections ↑Contracts allocate customer disclosures, use restrictions, cardholder interface duties and funding obligations. That makes Marqeta materially different from a bank account, a merchant acquirer or a self-contained broker cashier despite areas of overlapping payment functionality.[3]
- Operator
- Marqeta, Inc. and participating issuing banks under card-program arrangements
- Service scope
- Technology for card issuing and processing, physical/virtual/tokenised cards, authorisation, JIT funding, configurable spend controls, tokenisation, webhooks and card-program management; issuer banks and legal permissions remain separate.
- Customer types
- Fintech platforms; Financial institutions; Embedded-finance providers; Corporate expense platforms; Payments businesses; Licensed card programme sponsors
- Delivery
- SaaS; API; Managed service
- Pricing publication
- Quote only
- Platforms
- Marqeta Card Issuing; Marqeta Card Processing; Marqeta Just-in-Time Funding; Tokenization as a Service
- Integrations
- REST APIs; Real-time webhooks; Mobile wallet provisioning; Payment networks; Issuing bank integration
- Implementation
- Issuer/brand and bank approvals, card program rules, API configuration, security credentials, webhooks, settlement funds and support operating model must be agreed before live use.
- Support
- Account and card-program management with documented service terms; the actual order form and service-level schedule determine fees, support and remedies.
- Permissions and regulatory scope
- Marqeta states that it is not a bank and provides technology supporting products offered through issuing-bank partners; card-program approvals and lending licences are not automatic.
Provider metadata checked 26 Oct 2026Source 1Source 2Source 3Source 4Source 5Source 6Source 7Source 8
Sources & further reading
- Marqeta card issuing platform and operating model Marqeta · Accessed 22 Oct 2026
- Just-in-Time funding modes and authorization Marqeta · Accessed 22 Oct 2026
- Marqeta Terms and Conditions, service and issuer obligations Marqeta · Accessed 22 Oct 2026
- Marqeta virtual card issuing Marqeta · Accessed 22 Oct 2026
- Tokenisation and mobile wallet provisioning Marqeta · Accessed 22 Oct 2026
- About Just-in-Time funding Marqeta · Accessed 26 Oct 2026
- Commando Mode reference Marqeta · Accessed 26 Oct 2026
- Managing Gateway JIT timeouts Marqeta · Accessed 26 Oct 2026
This profile reports dated public information, including provider-published services and terms. It does not independently test or guarantee service delivery, integrations or performance. Inclusion is not an endorsement. Permissions and protections apply only to the named legal entity, service and client category; check the current official records and your contract.