JIT funding for stablecoin cards: what happens in the few seconds of authorisation

Just-in-time (JIT) funding means a card account holds no balance until someone taps the card: your system moves the money while the scheme waits for an answer. With stablecoins, that move is an on-chain transfer, and the hard part is not the transfer but everything that happens after you say yes.

This is now a mainstream problem. Visa says more than 160 stablecoin-linked card programmes run on its network, with payment volume on them growing nearly 200% year on year [1]. On 15 October Mastercard and BVNK launched a platform that includes "stablecoin-linked cards" [2]. Many of those programmes will fund each payment just in time.

We have built crypto-wallet card issuing: the card ledger, JIT funding on Solana and clearing reconciliation. This post walks one payment from authorisation to refund, with synthetic examples.

The window

At authorisation, the processor asks your system whether to approve. Processors document how long you have:

• Marqeta's gateway JIT funding declines the payment if your gateway does not answer within three seconds [4].
• Lithic declines if it gets no answer within 6 seconds, and recommends answering within 3 [5].
• In Mastercard's processing documentation, its processing platform has at most 7 seconds to answer Mastercard, and treats an issuer that has not answered in 4 seconds as timed out [6].

So the budget is a few seconds, set by your processor, and it has to cover your fraud checks, your ledger write and the chain.

Where the money comes from

In the usual JIT model, accounts carry no balance and funds move from a funding source into the account at transaction time [3]. With a self-custody wallet on Solana, a common funding source is a token delegate. The user signs an Approve once, which records a delegate and an allowance on their token account; a token account has one delegate and one delegated amount at a time [7]. The programme's funding service can then transfer up to that allowance without the user signing each payment.

The token program checks the allowance on every delegated transfer. If the delegated amount is less than the transfer, it fails with InsufficientFunds; otherwise it subtracts the amount, and clears the delegate when the allowance reaches zero [8]. Three things follow:

• A user who spends their tokens elsewhere, revokes the delegate or approves a new one can make your pull fail at any moment.
• The allowance runs down. Your ledger needs to know the remaining allowance, not just the token balance.
• A pull that fails after you approved leaves you owing the scheme for a payment you never funded.

Why you wait for confirmation

The tempting design approves first and transfers afterwards. Don't. Once you approve, the payment will clear and you settle it with the scheme whatever happened on chain. Send the transfer, wait for it to land, then answer.

Which commitment level to wait for is a trade-off. Solana's documentation says confirmed is only a few slots behind processed and has a very low chance of being on a dropped fork, and that the latest finalized block is typically at least 32 slots, about 13 seconds, behind the latest confirmed one [9]. Thirteen seconds is longer than every deadline above. In practice that means confirmed, a hard internal deadline below the processor's, and a decline if the transfer has not confirmed by then.

Two details matter here:

• A blockhash expires after roughly 60 to 90 seconds, and RPC nodes may drop a transaction they cannot forward [9]. A transfer that missed your deadline might still land later. Track it by signature until its blockhash has expired, and reverse it if it lands after you declined.
• Marqeta warns that if your system authorises after the gateway has already timed out, your records fall out of step with the transaction, and says to reverse such authorisations [4].

Timeouts and stand-in

A timeout at the processor is usually a decline [4][5]. A failure further up is different. Mastercard's documentation describes stand-in processing: if the processing platform cannot be reached or does not answer in time, Mastercard can approve the payment itself, using fixed amounts the issuer set in advance [6]. You learn about it afterwards, from an advice message.

A stand-in approval has no on-chain pull behind it. Your system must accept the advice, post it to the ledger and then try to collect the funds, which may fail. Set your stand-in limits knowing they are unsecured.

Partial and incremental authorisations

A partial approval answers "yes, but only this much". Lithic lets you approve an amount lower than the request, and notes that the terminal must support partial approvals for it to take effect [5]. For JIT, this is how you approve a payment the remaining allowance only partly covers: pull what is there, approve that amount.

An incremental authorisation raises an existing hold, as a hotel or car hire merchant might. Marqeta lists it as a separate event that reduces the available balance and is sent to your gateway [11]. Treat each increment as its own pull with its own deadline, linked to the original authorisation.

The hold, clearing and settlement

Approval is not the end. The flow, in a synthetic example:

Day 0  10:02:00.000  auth request   amount_minor: 4000, currency: EUR (USDC equivalent pulled)
Day 0  10:02:01.200  pull confirmed, approve
Day 0                hold amount_minor: 4000, currency: EUR on card ledger
Day 1                clearing        amount_minor: 3850, currency: EUR (final)
Day 1                release hold, post 3850, 150 owed back to user (EUR minor units)
Day 2                settlement with the scheme in fiat

You pulled the authorised amount, so when clearing comes in lower, the difference goes back to the user, on chain or as a ledger balance. Clearing can also come in higher, or in several parts, and Marqeta says every clearing must be processed, because settlement is already under way [12]. Your ledger must hold the pulled amount against the authorisation until the final clearing.

Expired authorisations

If no clearing arrives, the hold expires. Lithic's documentation lists expiry periods of 1 to 30 days depending on the scheme and transaction type, and says expiring an authorisation does not stop a clearing arriving afterwards [10]. Marqeta lists issuer expiry as a reversal event that restores the available balance [11].

For JIT this is awkward. If you return the pulled funds when the hold expires and the clearing arrives a week later, you must pull again, and the allowance may be gone. Decide in advance whether you return funds at expiry, hold them longer, or accept the late-clearing loss.

Refunds

A refund arrives as its own credit, separate from the purchase, and Marqeta treats refund events as final and positive for the balance [11]. It may not match any authorisation you hold. Your system must find the original purchase if it can, credit the user, and decide whether to push stablecoins back on chain or keep the credit on the card ledger. Either way, record which on-chain transfer, if any, the refund relates to.

A checklist

• An internal deadline below your processor's, and a decline when it passes.
• Wait for confirmed; track late transfers by signature.
• The remaining allowance in your ledger, not just the balance.
• Stand-in limits sized as unsecured exposure.
• A rule for expiry, late clearing and refunds, written down before launch.

None of this is legal or regulatory advice. Scheme and processor rules differ, and yours set the real numbers.

What we do: our card-programme diagnostic reviews designs like this one. See https://centrob.co/#payments.