Adding Crypto as a Rail to Your Existing Payment Stack

If you already run Stripe or Adyen plus two or three regional acquirers, adding crypto does not require an orchestration layer and will not reduce your gateway count. Crypto is a global rail with no regional variants: it sits beside your existing processors as one more checkout option, the buyer selects it, and no routing engine is involved. The integration is a few days of work. The operating model around it, meaning refunds, reconciliation, and converting what you receive, is where the real cost sits, and almost nobody writes that part down before shipping.

The question behind most of this research is whether one orchestration layer can replace multiple regional gateways. On the card side, sometimes. For crypto, no: your regional gateways exist because buyers in those markets use local methods, not because cards fail. Crypto does not consolidate iDEAL, PIX, or UPI. It adds a rail with a different risk profile. What it can genuinely replace is a high-risk card processor for the slice of volume where disputes rather than conversion are your problem.

We have covered the engineering side before, for the other audience. Our multi-rail orchestrator playbook is written for gateway and PSP teams building the control plane itself — decision engines, liquidity pools, LSP redundancy, settlement SLAs. As a merchant you are the customer of that system, not its operator. This is the merchant-side counterpart: what changes in your operation the week after crypto goes live.

Which orders should go to the crypto rail

Most merchants enable crypto everywhere and then discover the edge cases in support tickets. Set the boundaries deliberately. Four signals actually change the answer, and each has a threshold rather than a shrug.

Signal	Where the line sits	Why it sits there
Order value under $25	Offer Lightning or ERC-20 only; suppress TRC-20 quotes	Our own measurement put a TRC-20 transfer at $2.11–$4.36 — on a $25 order, 8–17% of the basket, paid by the customer. Lightning came in under $0.01 and ERC-20 at about $0.02.
Order value above roughly $500	Best candidate for the crypto rail	A flat 0.8% fee against your blended card cost is real money at this size, and cross-border decline rates are worst on high-value baskets.
Dispute rate your acquirer has already flagged	Route the affected category, not the whole store	On-chain payments have no chargeback mechanism. That removes the dispute and also the buyer-protection story you were relying on. Trade it deliberately.
Physical goods with a return rate above ~10%	Enable last, after your refund SOP exists	Every refund is a new outbound transaction with its own address collection, network fee, and valuation question. High-return catalogs multiply that work linearly.

Note what is missing: region. Crypto demand does not map to geography the way local payment methods do, so region-based rules mostly produce false negatives.

Use your own blended effective rate here, not a list price. Published card rates vary by market: Stripe’s Singapore page listed 3.4% + $0.50 per successful domestic-card transaction when we checked on 2026-09-07, and its US page differs. Crypto pricing varies too — Aurpay is a flat 0.8%, while BitPay’s published pricing was 2% + $0.25 under $500K monthly volume when we verified it on 2026-08-31, stepping down at higher tiers. Flat and tiered rates diverge at different volumes, so run it on your actual mix; we compare the field in our crypto payment gateway comparison.

The operational differences that matter, side by side

Hand this table to whoever runs finance and support. Every row is a place where an existing card-rail process produces a wrong answer if applied unchanged to crypto.

Dimension	Card rail	Crypto rail (non-custodial gateway)
Settlement timing	Authorization is instant; money reaches your bank on a payout schedule of daily, weekly, or monthly, layered on a pending-balance availability period	Funds arrive at your wallet on network confirmation: seconds on Lightning, a few minutes on Tron and Ethereum, roughly ten minutes per block on Bitcoin mainnet. No payout schedule, because there is no intermediary balance
Who holds the money in between	The acquirer or PSP holds it, and can hold it longer under a reserve	Nobody. The transfer goes from the buyer to an address you control. No balance to freeze, no reserve to negotiate
Fee structure	Interchange plus scheme fees plus processor markup, itemized after batching, varying by card type and region	0.8% per transaction, flat and known at quote time. The network fee is paid by the sender, not deducted from you
Disputes	The issuer can reverse a settled payment long after delivery; the reversal pulls the amount plus a network dispute fee from your balance before you respond	None. A confirmed on-chain transaction cannot be reversed by the payer, their bank, or us. Fraud exposure moves entirely to pre-delivery checks
Refunds	Credit against the original charge, routed back to the same card automatically	A new outbound transaction to an address you collect from the customer. No link to the original payment except the one you record
Failed payments	A decline is instant, terminal, and moves no money	Failures are asynchronous and partial: underpayment, overpayment, payment after quote expiry, right asset on the wrong chain. Money exists but the order has not cleared
Reconciliation key	Charge ID and authorization code, plus an acquirer reference number for escalation	Gateway order ID, with the on-chain transaction hash as evidence. The hash is proof, not a join key
What you end up holding	Your bank currency	The asset the buyer paid in — BTC, Lightning BTC, ETH, USDT or USDC on ERC-20 or TRC-20, DAI on ERC-20. Converting to fiat is a separate step you run
Regional availability	Depends on acquirer coverage, issuer behavior, and local scheme rules	Identical wherever the buyer has a wallet. No BIN-level declines, no 3DS step-up, no acquirer to onboard

