Key Highlights
- A virtual asset is a unit balance the card issuer tracks for the programme. It needs a symbol, a decimal precision and a price in the programme's billing currency.
- Anything that can be named and priced works through the same mechanism, including stablecoins, volatile tokens, yield-bearing share tokens, loyalty points, cashback and credit lines.
- Programmes price an asset either at a rate they set themselves, or from an endpoint they host that the issuer polls on a fixed interval, and authorisation reads the latest stored snapshot rather than a live price.
- Using a withdrawal where a settlement belongs debits the user twice, once when card debt accrues and again when the withdrawal posts.
- One account holds several asset balances at once. The issuer values each in the billing currency, adds them up and subtracts card debt. One available figure comes out.
What does it take to let your users spend a virtual asset on a card?
A symbol, a decimal precision and a rate source. That is the whole definition, and it is why stablecoins, Bitcoin, staked positions, loyalty points, credit lines and payroll allowances all run through one mechanism. Mirror each user's balance and the card treats that unit exactly as it treats a currency.
Everything below reflects how these programmes are documented as of September 2026.
What counts as a virtual asset?
A virtual asset is a single unit of value the issuer tracks on the programme's behalf. Its definition carries a symbol, a decimal precision, and a rate that prices it in the programme's billing currency.
A virtual asset definition stays deliberately narrow, which means the same general model can represent many kinds of value. The examples below illustrate how different units could be defined and priced. They are not a list of assets supported by every card programme:
The mechanism does not digitise or move the physical asset. It represents a claim on its value as a priced virtual balance that can contribute to card spending.
What are the patterns a programme falls into?
Almost every programme takes one of two shapes, and the difference is not technical. Both use the same definitions and the same operations. What differs is what the balance represents and who funded it.
Custodied balances. The virtual balance mirrors real value the programme holds for the user somewhere else: stablecoins in a custody wallet, crypto on an exchange, fiat in a trust account, gold in vaulted storage. The programme keeps custody and the balance on the card follows it.
Issued credits. The virtual balance is value the programme grants from its own funds: cashback, sign-up bonuses, salary allowances, credit lines. There is nothing to custody because the programme is the source.
Custodied balances and issued credits coexist on one account. A wallet can mirror a custodied stablecoin balance for everyday spending and issue a points balance for rewards earned in its own programme, and the card shows one available figure across both. Which pattern an asset uses determines which posting operations the programme needs to implement.
How is a virtual asset priced?
Every asset carries an exchange rate in the programme's billing currency, and that rate is set one of two ways.
1. A rate the programme sets and stores.
The value holds until the programme explicitly changes it. This suits any unit the programme controls or pegs, such as a points system at 0.01 for one hundred points per unit. Every change is stored as a timestamped snapshot, so past balances recompute against whichever rate was active at the time.
2. An endpoint the programme hosts and the issuer polls.
A hosted endpoint suits anything priced against a moving market the programme already has data for: volatile assets, FX, or a NAV. The programme exposes a URL and the issuer reads it on a schedule.
A hosted rate endpoint carries one design constraint though. The issuer polls the endpoint on a fixed interval and stores each value as a snapshot, and card authorisation reads that stored snapshot at the moment of the swipe. For a volatile asset priced this way, the rate applied at the till can therefore lag the market by the length of one polling interval. Intervals are set by the issuer and are not standardised across the industry, so confirm the figure with yours. A programme pricing volatile assets should consider that window against its own risk tolerance and treat endpoint uptime as an operational responsibility.
Rate source is chosen per asset, and a single programme can mix both rate sources.
What should teams decide when defining an asset?
Two settings require particular care when an asset is defined.
1. Its decimal precision should match the programme's internal ledger to prevent rounding differences.
2. Its symbol should also be chosen carefully because it cannot be changed after creation and appears in balance records, posting payloads and webhook events.
How do several assets share one spending limit?
Balances roll up into one figure. Each active asset balance on an account is valued in the programme's billing currency, the values are added together, and outstanding card debt is subtracted. The formula is plain:
available balance = assets - liabilities
A user holding 400 units of one balance and 600 units of value in another sees 1,000 units available, and a transaction need not draw on a single one. That single limit is what lets one card carry a custodied balance alongside a cashback balance, or a payroll allowance alongside a credit line.
Two constraints are worth planning for. Card debt reduces the available figure directly, so a large sum of asset balances can still leave little spending capacity. And spending limits across the programme remain a function of the funds the programme has posted to the master account, so per-user headroom sits inside a programme-level ceiling.
What operations keep balances in sync, and where do programmes go wrong?
Postings apply atomically. A posting that carries several entries lands in full or not at all, so a partial state never becomes visible.
Deposit, withdrawal and settlement name the posting operations. Each describes a change to a balance the issuer tracks, and none of them describes how the card itself works.
Two things about deposits, withdrawals and settlements cause real bugs.
A posting amount is the change to apply. It says how much to add or subtract. Write the intended new total into that field and the balance is overwritten, which the issuer's own API documentation flags as a common integration mistake.
Using a withdrawal where a settlement belongs double-debits the user. After a card transaction clears, the programme has to pull from the user's holdings on its own side to cover the spend. If it posts that pull as a withdrawal, the user's available balance drops twice: once when the card debt accrued, and again when the withdrawal landed. Settlement nets the card debt and the balance pull against each other. The user's spending position then moves once, and it matches what they actually swiped.
A pure issued-credits programme may never post a settlement at all, because there is no user-side holding to draw down.
Who holds the assets?
The programme holds the assets its users own, along with the customer relationship. A separate master account backs card spending across the whole programme, and the programme keeps that account funded. The two are distinct.
Real assets do not move when a virtual asset is defined or allocated. A virtual balance is an entry the issuer tracks, backed by the master account rather than the underlying token, share or bar of gold. The issuer does not custody the underlying asset and does not act as an exchange.
How do yield-bearing and staked assets work?
Users can spend against a yield-bearing position without unstaking, because nothing about the position changes at the point of sale. The programme prices the asset from a NAV or share-price endpoint, authorisation reads the stored snapshot of that value, and the position stays where it is and keeps earning.
The user sells nothing at the till. The programme extends spending power against a position whose value it reports, then reconciles with the user afterwards.
The value is only as good as the endpoint the programme chooses. Staked positions keep whatever lock-up or redemption terms they already carry. The programme authorises the spend before it can redeem the position, so the master account backs the card spend in the meantime.
How Reap Can Help
Reap's Virtual Assets capability is the implementation described above. A client defines each asset, chooses a fixed rate or hosts a rate endpoint, and mirrors each user's balance to Reap. The card spends against what the user already holds.
- Rate endpoints are polled every 5 minutes, with each new value stored as a snapshot. Authorisations use the latest snapshot, so the timing behaviour is predictable.
- One master account covers every asset type. A single master account in USDC or USDT, funded by the client, backs card spend across the whole programme. That account is separate from the assets a user holds, which stay with the client. Adding an asset type means writing a definition, and it needs no new funding pipeline.
- The client keeps custody and the user relationship. Reap does not custody underlying assets and does not operate as an exchange.
It runs inside Reap's wider card issuing platform, alongside issuance, risk and programme operations. Reap is a Visa Principal Issuer in Hong Kong and Mexico, and programmes can layer Reap Rewards benefits within Reap's embedded finance stack. Start from the API documentation.
Disclaimer
The information provided in this material is for general informational purposes only and does not constitute legal, financial, tax, or business advice. It should not be interpreted as a recommendation, offer, solicitation, or inducement to engage with Reap's products or services. Any use of Reap's services is at the user's sole risk and discretion.
Reap makes no representation or warranty, express or implied, regarding the accuracy, completeness, or reliability of the information provided. Services are governed exclusively by Reap's applicable legal agreements. Service availability, features, and eligibility may vary by jurisdiction and are subject to regulatory, card network, and operational limitations.
All trademarks, logos, and brand names are the property of Reap and/or their respective owners. References to third-party platforms or services are for descriptive purposes only and do not imply endorsement, partnership, or affiliation.
Reap's services and information are provided on an "as is" and "as available" basis, without warranties of any kind. Reap shall not be liable for any loss or damage arising from the use of, or reliance on, this information or its services.
