Introduction

What Rasto Business does

You onboard your end customers through our API. We verify them, issue each one a dedicated USD bank account, and attach a standing destination: a stablecoin, a chain, and an address. Every payment that arrives on that account is converted and delivered to the destination automatically, and your backend hears about each step over webhooks.

The same customers can hold non-custodial wallets. We derive the addresses, read the balances from the chain, and prepare every send, but only your own key can authorize one. See Custody Architecture for what that guarantees.

The building blocks

New to the object model? Objects & Terminology is the one-page map: who is who, which object gates which, and the vocabulary the rest of these docs assume.

What is supported at launch

EUR over SEPA, with EURC and EURe delivery, returns after the USD launch. The rail vocabulary in Coverage is already built for it.

Design decisions you will notice

• Amounts are decimal strings ("100.50"), never floats. Rates are basis points, never percent: partner_fee_bps: "100" is 1%. See Amounts & Precision.
• Every mutation is idempotent. POSTs require an Idempotency-Key, and retries replay the stored response byte for byte. See Idempotency.
• Webhook payloads match GET responses. The data.object inside an event is exactly what the matching GET returns. One serializer, no drift.
• State is explicit. Every customer carries endorsements, with per-currency readiness and five requirement buckets, so you never infer where onboarding stands. One channel, bare documented codes, no prose to parse.
• Nothing is implicit about money. Virtual accounts need an explicit currency and rail. Wallet sends need your signature. Verification needs an explicit submit.

Start here