How Prepaid Card Works
A prepaid card operates on a simple spend-what-you-load model. Funds are deposited onto the card before any purchase is made, and the payment network validates each transaction against the available balance in real time. Understanding the end-to-end flow is essential for merchants and developers building or accepting prepaid instruments.
Card Issuance
A card issuer — typically a bank, fintech company, or retailer — provisions a prepaid card linked to a dedicated stored-value account. The card is assigned a BIN (Bank Identification Number) that identifies it as prepaid on the payment network. Cards may be physical, virtual, or both, depending on the program design.
Loading Funds
The cardholder deposits money onto the card through one of several reload channels: bank transfer (ACH), cash reload at a retail reload location, direct deposit of payroll or government benefits, or a card-to-card transfer. Reload limits are set by the issuer and are typically governed by the card's KYC tier — anonymous cards carry lower limits than fully verified accounts.
Transaction Authorization
At checkout, the merchant's terminal or payment gateway submits an authorization request to the payment network (Visa, Mastercard, etc.). The network routes the request to the card issuer, which checks the available balance against the requested amount in real time and returns an approval or decline response within milliseconds.
Balance Deduction
If sufficient funds exist, the issuer approves the transaction and places a hold on the authorized amount. Funds are captured and settled — typically within one to two business days — reducing the card's available balance accordingly. When the available balance is lower than the requested amount, many prepaid issuers return a partial approval for the available amount rather than a hard decline.
Reload or Disposal
Reloadable prepaid cards allow the cardholder to add funds and continue using the card. Non-reloadable cards — common for gift cards and single-use promotional programs — are discarded once the balance reaches zero. Some issuers charge dormancy fees on inactive balances, which erode remaining value over time if the card is not used or refunded.
Why Prepaid Card Matters
Prepaid cards occupy a uniquely broad role in the payments landscape, serving both financially excluded consumers and sophisticated enterprise disbursement programs at scale. Their consistent growth across consumer, government, and B2B segments reflects durable demand rather than a niche use case.
According to Allied Market Research, the global prepaid card market was valued at approximately $2.03 trillion in 2022 and is projected to reach $4.76 trillion by 2030, growing at a compound annual rate of around 11.2%. This expansion is driven by rising e-commerce adoption, corporate expense management needs, and the accelerating shift away from cash disbursements in insurance, HR, and government programs.
The World Bank's 2021 Global Findex report found that approximately 1.4 billion adults worldwide remain unbanked, making prepaid cards a primary financial access tool in markets where traditional bank accounts are unavailable or culturally avoided. In the United States, the FDIC's 2021 National Survey of Unbanked and Underbanked Households estimated that 4.5% of US households — roughly 5.9 million — were unbanked, representing a substantial addressable population for prepaid products.
Prepaid in B2B
Beyond consumer use, prepaid cards underpin enterprise disbursement programs at scale: insurance claim payouts, gig economy worker payments, healthcare flexible spending accounts (FSAs), corporate virtual card programs for AP automation, and government benefit transfers such as EBT all rely on prepaid infrastructure.
Prepaid Card vs. Debit Card
Merchants and developers frequently conflate prepaid cards with debit cards because both instruments draw from a pre-existing balance rather than extending credit. The operational differences matter significantly for fraud management, authorization logic, compliance, and customer support design.
| Attribute | Prepaid Card | Debit Card |
|---|---|---|
| Linked account | Standalone stored-value account | Demand deposit account (DDA) at a bank |
| Bank account required | No | Yes |
| Credit check required | No | No (but bank relationship required) |
| Overdraft possible | No (unless issuer enables opt-in feature) | Yes, with overdraft protection enabled |
| Reload method | Cash, ACH, direct deposit, card-to-card | Direct deposit, linked bank transfers |
| KYC requirement | Tiered — low for unregistered, full for high-value | Full KYC at account opening |
| Partial approval support | Common across issuers | Rare — most decline if insufficient funds |
| Chargeback rights | Network-dependent, often limited | Full Reg E protections in the US |
| Primary use cases | Disbursements, gifting, unbanked consumers | Everyday banking transactions |
The single most impactful operational difference for developers is partial authorization behavior. Prepaid issuers frequently return approvals for less than the requested amount rather than declining outright. Payment integrations must handle this response gracefully — prompting for a secondary payment method for the remainder — or the transaction fails silently.
Types of Prepaid Card
Prepaid cards span a wide product spectrum. The architecture of a prepaid program — open or closed loop, reloadable or not, physical or virtual — determines its acceptance footprint, regulatory obligations, and the use cases it can serve.
Open-Loop Prepaid Cards run on major payment networks (Visa, Mastercard, American Express) and are accepted at any merchant that accepts those networks. They include general-purpose reloadable cards, virtual cards optimized for online spending, and payroll cards.
Closed-Loop Prepaid Cards are restricted to a specific merchant or merchant group. A coffee chain gift card, a transit fare card, or a gaming platform currency card are all closed-loop instruments. Because these cards do not route through an external payment network, they carry fewer regulatory requirements but also carry much narrower acceptance.
Reloadable Prepaid Cards allow the cardholder to add funds multiple times. They are standard in payroll programs, government benefit distribution (such as EBT), and consumer budgeting tools. Higher reload limits and balance caps typically require enhanced identity verification under tiered KYC frameworks.
Non-Reloadable (Single-Use) Cards are pre-loaded with a fixed amount and discarded once spent. They are common in promotional campaigns, insurance disbursements, and incentive rewards programs where the issuer wants to bound the liability to a specific amount.
Virtual Prepaid Cards exist solely as a card number, expiry date, and CVV — no physical plastic is issued. They are purpose-built for card-not-present and online transactions and are increasingly used for B2B supplier payments, subscription management, and employee virtual expense cards.
Payroll Cards are a regulated subset of reloadable prepaid cards used to pay employee wages. In the United States they are subject to the Electronic Fund Transfer Act (EFTA) and an array of state-level payroll delivery laws that govern fee restrictions and access to funds.
A stored-value card is the broader technical category encompassing most of these variants. The distinction between "stored-value card" and "prepaid card" is largely one of framing: stored-value is the infrastructure term, prepaid card is the consumer-facing product label.
Best Practices
Effective prepaid card programs require discipline across both merchant operations and technical implementation. Mistakes in either domain drive chargebacks, compliance exposure, and poor cardholder experiences that erode program economics.
For Merchants
Disclose all fees before purchase. Activation fees, monthly maintenance fees, reload fees, and dormancy fees must be prominently disclosed before the card changes hands. The US CFPB and the EU Payment Services Directive both enforce strict prepaid fee transparency requirements. Non-disclosure is the most common source of regulatory action against prepaid program managers.
Distinguish open-loop from closed-loop acceptance. Not all prepaid cards are accepted everywhere. Train customer service staff to identify closed-loop declines — where the card is simply not valid at your merchant — versus insufficient-funds declines, so they can direct customers toward the correct resolution without unnecessary friction.
Build out reload partnerships for consumer programs. For reloadable cards targeting cash-preferred or unbanked customers, partnering with established cash reload networks (InComm, PayNearMe, Green Dot's reload network) dramatically expands accessibility beyond digital-only loading channels.
Encourage card registration. Unregistered prepaid cards cannot be replaced if lost or stolen and are subject to lower balance and reload limits under KYC tiering. Embedding a registration prompt in the activation flow improves cardholder protection and increases average program balances.
For Developers
Implement partial authorization handling as a first-class feature. Your payment integration must be capable of receiving a partial approval response, charging the available balance, and prompting the cardholder for a secondary payment method for the remaining amount. This is not an edge case — it is routine for prepaid card transactions.
Enforce reload limits at the application layer. Validate per-load and aggregate balance limits in your UI before submitting a reload request to the issuer API. Surfacing limit errors at the application layer rather than through API error responses produces a significantly better user experience and reduces failed API calls.
Account for pre-authorization holds in balance display. Hotels, car rental companies, and fuel merchants place holds that can tie up a card's available balance well beyond the final settled transaction amount. If your platform displays a real-time balance, factor hold release timelines into the calculation to avoid confusing cardholders.
Include prepaid BIN ranges in your test matrix. Prepaid credit cards and debit instruments share BIN structures with distinct behavioral differences. Some payment gateways block prepaid BINs for recurring billing by default. Test against known prepaid BIN ranges before enabling subscription or recurring charge flows.
Common Mistakes
Prepaid card programs that fail in production consistently share the same set of avoidable errors. These mistakes surface across product design, compliance, and technical integration and are disproportionately costly once a program has scaled.
1. Violating dormancy fee regulations. In the US, the CARD Act prohibits inactivity fees until a card has been dormant for 12 consecutive months, and cards must remain valid for at least five years from purchase. Many program managers building on legacy issuer platforms inherit fee schedules that violate these rules without realizing it until an enforcement action or class-action complaint surfaces.
2. Conflating open-loop and closed-loop compliance requirements. Closed-loop gift cards have different AML thresholds, Bank Secrecy Act treatment, and state escheatment rules compared to open-loop prepaid cards. Designing a program assuming closed-loop simplicity and then adding Visa or Mastercard network connectivity mid-build is a common and expensive mistake that requires regulatory re-classification.
3. Skipping partial approval handling entirely. Developers who treat authorization as a binary approved/declined outcome will generate silent failures for prepaid cards with partial balances. In checkout flows without a fallback payment option, this results in abandoned carts and cardholder frustration that is difficult to diagnose from standard decline reporting.
4. Underestimating KYC tiering complexity. Tiered KYC models — anonymous cards with low limits, registered cards with higher limits, fully verified cards at the top tier — create significant operational overhead for identity verification, tier upgrade workflows, and compliance documentation. Product teams systematically underestimate this complexity when initially scoping a prepaid program.
5. Using generic decline messages for prepaid-specific failures. Prepaid cards return issuer-specific decline codes — insufficient funds, card not active, reload limit exceeded, card blocked for card-not-present use — that differ from standard decline codes. Surfacing only a generic "card declined" message to cardholders misses the opportunity to guide them toward a clear resolution path, increasing support volume and program churn.
Prepaid Card and Tagada
Prepaid cards introduce authorization patterns — partial approvals, tiered balance limits, BIN-specific routing rules — that require careful handling at the payment orchestration layer. Tagada's platform manages these complexities by applying BIN intelligence to identify prepaid instruments and adjusting the authorization flow accordingly across connected processors.
Orchestrating Prepaid Transactions
When accepting prepaid cards through Tagada, enable partial authorization handling in your integration configuration. Tagada automatically detects prepaid BIN ranges, requests partial approvals where the network supports it, and surfaces the split-payment prompt to cardholders — reducing hard declines and improving checkout conversion for prepaid instruments without custom integration work on your side.
For businesses running outbound disbursement programs — payroll cards, insurance claim payouts, incentive campaigns, or gig worker earnings distribution — Tagada can orchestrate the funding flow alongside inbound acceptance, providing unified transaction reporting, reconciliation, and failure-handling across both directions of money movement within a single integration.