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 returns either a demo 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 card number or CVV. Card data is tokenised by the payment provider, and the reveal is either a sandboxed provider-hosted iframe or a clearly marked demo view with a short time limit. This keeps sensitive card data out of Hostra's systems and 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 capability depends on a provider, that dependency is stated.