Skip to main content
Applies to Program-Funded programs. See Funding Models for where this fits.
Virtual Assets are unit balances Reap tracks on behalf of your users. You define the asset (a symbol, a display name, a USD rate), allocate amounts to each account, and Reap turns those allocations into spendable balance the user can use on their card. You never move real crypto for a virtual asset. The backing is your master collateral account, which covers card spending across the whole program. Virtual Assets are how you tell Reap who gets to spend how much, and in what currency.

​
Why they exist

Running a card program usually forces a choice: custody your users’ funds with the card issuer, or build your own authorization, clearing, and settlement stack so you can keep custody. Virtual Assets remove that choice.
  • You keep the user relationship, the custody model, and the currency denomination you already use.
  • Reap authorizes, clears, and settles every card transaction against the master account.
  • The user’s spending power on Reap is a single number per account per asset, set by you.

​
Two primary patterns

Virtual Assets support two patterns that cover almost every program shape we see. They use the same API and the same lifecycle. What differs is what the balance represents on your side.

Custodied balances

The virtual balance represents real value you hold for the user off-platform: stablecoins in a custody wallet, crypto on an exchange, fiat in a trust account, gold in vaulted storage. You mirror your internal balances into Reap.

Issued credits

The virtual balance represents value you grant to the user from your own program funds: cashback, sign-up bonuses, salary allowances, credit lines. Nothing to custody, you are the source.
The two patterns can coexist in the same project. A wallet app can allocate USDC from custody and POINTS as cashback on the same account. The card sees one available balance.

​
Use-case vignettes

Users hold USDC, USDT, ETH, or BTC on your platform. Define one virtual asset per token with appropriate rate sources (FIXED for stablecoins, HTTP for volatile assets). Mirror each user’s balance into Reap. Their card spends against what they already own.
Define a POINTS or CASHBACK virtual asset with a FIXED rate (e.g. 1 point = 0.01 USD). Allocate on qualifying transactions. Users spend their rewards through the same card, no separate redemption flow.
Define a BONUS_USD virtual asset. Allocate the bonus when onboarding completes. Users see it in their available balance immediately and can spend it on their first transaction.
Define a CREDIT_USD virtual asset. Allocate the approved limit to each user who qualifies. The user spends against it. You top up the master account to cover; you handle repayment on your side.
Define a PAYROLL_USD virtual asset. Allocate the monthly amount to each employee on payroll day. Optionally deallocate unused balance at period end, or let it roll over.
Allocate USDC from real custody for everyday spending, and CASHBACK_USD for rewards earned through the program. Both show up as part of the same available balance on the same card.

​
How they feed into available balance

Virtual Asset allocations contribute to the assets side of the balance equation on an account: 
availableBalance = assets - liabilities
Each virtual asset is valued in USD using its exchange rate. All active allocations on an account are summed. Card debt is subtracted as liabilities. See Accounts Overview for the full balance model.

​
Lifecycle at a glance

  1. Define the virtual asset once at the project level. Pick a rate source and, for FIXED rates, an initial rate.
  2. Allocate balance to each user’s account by posting a DEPOSIT. The balance becomes spendable immediately.
  3. The user spends. Reap authorizes against the available balance and settles card network debt from the master account. You do not touch this flow.
  4. Settle card spend by posting a SETTLEMENT. The user’s virtual balance drops and the outstanding card debt is cleared in one atomic step.

​
What Reap does, what you do

  • Authorizes every card swipe against the user’s available balance.
  • Clears, reverses, and settles card transactions with the card network.
  • Custodies the master collateral account.
  • Fetches HTTP-source rates on a schedule and stores a snapshot for every update.
  • Atomically applies your postings against the user’s balance and card debt.

​
Next