The on-chain fee figures above are our own measurement from 2026-08-31, not an industry roundup. We sampled 1,024 Ethereum blocks, about 3.4 hours, across two independent RPC providers using eth_feeHistory: base fee 0.070 gwei minimum, 0.116 median, 0.265 maximum, plus a 0.05 gwei tip on a roughly 65,000-gas transfer. Tron came from the getEnergyFee chain parameter, then 100 sun. The result contradicts nearly every comparison page: ERC-20 transfers were 80 to 100 times cheaper than TRC-20, because Tron’s energy price is a governance constant tracking the TRX price while Ethereum base fees have sat below one gwei since proto-danksharding. Two caveats. Ethereum is an auction and can exceed a dollar during congestion, and Tron users who stake TRX for energy pay close to nothing.

Write the refund policy before you take the first order

Refunds are where merchants get hurt, and one decision made in advance avoids most of it. A crypto refund is an outbound payment, so three things are true that are not true on cards: you pay the network fee, you need a destination address, and the asset’s price has moved since the sale.

On the address: never refund to the address the payment came from. Exchange withdrawal addresses are the classic failure: the customer paid from a shared hot wallet they do not control, and the refund lands somewhere unrecoverable. Collect a refund address as an explicit field in your returns flow, and confirm the chain with it.

On valuation, pick one of three policies and write it into your terms of sale:

• Same quantity, same asset. You return exactly what you received. Simple and defensible, but the customer bears the price move, which reads as unfair when the asset has fallen.
• Original fiat value, with quantity recomputed at refund time. The customer is made whole and you absorb the delta. Most merchants land here for stablecoins, where the delta is negligible; avoid it for BTC and ETH unless you are hedging.
• Off-rail refund, meaning store credit or a bank transfer. Cleanest operationally, and legitimate as long as you disclose it before purchase, not at the moment of complaint.

Stablecoin-denominated orders collapse most of this, which is the strongest practical argument for defaulting your crypto checkout to USDT or USDC rather than BTC. If quote, settlement, and refund are all in the same dollar-pegged asset, valuation policy stops being a live question.

The failure modes cards do not have

A card decline is binary and instant. Crypto failures are partial and arrive late, so they need order states your system probably does not have. Build these four explicitly rather than mapping everything to “failed”:

Underpayment. The customer sends less than quoted, usually because their wallet deducted the network fee from the amount instead of adding it. Define a tolerance band, one network fee’s value for that chain being a reasonable default, then auto-complete inside it and queue the rest for review with the shortfall shown in fiat. Do not auto-refund; you pay a second network fee to return something the customer intended to top up.

Overpayment. Fulfil the order and treat the excess as a refund case under the policy you just wrote. Rare enough to handle manually, common enough to need a rule.

Late payment after quote expiry. Your quote has a validity window; the blockchain does not honor it. Decide now whether a late payment is honored at the original rate, re-quoted, or refunded. Support will ask in week one.

Wrong chain. USDT exists on both ERC-20 and TRC-20, and customers still send the wrong one. Show the chain prominently at checkout and accept that recovery is manual.

All four reach your system through webhooks, which are at-least-once by nature. Make every state transition idempotent, keyed on the gateway order ID plus target status, and poll the orders endpoint as a backstop. We cover event and retry design in our guide to payment API webhooks and merchant reconciliation.

