---
title: "On/off ramp liquidity with live quotes: how it works and why it matters"
description: "What on/off ramp liquidity with live quotes means for developers: live quote vs batch rate, the quote ID flow in an API, what happens on expiry, how liquidity depth changes spread by transaction size, rate windows and UX, and a checklist for evaluating a live quote API."
date: "2026-09-03"
updated: "2026-09-03"
author: "BlindPay Team"
category: "payments"
faq:
  - q: "What is quote slippage in crypto on-ramps?"
    a: "Quote slippage is the difference between the rate shown to the user and the rate at which the conversion actually settles. It appears when a provider quotes a cached or indicative rate and executes later at the market rate. A live quote with a quote ID and an honored window removes slippage from the user's side: the provider absorbs any move within the window, and after expiry the user gets a fresh quote instead of a surprise."
  - q: "How do I test live quotes during API integration?"
    a: "Request two quotes ten seconds apart on a volatile corridor and confirm the rate moves. Confirm each response carries a quote ID and an expiry timestamp. Submit a transaction with an expired ID and confirm a specific expiry error code. Request quotes at $500, $5,000, and $50,000 on the same corridor and compare the effective rate. Finally, confirm the sandbox enforces the same rules as production."
  - q: "Can I lock a live quote for longer than the standard window?"
    a: "Sometimes, at a price. Some providers offer extended locks for scheduled or large payments, and the spread widens to cover the provider's exposure over the longer period. For most flows the better design is to request the quote at the last responsible moment, right before the user confirms, and to re-quote automatically when the window expires rather than pay for a lock you rarely need."
  - q: "Why do some on-ramp providers not offer live quotes?"
    a: "Because they do not hold the liquidity themselves. A provider that routes conversions to a third-party exchange or market maker cannot commit to a rate it does not control, so it quotes an indicative rate and settles at whatever the partner returns. Live quotes with an honored window require the provider to own or directly access the liquidity that fills the trade."
---

*Reading time: about 6 minutes.*

On/off ramp liquidity with live quotes means a provider holds enough fiat and stablecoin inventory to fill conversions on demand, and prices each one at the moment it is requested rather than from a cached rate. For a developer, the implication is that the rate returned by the quote endpoint is the rate that settles, as long as the transaction is confirmed inside the quote's window.

## What is the difference between a live quote and a batch rate?

| | Live quote | Batch rate |
| --- | --- | --- |
| When rate is determined | At the moment of the API request | On a schedule (every minute, hour, or day) and cached |
| Rate window | Stated expiry, typically 10 seconds to 5 minutes, honored on confirmation | No commitment; settlement happens at the rate in effect later |
| User experience | The amount on the confirmation screen is the amount that settles | The user sees an estimate and learns the real amount afterward |
| Slippage risk | Carried by the provider inside the window | Carried by the user, or hidden inside a wider spread |
| Best for | Consumer flows, payroll, any product that shows an amount before sending | Internal treasury moves where the sender tolerates variance |
| Worst for | Nothing at the application layer; the cost is on the provider's side | Any flow where a person confirms a number they expect to receive |

A batch rate is not a cheaper version of a live quote. It is a different allocation of risk, and the risk lands on the user.

## How does a live quote actually work in an API?

The flow has six steps, and the quote ID is what ties them together.

1. The application calls the quote endpoint with the corridor, the amount, and which side (sender or receiver) the amount is fixed on.
2. The provider returns the rate, the itemized fees, the resulting amount, a quote ID, and an expiry timestamp in a single synchronous response.
3. The application displays the amount and a countdown to the user.
4. The user confirms.
5. The application submits the transaction with the quote ID attached.
6. The provider checks that the quote has not expired, honors the quoted rate, and executes the conversion.

Providers that own their liquidity implement this directly. BlindPay, for example, returns `expires_at` with every quote and holds bank payout quotes for a default five minute window, rejecting late submissions with a `quote_expired` error so the client can re-quote.

## What happens when a live quote expires?

