Skip to content

Reference stack

Issue physical and virtual cards

A card-programme architecture separating sponsorship, issuer processing, programme management, manufacturing, tokenisation and fraud.

FintechsExpense platformsConsumer and business wallets

Intended audience and markets

Audience

FintechsExpense platformsConsumer and business wallets

Markets

EuropeNorth AmericaSelected global markets

Infrastructure layers

01

Sponsor and regulated issuer

Required

Provide scheme membership, BIN sponsorship and regulated issuing capacity.

Selection criteria

  • Jurisdiction and programme eligibility
  • BIN ownership and portability
  • Scheme approval responsibilities
02

Issuer processor

Required

Authorise, clear and manage card transactions and card controls.

Selection criteria

  • Real-time authorisation controls
  • Ledger integration
  • Disputes and lifecycle tooling
03

Programme and card operations

Required

Operate programme configuration, card lifecycle, fulfilment and support.

Selection criteria

  • Roles between sponsor, processor and programme manager
  • Card production and logistics
  • Customer support and disputes
04

Tokenisation and mobile wallets

Optional

Provision cards into wallets and manage network tokens.

Selection criteria

  • Network token support
  • Apple Pay and Google Pay certification
  • Lifecycle event handling
05

Fraud, 3-D Secure and disputes

Required

Manage authorisation fraud, authentication, disputes and chargebacks.

Selection criteria

  • Real-time decision latency
  • 3-D Secure role
  • Case and dispute workflow

Implementation sequence

  • Sponsor and regulated issuer
  • Issuer processor
  • Programme and card operations
  • Tokenisation and mobile wallets
  • Fraud, 3-D Secure and disputes

Regulatory considerations

  • Card issuing requires an appropriate regulated issuer and scheme approval.
  • BIN sponsorship does not transfer all compliance, complaints or conduct obligations to the sponsor.

Technical considerations

  • Define a single source of truth for available balance and authorisation decisions.
  • Test reversals, partial captures, offline transactions, token lifecycle and stand-in processing.

Questions to ask providers

  • Which legal entity contracts for each service and in which jurisdictions?
  • Which responsibilities remain with the product operator rather than the provider?
  • What are the implementation, approval, testing and migration timelines?
  • How are incidents, exits, data portability and business continuity handled?
  • Who owns the BIN, cardholder relationship and scheme liabilities?
  • Can the programme migrate processors or sponsors without reissuing every card?

What this stack does not cover

  • Card design approval, legal terms, customer support staffing and local consumer-credit rules are not included.

Related stacks

Reviewed on 2026-07-07.

Provider options are examples of infrastructure roles, not endorsements or a guarantee of suitability, availability or regulatory compliance. Confirm requirements for your product with each provider and qualified advisers.