For decades, the mental model of a payment card was simple: a physical piece of plastic represented an account, and that account had a balance or credit limit behind it.
You applied for a card. The issuer approved you. The issuer established an account and made spending capacity available to it. A card was manufactured, personalized, and delivered. When you eventually used it, the merchant sent an authorization request through the card network, and the issuer checked whether the transaction could be approved.
Digital wallets changed the interface, but not the fundamental architecture. Apple Pay or Google Wallet could tokenize the card, but the token still represented an existing card account.
Banking-as-a-Service introduced a different possibility.
Instead of requiring cardholder accounts to remain continuously pre-funded, some card programs can use Just-In-Time (JIT) Funding: required funding can be made available in connection with an authorization, based on the transaction and the program’s rules.
This changes the role of the card.
The card is no longer best understood as a physical object with a permanently attached pool of money. It becomes a credential connected to an authorization system whose funding and spending decisions can be executed programmatically.
That is the architectural shift.
1. The Card Is Not the Money
The first conceptual mistake is to think of a 16-digit card number as an account that “contains” money.
It does not.
A card credential identifies a payment instrument. The economic value behind that instrument lives in accounts, ledgers, funding sources, credit facilities, and settlement relationships maintained by the issuer and its infrastructure providers.
A virtual card therefore does not need to be a digital version of a piece of plastic with its own independent balance.
A program can create a virtual card credential and associate it with a particular cardholder, account, or spending policy. The credential can then be governed by rules such as:
- maximum transaction amount;
- merchant category;
- geography;
- online versus card-present usage;
- number of permitted transactions;
- expiration time;
- available customer balance; and
- program-specific risk controls.
The credential persists.
The decision about whether it can spend can be evaluated dynamically.
This distinction is important because JIT funding is not the creation of money when a card is swiped. It is a mechanism for making the necessary funding available to the card program’s transaction account at the time the authorization is processed.
So “stateless card” is useful as an architectural metaphor, but not literally.
The card still has state: its credential, status, controls, lifecycle, and transaction history all persist.
What becomes dynamic is the funding and authorization decision.
2. The Authorization Flow: Where JIT Happens
Consider a user with a virtual card attempting to purchase a $50 item online.
The transaction begins like an ordinary card payment.
Step 1: The merchant sends an authorization
The merchant submits the transaction through its acquiring bank or payment processor.
The transaction travels through the card network and reaches the infrastructure responsible for authorizing the card.
Conceptually:
MERCHANT
│
▼
ACQUIRER
│
▼
CARD NETWORK
│
▼
ISSUER / CARD PROCESSOR
Nothing about this first part requires the network to understand the application’s internal architecture.
It sees a normal card authorization request.
Step 2: The issuer processor evaluates the transaction
The issuer processor receives information such as:
- card credential;
- transaction amount;
- merchant;
- merchant category;
- transaction type;
- currency;
- location; and
- other authorization data.
The processor applies the card program’s controls.
For a JIT program, this can include a request to the program’s own authorization or funding logic.
In a gateway-based JIT model, for example, the processor can send transaction information to the program’s gateway, allowing the program to participate in the real-time funding and authorization decision.
That makes the authorization layer programmable.
Step 3: The funding decision is made
Suppose the user’s available economic balance is $500 and the requested transaction is $50.
The program might evaluate:
Available balance: $500
Transaction: $50
Merchant allowed: YES
Card active: YES
Daily limit: $200
Daily spend so far: $80
Decision: APPROVEThe system can now authorize the transaction and, where the JIT architecture requires it, make the necessary funding available to the card program or relevant account.
This is the critical distinction:
The system is not creating $50 of new money. It is making the required funding available to satisfy the transaction.
Step 4: The authorization is returned to the network
Once the issuer-side processing succeeds, the processor sends an authorization response back through the card network.
PROGRAM / PROCESSOR
│
│ APPROVED
▼
CARD NETWORK
│
▼
ACQUIRER
│
▼
MERCHANT
The merchant receives the approval.
From the merchant’s perspective, this looks like a normal card transaction.
The complexity is inside the issuer’s infrastructure.
3. The Programmable Rule Engine
This is where BaaS becomes particularly interesting.
The card credential can become a programmable authorization surface.
Instead of defining a card only by its static spending limit, the program can define the conditions under which an authorization is allowed.
Consider a delivery company issuing virtual cards to drivers.
The policy might be:
CARD = DRIVER_8472
Allowed MCCs:
Gas stations
Parking
Maximum per transaction:
$150
Daily maximum:
$300
International transactions:
DENY
E-commerce:
DENYThe driver can possess a perfectly valid card credential.
But validity does not imply permission.
When the driver attempts to purchase $90 of fuel:
CARD VALID? YES
MCC ALLOWED? YES
AMOUNT <= $150? YES
DAILY LIMIT AVAILABLE? YES
↓
APPROVEIf the same driver attempts to purchase a $90 television:
CARD VALID? YES
MCC ALLOWED? NO
↓
DECLINEThe credential did not change.
The authorization state did.
This is why programmable cards are better understood as policy-controlled payment instruments rather than merely virtual versions of physical cards.
4. Single-Use Cards
The same programmable card infrastructure makes single-use and purpose-specific credentials possible.
A program can generate a virtual card for a particular transaction and configure controls so that only one authorized transaction is permitted.
After the transaction, the credential can be terminated, suspended, or rendered unusable according to the program’s implementation.
The security benefit is straightforward.
Suppose a user generates a virtual card for a merchant they do not completely trust.
Instead of exposing their primary card credential, they provide a credential constrained by:
Merchant: Example Merchant
Maximum: $75
Transactions: 1
Expiration: Short-lived
The payment credential becomes disposable infrastructure.
The underlying account remains persistent.
5. Dynamic Spending Limits
JIT architecture also makes spending controls more dynamic.
Imagine that an application maintains this state:
Available customer balance: $420
Essential categories:
Allowed
Non-essential categories:
Maximum $100/day
High-risk categories:
BlockedThe customer spends $350.
The application now knows that only $70 remains available.
The next authorization can be evaluated against the updated state.
There is no need to wait for a monthly statement or manually reconfigure a physical card.
The authorization service can make a decision from current program state.
This is one of the fundamental advantages of putting programmable logic directly into the payment authorization path.
Modern issuing platforms expose similar concepts through real-time authorization controls, merchant-category restrictions, geographic controls, and dynamic spending limits.
6. The Authorization State Machine
The transaction can be understood as a state machine:
CARD CREDENTIAL EXISTS
│
▼
AUTHORIZATION REQUEST
│
▼
PROGRAM RULES / RISK CHECK
│
▼
FUNDING / AUTHORIZATION DECISION
│
▼
FUNDS MADE AVAILABLE /
AUTHORIZATION HOLD CREATED
│
▼
AUTHORIZATION APPROVED
│
▼
CLEARING
│
▼
FINAL SETTLEMENTThe exact ordering of funding, reservation, and authorization operations depends on the implementation.
The important point is that authorization and settlement are different events.
An authorization says, in effect:
This transaction is currently approved under the issuer’s rules.
Clearing later provides the transaction information used to determine what ultimately needs to be settled.
Settlement is the subsequent movement of funds between the relevant financial institutions.
This distinction matters because the final amount does not always have to equal the original authorization.
A restaurant transaction, for example, can authorize one amount and later clear for another because of a tip. Other transactions can be reversed, partially captured, or otherwise adjusted.
The infrastructure must therefore reconcile authorization state with clearing state.
7. What Actually Happens to the Ledger?
This is where the original “transient settlement ledger” concept needs precision.
There isn’t one universal BaaS architecture.
Different providers can implement their ledgers and funding flows differently.
One implementation might maintain a program ledger representing the customer’s available balance.
Another might use a processor-managed account structure.
Another might have the BaaS application maintain its own ledger while the processor maintains the card transaction ledger.
The important invariant is not the name of the ledger.
It is the sequence of economic events:
CUSTOMER BALANCE
│
│ authorization
▼
AVAILABLE FUNDS
│
│ temporary reservation / funding
▼
CARD TRANSACTION
│
│ clearing
▼
SETTLED OBLIGATIONIn a JIT architecture, the relevant account does not necessarily need to remain permanently funded.
Depending on the implementation, funding can be provided in connection with authorization and later reconciled when the transaction clears.
That is a much more precise way to describe the mechanism than saying that money simply “appears in a settlement ledger.”
8. Authorization Is Not Settlement
This distinction is one of the most important concepts in payment infrastructure.
Consider a $100 purchase.
At authorization:
Merchant asks:
"Can I spend $100?"
Issuer-side system:
"Yes, subject to these rules."A temporary hold or corresponding funding state can then be established.
Later, the merchant submits the transaction for clearing.
The final transaction might be:
Authorized: $100
Cleared: $97or:
Authorized: $100
Cleared: $105depending on the transaction type and circumstances.
The infrastructure must therefore reconcile authorization state with clearing state.
This is why a real card platform needs more than a simple:
balance -= $100operation.
It needs transaction identifiers, authorization records, reversals, clearing records, settlement records, holds, adjustments, and reconciliation logic.
JIT funding doesn’t eliminate this complexity.
It moves an important funding decision into the real-time authorization path.
Real issuing systems explicitly support authorization reversals, incremental or partial authorizations, clearing, and other transaction lifecycle events rather than treating a card payment as one atomic balance subtraction.
9. The Real Architectural Innovation
The breakthrough in modern card infrastructure is therefore not that virtual cards somehow eliminate the ledger.
They don’t.
It is not that a 16-digit number itself holds money.
It doesn’t.
And it is not that money is magically created at the moment someone clicks “Buy.”
It isn’t.
The real innovation is that the funding and authorization relationship can be dynamically orchestrated by software.
A traditional model looks approximately like:
FUND ACCOUNT
│
▼
ACCOUNT MAINTAINS BALANCE
│
▼
CARD TRANSACTION
│
▼
AUTHORIZATION
A JIT model can look more like:
CARD TRANSACTION
│
▼
AUTHORIZATION REQUEST
│
▼
PROGRAMMABLE DECISION
│
├─────── NO ──────► DECLINE
│
▼ YES
FUND / MAKE AVAILABLE
│
▼
AUTHORIZATION
│
▼
CLEARING
│
▼
SETTLEMENT
That is the architectural inversion.
Instead of asking:
“Is this cardholder account already funded enough?”
the system can ask:
“Given this transaction, these rules, and this current account state, should we make the required funding available now?”
10. The Programmable Card
This changes what a card represents.
A physical card is a durable credential attached to a financial account.
A virtual card can be created, modified, constrained, suspended, or terminated entirely through software.
And with JIT funding, the funding relationship can also be orchestrated at transaction time.
The result is a new abstraction:
USER
│
▼
VIRTUAL CARD
│
▼
AUTHORIZATION API
│
┌──────┴──────┐
│ │
▼ ▼
ACCOUNT RULE ENGINE
/ LEDGER / RISK LOGIC
│ │
└──────┬──────┘
│
▼
FUNDING DECISION
│
▼
CARD NETWORK
│
▼
MERCHANT
The card is no longer primarily a piece of plastic.
It is a credential connected to a programmable financial system.
The Architecture Revealed
The most important shift introduced by modern card infrastructure is not the disappearance of the physical card.
It is the separation of concepts that older payment systems encouraged us to think of as one thing:
credential, account, authorization, funding, clearing, and settlement.
They are different layers.
A card credential identifies the payment instrument.
A ledger represents economic ownership or obligation.
An authorization determines whether a proposed transaction can proceed.
JIT funding determines how required funding can be made available at transaction time.
Clearing establishes the transaction that ultimately needs to be settled.
Settlement moves the resulting financial obligation through the payment ecosystem.
Once those layers are separated, the card becomes software-controlled infrastructure.
The user sees a 16-digit number.
The merchant sees an authorization response.
The card network sees a conventional payment transaction.
But underneath those interfaces is a programmable state machine deciding, in real time, whether the transaction is permitted and how the corresponding funding should be handled.
That is the real promise of modern card infrastructure.
The programmable card is not a card with software attached to it.
It is a software-defined payment instrument connected to a financial ledger and a real-time authorization system.
And that is why modern card-issuing infrastructure can produce a new virtual card in seconds without ever manufacturing a piece of plastic.