Hostra logoHostra
Payment infrastructure · v2026.7

Hostra — payment settlement infrastructure. Move money.Without the hassle.

Global payment infrastructure for moving, settling and managing money across fiat, cards and stablecoins.

Issue Virtual CardRequest DemoRead DocumentationSign in →
Move money. Without the hassle.
USDT · USDC
Settlement assets
7
Supported networks
1.5%
Platform fee
12
RBAC API scopes
Virtual cards

Virtual card infrastructure — in development.

Hostra is building virtual card issuing on top of the same settlement core. Virtual card availability, including compatibility with Apple Wallet and Google Wallet, is subject to issuer approval and the terms of the card program.

Card issuing (in development)

Virtual card issuing is in development. Production availability depends on issuer and program approval.

Apple Wallet (in development)

Apple Wallet provisioning is planned and will be enabled after issuer approval.

Google Wallet (in development)

Google Wallet provisioning is planned, with one card record behind both wallets.

Issue Virtual Card

Manage your cards from your Hostra account dashboard.

Balances, card state and authorizations sit next to settlements and the audit chain you already run.

Open your account dashboard
Card overview
active
Available
$4,820.00
Card
•••• ••••
Wallet
Apple · Google
  • Northwind Labs
    card · approved
    −$128.40
  • Apple Services
    card · approved
    −$9.99
  • Top-up
    settlement · succeeded
    +$1,500.00
Money movement

One continuous path from card to network.

Value never sits in an unexplained state. Every stage of a Hostra transfer is a recorded, verifiable step.

01 · Card

The card is the entry point

A customer card starts the transfer. Hostra never stores raw card data — tokenization happens at the processor.

Hostra payment card moving through a digital settlement network
  1. CardThe card is the entry point — A customer card starts the transfer. Hostra never stores raw card data — tokenization happens at the processor.
  2. PaymentAuthorization and capture — The payment is authorized, then captured. The result — approved or declined — is the only signal that starts settlement.
  3. HostraThe settlement engine — Hostra orchestrates the transfer with idempotency keys, request IDs and exactly-once semantics.
  4. LedgerDouble-entry state — Every movement is written as balanced double-entry postings, so the ledger always reconciles against the network.
  5. SettlementSettlement executes — The settlement leg runs against its status machine: pending, in flight, retrying, succeeded, failed or reversed.
  6. USDT / USDCValue becomes a stablecoin — Card value is settled into USDT or USDC — the payout representation of the completed transfer.
  7. NetworkDelivered on-chain — Payout lands on Tron, Ethereum, Polygon or BSC, with the on-chain reference recorded on the transfer.
Why Hostra exists

Payments break at the edges. We rebuilt the core.

01The problem

Modern payment infrastructure fails under retries, partial failures and duplicate delivery.

02Our approach

Hostra was designed around deterministic state transitions instead of best-effort recovery.

03The guarantee

Repeated requests for the same settlement intent do not create duplicate accounting effects.

Read more about what Hostra is, how the settlement engine guarantees exactly-once execution, and the security controls around it. Explore the platform or see how it is used by fintechs, payment service providers and enterprises.

Engineering proof

Six properties the engine holds under load

Not marketing claims. Invariants enforced in code and verified through automated and integration testing.

01

Idempotency by construction

Every settlement intent carries a client-side key. Duplicate submissions do not create duplicate accounting effects in the ledger.

02

Deterministic state transitions

State is a pure fold over an append-only journal. Two nodes at the same offset compute the same hash, byte-for-byte.

03

Append-only ledger

Double-entry, hash-chained postings. Corrections are compensating entries — the history is never rewritten.

04

One authorized worker per operation

Each operation is managed by a single authorized worker using a time-limited lease. Once that lease is no longer valid, the worker cannot continue performing lease-protected actions. Execution ownership is separate from terminal commit authority.

05

Controlled retries

Backoff, jitter, budget and dead-letter routing are first-class objects — declared per counterparty, inspected in the control plane.

06

Verifiable audit trail

Merkle root emitted per epoch. External auditors verify the ledger end-to-end without trusting the operator.

Idempotency-Key
Exactly-once mutations
HMAC webhooks
Signed, retried, dead-lettered
RBAC scopes
Merchant-scoped M2M keys
RFC 7807
Machine-readable errors
Hash-chained audit
Append-only history
Tokenized cards
No PAN or CVV stored
Platform

Financial infrastructure. One platform.

Composable building blocks engineered for money movement — from ledger to settlement.

Buy crypto with a card

Charge a tokenized card and disburse USDT or USDC as one composite saga with automatic compensation.

Server-side quotes

Rate, platform fee and network fee are priced by the engine before a transfer is ever created.

Settlement & ledger

Every intent moves through an explicit lifecycle and lands as double-entry postings you can reconcile.

Virtual cards

Issue cards, inspect state and reveal secure details through a short-lived, scoped session.

Balance overview

View fiat, card and crypto-asset balances in one place.

Secure notifications

HMAC-signed notifications with automatic retries and a pending-message queue for status changes.

Receipts & ISO 20022

Download the PDF receipt, the JSON payload and — where the flow produces one — the ISO 20022 message.

Devices & sessions

View and manage your registered devices from your account.

Audit & compliance

