On/off-ramp provider contracts: 12 terms to negotiate before you sign

The 12 contract terms that decide what an on/off-ramp provider owes you: quote firmness, last look, refunds, settlement, fees, records, holds, and exit.

Negotiate 12 terms before signing with an on/off-ramp provider: quote firmness, quote window, last look, fee change notice, volume minimums, custody, refunds, settlement commitments, compliance holds, records, incidents, and exit. The demo shows how the API behaves. The contract decides what the provider owes you when a quote, payout, or provider goes wrong.

This is the stage after the RFP. You picked a provider; now the commercial and legal teams turn answers into obligations. The table below is the checklist. The sections after it cover the terms that cause the most trouble later.

Key takeaways

  • A quote is only as firm as the contract makes it. Get execution at quoted rate and fees in writing.
  • Ask for the last look policy explicitly. The FX Global Code expects disclosure.
  • Refund clauses should name the destination, the trigger, and the timeline per rail.
  • Fee changes need a notice period. Volume minimums need a reason.
  • Plan the exit now: return of funds, notice, and a full data export.

Which 12 terms should you negotiate?

These twelve, in roughly the order they bite. The stablecoin API RFP template covers the questions you asked earlier; this table covers what to write down.

#TermWhat to ask forRed flag
1Quote firmnessAccepted quotes execute at the quoted rate and fees"Rates are indicative until settlement"
2Quote windowExpiry returned with every quote, in the APIWindow set only in a PDF appendix
3Last lookWritten disclosure of whether accepted requests can be rejectedSilence, or "at our discretion"
4Fee changesNotice period before per-transaction fees changeChanges effective immediately
5Volume minimumsNo minimum, or a minimum tied to a fee tierShortfall fee with no benefit
6Custody and fundingWho holds funds at each step; pre-funding requirementsUnclear who holds funds between steps
7RefundsDestination, triggers, and timing per rail"Refunds processed as available"
8Settlement commitmentsPer-rail windows and what counts as settledOne global number for every rail
9Compliance holdsResponse times for requests for information, and outcomesNo timeline, no notice
10Records and dataAPI access to full history and an export on requestRecords only through support tickets
11IncidentsNotice and status updates when a rail or network degradesNo incident notice obligation
12ExitReturn-of-funds procedure, notice period, data exportExit fees, or funds frozen during notice

How should quote and last look terms be written?

Tie them to the API, not to a rate sheet. A good clause says the provider executes an accepted quote at the rate and fees it returned, before the expiry the response states.

On BlindPay, a payout quote locks the exchange rate and fee, expires 5 minutes after creation, and a quote can back only one payout (payout quotes docs). BlindPay's docs also tell integrators to read expires_at from each response rather than assume a fixed lifetime, since some rails can return a shorter window (cut-off times). That's the behavior the contract should describe in your terms. If a provider's quotes are short or long, the window is less important than the commitment that it is honored. Why a locked quote costs the provider money explains what the provider is pricing when it agrees.

Last look needs its own line. The FX Global Code defines it as a practice "whereby a Market Participant receiving a trade request has a final opportunity to accept or reject the request against its quoted price," and Principle 17 says participants using it "should be transparent regarding its use and provide appropriate disclosures to Clients" (FX Global Code). For payouts, a rejection after acceptance means a late salary. Ask for firm quotes, or at least a disclosed rejection rate.

What should refund and compliance hold clauses say?

Name the destination, the trigger, and the clock. Vague refund language is where cross-border contracts fail people.

Ask the provider to state, per rail:

  1. Where funds go when a payout can't be delivered.
  2. Which cases refund automatically and which need a person.
  3. How long each takes.
  4. Who pays network or bank costs on the return.

BlindPay's published position is a useful benchmark. If a payout can't be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set. On Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review.

Holds need a timeline too. BlindPay's compliance team reviews flagged payins and payouts, may send a request for information, and a transaction whose request isn't answered within 24 hours may be refunded to the sender (on-hold transactions). A contract should say how you'll be notified and how fast you must answer, so your ops team staffs for it.

Settlement windows belong in an annex per rail. Stablecoin API SLAs and settlement finality explains why one global number hides the corridor that matters to you.

What fee and minimum terms protect you as you grow?

A notice period on fee changes, and no penalty for slow months. Illustrative example, with invented numbers:

You pay 400 supplier invoices a month, averaging USD 5,000 each, so USD 2,000,000 of volume. A provider raises its per-transaction fee by 0.10% with immediate effect. That is USD 2,000 more per month, and you can't reprice your own customers fast enough to pass it on. A 60-day notice clause turns the same change into a planned price update.

Now add a USD 1,000,000 monthly minimum with a shortfall fee of 0.20%. In a slow month of USD 600,000, you pay 0.20% on the missing USD 400,000: USD 800 for volume you never sent.

What to ask for:

  • Notice before fee changes, with the right to terminate without penalty if you don't accept them.
  • Fees visible per transaction. BlindPay combines a monthly plan for platform access with per-transaction fees that vary by rail and network and are disclosed in the live quote before execute; owners and admins can also read the configured fee per rail and network from the billing fees endpoint (billing docs).
  • No setup fee and no unexplained minimum. BlindPay's billing docs state there is no setup fee.

How do you plan the exit before you sign?

Write the return-of-funds and data clauses now, while you still have room to negotiate. What happens if a stablecoin payment provider fails walks through the bad case.

Four exit terms:

  1. Return of funds. In what form (stablecoin to a named wallet, or fiat to a named account), on what timeline, and with what fees.
  2. Notice period. Long enough to move customers and bank accounts, short enough that you aren't trapped.
  3. Data export. Every quote, payout, payin, and customer record in a machine-readable format. US rules require financial institutions to retain records the Bank Secrecy Act chapter requires "for a period of five years" (31 CFR 1010.430), so ask how the provider meets that for you after termination.
  4. Custody clarity. Funds held by the provider are an exit problem; funds that never leave your control are not. BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets, where you authorize the exact amount and BlindPay executes that single transaction. Optional BlindPay-managed wallets (beta) are custodial when you choose that path, so put a return procedure for those balances in the contract.

The pricing behind all twelve terms is the same thing every ramp sells: a spread, fees, and a commitment to a price. How on/off-ramp providers make money shows where each term touches the provider's economics, which is where your negotiating room is.

What to do next

Paste the 12-row table into your redline, mark each term as agreed, open, or missing, and send the open ones to the provider before the next call. Pair it with the questions in the provider due diligence list.

FAQ