---
title: "On-ramp, off-ramp, or both? How to tell which stablecoin API your product needs"
seoTitle: "On-ramp vs off-ramp: which stablecoin API do you need?"
description: "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."
date: "2026-09-26"
updated: "2026-09-26"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "How do I know if my product needs an on-ramp or an off-ramp?"
    a: "Follow the money. If it starts in a bank account and has to end up as USDC or USDT in a wallet, you need an on-ramp. If it starts as stablecoins and has to land in someone's bank account in local currency, you need an off-ramp. If your product collects from one party in fiat and pays another party in fiat, you need both."
  - q: "Does a payroll platform need an on-ramp or an off-ramp?"
    a: "Mostly an off-ramp. A payroll platform that already holds stablecoins, or funds pay runs in stablecoins, only needs to pay workers in their local currency over rails like Pix, SPEI, or ACH. It needs an on-ramp too if the employer funds payroll by bank transfer in dollars. In that case the on-ramp runs once per pay run, and the off-ramp once per worker."
  - q: "What happens if a stablecoin off-ramp payment cannot settle?"
    a: "The payout ends in a terminal status, and what happens to the money depends on which one. A refund returns the stablecoins to the wallet that funded the payout. A failed status means the payout did not complete, and with some providers it is not refunded automatically, so your operations team has to open a case. Ask each provider which outcome applies to bank rejections."
  - q: "Is it cheaper to use one provider for both the on-ramp and the off-ramp?"
    a: "Often, but not always. One provider means one KYB, one ledger, one webhook format, and no fee for moving stablecoins between two vendors. It also means the provider prices both conversions, so compare the total cost of the round trip, not each leg alone. Two specialist providers can win on a single corridor where one has deeper liquidity."
  - q: "Do on-ramps and off-ramps have the same compliance requirements?"
    a: "The core checks are the same: verify the customer, screen against sanctions lists, and monitor transactions. What changes is the counterparty. On an on-ramp, the provider checks who sent the bank transfer. On an off-ramp, it checks who receives the money and the bank account details. Both directions can trigger Travel Rule data collection when a transfer crosses between providers."
  - q: "How long does an on-ramp take compared with an off-ramp?"
    a: "Both are usually set by the bank rail, not the blockchain. Instant rails such as Pix and SPEI move in seconds to minutes in either direction. ACH and wires follow business days and cut-offs, so a deposit sent late Friday may not arrive until the next banking day. The onchain leg on most payment chains confirms in seconds to minutes."
---

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**

- Direction is the first decision. It sets which rails, which compliance checks, and which failure modes you have to build for.
- Payroll, contractor, and supplier payments start off-ramp. Merchant and B2B collections start on-ramp.
- Marketplaces, remittance, and cross-border collections need both, which is where one provider for both legs saves a KYB and a reconciliation job.
- Failure handling differs by direction. A rejected deposit goes back to a sender's bank; a rejected payout goes back to a wallet, or does not move at all.
- Ask providers the same 10 questions for each direction. The answers are rarely the same.

If the terms are new, [what is a crypto on-ramp and off-ramp](/resources/more/what-is-a-crypto-on-ramp-and-off-ramp) covers the definitions, and [types of stablecoin APIs](/resources/more/types-of-stablecoin-apis) shows where ramps sit among issuer, wallet, and orchestration APIs. This guide is about choosing.

## What are a stablecoin on-ramp and off-ramp?

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.

## How do on-ramps and off-ramps compare side by side?

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 |

## Which direction does each use case need?

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.

## How does an on-ramp API flow work?

An on-ramp API flow turns a quote into deposit instructions, waits for the bank transfer, converts it, and credits a wallet.

1. **Verify the customer.** KYC for a person, KYB for a business. The provider checks who will be sending money in.
2. **Create a quote.** Lock the payment method, amount, and fees. Quotes are short-lived; many expire within minutes.
3. **Share deposit instructions.** The API returns what the payer needs: bank details and a reference code, a Pix code, a CLABE, or a dedicated virtual account.
4. **Wait for the deposit.** Timing follows the rail. Banco de México says [SPEI](https://www.banxico.org.mx/services/interbanking-electronic-payme.html) payments should take no more than 30 seconds. ACH follows banking days; [Nacha](https://www.nacha.org/content/how-ach-payments-work) estimates about 80% of ACH payments settle in one banking day or less.
5. **Convert and credit the wallet.** The provider converts the deposit to USDC or USDT and sends it to the wallet on the network the quote named.
6. **Confirm by webhook.** A completion event tells your system to update the ledger.

## How does an off-ramp API flow work?

An off-ramp API flow locks a rate, takes the stablecoins, and pays local currency into a bank account.

1. **Verify the customer and add the recipient.** Store the bank account or Pix key and the recipient's name and tax ID where the country requires it.
2. **Create a quote.** Lock the rate, fees, and the amount the recipient will receive.
3. **Fund the payout.** Either approve the exact stablecoin amount from your wallet or draw on a balance the provider holds.
4. **Convert and pay out.** The provider sells the stablecoins for local currency and sends it over the local rail. [Pix](https://www.bcb.gov.br/en/financialstability/pix_en), run by Banco Central do Brasil, operates 24/7. ACH and wires follow business days.
5. **Confirm by webhook.** A terminal event reports completed, failed, or refunded.

## What happens when a payment fails or cannot settle?

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](/resources/more/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.

## When does a product need both directions?

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](/resources/more/how-to-choose-on-off-ramp-provider) has the scoring method.

On compliance, both legs carry the same core checks. FATF's [guidance on virtual assets](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html) 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.

## What should you ask a provider before integrating?

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](/docs/payins) for the on-ramp side and [payouts](/docs/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.