Wide at the checkout.
Narrow in the treasury.

The treasury problem nobody prices in

Say you invoice $149 and a buyer pays in BTC. If BTC drops 4% before you get around to converting, your $149 sale quietly became $143 — a 4% "fee" that dwarfs any gateway's pricing, applied at random. Multiply across a dozen accepted coins and your revenue is a small unmanaged crypto portfolio. Most merchants discover this at tax time, which is the worst possible time.

The traditional fixes are all labor: convert manually every day (a job), accept stablecoins only (turns away buyers), or run treasury scripts against an exchange (custody + API risk you didn't want). The gateway is the right layer to solve this, because the gateway is the one party that knows the moment value arrives.

One field, two modes

Auto Settle is a settlement declaration, not a trading feature:

• Per payment: pass settlement_coin on a white-label payment. The conversion quote locks when the invoice is created — the amount the buyer sees already prices the swap in, so a rate move between invoice and payment is not your problem.
• Account-wide: set a default settlement coin once in settings. Every credited deposit in any other coin auto-converts — including static-address deposits that never went through an invoice.

Nearly everyone picks USDT (TRC20, for cheap withdrawals) or USDC. But "hold one thing" is your choice — a BTC-standard business can just as well settle everything into BTC.

What happens when the market moves against the swap

The part that matters more than the happy path: conversions execute against a real venue, and venues can deliver less than quoted. Auto Settle bounds that with a slippage guard — if delivery falls materially short of the quote, the conversion is refused, and you're credited in the original coin instead. Funds never sit in limbo and never silently evaporate into spread. The webhook tells you which of the two happened:

{
  "status": "PAID",
  "coin": "BTC",
  "amount": "0.00131",
  "settled_coin": "USDT_TRC20",
  "settled_amount": "148.61",
  "swap_fallback": false
}

Reconcile against settled_coin / settled_amount — that's your leg of the trade. swap_fallback: true means the guard fired and the original coin is in your balance; convert it later with a manual balance swap, or don't. Either way your books see exactly what happened, in the same signed webhook that told you about the sale.

On pricing: OrbChain adds no markup on the conversion. The standard deposit fee applies once; the venue's rate passes through. The economics of Auto Settle are the volatility you stop eating, not a spread we start collecting.

When not to auto-settle

Honest boundaries, because a settlement declaration is a policy decision:

• If you're deliberately accumulating a coin — some businesses want the BTC exposure. Auto Settle is off by default; that's a feature.
• Very small payments — venue minimums exist. Below them, deposits credit in the original coin (and the webhook shows it), so dust doesn't get eaten by conversion mechanics.
• Split payments — revenue splits distribute the deposit coin and can't be combined with a settlement conversion on the same payment. Stablecoin invoices + splits is the usual answer for marketplaces.

The shape of the result

With Auto Settle on, "which coins should we accept?" stops being a treasury question and becomes a pure conversion-rate question — accept whatever your buyers hold, because it all lands as the one asset your books are denominated in. Wide at the checkout, narrow in the treasury. One field on the API, or one dropdown in settings.