Objects & Terminology
The object model in one page: who is who, which object gates which, and the vocabulary the rest of these docs assume.
The three parties
- You are the partner. The business holding the API key. Everything you create belongs to your partner account, scoped per environment.
- Your end users are customers. Individuals or businesses you onboard. A customer is not a login: it is a compliance identity that unlocks accounts and wallets.
- We are Rasto. Verification and banking rails run behind our API. You never integrate with anyone else, and nothing from behind the API reaches you: every status, code, and message you see is ours.
How the objects relate
Two objects do the gating:
- An approved endorsement for a currency unlocks that currency's virtual accounts. Any approved endorsement unlocks wallets.
- An operation is the only way funds leave a wallet. We prepare it, you verify and sign it.
The objects
| Object | Id prefix | What it is |
|---|---|---|
| Customer | cus_ | An onboarded end user, individual or business. Also the verification intake: identity data and documents go on it directly |
| Endorsement | none | The public verification reading per currency, identified by its name (endo_usd at launch). Requested explicitly. Its requirements buckets are the one channel for anything outstanding |
| Verification | ver_ | One submission of the customer to one endorsement's review. You read the endorsement instead, but the rounds are listed for history |
| Terms link, acceptance | tos_, sig_ | The hosted terms flow and the receipt it produces. Terms come before the customer |
| Virtual account | va_ | A dedicated USD bank account with a standing stablecoin destination. Senders pay it over any rail in its payment_rails |
| Deposit | dep_ | Money that arrived on a virtual account |
| Conversion | cnv_ | The FX and fee event between deposit and delivery. Fee lines live here |
| Payout | pay_ | The on-chain delivery, carrying the tx_hash |
| Transaction | txn_ | The unified, filterable list across the whole trail. Your reconciliation surface |
| Wallet | wal_ | A non-custodial, chain-scoped stablecoin wallet. Balances are chain reads |
| Wallet operation | wop_ | A prepared wallet send awaiting your signature. Verify, sign, return within 30 seconds |
| Wallet transaction | wtx_ | One balance-affecting event at a wallet address (kind: deposit or withdrawal) |
| Webhook, event | whk_, wev_ | Your registered delivery URL, and the outbound event log ordered by sequence |
Who is who in your product
The model is the same whatever you build. Only what your customers are changes. What You Can Build works through four products in full.
| You are building | Your customer is | A typical flow |
|---|---|---|
| A payroll platform paying contractors | Each contractor, an individual | The employer pays the contractor's virtual account by ACH, USDC lands in the contractor's wallet |
| A B2B invoicing product settling on chain | Each invoicing business, KYB | The buyer wires the virtual account, USDC delivers to the seller's treasury address |
| A neobank with stablecoin balances | Each account holder | Deposits convert into the holder's held wallet, and sends are operations your backend authorizes |
Terms that trip people up
- Business customer and partner. A business you onboard is still a customer, verified through KYB rather than KYC, never a partner.
- Endorsement and verification. Each endorsement is the review of the
customer for one currency, and that review is the verification. A
verification round records one submission to it. The endorsement is the
only verification status you read or react to. There are no
verification.*webhooks. - Virtual account and wallet. The virtual account is fiat in: a bank account number whose arrivals convert. The wallet holds stablecoins on chain. A virtual account's destination can point into a wallet.
- Operation and transaction. An operation is a wallet send awaiting your authorization. A transaction is a read-only row in the money-movement trail.
- Payment rail and corridor. A payment rail is how fiat moves (
ach,wire), namedpayment_railon a deposit andpayment_railson a virtual account. A corridor is a supported fiat, asset, and chain combination. Discover both fromGET /api/corridorsrather than hard-coding them. kind, decimal strings, bps. Discriminators are always namedkind. Money values are decimal strings ("250","0.5"), sent as strings and returned without trailing zeros. A fractional JSON number is refused. Rates are basis points, never percent.
Was this page helpful?