Corporate cards funded from a stablecoin balance: how it works

A corporate card funded from a stablecoin balance connects a company’s USDC or USDT treasury to standard card payment rails. Employees pay merchants as they would with a conventional business card, while the card programme reserves and ultimately debits the corresponding value from the company’s treasury funding source. The merchant generally receives its normal settlement currency, not stablecoins.

What “funded from a stablecoin balance” means

The phrase describes the company’s funding arrangement, not the payment method seen by the merchant. A card purchase is different from sending USDC or USDT directly to a merchant wallet. The employee presents a card, the merchant requests authorisation through a card network, and the programme determines whether sufficient funds and permissions are available.

With a direct treasury-funded model, finance maintains an available stablecoin balance rather than forecasting card expenditure and repeatedly transferring money into a separate prepaid account. This reduces internal funding movements, but it does not create credit or make the entire treasury automatically spendable. Card limits, merchant controls, pending holds, programme rules and the available balance still constrain spending.

Stablerail’s corporate cards are used with a company’s own stablecoin treasury, alongside treasury controls and exportable audit evidence. They are not a mechanism for holding or spending customer funds.

What happens from card tap to settlement

1. The merchant requests authorisation

When an employee taps, inserts or enters the card online, the merchant sends an authorisation request. It commonly contains the requested amount, purchase currency, merchant identifier and merchant category code, or MCC.

The card programme evaluates whether the card is active, the requested amount fits its limits, the merchant category is permitted and enough available funding exists. Card-network fraud and security checks may also affect the decision. An approval confirms that the transaction can proceed at that moment; it does not necessarily represent the final posted amount.

2. The programme places an authorisation hold

An approved amount normally reduces the balance available for further card spending. This is an authorisation hold rather than a final debit. Hotels, car rental agencies, restaurants and fuel stations may request estimated amounts, incidental deposits or amounts that later change because of tips.

For example, a hotel may authorise the room cost plus an incidental deposit. At checkout, it can submit a lower final charge. The unused portion of the hold is released according to the programme and network process. If a merchant never completes the charge, the hold may be reversed or expire rather than becoming a settled transaction.

3. The merchant presents the final charge

After the purchase, the merchant submits the transaction for clearing, often called presentment. The programme attempts to match that record to the earlier authorisation. The final amount can equal, exceed or fall below the hold.

At settlement, the final value is applied to the company’s treasury funding source. Any excess hold is released; if the final charge is higher, the additional amount must be covered. Settlement timing varies by merchant, network and transaction type, so the purchase, authorisation and settlement dates should remain separate fields in finance records.

How foreign exchange works

A company may hold USDC or USDT while an employee pays a hotel in euros or a vendor in pounds. The transaction can involve three relevant units: the merchant’s purchase currency, the card programme’s billing or settlement currency, and the stablecoin used as the treasury funding source.

The transaction record should identify the merchant amount and currency, the amount charged against the treasury, the authorisation and settlement dates, the conversion basis, and separately identifiable fees. Exact rates and charges depend on the programme terms, transaction currency and card-network process.

A stablecoin targeting parity with the US dollar does not eliminate foreign exchange on a non-dollar purchase. Nor should finance assume the authorisation conversion will always equal the settled conversion, because the amount, date or applicable rate may change before presentment.

Employees may also be offered dynamic currency conversion, where the merchant converts a local purchase into a displayed home currency. That offer can use the merchant’s own rate or markup. A practical policy is to instruct employees to select the local currency unless finance has reviewed the alternative and determined that it is preferable.

Card controls and operating patterns

Virtual cards are useful for online purchases, recurring software and vendor-specific spending. Physical cards are generally better suited to travel and point-of-sale purchases. Depending on the programme, finance can apply per-transaction or periodic limits and restrict merchant categories.

• Recurring software: issue a dedicated virtual card for one vendor to simplify identification and replacement.
• Business travel: permit relevant categories such as airlines, hotels and ground transport while restricting unrelated use.
• Projects: set a defined spending ceiling and close or freeze the card when the project ends.
• Employee departures: freeze or cancel cards promptly and review pending transactions before closing access.

These controls govern how cardholders access the shared funding source; they do not necessarily create a separate wallet or sub-account for every employee. Finance should document who may issue, change, freeze and cancel cards. Treasury approval and signing quorum should also be distinguished from card permissions: controls for sending stablecoins from the treasury are not a substitute for card-level limits.

Statements, refunds and month-end reconciliation

A card statement is primarily a record of posted activity, not a complete real-time view of every outstanding obligation. Recently approved purchases can remain pending, and reversals, refunds or disputes can appear later. The available balance may therefore differ from a simple calculation based only on settled statement lines.

At month-end, reconcile the opening treasury balance, settled card debits, pending authorisations, fees, non-card treasury movements, refunds and the closing balance. Match settled charges to receipts or invoices, cardholders, cost centres and general-ledger accounts. Exportable transaction and audit evidence can support this process, but finance still needs a documented cutoff and booking policy.

Authorisation and settlement may cross accounting periods. The appropriate recognition and stablecoin accounting treatment depend on the applicable reporting framework, jurisdiction, materiality and company policy. Controllers should document whether and how material pending purchases are accrued rather than treating every authorisation as a final expense.

A refund is a new credit, not the deletion of the original transaction. It can settle after the original reporting period, and its treasury value may differ from the initial debit if currencies were converted or fee treatment changed. Keep a link between the purchase and refund while recording any resulting difference under the company’s accounting policy.

Finance rollout checklist

1. Confirm the supported stablecoin, card currencies, eligible jurisdictions and designated treasury funding source.
2. Review transaction limits, FX methodology, card charges and the treatment of authorisation holds.
3. Define who can issue, modify, freeze and cancel virtual or physical cards.
4. Set card limits and MCC restrictions by role, vendor or use case.
5. Document employee rules for local-currency payments, receipts, lost cards and unrecognised transactions.
6. Test exports and map settled charges, refunds, fees and FX differences to the general ledger.
7. Establish month-end procedures for pending holds, cutoff, disputes and employee departures.

Card availability is subject to company onboarding, including jurisdiction, industry and know-your-business eligibility. Supported spending locations and physical-card delivery also depend on the applicable programme.

The operational difference for treasury

The central benefit is fewer internal funding steps. Finance can use corporate cards without continually prefunding a separate card wallet, while employees retain familiar card acceptance. The tradeoff is that treasury availability and card operations become closely connected: pending holds, settlement, FX and refunds must all be visible in liquidity monitoring and reconciliation. Stablerail brings corporate cards together with USDC or USDT treasury activity, fiat conversion, global payouts and audit evidence for the company’s own funds.