Skip to content

Onramp

Prompt for AI· paste into Claude, ChatGPT, Cursor or any coding agent

Read the Rubin Onramp docs starting at https://docs.rubin.trade/onramp/overview (with the Authentication, Integration Flow and API Reference pages) and add a fiat top-up via SBP to my app. Work against testnet https://onramp.testnet.rubin.trade: give each user their own secp256k1 key and sign requests with the cosmos scheme, drive the verification steps from the `flow` in GET /v4/sbp/customer, create an order, show paymentLink as a QR code and poll the order until creditStatus is "credited".

Rubin Onramp lets a user buy USDC with fiat currency (RUB) through SBP (Faster Payments System, QR) and receive it on their Rubin account. A licensed payment provider verifies the user and accepts the fiat payment; Rubin credits the USDC on-chain once the provider confirms it.

The rubin.trade deposit dialog is built entirely on the API described in this section, so a partner can embed the same flow in their own product: the partner's app talks to the Onramp API on behalf of a Rubin account, the end user verifies and pays by SBP, and the USDC arrives on that account. From there it can be moved to a trading subaccount or transferred to the partner's own account inside Rubin.

How it works

  1. Customer = Rubin address. Every customer is identified by a Rubin address (rit1…). Authorized requests are signed with a key of that address — see Authentication. The partner never holds the user's funds: the USDC is credited to the address that signed the order.
  2. Verification. Before the first order the user completes verification with the provider: phone number and SMS code, then identity-document details or a government eID (ESIA) login — or the provider's hosted KYC page, depending on the provider. See Integration flow.
  3. Quote. GET /v4/sbp/rates returns the rate in RUB per 1 USDC and a short-lived signed quote.
  4. Order. POST /v4/sbp/orders locks the quote and returns a payment link. Render it as a QR code or open it on the user's phone; the user pays in their banking app.
  5. Payment confirmation. The provider notifies Rubin. Rubin never trusts the notification alone: it re-reads the order from the provider before crediting.
  6. Crediting. Rubin credits USDC to the customer's main account by an on-chain message (MsgAcknowledgeOnrampDeposit). Poll GET /v4/sbp/orders/{orderId} until creditStatus becomes credited.
User ── SBP payment (RUB) ──► Provider ── confirmation ──► Rubin Onramp ── USDC ──► rit1… main account
  ▲                                                               │
  └──────────── payment link / QR ◄── POST /orders ◄── Partner app┘

Environments

NetworkOnramp API base URL
Mainnethttps://onramp.mainnet.rubin.trade
Testnethttps://onramp.testnet.rubin.trade

All paths in this section are relative to the base URL. On testnet the provider runs in sandbox mode: payments and verification can be simulated with dedicated endpoints, and no real money moves.

Payment providers

Rubin works with licensed payment providers, and the API does not name them: every customer endpoint lives under one route, /v4/sbp, and Rubin decides which provider serves a customer.

A customer exists at a particular provider — the phone number, the verification and the limits live there — so Rubin picks the provider on the first signed request of an address and keeps that address with it from then on. Nothing needs to be stored on your side.

Providers can differ in the steps they need (for example, an SMS code and an identity-document form, or a hosted KYC page). GET /v4/sbp/customer returns a flow descriptor with the steps for this customer; build the UI from it. See Integration flow.

What the partner does and does not do

  • Does: keeps a Rubin key per end user (or uses the user's own wallet), signs requests, shows the verification steps, renders the payment link, and polls the order until it is credited.
  • Does not: collect, store or transfer KYC records. The user types their phone, identity document or eID login into the flow, and the data goes to the provider; Rubin does not ask the partner for verification documents.
  • Does not: hold user funds. Credited USDC sits on the user's Rubin address; moving it to the partner's account is a regular on-chain transfer signed by the user's key.

Pages