Getting both rails into one ledger

Finance will ask for a single revenue report covering both rails. Some fields align cleanly and some do not; pretending the second group aligns is how reconciliation breaks in month two.

Field	Card rail	Crypto rail	Aligns?
Join key	PSP charge ID	Gateway order ID	Yes. Key both on your own order ID and store the rail-specific ID beside it
Proof of payment	Authorization code, acquirer reference number	On-chain transaction hash	Structurally yes. Same column, different evidence class. Both are opaque strings you present when challenged
Gross amount	Presentment currency, fixed at authorization	Fiat quoted at checkout plus asset quantity received at confirmation	Partly. Persist both numbers, not only the fiat one
Fees	Interchange, scheme, and markup, itemized after batching	0.8%, known at quote time; network fee paid by the sender	No. There is no interchange breakdown to reconcile, which is a simplification rather than a gap
Settlement date	Payout batch and deposit ID, several days after the sale	Block timestamp of the confirming transaction, same day as the sale	No. There is no batch layer, so batch-oriented reports show empty groupings
Settlement currency	Your bank currency	The asset received	No. Every crypto order needs a booking rate and a documented valuation timestamp
Reversals	Chargeback record referencing the original charge	An independent outbound transaction with no protocol-level link back	No. Carry your own refund-of field, or the two sides never tie out

In practice: one orders table with rail as a column, your order ID as the key, and two columns only crypto rows populate: asset quantity and booking rate. Everything else fits the schema you have. For the day-by-day version, our first 30 days of crypto checkout playbook covers the same ground chronologically.

When a routing layer is actually worth building

We do not sell an orchestration layer, and for most merchants asking about one the honest answer is that you do not need it. Routing logic earns its keep only when your system makes the rail choice. At checkout the buyer makes it, and that is a payment method selector rather than routing. Your cart already has one.

Real routing decisions are narrower than the term suggests: subscription retries across acquirers, marketplace payouts choosing a rail by destination and amount, or a multi-acquirer setup shifting volume on live authorization rates. If none describe you, run crypto in parallel and spend the budget on the refund and reconciliation work above. If they do, the gateway-side playbook covers decision engines and failover.

The limitation you have to budget for

Aurpay settles in the asset the customer paid. There is no fiat conversion and no automatic FX in the product. If a customer pays in USDT, USDT is what lands in your wallet, and converting it to bank money is a step you run yourself. That step is not free, and an honest cost comparison has to carry it: a funded exchange account for each settlement asset, with its own onboarding and withdrawal limits; a transfer from your wallet to that exchange, costing another network fee; a trade, costing an exchange fee and a spread; a fiat withdrawal on bank rails, which puts you back on the T+N timing you were trying to escape; and a booking rate recorded at each step. You also carry price exposure between confirmation and conversion, which is trivial for stablecoins and not trivial for BTC.

So: if you want the crypto rail for faster access to bank money, it does not deliver that, and someone should say so before a business case is built on it. If you hold stablecoins as working capital, pay suppliers or contractors in them, or convert weekly rather than per order, the loop closes and the flat 0.8% against your blended card cost is a real saving. If every order must become fiat immediately, price the conversion step as an operating cost and subtract it before comparing. Our guide to crypto on-ramps and off-ramps covers that side.

What to do this week

Pick one order-value band and one product category, enable the crypto rail there only, and write the refund policy and underpayment tolerance before the first order lands. Add the two crypto columns to your orders table on day one, not after finance asks. Then measure what you already measure on cards — completion rate, tickets per hundred orders, and effective cost per order after conversion — and widen it from your own data.

Aurpay is a non-custodial gateway on Bitcoin, Bitcoin Lightning, Ethereum, and Tron, accepting BTC, ETH, USDT and USDC on ERC-20 and TRC-20, and DAI on ERC-20, at 0.8% per transaction with funds going straight to your wallet. Native integrations cover Shopify via a Custom App, WooCommerce, Ecwid, BigCommerce, PrestaShop, OpenCart, Paid Memberships Pro, and Easy Digital Downloads, plus a REST API for your own stack. No contracts or banking details are required to start. If you are still choosing a provider, start with our gateway comparison and bring your own blended card rate.