Prefund, JIT or borrow: three ways to fund a stablecoin card programme

A stablecoin card programme has to pay the card scheme in fiat at settlement, whatever its users hold on chain. How the money gets from the user to that settlement is the funding model, and there are now three to choose from: prefund the balance, pull just in time, or borrow against the settlement.

The third is new to most teams. On 8 September Visa announced work with Credit Coop, which "provides working capital and settlement financing for stablecoin-linked card programs", using smart contracts to automate funding, collateral management and repayment [1]. We have built crypto-wallet card issuing, including JIT funding on Solana, and this post compares the three on the things that decide the choice.

The three models

Prefund. The user moves money into an account the programme controls before they spend. Marqeta describes this as standard funding: you load money into each account ahead of time and keep enough there to cover the cardholder's spending [2]. Authorisation is a ledger check.

Just in time (JIT). The user's money stays where it is until a payment needs it. With JIT, accounts do not need to carry a balance, and funds move from a funding source at transaction time [2]. On Solana that source is often the user's own token account, with the programme holding a delegate allowance the user approved [4].

Borrow. The programme pays the scheme with borrowed working capital and repays from what it collects. In Visa's description, Credit Coop combines Visa settlement data with on-chain transaction records, with customer authorisation, to assess credit performance and support automated settlement financing [1]. Visa says the model has supported more than $2.5 billion in cumulative financed settlement volume since 2023, with zero defaults across participating facilities, and more than 3,000 borrow events and 9,000 repayment events processed on chain [1].

Borrowing is about the programme's side of settlement, so it sits alongside prefund or JIT rather than replacing them: it changes when the programme needs the money, not how the user's money arrives.

The trade-offs

Prefund: simple at the till, heavy behind it

Authorisation is the easy part: a balance check against your own ledger, well inside any deadline. The cost moves elsewhere. You hold users' money, which brings rules of its own on how it is held and protected; take advice on what applies to you. Users must top up before they spend, which is friction in a product whose pitch is "spend from your wallet". And your ledger must match the money you hold every day.

JIT: light on capital, tight on time

JIT keeps the money with the user until the payment. The price is a deadline. Marqeta's gateway JIT funding declines if your system does not answer in three seconds [3], so your on-chain transfer has to land inside that. The delegate allowance is also fragile: the token program refuses any delegated transfer above the remaining allowance, and clears the delegate when the allowance reaches zero [5]. A user can also revoke it at any time.

Two failure modes matter most:

• Approved but unfunded. If you approve before the transfer confirms and it then fails, the payment still clears and you settle it.
• Funded but unwanted. If you decline on timeout and the transfer lands anyway, you owe the user a refund. Marqeta warns that late processing after a timeout leaves your records out of step, and says to reverse such authorisations [3].

Stand-in adds a third. Mastercard can approve on the issuer's behalf, within fixed amounts set in advance, if the processing platform cannot be reached or does not answer in time [6]. That payment has no pull behind it until you collect one.

Borrow: the timing gap, financed

Even a well-run JIT programme has a gap. Merchants batch clearing roughly once a day [7], settlement is reported daily against scheme cut-off times [8], and the stablecoins you collected must become fiat in the right bank account before the scheme debits it. Clearing can also exceed the authorised amount in some cases, and every clearing must be processed because settlement is already under way [7]. Someone has to fund that gap. Without a facility, it is the programme's own cash, sitting idle as a buffer.

Settlement financing replaces some of that buffer with a credit line sized from settlement data. It does not remove the programme's obligations. You still owe the repayments, and you still need clean data, because Visa's description has the lender combining settlement data with on-chain records to assess credit performance [1]. A programme whose ledger and chain disagree will find that hard to show.

Questions to ask a lender:

• What data do they need, how often, and in what form?
• What triggers a margin call or a pause in drawdowns?
• Where does collateral sit, and who can move it?
• What happens to a drawdown if a repayment transaction fails on chain?

Choosing

There is no single right answer, but the questions are the same:

1. Where must the user's money live? If the product promises self-custody until the swipe, it is JIT, and you need the engineering for it.
2. How much idle capital can you carry? If not much, look at JIT for the user side and financing for the settlement side.
3. Can you prove your numbers daily? Every model needs a ledger that reconciles to the chain and to settlement. Borrowing adds a lender who reads it.

A mix is worth considering: a small prefunded buffer for stand-in and late clearing, JIT for normal spend, and a facility for the settlement gap.

This post compares engineering and operations, not legal, regulatory, tax or financial matters. Holding customer money, lending and stablecoin conversion each have rules of their own; take advice on yours.

What we do: our card-programme diagnostic looks at funding models like these with you. See https://centrob.co/#payments.