Match your use case to the direction money moves: on-ramp, off-ramp, or both. Covers payroll, remittance, marketplaces, treasury, and 10 questions to ask.
You need an on-ramp if money starts in a bank account and must end up as stablecoins, an off-ramp if stablecoins must end up in someone's bank account, and both if your product collects in one currency and pays out in another. Most payroll and supplier products are off-ramp first. Marketplaces and remittance apps usually need both.
Key takeaways
If the terms are new, what is a crypto on-ramp and off-ramp covers the definitions, and types of stablecoin APIs shows where ramps sit among issuer, wallet, and orchestration APIs. This guide is about choosing.
A stablecoin on-ramp converts local currency from a bank transfer into stablecoins and delivers them to a blockchain wallet. A stablecoin off-ramp does the reverse: it converts stablecoins into local currency and pays it into a bank account.
Definition. A stablecoin on-ramp is a service that accepts a bank deposit in local currency, such as USD by ACH or BRL by Pix, converts it to a stablecoin like USDC or USDT, and credits that amount to a wallet the customer chose.
Definition. A stablecoin off-ramp is a service that accepts stablecoins from a wallet, converts them to local currency at a quoted rate, and pays the result into a named bank account over a local rail such as ACH, Pix, SPEI, or SEPA.
An on-ramp and an off-ramp run the same conversion in opposite directions, so their inputs, risks, and users mirror each other.
| On-ramp | Off-ramp | |
|---|---|---|
| Direction | Bank account to wallet | Wallet to bank account |
| Input | Fiat bank transfer | USDC or USDT |
| Output | Stablecoins in a wallet | Local currency in a bank account |
| Typical rails | ACH, wire, Pix, SPEI, SWIFT in | Pix, SPEI, ACH, RTP, SEPA, SWIFT out |
| Typical user | Merchants, employers funding payroll, treasuries | Payroll platforms, marketplaces, importers |
| Key risk | Deposits that arrive without the right reference | Wrong bank details or a recipient name mismatch |
| Example product | A US virtual account that settles deposits to USDC | Paying contractors in Brazil over Pix |
Most products can be placed in one row below. The last column is the first thing to test in a sandbox, because it is where that use case usually breaks.
| Use case | Direction | Why | Test first |
|---|---|---|---|
| Contractor payroll | Off-ramp (on-ramp if the employer funds in fiat) | Workers want local currency | A batch with one invalid bank account |
| Remittance | Both | Sender pays in fiat, recipient gets fiat | Total cost of both conversions on one corridor |
| Marketplace seller payouts | Off-ramp, often both | Buyers pay by card or bank, sellers want local currency | Payouts to many new recipients in one day |
| Merchant collections | On-ramp | Customers pay by bank transfer, the merchant settles in stablecoins | A deposit missing its reference code |
| B2B collections from abroad | On-ramp | Foreign clients wire dollars to a named account | A SWIFT deposit with intermediary fees deducted |
| Supplier payments | Off-ramp | Suppliers invoice in local currency | Name matching on business accounts |
| Treasury funding | On-ramp | Moving bank cash into stablecoins | Large deposits near the rail's cut-off |
| Treasury exit | Off-ramp | Moving stablecoins back to a bank | Per-transaction limits on large amounts |
A useful rule: if your product's ledger is denominated in stablecoins, ask which side of the ledger touches a bank. That side needs a ramp.
An on-ramp API flow turns a quote into deposit instructions, waits for the bank transfer, converts it, and credits a wallet.
An off-ramp API flow locks a rate, takes the stablecoins, and pays local currency into a bank account.
When a ramp payment cannot settle, the money goes back the way it came, but the two directions return to different places and at different speeds.
On-ramp failures happen before the conversion. A deposit arrives without its reference, from a sender name that does not match, or after the quote expired. The usual outcome is a manual review, then a return to the sender's bank account over the same rail. Returns on business-day rails take business days.
Off-ramp failures happen after the stablecoins moved. The receiving bank rejects the account number, the name does not match, or a limit is hit. The provider has to send the stablecoins back to the funding wallet or hold them until you fix the recipient.
BlindPay separates these outcomes in its statuses. A refunded payin means the deposit was returned to the sender. A refunded payout means the stablecoins were returned to the funding source instead of being converted. A failed payout did not complete and is not refunded automatically, so the right response is to contact support rather than wait. Stablecoin payout statuses explained covers each state.
Build for this from day one: store the quote ID, handle every terminal status in your webhook handler, and never mark a payout as paid on the "processing" event.
A product needs both an on-ramp and an off-ramp when it collects money in one currency and pays it out in another, and holds stablecoins only in between.
That is the remittance and marketplace pattern. A US buyer pays in dollars by ACH, the platform settles in USDC, and the seller in Mexico receives pesos over SPEI. The stablecoin is the settlement layer, not the product.
Using one provider for both legs removes three joins: a second KYB of the same customer, a transfer of stablecoins between vendors, and two webhook formats to reconcile into one ledger. The trade-off is pricing power. Compare the full round-trip cost on your top corridor against two specialists before you commit. How to choose an on/off ramp provider has the scoring method.
On compliance, both legs carry the same core checks. FATF's guidance on virtual assets applies the Travel Rule to transfers between virtual asset service providers in either direction, so originator and beneficiary data can be required on both sides. Confirm your own obligations with qualified counsel.
Ask the same 10 questions for each direction you need. The answers often differ between the on-ramp and the off-ramp of the same provider.
| # | Question | Why it matters |
|---|---|---|
| 1 | Which rails are live in production, per direction? | A rail can be live for payouts and not for deposits |
| 2 | Which chains and stablecoins does each direction support? | Not every token exists on every chain |
| 3 | What are the per-transaction and daily limits? | Limits decide whether treasury flows fit at all |
| 4 | Who runs KYC and KYB, and on whom? | You may still have to verify the end recipient |
| 5 | How long is a quote valid? | Short expiry needs a fast execute path in your code |
| 6 | What are the fees, and who pays them? | Fees can come off the sent or the received amount |
| 7 | What happens to funds on a failure or a return? | Refund to wallet, return to bank, or manual case |
| 8 | Which webhook events exist, and are they signed? | Your ledger depends on every terminal event |
| 9 | Does the sandbox simulate failures and refunds? | Untested failure paths break in production |
| 10 | What are the settlement SLAs per rail? | Your users will ask when the money arrives |
BlindPay answers these per rail in its docs: payins for the on-ramp side and payouts for the off-ramp side, with sandbox amounts that force a failed or refunded payout so you can test question 9 before going live.
Seven places blockchain payments beat bank rails: contractor payroll, remittances, B2B suppliers, marketplaces, 24/7 treasury, bill pay, and PSP payouts.
AP2, ACP, and x402 each verify that an AI agent had permission to spend. Here is what every protocol covers, who backs it, and the reconciliation gap none of them close.
Seven stablecoin payment platforms compared for US fintechs in 2026: what makes an API production-ready, how each provider handles compliance, settlement speed against ACH, and how to run the evaluation.