**The user confirms in time.** The transaction is submitted with a valid quote ID, the provider executes at the quoted rate, and the user receives the amount shown on screen. This is the only scenario in which the provider carries any rate risk.

**The user does not confirm.** The quote lapses, nothing is executed, and no funds move. The application requests a new quote when the user returns, and the new amount may differ.

**The quote expires during processing.** The application submitted the quote ID inside the window, so the provider honors it even if on-chain confirmation or fiat settlement finishes after the expiry timestamp. If the application submits after the window has closed, the provider rejects the transaction with an expiry error, and the correct client behavior is to re-quote and ask the user to confirm again rather than to retry blindly.

## How does liquidity depth affect quote quality?

Liquidity depth is the volume a provider can convert on a corridor before the rate degrades. A deep book fills a large order at nearly the same price as a small one; a thin book has to reach for worse prices as the order grows.

Take a USDC to BRL corridor. A $500 quote and a $50,000 quote from a deep provider might differ by a few basis points, because both fill from the same inventory at the same price. The same two quotes from a thin provider might differ by 50 to 150 basis points, because the larger order exhausts the good inventory and fills the remainder at worse prices or is routed to a third party with its own markup.

Depth also sets reliability. A provider that has to source liquidity from a partner at quote time cannot guarantee the rate, so it either widens the spread to protect itself or quotes indicatively and settles at market.

To test depth during evaluation, request quotes at $500, $5,000, and $50,000 on the same corridor within one minute and compare the effective rate after fees. Then ask for the maximum single-transaction size per corridor and whether that limit is stated in writing. A provider whose spread is flat across the three sizes has the depth it claims.

## What is a typical rate window and how should it affect your UX design?

Most live quote windows fall between 10 and 90 seconds for crypto-native flows, with some providers holding bank payout quotes for several minutes. The window length dictates which confirmation pattern your interface can support.

- **About 15 seconds:** single-screen confirmation only. The amount and a confirm button must be on the same screen with a visible countdown, and the quote should be requested when that screen loads, not earlier.
- **About 60 seconds:** multi-step confirmation is possible. The user can review a summary, pick a bank account, and confirm, provided the app re-quotes automatically if the timer runs out.
- **90 seconds and up:** batch approval flows work. A finance user can review a list of payouts, each with its quoted amount, and approve them together before any quote lapses.

A window under 10 seconds is a bad consumer experience. Network latency, screen rendering, and the user reading the number consume most of it, so a meaningful share of confirmations arrive expired and the user sees a changed amount on every retry. If a provider's window is that short, either the corridor is illiquid or the provider is passing its own risk to your users.

Design for expiry as a normal path, not an error. Show the countdown, re-quote silently when it hits zero, and highlight the change only if the amount moved.

## What should a developer look for in a live quote API?

- **Synchronous response under one second.** The quote is on the critical path of the confirmation screen, so a slow endpoint eats into the rate window before the user sees a number.
- **Quote ID enforcement on the transaction endpoint.** The execute call must require the quote ID and reject unknown or expired ones, otherwise the "honored rate" is a promise with no mechanism behind it.
- **Explicit expiry timestamp and a distinct expiry error code.** The client needs the timestamp to render a countdown and the error code to distinguish "re-quote" from "something else failed".
- **Itemized fees in the quote.** Rate, spread, flat fee, and network fee as separate fields, so the amount displayed matches the amount settled and reconciliation works without guesswork.
- **Webhook settlement events.** Execution is asynchronous after confirmation, so the API must emit signed events for on-chain confirmation and fiat settlement rather than requiring polling.
- **Sandbox parity with production.** Expiry, rejection, and error codes must behave the same in sandbox, or the integration ships with untested failure paths. [Sandbox vs production](/resources/more/stablecoin-api-sandbox-vs-production) covers what sandboxes can and cannot exercise.

A provider that meets all six has built a live quote system. A provider that meets fewer has built a rate display. The [buyer's guide to on/off ramp providers](/resources/more/how-to-choose-on-off-ramp-provider) shows how to weigh this against corridor coverage, settlement speed, and licensing.

*This article is general information, not legal, tax, or financial advice.*