Virtual card infrastructure
Cards are one of the rails Hostra settles over. Today that means tokenised card payments, card records exposed through the API and dashboard, and a controlled reveal of sensitive details. Card issuing, network membership and wallet provisioning are in development and are not available.
Available today
- Card payments (card_charge): the card is tokenised in the browser by Stripe.js; only the resulting payment method token reaches the Hostra API.
- Card push (card_push): payout to an eligible card over Visa Direct OCT as a settlement method of the engine.
- Card records: GET /v1/cards returns the cards visible to the authenticated session, with status and non-sensitive metadata.
- Secure details: a password-protected, time-limited reveal endpoint returns either a demo loopback view or an embedded iframe hosted by the card provider — sensitive values never pass through Hostra's own storage.
- Every card-funded movement is settled by the engine and posted to the ledger like any other rail.
Handling of sensitive data
Hostra does not receive or store a primary account number or CVV. Card data is tokenised by the payment provider, and the secure-details reveal is either a sandboxed provider-hosted iframe or an explicitly marked demo view, bounded by a short TTL after which the reveal expires. This design keeps sensitive card data out of Hostra's systems and materially reduces PCI scope for integrators — see security.
In development — not available
- Card issuance and lifecycle management (create, freeze, replace, spend controls).
- Apple Pay and Google Pay wallet provisioning.
- Authorisation controls and issuer-side decisioning.
- Mastercard Send as an additional push rail.
Hostra makes no claim to card network membership, issuer status or a card-scheme partnership. Where a card capability depends on a provider, that dependency is stated rather than implied.