An audit trail that enables integrity verification for events associated with account activity.

Products

Ship faster with modular products

Adopt what you need today. Extend without re-platforming tomorrow.

  1. 01POST /v1/quotes
    Quote

    The engine prices the rate, platform fee and network fee and returns a quote you can show before anything moves.

  2. 02Tokenized card
    Authorize

    The card is tokenized by the payment provider. Hostra never receives or stores a PAN or CVV.

  3. 03POST /v1/transfers
    Transfer

    The transfer is created with an Idempotency-Key, so retries from any layer collapse into one effect.

  4. 04GET /v1/transfers/{id}
    Settle

    The saga advances through its lifecycle. Status is read from the engine — never simulated in the browser.

  5. 05Double-entry postings
    Reconcile

    Balanced double-entry postings are linked to the settlement record for internal reconciliation.

  6. 06GET /v1/receipts/{uetr}
    Transaction receipt

    After the transaction is completed, you can download the PDF receipt and JSON transaction data from your account when those artifacts are available.

Solutions

Financial infrastructure for every model

From banks modernizing their core to fintechs building from scratch — one platform, one API surface.

For Banks

Modernize your core without replacing it

Wrap legacy cores with a modern ledger, real-time rails and a developer-first API surface.

Talk to us
For Fintech

Go to market in weeks, not years

Accounts, payments, treasury, compliance and reporting — as composable, production-grade primitives.

Talk to us
For PSPs

Run acquiring and payouts at scale

Intelligent routing, adaptive retries, split payouts and merchant onboarding on a single control plane.

Talk to us
For Enterprises

Embed money movement in your products

Global money movement, virtual accounts and treasury automation embedded into your products.

Talk to us
For Developers

APIs engineered like software, not banking

A REST API described by OpenAPI 3.0, HMAC-signed webhooks, M2M keys with RBAC scopes and runnable cURL examples.

Talk to us
Developer Experience

Made for engineers who ship money

A REST API described by OpenAPI 3.0, HMAC-signed webhooks and M2M keys with RBAC scopes — with docs your team will actually read.

REST
OpenAPI 3.0
7
Networks
12
RBAC scopes
Stack
Go 1.25
Runtime
PostgreSQL
Datastore (pgx v5)
Redis
Cache (go-redis v9)
RabbitMQ
Queue (amqp091)
Docker
Containerized
OpenTelemetry
Tracing

HMAC-SHA256 signed webhooks with retry, backoff and dead-letter. M2M API keys with RBAC scopes. Machine-readable API description at api.hostracore.com/llms.txt.

curl -X POST https://api.hostracore.com/v1/transfers \
  -H "Authorization: Bearer $HOSTRA_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "flow": "card_to_crypto",
    "quote_id": "q_...",
    "card_pm": "pm_card_visa",
    "wallet": "TXaZ9wDeEVnH4m7u5gK3PvQr8sT6uN2mWp",
    "network": "tron",
    "asset": "USDT"
  }'
FAQ

Frequently asked questions

Direct answers about the settlement engine, the card_to_crypto saga and integrating with the production API.

What is Hostra?

Hostra is a payment settlement engine with a double-entry ledger and exactly-once semantics.

What problems does Hostra solve?

Hostra solves the exactly-once problem for payments: every settlement intent survives any failure and executes exactly once — never zero, never twice.

How does the settlement engine work?

Settlement intents are durable records with a lifecycle (pending → in_flight → succeeded/failed/reversed). A single worker holds an exclusive lease at any time. Terminal commit uses compare-and-set with a fencing token to prevent ABA errors.

How do I integrate with the Hostra API?

Register at POST /v1/auth/m2m/register to get an API key with RBAC scopes. Use POST /v1/quotes for a server-side quote, then POST /v1/transfers to create a card_to_crypto saga.

How does merchant onboarding work?

Self-service. POST /v1/auth/m2m/register creates a merchant and its first API key. Human signup at POST /v1/auth/register creates an owned merchant with active status.

What blockchains are supported?

Tron, Ethereum, Polygon and BSC. Assets: USDT and USDC.

What is card_to_crypto?

A composite saga: leg 1 charges a card via Stripe, leg 2 disburses USDT or USDC on-chain. If leg 2 fails, the saga compensates by refunding leg 1.

How does Hostra ensure exactly-once?

Terminal CAS commit, lease ownership with fencing tokens, a transactional outbox and query-before-retry.

How does Hostra handle card data?

Hostra works only with Stripe payment method tokens and never receives or stores a PAN or CVV.

Who is the architect of Hostra?

Ildar Lykmanov (Ильдар Лукманов), machine learning engineer and payment systems architect.

Enterprise

Built for teams moving money at scale

Security posture, availability guarantees and observability built for banks and enterprise fintech.

Tokenized cards

PAN and CVV never reach Hostra; secure details are short-lived and scoped.

Scoped M2M keys

Merchant-scoped API keys with RBAC scopes, shown once at creation.

Observability

OpenTelemetry tracing plus public health and version endpoints.

Audit trail

Hash-chained audit events for every state change in the engine.

Build payment infrastructure with Hostra

Talk to our team about your platform, or explore the developer documentation.

Request DemoTry the live demo
7
Networks
REST
OpenAPI 3.0
12
Scopes