Skip to main content
Open-loop cards are funded from your account, not the recipient’s. When someone claims a hosted card link and spends it, the money comes out of a spend account you nominate at the moment you generate the link.
The funding options here are narrower than on createVirtualCard.The open-loop path exposes exactly one funding control: userCashBalanceId. There is no primaryFundingSource, no bankAccountId, no usePrepaymentBalance, and no useRewardsBalance. External bank accounts cannot fund an open-loop card — the spend account must be funded first.If you are porting an integration from createVirtualCard, do not assume the same fields carry over. See Differences from standard cards.

Setting the funding source

Pass userCashBalanceId on generateVCShareLinks. It applies to every card generated in that request.
userCashBalanceId is marked optional in the schema, but treat it as required.Omit it and the cards fall back to a default balance on your account. For a payout or rewards program that is almost never what you want — it makes spend unattributable and puts campaign disbursements against general account funds. Always set it explicitly, on every request.

Restricted Access

This mutation requires a Bearer token with the CREATE_SHARE_LINK scope. Basic auth is rejected.

Per-card funding across a batch

userCashBalanceId is set per request, not per link. Every card in one generateVCShareLinks call draws from the same spend account. To fund different cards from different accounts, issue one request per funding source:
Use one spend account per program, not one shared pot. A dedicated spend account per campaign gives you a clean balance to reconcile against, an obvious place to see remaining exposure, and a natural stopping point if something goes wrong — draining one account cannot touch another. It also means getSpendAccountVirtualAccountNumbers gives that campaign its own routing and account number for direct funding.

Funding the spend account

Because open-loop cards cannot pull from an external bank at spend time, the spend account has to hold funds before recipients start claiming. Three ways to get money in: Check the balance before a large batch with getUserCashBalances, reading availableCashBalance rather than totalCashBalance.

Differences from standard cards

The practical consequence: open-loop programs are prefunded. You cannot run them off an external bank account the way you can run a standard corporate card, so treat spend account balance as an operational requirement and monitor it. For the full picture on standard cards, see Manage Virtual Card Funding Sources.

Common mistakes

Neither field exists on GenerateVCShareLinksInput. Open-loop cards are funded from a spend account only. Fund the spend account first, then generate links against it.
It is optional in the type definition but effectively required in practice. Without it your cards draw from a default balance, and campaign spend becomes impossible to attribute or cap.
Confirm availableCashBalance covers the batch — spendLimit multiplied by the number of links — before generating. A batch that outruns its funding fails at the recipient, not at your API call, which means your support team hears about it before you do.

Open Loop Cards Overview

Generating, listing, and deactivating hosted card links.

Delivery Methods

The four ways to get a card link to a recipient.

Virtual Account Numbers

Give each program’s spend account its own routing and account number.

Virtual Card Funding Sources

The fuller set of funding controls on standard cards.