Credit, Debit, Prepaid, EBT and Closed-Loop Value. A practitioner comparison of credit, debit, prepaid, EBT and closed-loop value across funding source, authoritative ledger, regulation, authorization impact, posting, disputes, accounting, reconciliation, fraud, operations and migration.
A customer can present five cards that look almost identical at a checkout counter and yet the bank, merchant, processor and regulator may be dealing with five very different financial products. One card may draw on a revolving credit line. Another may debit a checking account. A third may spend value that was loaded in advance. A fourth may access government benefits that can be used only for eligible purposes. A fifth may represent value that exists only inside one merchant or a defined merchant group.
That distinction is the subject of Chapter 30.
Chapter 27 explained the US card ecosystem and its participants. Chapter 28 owns the real-time authorization lifecycle. Chapter 29 owns clearing, interchange, settlement and merchant funding. This chapter does not repeat those mechanics. Instead, it asks a different bank-grade question: what is the financial value behind the credential, who owns that value or credit exposure, what legal and product rules apply, and how does that change processing, controls, posting, disputes, reconciliation and operations?
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–7 and Sections 10–13. For the next 10 minutes, use the chapter’s three diagrams to identify the ledger and source of value behind each card product. Use 10 minutes to work through one operational case in Section 15, then spend the final 5 minutes explaining: Why would the same purchase create different accounting and control requirements across card products? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Why card form factor and financial product must be separated
- The five value models at a glance
- Credit cards: revolving credit, charge structures and issuer exposure
- Debit cards: deposit-account access and immediate asset-account impact
- Prepaid cards: stored value, pooled funds and program structures
- EBT: government benefit value and program-controlled spending
- Closed-loop value: merchant-specific balances, gift cards and private ecosystems
- Funding, loading, repayment and balance lifecycle
- Transaction processing differences across the five models
- Limits, controls, fraud and customer-protection boundaries
- Returns, refunds, disputes, chargebacks and error resolution
- Settlement, accounting and financial-position differences
- Reconciliation, reporting and break management
- Real-bank architecture and data ownership
- Operational cases, testing and production controls
- Role checklist, learning closure and authoritative references
1. Why card form factor and financial product must be separated
A card number, token or chip credential is an access mechanism. It is not, by itself, the financial product. That distinction sounds basic, but it is one of the most important architecture rules in card banking. A physical card can access a revolving credit account, a checking account, a general-purpose reloadable prepaid account, a government-benefit balance, or a merchant-specific stored-value ledger. A digital wallet can carry any of those credentials as well. If a bank models everything as simply CARD, it eventually creates ambiguity in limits, posting, disclosures, disputes, accounting and reconciliation.
The strongest bank implementations therefore separate at least four dimensions: credential type, product type, funding source and transaction rail. Credential type tells us whether the customer used PAN, network token, chip, contactless credential, mobile wallet token or another approved form. Product type tells us whether the underlying relationship is credit, debit, prepaid, EBT or closed-loop. Funding source tells us whether value comes from a credit line, deposit balance, prefunded pooled account, government program ledger or merchant liability ledger. Transaction rail tells us which network or private switch carried the payment.
This separation matters because two transactions routed through the same network can produce different accounting. A $100 credit-card purchase increases the cardholder's receivable or loan-like balance subject to the issuer's card-account model. A $100 debit-card purchase reduces available funds in an asset account. A $100 prepaid purchase reduces stored value already funded in advance. A $100 SNAP EBT purchase reduces an eligible government-benefit balance, not the customer's checking account. A $100 store gift-card purchase reduces the merchant's deferred-value liability or program ledger.
It also matters for customer protection. Consumer credit cards sit principally inside the Truth in Lending Act and Regulation Z framework for consumer credit, with specific credit-card provisions. Consumer debit transfers and many prepaid-account transactions sit inside the Electronic Fund Transfer Act and Regulation E framework. Gift cards have a specific Regulation E section covering matters such as expiration and certain fees. Government-benefit arrangements have their own treatment and may also be governed by program-specific law. EBT is additionally constrained by the benefit program itself: what can be purchased, where, with which balance, and under what authorization rules.
The product is therefore not cosmetic metadata. It changes the bank's legal obligation, credit exposure, customer balance, control framework, accounting event and operational response.
2. The five value models at a glance
A useful mental model starts with the question, “Whose money is being spent at the moment of purchase?”
With a credit card, the customer is normally drawing on credit made available by the issuer. The customer may later repay the issuer according to the account terms. The issuer therefore manages credit exposure, available credit, billing cycles, minimum payments, interest or finance charges where applicable, delinquency and collections. Authorization is not merely a funds check; it is a decision against credit availability, account status, fraud risk and issuer policy.
With a debit card, the customer generally accesses funds in a deposit or transaction account. The bank must protect the integrity of the underlying asset account, manage available balance and holds, and post the financial transaction against that account. The card network may resemble a credit-card network technically, but the underlying financial relationship is fundamentally different. US debit also carries Regulation II routing and interchange considerations that do not apply in the same way to credit cards.
With a prepaid card, value is typically funded before it is spent. The customer or another party loads money into a prepaid program. Depending on program design, the actual funds may sit in pooled or custodial accounts while the prepaid platform maintains a subledger showing each cardholder's balance. The CFPB prepaid-account framework applies to covered prepaid accounts and creates tailored disclosure, error-resolution and account-history requirements. Some prepaid structures also create deposit-insurance questions depending on how underlying funds are held and recorded.
With EBT, the balance represents government benefits rather than ordinary customer funds. SNAP EBT is the clearest example. The customer can use an EBT credential at an authorized retailer to spend eligible SNAP benefits. Program controls determine what value exists and what can be purchased. The retailer, acquirer/processor, state EBT environment and USDA/FNS authorization framework all matter. This is not simply “another prepaid card” even if some technology resembles stored-value processing.
With closed-loop value, the customer usually holds value redeemable only at a particular merchant, affiliated merchant group, campus, transit system or other restricted ecosystem. A store gift card is the familiar example. There may be no Visa/Mastercard/Discover/Amex network in the transaction path. The merchant or program manager can maintain the value ledger and authorize transactions directly or through a private processor. The economics, settlement and reconciliation model can therefore be radically different from open-loop cards.
The architecture consequence is that a bank or processor should never derive product behavior only from the card brand. A Visa-branded credential could be debit, credit or prepaid. The product master, BIN/IIN configuration, account relationship and program configuration must collectively determine how the transaction is processed.
3. Credit cards: revolving credit, charge structures and issuer exposure
A consumer credit card is a credit product first and a payment credential second. The issuer agrees to extend credit up to applicable limits and under account terms. The cardholder uses the credential to initiate purchases, cash-like transactions or other permitted activity, and the issuer records those transactions against the credit account. The customer later pays the issuer rather than having the purchase immediately debit a checking balance.
For a revolving credit-card account, several balances coexist. A credit limit defines the approved ceiling. Available credit reflects how much may still be used after posted balances, authorization holds and issuer rules. Current balance represents posted account activity. A statement balance captures the balance for a billing cycle. There may also be cash-advance balances, installment-plan balances, promotional balances, fees and interest components. A good card ledger does not flatten them into one number.
The authorization hold is especially important. When a merchant receives approval, the issuer often reduces available credit immediately even though the final transaction has not yet cleared. When presentment arrives, the posted transaction replaces or matches the authorization according to network and issuer logic. If the authorization expires or is reversed, the hold must be released correctly. Chapter 28 explains that lifecycle; Chapter 30 focuses on why the hold consumes credit availability, not deposit funds.
Regulation Z is central to US consumer credit-card operations. It governs consumer credit disclosures and contains extensive credit-card requirements around account opening, periodic statements, payment allocation, certain fees, billing-error procedures and other protections. Product teams must distinguish what is mandated by regulation from what is simply an issuer commercial policy.
Issuer economics also differ from debit. The issuer may earn interest, fees and interchange, but also bears credit losses, fraud losses, rewards expense, funding costs and operational costs. Credit risk therefore exists even when every individual card transaction is operationally valid. Portfolio management, underwriting and collections sit outside the network transaction itself but are inseparable from the credit-card product.
Operationally, credit-card accounts also require delinquency states, payment due dates, minimum payment logic, credit-line management, overlimit policies where applicable, account blocking, hardship or collections treatment and charge-off processes. Those states can affect whether a new authorization is accepted even when the technical credential is valid.
A useful requirement rule is: never use “balance” without naming which balance. Available credit, current balance, statement balance and outstanding principal are not interchangeable.
4. Debit cards: deposit-account access and immediate asset-account impact
A debit card is generally an access device to an asset account. The customer is spending money already held in a checking, transaction or other eligible account rather than drawing on a revolving line of credit. The issuer therefore has a different central question: does the underlying account have sufficient available funds and is the transaction allowed against that account?
Available balance may differ from ledger balance because the bank can have holds, pending debits, deposits not yet available, overdraft arrangements and other controls. The debit-card authorization engine therefore needs reliable access to account status and available-funds logic. If the card platform keeps a stale shadow balance without disciplined synchronization to the deposit ledger, the bank can approve transactions against money that is no longer available or decline transactions unnecessarily.
US debit cards also introduce a routing dimension under Regulation II. The Federal Reserve's rule requires debit cards to be enabled for processing over at least two unaffiliated networks and protects a merchant's ability to direct routing over enabled networks. The exact routing path may therefore depend on card configuration, transaction type, merchant routing choice, PIN capability, network reachability and processor logic. A debit card carrying a global network brand can also participate in unaffiliated debit-network routing.
The Regulation II interchange-fee standard applies to covered issuers, with exemptions for certain small issuers, certain government-administered programs and qualifying reloadable general-use prepaid cards. As of the Federal Reserve's 2026 small-issuer lists, institutions with assets below the statutory $10 billion threshold may qualify for the small-issuer exemption, subject to the rule's definitions and affiliate treatment. That exemption does not mean network-routing requirements disappear.
From a ledger perspective, debit transactions interact directly with customer deposits. Authorization may place a hold or reduce available balance. Presentment causes posting. Reversals and unmatched presentments must be controlled. A refund generally credits the deposit account when processed through the card system. If the account is closed or restricted, special handling may be required.
Consumer debit-card error handling also interacts with Regulation E. Unauthorized electronic fund transfers, error notices, investigation timing and provisional-credit requirements can be materially different from credit-card billing-error treatment. Product and operations teams therefore need a clean product classifier before the dispute engine chooses its workflow.
Debit is thus not “credit without a loan.” It has its own balance truth, legal framework, routing rights, account posting and reconciliation model.
5. Prepaid cards: stored value, pooled funds and program structures
Prepaid cards reverse the credit-card sequence: value is generally funded before spending. The account or program must know how much value has been loaded, how much remains available, who legally owns the underlying funds, where those funds are held, and whether the card is reloadable, general purpose, payroll-related, benefit-related or limited purpose.
The CFPB's prepaid rule brought covered prepaid accounts into a tailored Regulation E framework. Covered programs can include general-purpose reloadable cards and other prepaid accounts, with requirements addressing disclosures, limited liability, error resolution, transaction history and account agreements. Certain overdraft credit features linked to prepaid accounts can also create Regulation Z consequences.
A typical open-loop prepaid architecture separates the program bank or issuer, program manager, processor, network credential, funding account and cardholder subledger. Customer balances may be represented in a processor or program ledger even though cash is held in one or more pooled bank accounts. This creates a critical reconciliation requirement: the total liability represented by cardholder subledgers must reconcile to the safeguarded or custodial funds and any legitimate in-transit items.
Loading can occur through ACH, cash reload networks, payroll, card-to-card transfer, bank transfer, government disbursement or other approved mechanisms. Every load source has fraud, return and settlement implications. A load that appears immediately in the prepaid balance but later fails financially creates exposure unless the program controls availability properly.
Prepaid programs also vary in identity requirements and functionality. Some cards can be acquired before full customer verification but may have restrictions until registration or identity verification is completed. Reload capability, ATM access, person-to-person transfer, international use and cash access all change the risk profile.
Deposit insurance must be described carefully. A prepaid card is not automatically FDIC insured simply because a bank is somewhere in the program. FDIC coverage for underlying prepaid funds depends on how funds are deposited, recordkeeping, ownership and other requirements. The FDIC specifically notes that registered prepaid cards may be insured when the applicable requirements are met and that deposit insurance protects against bank failure, not every loss scenario.
The safest architecture principle is therefore: prepaid balance truth and pooled-cash truth are two separate ledgers that must reconcile continuously.
6. EBT: government benefit value and program-controlled spending
Electronic Benefits Transfer is a government-benefit delivery mechanism. The familiar customer experience resembles a debit card, but the value is not an ordinary checking balance. It represents benefits allocated under a government program and governed by program eligibility and usage rules.
SNAP EBT is administered through state systems under the federal SNAP framework. USDA's Food and Nutrition Service authorizes retailers to accept SNAP benefits. A retailer cannot simply decide to accept SNAP because it already accepts debit cards; it must satisfy the applicable retailer-authorization requirements. Online SNAP acceptance has additional requirements.
The EBT balance can also be benefit-type specific. A household may have SNAP food benefits and, depending on the state/program, cash-assistance value accessed through related EBT infrastructure. Those balances cannot be mixed casually because purchase eligibility and withdrawal rules differ.
At checkout, an EBT transaction needs to establish the correct benefit account, eligible amount and merchant/retailer authorization. In a mixed basket, only eligible items may be charged to SNAP. The remaining amount may be paid with another tender. The POS and retailer systems therefore need to separate tender eligibility before or during authorization.
A simplified SNAP path is: beneficiary → authorized retailer/POS → retailer processor/acquirer path → state EBT processor/system → benefit-account validation → approval/decline → retailer settlement/reimbursement process. The exact processor and settlement implementation varies by program and state, so a bank should not assume that a standard debit-network settlement file is the only source of truth.
Fraud controls also differ. EBT programs face stolen benefits, credential compromise, skimming, trafficking and retailer fraud. Controls can therefore exist at cardholder, retailer, transaction, device and program levels. A technically valid PIN transaction may still represent program fraud.
Regulation E treatment of government-benefit accounts is nuanced, and the regulation itself excludes certain needs-tested benefits established or administered under state/local programs from the defined government-benefit-account provision. SNAP and other EBT programs are also subject to their own statutory and program rules. For training purposes, the important lesson is not to force every EBT case into the generic prepaid or debit regulatory model without checking the specific program.
7. Closed-loop value: merchant-specific balances, gift cards and private ecosystems
Closed-loop value is spendable only inside a defined acceptance environment. A store gift card redeemable only at one retailer or an affiliated merchant group is the classic example, but closed-loop value can also appear in transit systems, campuses, gaming or entertainment ecosystems, cafeterias, loyalty wallets and other private networks.
Because the acceptance perimeter is restricted, the merchant or program operator can control both sides of the transaction. There may be no external card network, no traditional acquirer/issuer pair and no interbank card settlement. A transaction can simply reduce a stored-value liability in the merchant's ledger while recording the sale in the merchant's commerce system.
That does not make the model simple. The program still needs issuance, activation, load, redemption, refund, expiry/fee compliance where applicable, lost-card handling, fraud controls, breakage accounting, escheat/unclaimed-property analysis, channel synchronization and reconciliation between commerce and stored-value ledgers.
Regulation E §1005.20 provides federal requirements for covered gift cards and gift certificates, including restrictions relating to fees and expiration. The regulatory definition can cover cards, codes and other devices, so a digital gift code can be legally significant even without plastic.
Closed-loop should also be distinguished from open-loop gift cards. A gift card bearing a general-purpose network logo may be accepted broadly and involve an issuer, network and processor. It can still be a gift-card product even though its transaction path looks like other open-loop prepaid products. Conversely, most store gift cards are closed-loop and never touch the open-loop network.
Accounting is particularly important. When a merchant sells a $100 gift card, it typically receives cash but has not yet earned the retail sale represented by the future redemption. The merchant records an obligation or stored-value liability according to its accounting policy. When the customer redeems $60, the stored-value balance declines and the merchant records the underlying sale. Unredeemed balances create breakage and unclaimed-property questions that are outside ordinary card-network settlement.
A good bank or merchant architecture therefore treats closed-loop value as a liability-ledger product, not merely a payment method button.
8. Funding, loading, repayment and balance lifecycle
The five models become easiest to distinguish when viewed through the full value lifecycle.
Credit begins with underwriting and line assignment. Spending consumes available credit. Customer repayments restore available credit subject to posting rules. Interest, fees, credits and adjustments change the account balance. Delinquency and collections can restrict further spending.
Debit begins with deposit funding. Salary, ACH credits, cash deposits, transfers and other credits increase the underlying asset-account balance. Card spending reduces available funds and later posts as a debit. There is no separate “reload” event because the customer is funding a bank account, not a card balance.
Prepaid begins with issuance and load. The program must confirm the financial source of every load and decide when value becomes available. Reloads increase the prepaid subledger. Purchases, cash withdrawals, transfers and fees reduce it. Refunds and reversals restore value. Program closure requires returning remaining funds according to terms and law.
EBT begins with benefit authorization/allocation by the government program. Benefits are posted to the beneficiary's EBT balance according to the program schedule. Eligible purchases reduce that balance. The beneficiary does not normally “reload” SNAP benefits with personal funds, because the value source is the benefit program.
Closed-loop value begins with merchant/program issuance and funding. A gift-card sale creates stored value. Promotional value may be issued without equivalent customer cash and therefore needs separate accounting from purchased value. Redemptions reduce the liability. Refunds may restore closed-loop value rather than return cash depending on policy and law.
This lifecycle should be modeled explicitly in data. Fields such as funding_source, value_type, load_event_id, benefit_program, credit_line_id, deposit_account_id, stored_value_ledger_id and closed_loop_program_id allow the transaction layer to maintain traceability back to the economic source.
9. Transaction processing differences across the five models
All five products can show “approved,” but the decision behind that response is different.
For credit, the issuer checks account status, available credit, authorization holds, fraud, merchant and transaction controls, and credit policy. The financial effect of approval is normally a reduction in available credit through a hold, followed later by posting.
For debit, the issuer checks account status and available funds, plus card and fraud controls. Approval generally reserves or consumes spendable deposit funds. Debit routing may also involve network selection under Regulation II.
For prepaid, the processor or issuer checks the prepaid program account, available stored value, identity/program status, restrictions and fraud controls. The balance check may occur in a prepaid subledger rather than a core deposit ledger.
For EBT, the system checks program value, retailer eligibility and benefit-specific purchase rules. An available benefit balance alone is insufficient if the item or merchant is ineligible.
For closed-loop value, the merchant/program processor checks the private stored-value ledger and acceptance rules. The transaction may never leave the merchant ecosystem.
Offline behavior also differs. Allowing a transaction without real-time balance validation can create credit or negative-balance exposure in debit/prepaid/EBT programs. Some environments permit limited offline or fallback behavior under specific rules, but the product design must understand who bears the exposure. EBT and prepaid programs commonly require particularly controlled handling because the ledger balance is finite and externally constrained.
Partial approval is another product-sensitive feature. A prepaid or EBT balance may be lower than the transaction amount, and the system may support using the remaining value with another tender depending on network/program/merchant capability. The merchant must then present the correct split tender and avoid charging more than the approved amount.
10. Limits, controls, fraud and customer-protection boundaries
Every product needs limits, but the meaning of a limit changes by model.
Credit limits control issuer exposure. Additional limits may apply to cash advances, balance transfers, single transactions, merchant categories, geographies or risky channels. A transaction can be within the credit limit and still be declined for fraud or account-status reasons.
Debit limits protect the deposit account and the bank. Daily purchase, ATM and transfer limits may sit below the available account balance. Overdraft settings and account-level blocks can further influence approval.
Prepaid limits can apply to load value, account balance, purchase value, cash withdrawal, velocity and transfer activity. They may arise from program risk policy, regulatory obligations, network requirements or identity-verification status.
EBT controls include benefit balance, merchant eligibility and item/category eligibility. Transaction velocity, geographic anomalies and retailer patterns can also be monitored for fraud.
Closed-loop limits can include maximum card value, load frequency, redemption restrictions, promotional-value rules and channel limits. Fraud patterns include card-number enumeration, stolen activation data, refund abuse, account takeover and resale marketplaces.
Customer protection must be selected from the product/legal model rather than the UI. Credit-card billing errors, unauthorized debit EFTs, prepaid-account errors, gift-card restrictions and EBT benefit disputes are not one universal workflow. A servicing system that uses one generic “card dispute” process needs a rules layer that routes cases to the correct legal and operational path.
11. Returns, refunds, disputes, chargebacks and error resolution
The word “return” is dangerous in card programs because it can refer to a merchant refund, a network chargeback, a credit balance refund, a returned customer payment, a prepaid load reversal or a program-specific EBT correction.
A merchant refund is a commercial reversal of a sale. It normally travels from merchant/acquirer toward issuer and ultimately credits the customer's relevant account or value balance.
A chargeback/dispute is a network-governed financial dispute process. It can apply to credit, debit and some open-loop prepaid transactions because those products can use the same card network, although customer-protection obligations and account posting differ.
A Regulation E error investigation is a legal/customer servicing process concerning electronic fund transfers. It is not synonymous with a card-network chargeback, even though a bank may use chargeback rights as one recovery mechanism while separately meeting its customer obligations.
A credit-card billing-error investigation similarly exists in the Regulation Z context and should not be reduced to the network dispute outcome.
For prepaid, a valid network refund should restore prepaid value even if the original load source no longer exists. The processor needs to know which prepaid account to credit and how to treat a closed or blocked account.
For EBT, merchant voids, reversals and adjustments must respect program rules and the benefit ledger. A retailer cannot issue unrestricted cash simply because a normal debit-card refund might allow money to return to a bank account.
For closed-loop gift cards, refund policy may restore value to the same card, issue a new stored-value credential, or use another permitted method. The merchant's commerce and stored-value systems must agree on the refund event to avoid creating or destroying value incorrectly.
12. Settlement, accounting and financial-position differences
Chapter 29 explains card clearing and settlement in depth. Chapter 30 focuses on what settlement means after it reaches each product ledger.
For credit, issuer settlement outflow to the network/acquirer side creates or confirms a receivable from the cardholder. The cardholder has not yet funded the purchase. The issuer's balance sheet therefore carries customer credit exposure.
For debit, the transaction is funded from a deposit liability owed by the bank to the customer. Customer posting reduces that liability while network settlement moves the interbank financial position.
For prepaid, network settlement is funded from the program's underlying cash arrangements while the prepaid subledger liability to cardholders declines as purchases post. The program must ensure the customer subledger and safeguarded cash remain aligned after settlement, fees and in-transit items.
For EBT, settlement/reimbursement is connected to program funding rather than the beneficiary's private bank account. Program accounting must link retailer transaction value to benefit-account reduction and government funding.
For closed-loop value, there may be no network settlement at all. The merchant can recognize a retail sale and reduce a stored-value liability internally. If multiple affiliated merchants or franchisees participate, however, an internal settlement or reimbursement mechanism may be necessary between legal entities.
The key principle is: network settlement is not the same thing as customer-account accounting. A network can settle correctly while the wrong product ledger is posted.
13. Reconciliation, reporting and break management
Chapter 30 needs a product-aware reconciliation model. At minimum, the bank or program should reconcile transaction events, network or private-processor financial events, customer/product ledger entries and GL/control-account movements.
Credit reconciliation asks whether authorized and presented transactions correctly posted to the credit account, whether holds were released, whether settlement positions match network reports, and whether receivables/fees/interest were accounted correctly.
Debit reconciliation asks whether network presentments match customer-account debits, whether holds match posted items, whether settlement matches clearing, and whether reversals/refunds restored the right account.
Prepaid reconciliation adds the pooled-funds dimension. The sum of customer prepaid balances plus legitimate reconciling items must align to underlying cash and settlement accounts. An unexplained difference can mean customer-value loss or program overstatement.
EBT reconciliation links beneficiary benefit reductions, retailer transactions, processor records and program settlement/reimbursement. Program-level totals and retailer-level totals both matter.
Closed-loop reconciliation links issuance/load, redemption, refund, expiry, breakage and program liability. If one store's POS says a gift card was redeemed but the central value ledger did not reduce the balance, the customer may be able to spend the same value twice.
Operational break categories should therefore include AUTH_WITHOUT_PRESENTMENT, PRESENTMENT_WITHOUT_AUTH, LEDGER_POSTING_MISSING, WRONG_PRODUCT_LEDGER, LOAD_UNFUNDED, PREPAID_POOL_MISMATCH, EBT_ELIGIBILITY_MISMATCH, CLOSED_LOOP_REDEMPTION_MISMATCH, REFUND_NOT_APPLIED, and SETTLEMENT_GL_MISMATCH.
Reporting should expose product type explicitly. A report showing total “card spend” without separating credit, debit, prepaid and benefit programs hides fundamentally different risk and balance-sheet positions.
14. Real-bank architecture and data ownership
A mature card architecture usually contains a shared transaction layer plus product-specific ledgers and services. The shared layer can normalize credential, merchant, network, authorization and clearing identifiers. Product services then decide how those events affect available credit, deposit funds, prepaid value, benefit balances or closed-loop liabilities.
A canonical transaction record should therefore contain more than PAN/token and amount. Useful dimensions include product_family, funding_model, consumer_or_commercial, issuer_program, network, debit_network_capabilities, underlying_account_reference, benefit_program, closed_loop_program, regulatory_treatment, ledger_of_record, authorization_id, clearing_reference, settlement_reference, and customer_case_reference.
The ledger of record must be unambiguous. Credit account system for credit. Core deposit ledger for debit. Prepaid subledger for stored value. EBT benefit ledger for government value. Merchant/program stored-value ledger for closed-loop. Shadow balances can help performance, but they must not become uncontrolled competing truths.
Configuration also matters. BIN/IIN ranges and account metadata often drive product classification. A migration that changes processor or BIN configuration without preserving product type can route transactions into the wrong balance service. Testing therefore must verify configuration lineage, not just message syntax.
Shared fraud platforms should consume product context. The same $500 transaction can mean very different risk on a premium credit line, a payroll prepaid card, an EBT account or a store gift card. Models and rules that ignore product context generate weak decisions.
15. Operational cases, testing and production controls
Consider five $80 grocery transactions at the same merchant.
The credit card has $4,000 available credit. Authorization approves and places a hold. The issuer later posts the cleared transaction to the credit account.
The debit card has $120 available funds. Authorization reserves $80 against the deposit account. The eventual presentment posts an $80 debit.
The prepaid card has $60 stored value. Depending on program and merchant/network capability, the transaction may decline or partially approve $60 for split tender. The bank must not silently create a $20 negative prepaid balance unless the product explicitly permits a credit/overdraft feature with appropriate controls.
The SNAP EBT card has $100 of SNAP benefits, but the basket contains only $50 of SNAP-eligible items. The EBT path can approve only the eligible benefit amount; another tender must cover the remainder.
The store gift card has $80 value but is presented at a merchant outside its acceptance group. It declines even though the numerical balance is sufficient, because acceptance scope is part of the product.
Testing should therefore use the same commercial transaction across all product models and verify that product-specific outcomes differ correctly. Important tests include insufficient credit versus insufficient funds, expired authorization holds, overdraft settings, debit network routing, prepaid load reversal after spend, prepaid pooled-account mismatch, partial approval, EBT mixed basket, unauthorized EBT retailer, closed-loop wrong merchant, gift-card expiry/fee behavior, network refund to blocked account, lost/stolen credential, account closure, duplicate presentment and disaster-recovery reconciliation.
Production controls should monitor unusual negative balances, credit-line breaches, debit overdraft exceptions, prepaid subledger-to-cash differences, EBT retailer anomalies, closed-loop double redemption, refund failures and cross-product posting errors.
16. Role checklist, learning closure and authoritative references
A Business Analyst should be able to identify the exact product and funding model before documenting card requirements. “Support cards” is never enough. Requirements must name the ledger, balance type, customer protection, load/repayment process, limits, refund behavior and reconciliation source.
A Product Owner should understand that a common card UI can sit on very different economics and regulations. Product decisions around fees, rewards, overdraft, reload, cash access, benefit restrictions and expiry have downstream operational consequences.
An Architect should separate shared card-network services from product ledgers and preserve one financial system of record per value model.
A Developer should treat product type and funding model as first-class data and avoid hard-coded assumptions such as every Visa credential being credit or every PIN transaction being ordinary debit.
A Tester should test cross-product differences, not only happy-path authorization. The same transaction should intentionally produce different balance, routing, posting and dispute behavior by product.
Operations and reconciliation teams should be able to trace from credential to transaction to product ledger to settlement/accounting evidence. Prepaid and EBT teams additionally need program-level balance controls.
Fraud and compliance teams should understand the legal and program boundaries around customer liability, prepaid access, EBT restrictions and gift-card abuse.
Finance and Treasury should understand which balances represent receivables, deposit liabilities, prepaid liabilities, government-program positions or closed-loop merchant liabilities.
The final learning principle is:
A card tells you how the customer accesses value. The product tells you what that value actually is.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.