On-ramp: fiat to crypto

• Auto-ramp accounts (this guide): a dedicated virtual bank account for the user. Anything paid into it over ACH, FedNow, wire, or SEPA auto-converts to crypto and lands at a wallet address. Good for recurring or third-party funding, like payroll or invoices.
• Linked bank on-ramp: link the user’s bank and pull funds on demand via ACH debit.

​

Before you start

• Authenticate as an integrator and act on behalf of a verified user. See Authentication and Onboarding.
• Confirm the user’s fiat_to_crypto capability is active — read it from GET /v1/users/me, don’t assume it from KYC status. US users typically see requirements_needed with a terms_acceptance requirement first: send the user through the requirement’s actionUrl hosted flow, then record the acceptance with POST /v1/users/me/terms.

​

Create an auto-ramp account

curl -X POST https://platform.spritz.finance/v1/auto-ramp-accounts \
  -H "Content-Type: application/json" \
  # plus your integrator signing headers and the user's Authorization (see Authentication)
  -d '{
    "address": "0x742d35Cc6634C0532925a3b844Bc9e7595f2bD18",
    "network": "base",
    "token": "USDC"
  }'

{
  "id": "6a43ac369288351e982157b9",
  "status": "active",
  "network": "base",
  "address": "0x742d35cc6634c0532925a3b844bc9e7595f2bd18",
  "token": "USDC",
  "currency": "USD",
  "depositInstructions": {
    "type": "us",
    "bankName": "Lead Bank",
    "bankAddress": "1800 North Pole St., Orlando, FL 32801",
    "bankRoutingNumber": "101019644",
    "bankAccountNumber": "1234567890",
    "paymentRails": ["ach_push", "fednow", "wire"]
  }
}

1. The account is keyed to the (token + network + destination wallet) triple. You are not creating “a virtual account for the user” — you’re creating “a virtual account for USDC on Base going to 0xABC…”. Change the destination wallet and you get a whole new virtual account with new deposit details; the old one doesn’t follow. Store the destination address alongside the account in your database, and when a user changes their receiving wallet, expect to create a new auto-ramp account and update the deposit instructions everywhere you’ve shown them — including any saved payee the user set up at their own bank. That last one is the real-world failure mode: a recurring transfer pointed at the old details.
2. The beneficiary is the end user, not Spritz and not you. The user is sending money to an account in their own name — exactly what their bank expects to see. Present it that way in your UI.
3. Check status before showing deposit instructions. Only active accounts should receive money. Confirm it on every render.

​

Valid combinations and sizes

{
  "input": { "amount": "100.00", "currency": "USD" },
  "fees": { "total": "1.00", "currency": "USD", "breakdown": { "…": "…" } },
  "output": { "amount": "99.00", "token": "USDC", "network": "base", "address": "0x…" },
  "rate": { "value": "1", "source": "peg", "asOf": "2026-09-03T16:09:09.229Z" }
}

​

Track conversions

​

Sandbox testing

curl -X POST https://sandbox.spritz.finance/v1/sandbox/auto-ramp-accounts/{id}/deposit \
  -H "Content-Type: application/json" \
  # plus your integrator signing headers and the user's Authorization
  -d '{ "amount": "10.00" }'

​

Integration checklist

• UI is driven from capabilities, and terms_acceptance is completed before account creation
• Creation retries (or defers) through the provider’s asynchronous activation window instead of surfacing The customer account is not active to users
• Deposit instructions are only shown for active accounts
• The (token + network + wallet) triple is stored with the account, and a wallet change creates a new account plus new instructions everywhere they’re saved
• The beneficiary is presented as the end user
• Valid pairs and minimums come from GET /v1/on-ramps/supported-pairs, not a hardcoded list
• onramp.* webhooks drive updates; GET /v1/on-ramps reconciles misses

​

Related