What Is Card Issuing? BIN Sponsorship, Virtual Cards and Compliance Explained
Card issuing explained for 2026: what it is, how the issuer, processor, network and BIN sponsor interact, physical vs virtual cards, tokenization, program types and PCI DSS compliance - the concepts behind launching a branded card program.
What card issuing is
Card issuing is the process by which a financial institution or licensed program manager creates and distributes payment cards - physical or virtual - to cardholders. It sounds simple, but behind every tap-to-pay transaction sits a chain of four distinct roles that must work together in real time.
The four roles in every card transaction
- Issuer: the entity that opens the cardholder account, extends credit or holds funds, and is ultimately liable to the card network. In regulated markets this must be a licensed bank or e-money institution.
- Card network (scheme): Visa, Mastercard, Amex - sets the rules, routes authorization messages, and settles funds between issuer and acquirer.
- Processor: the technology layer that handles the real-time authorization flow between the network and the issuer's systems (balance check, fraud check, response).
- BIN sponsor: when a fintech or brand wants to issue cards without its own banking licence, it piggybacks on a licensed bank's Bank Identification Number. The sponsoring bank takes regulatory responsibility; the fintech controls the product.
How an authorization flows
- Cardholder taps card at merchant terminal.
- Acquirer (merchant's bank) sends the authorization request to the card network.
- Network routes to the issuer/processor identified by the BIN.
- Authorization server checks balance, limits, fraud rules and responds approve or decline in under 100ms.
- Network relays the response to the acquirer and merchant.
- Settlement runs at end of day across the network's clearing house.
For a fintech or brand launching a card program in 2026, the typical path is: choose a BIN sponsor (a licensed bank willing to extend its BIN range), connect to a card processor, plug into the network via the sponsor's membership, and then build the product experience on top. Crassula packages all of those layers - sponsor relationship, processor connectivity, authorization server, and cardholder-facing app - into one platform.
Let's discuss your project and see how we can launch your digital banking product together
Request demoTypes of card programs: debit, credit and prepaid
"Card issuing" covers three product types, and the one you pick decides your licensing, your funding model and your risk. Most fintech programs start with debit or prepaid because they avoid extending credit, then add credit once the book and the balance sheet can support it.
| Program type | How it funds | Who issues it | Typical use case |
|---|---|---|---|
| Debit | Spends against the cardholder's own account balance in real time. | Bank or EMI, or a fintech on a BIN sponsor's e-money licence. | Neobanks, e-wallets, current-account products. |
| Prepaid | Spends against funds loaded in advance onto the card. | Usually an EMI or prepaid program manager. | Gift cards, expense and per-diem cards, payouts, gig-economy. |
| Credit | Spends against a credit line the issuer extends and later bills. | A licensed bank or lender (credit risk sits on a balance sheet). | Consumer credit cards, BNPL, SME charge cards. |
The practical rule: debit and prepaid programs can launch on a BIN sponsor's e-money licence in weeks, because no credit is extended. A credit card issuing program needs a lending licence or a sponsor that underwrites the credit, plus affordability checks, billing and collections logic, so it carries a longer and heavier build. Many programs run all three card types from the same platform once the licensing is in place.
The card issuing market in 2026
Card issuing has shifted from a bank-only function to an infrastructure layer any product company can plug into. Two numbers frame the opportunity: there are over 25 billion payment cards in circulation worldwide, and the virtual cards segment alone is projected to move past $13 trillion in transaction value by 2030 as B2B spend, expense management and subscription use cases go card-native.
Embedded by default
Marketplaces, SaaS platforms and vertical software increasingly issue their own cards to control spend and capture interchange, rather than sending users to a third-party bank.
Virtual-first
Instant virtual issuance into Apple Pay and Google Pay is now the default first card, with the physical card optional and ordered on demand.
Interchange economics
Interchange on each transaction is the core revenue line for most programs, which is why owning issuing rather than referring out has become a deliberate strategy.
The result is a crowded field of card issuing platforms and services - from network-scale processors to program managers and white-label providers - that let a brand launch a card without becoming a card processor itself. The choice comes down to geography, the licensing model you need, time to market, and how much of the interchange you keep.
Personalized and branded card programs - why they matter
A payment card is one of the few physical or digital objects a customer interacts with every day. That makes it a branding surface, a loyalty instrument, and a retention tool - not just a payment mechanism.
Personalized card issuing means more than printing a company logo. Modern card programs allow full control over design, spending limits, merchant-category controls, rewards logic, notifications language and the cardholder app experience. When a customer holds a card that matches their brand - whether that is a neobank, a B2B expense platform, a crypto exchange or a retailer - the emotional connection to the product increases measurably.
Visual identity
Custom card art, brand colours, logo placement and card material (standard PVC, metal, eco-friendly) all reinforce the product identity at every point of sale.
Programmatic controls
Merchant-category blocks, per-transaction limits, geography restrictions and time-of-day rules - all configurable per card or per segment without touching the processor.
Loyalty and rewards
Cashback, points, spend-linked benefits and partner offers wired directly to transaction data - without a separate rewards middleware layer.
The business case for personalization is straightforward: cards with distinct brand identities see higher activation rates, higher monthly spend and lower churn than generic white-label products. The operational case is equally clear: a configurable card program means your product team can adjust card rules in days rather than waiting months for a processor to implement bespoke logic.
Physical vs virtual cards and tokenization
Most card programs in 2026 issue both physical and virtual cards, often from the same underlying card account. The choice is not either/or - it is about which form factor fits which use case.
| Dimension | Physical card | Virtual card |
|---|---|---|
| Use case | In-store, ATM, contactless at terminal | Online payments, subscriptions, B2B spend, mobile wallets |
| Issuance speed | 3-10 days (production and delivery) | Instant (seconds after approval) |
| Fraud exposure | Card-present risk; EMV chip limits cloning | Card-not-present risk; controls by merchant/MCC and single-use numbers mitigate |
| Cost per card | $2-8 including manufacturing and fulfilment | Negligible (software-generated credentials) |
| Typical fit | Consumer debit/credit, employee expense cards | B2B virtual cards, travel, subscriptions, digital-native products |
Tokenization sits at the intersection of both. When a cardholder adds a physical or virtual card to Apple Pay or Google Pay, the device does not store the real PAN (Primary Account Number). Instead, the card network generates a Device Primary Account Number (DPAN) - a token that is specific to that device and wallet. The real PAN never travels over the air at the point of sale.
For the issuer, tokenization dramatically reduces fraud on contactless and in-app payments. For the cardholder, it means the physical card can be cancelled and replaced without disabling the mobile wallet - the token transfers. Supporting Apple Pay and Google Pay provisioning is now a baseline expectation for any consumer card program; most card processors and BIN sponsors provide the required Token Service Provider connectivity out of the box.
BIN sponsorship and the issuing stack
A Bank Identification Number (BIN) - sometimes called an Issuer Identification Number (IIN) - is the first 6-8 digits of a payment card. It identifies the card network, the issuing bank, the product type (debit/credit/prepaid) and the geography. You cannot issue cards without a BIN range assigned by Visa or Mastercard, and you cannot hold a BIN range without being a licensed member of those networks.
That is where BIN sponsorship comes in. A BIN sponsor is a licensed bank that holds a principal membership with Visa or Mastercard and is willing to extend a sub-range of its BIN to a third-party program manager. The sponsor assumes regulatory and scheme-rule liability; the program manager (your fintech) designs the product, owns the customer relationship, and handles the marketing.
What a BIN sponsor provides
- Scheme membership and BIN range
- Regulatory cover (e-money or banking licence)
- Interchange settlement and chargeback handling
- Scheme rule compliance oversight
What the program manager controls
- Card design and brand identity
- Cardholder onboarding and KYC
- Spending controls and product rules
- Customer-facing app and notifications
- Pricing - interchange share, fees, FX margins
The full issuing stack for a typical fintech card program looks like this: card processor (authorization, clearing, settlement logic) - BIN sponsor bank (regulatory anchor) - card network (Visa/Mastercard routing and settlement) - card bureau (physical card manufacturing and personalization) - tokenization service (Apple/Google Pay provisioning). Crassula integrates with established BIN sponsors and processors in Europe, meaning a new program does not need to negotiate those relationships from scratch.
Compliance - PCI DSS and card scheme rules
Running a card program carries two distinct compliance obligations that operate in parallel: PCI DSS, which governs how you handle cardholder data, and card scheme rules, which govern how you operate within the network.
PCI DSS
The Payment Card Industry Data Security Standard applies to any entity that stores, processes or transmits PANs. In 2026 PCI DSS v4.0 is the active standard. Most card programs reduce scope dramatically by using tokenization (PANs never touch your servers) and by routing authorization through a PCI-certified processor. See our PCI DSS guide for the full scope-reduction playbook.
Card scheme rules
Visa and Mastercard publish rulebooks (hundreds of pages) covering acceptable card designs, acceptable merchant categories, cardholder authentication requirements (3DS2), chargeback dispute timelines and fraud thresholds. Your BIN sponsor is technically responsible for your compliance with these rules, but in practice you must understand them when designing your product.
Key compliance areas to address before launch:
- KYC and AML at onboarding: card programs that allow cash-equivalent spending must apply customer due diligence. Your onboarding flow needs identity verification, sanctions screening and transaction monitoring wired up before the first card is issued.
- Strong Customer Authentication (SCA): in the EU under PSD2, card-not-present transactions above EUR 30 require SCA. Your 3DS2 implementation must be in place for online card acceptance.
- EMV 3DS for e-commerce: card schemes now mandate 3DS2 for most card-not-present transactions. Your processor must support the full 3DS2 authentication flow.
- Chargeback management: you need a process and tooling to respond within scheme deadlines (typically 30-45 days) or you absorb the loss.
How Crassula enables card issuing
Crassula provides an end-to-end card issuing capability that fintechs, EMIs and brands can deploy without negotiating each component of the stack independently. The platform covers:
Authorization server
Enterprise-grade real-time authorization with configurable rule sets - spend controls, MCC blocks, geography limits, velocity checks - all managed through the admin console without code changes.
Physical and virtual issuance
Instantly issue virtual cards for online payments and mobile wallets; order physical cards with custom design through connected card bureaus. Both from the same underlying account and card management API.
White-label branding
Full brand customization across card design, mobile app, push notifications and cardholder portal. The product carries your brand, not Crassula's. 150+ companies already use the platform.
Mobile-first cardholder management
Cardholders check balances, view transaction history, freeze and unfreeze cards, and adjust limits - all from a branded mobile app. Card management is self-service, which reduces support volume.
Compliance integration
KYC orchestration, AML transaction monitoring, SCA/3DS2 handling and PCI-scope reduction built into the platform. Compliance tools are wired up before you issue the first card, not retrofitted later.
Fast launch path
Pre-negotiated BIN sponsor and processor relationships mean a new card program can reach market in weeks rather than the 12-18 months a from-scratch build typically takes.
The platform is built for scale. Spending controls, card designs, program rules and fee structures are all configurable without engineering involvement. Once live, your team manages the program through the admin console; Crassula handles the infrastructure, scheme connectivity and compliance stack underneath.
For the complete product, see the card issuing solution. See the Decta card issuing solution and the cards feature, or compare vendors in the top card issuing platforms guide.
FAQ
Card issuing is the process by which a licensed financial institution (or a fintech using a BIN sponsor) creates and distributes payment cards to cardholders. The issuer opens the account, sets spending rules, handles authorizations in real time and is liable to the card scheme for the cardholder's transactions. The card program - the product design, rewards, limits and brand experience - sits on top of that issuing infrastructure.
A BIN (Bank Identification Number) is the first 6-8 digits of a card - it identifies the issuing institution, card type and network. To issue cards, you need a BIN range, and only licensed Visa/Mastercard members can hold BIN ranges directly. If you do not have a banking or e-money licence, you need a BIN sponsor: a licensed bank that extends a sub-range of its BIN to your program. The sponsor takes regulatory and scheme liability; you control the product. Most fintechs launching card programs in Europe use BIN sponsorship to go to market without acquiring their own full banking licence.
Most card programs need both. Virtual cards are issued instantly, cost almost nothing per unit and are ideal for online payments, subscriptions, B2B spend management and mobile wallet use. Physical cards are needed for in-store and ATM use, take 3-10 days to manufacture and deliver, and cost $2-8 each. A single card account can support both a physical card and one or more virtual cards simultaneously. If your product is digital-native or B2B, you can often launch with virtual-only and add physical later.
Card personalization means giving cardholders a card - and a card program - that is distinctly theirs and distinctly yours. Visually: custom artwork, brand colours, cardholder name, card material. Functionally: configurable spending categories, merchant blocks, rewards logic and notification language. Personalized card programs consistently show higher activation rates, higher monthly spend and lower churn compared to generic white-label products, because the card becomes part of the customer's relationship with your brand rather than just a commodity payment instrument.
Debit cards spend against the cardholder's own account balance in real time and can be issued by a bank, an EMI, or a fintech on a BIN sponsor's e-money licence. Prepaid cards spend funds loaded in advance and are typically issued under an EMI - common for gift cards, expense cards and payouts. Credit cards spend against a credit line the issuer extends and bills later, which requires a lending licence (or a sponsor that underwrites the credit) plus affordability checks and collections. Debit and prepaid programs are faster and lighter to launch; credit programs carry more licensing and risk overhead.
A virtual card issuing platform generates card credentials in software - instantly, with no physical manufacturing - and provisions them into mobile wallets like Apple Pay and Google Pay. Virtual cards cost almost nothing per unit, can be single-use or merchant-locked to limit fraud, and suit online payments, subscriptions and B2B spend management. A good platform lets you issue virtual and physical cards from the same account and API, set spending rules per card, and freeze or replace a card without disrupting the rest of the program. Crassula issues virtual cards instantly and lets you add physical cards on the same card account when needed.
It depends on the model. Building issuing infrastructure from scratch and negotiating scheme membership directly can run into seven figures and 12-18 months. Launching on a white-label platform with a pre-negotiated BIN sponsor and processor compresses that to weeks and a fraction of the cost, with pricing usually built from a setup fee plus per-card and per-transaction charges. Physical cards add $2-8 per unit in manufacturing and fulfilment; virtual cards are effectively free to produce. The main ongoing economics are interchange revenue on each transaction against processor, scheme and sponsor fees.
Two main tracks. First, PCI DSS: any entity that stores, processes or transmits card data must comply with the Payment Card Industry Data Security Standard (v4.0 in 2026). Tokenization and a PCI-certified processor dramatically reduce your scope. Second, card scheme rules: Visa and Mastercard rulebooks govern card design, cardholder authentication (3DS2/SCA under PSD2 in the EU), chargeback handling and fraud thresholds. Your BIN sponsor is responsible to the scheme, but your product must be designed to comply. Additional layers: KYC/AML at onboarding, GDPR for EU cardholder data, and any specific e-money or payment institution requirements in your jurisdiction.
Crassula provides a complete card issuing platform: authorization server, virtual and physical card issuance, BIN sponsor and processor connectivity, white-label mobile app, compliance tools (KYC, AML, 3DS2) and admin console. You configure card programs, spending rules and brand design without writing code. Pre-negotiated scheme connectivity means a new card program can launch in weeks. More than 150 companies run their card programs on Crassula's platform.
