Crypto Order Fulfillment: Shipping, Customs and Refunds

Almost every guide to accepting crypto stops when the payment confirms. That is the halfway point. Nobody documents what happens next: how many confirmations before you print a label, what happens to the shipping cost between checkout and dispatch, what number goes on the customs form, and how you refund a customer on a network with no reverse gear.
The short version. Ship on a confirmation threshold that scales with order value, not one global setting. Price shipping in fiat and treat the crypto you hold as a separate treasury decision. Refund by sending a new transaction from your own wallet to an address the customer proved they control, in the same asset on the same network, on a basis you fixed before your first dispute rather than during it.
What follows is the procedure and the numbers behind it, written for a Shopify or WooCommerce store already taking payments. If you are still choosing an integration, our 2026 Shopify gateway comparison covers that decision instead.
When to ship: a confirmation threshold you can apply
“Wait for enough confirmations” never says what enough means. The threshold is a bet: fulfilment speed against the chance that the block holding your payment gets reorganised out of the chain. Size it against what you would lose.
Why six confirmations became the default
It traces to a probability table in the original Bitcoin whitepaper, section 11. Assuming an attacker with 10% of hash power actively trying to reverse your payment, the probability they succeed is 20.46% after one confirmation, 5.10% after two, 1.32% after three and 0.0243% after six. The paper solves for the depth where that drops below 0.1% and gets five.
So six is five rounded up, under an assumption that someone is spending real money to reverse your order. Nobody rents 10% of Bitcoin hash power to claw back a $180 pair of boots. In retail the realistic failure mode is an honest short reorg, almost always one block deep.
Counts do not translate to the other networks. Ethereum reaches finality through checkpoint voting rather than depth, and its own documentation says it “takes about 15 minutes for an Ethereum block to finalize” — the problem single-slot finality exists to solve. Tron solidifies instead: per the TRON protocol documentation, a transaction is confirmed once “at least 19 distinct active SRs” have produced blocks at or above that height, which “typically takes about 1 minute.” No partial credit. Lightning is final when your node has the preimage; the residual risk is a channel force-close, not a reversal.
The threshold table
Set the rule on order value and how recoverable the goods are. A download costs nothing to re-issue; a personalised item cannot be resold at all.
| Order value / recoverability | BTC on-chain | ETH and ERC-20 | Tron TRC-20 | Lightning |
|---|---|---|---|---|
| Under $100, or digital and re-issuable | 1 confirmation (~10 min) | ~12 blocks (~2.5 min) | Solidified (~1 min) | On preimage receipt |
| $100–$1,000 physical, resellable | 2 confirmations (~20 min) | ~32 blocks (~6.5 min) | Solidified | On preimage receipt |
| $1,000–$10,000, or non-resellable | 3 confirmations (~30 min) | Finalised (~15 min) | Solidified + 10 min hold | Finality plus manual check |
| Over $10,000, personalised, or ships same day | 6 confirmations (~60 min) | Finalised + manual review | Solidified + manual review | Manual review |
On a $200 order carrying $80 of goods, two confirmations put reversal at 5.10% only if someone is funding a 10% attack on it. Absent that, the exposure is a fraction of a cent against a support ticket costing several dollars. Most merchants set this too high. The bottom two rows are where release should be a person’s call.
Shipping cost and the FX window nobody prices in
There are two exchange-rate windows and merchants worry about the wrong one. The first is checkout to payment, and Aurpay closes it: the crypto amount is calculated when payment is initiated, so the obligation is fixed in coin terms while the order keeps a fiat reference value. Unpaid orders expire and fire a timeout callback.
The second window is settlement to conversion, and that one is yours. Aurpay is non-custodial and performs no fiat conversion, so what lands in your wallet is the asset the customer sent, while your label, packaging and cost of goods stay in fiat. Take BTC on Monday, ship Thursday, sell next week, and the margin on that order is a function of the coin price rather than your pricing. Price in fiat and pick a settlement asset matching the currency your costs are in.
One detail catches stores with free-shipping thresholds: test the threshold against the fiat order value, never the crypto amount, or a quote refresh moves customers across the line between two page loads.
Refunds when nothing on the chain reverses
A card refund is a message to a network that still holds a relationship with the money. A crypto refund reverses nothing: the original transaction stays on chain forever. You are sending a second, unrelated transaction from your wallet to your customer’s, and the only thing connecting them is your own bookkeeping.
On a non-custodial gateway that is structural, not a missing feature. Funds go straight to your wallet and Aurpay never holds them, so there is no pool at the gateway to refund from and no support ticket that can produce one. You can automate the outbound leg through the payout side of the REST API, but the funds and the signing authority are yours. The consequence people discover late: a refund needs someone with wallet access. Decide now whether that is a named person, a multi-signature approval, or a refund float wallet.
Step 1: get a refund address you can trust
Never refund to the sending address by reflex. If the customer withdrew from an exchange, that address is the exchange’s hot wallet, and funds sent back are at best a support ticket at a company you have no relationship with. On-chain sender data is not a customer record. Collect the address through an authenticated channel — the account they ordered from, or the original order thread — then verify it:
- Signed-message challenge. Issue a one-time string tied to the order, have the customer sign it with the receiving wallet, and check the signature recovers to the address they gave you. Free, and works on self-custodial Bitcoin and EVM wallets. It fails for exchange deposit addresses, which is itself the filter: if they cannot sign, they are asking you to send somewhere they hold no keys.
- Test transfer. Send a small amount first, have them confirm the exact figure received, then release the balance. Costs one extra network fee.
Which to use follows from what a transfer costs, and our own measurements point somewhere counterintuitive. Sampling on 2026-08-31, a typical USDT or USDC ERC-20 transfer came to about $0.02 ($0.01–$0.05, from 1,024 blocks of eth_feeHistory across two independent RPC providers, base fee p50 0.116 gwei). The same transfer on Tron cost $2.11–$2.15 to an address already holding the token, or $4.24–$4.36 to a fresh one, from TronGrid’s getEnergyFee parameter at 100 sun.
That runs against what most comparison pages claim, so treat it as a dated snapshot: Ethereum fees are an auction and spike under congestion, Tron’s dynamic energy pricing pushes popular contracts above the floor we measured, and merchants who stake TRX pay close to nothing. The conclusion survives either way — test transfers on Ethereum, signed messages on Tron.
Step 2: decide the amount before your first dispute
Refund in the same asset on the same network. Under Article 13(1) of the EU Consumer Rights Directive, a trader must reimburse within 14 days of being told of a withdrawal, “using the same means of payment as the consumer used for the initial transaction, unless the consumer has expressly agreed otherwise and provided that the consumer does not incur any fees as a result.” UK law carries the equivalent obligation. USDT on Ethereum to someone who paid on Tron is not the same means of payment.
How much is harder. For stablecoins it does not arise. For BTC and ETH the price has moved, and there are two defensible bases.
| Basis | Customer gets | Carries the price move | Use when |
|---|---|---|---|
| Fiat value — the coin amount worth the original price at the refund date | The purchasing power they paid | Merchant | Default for consumer goods priced in fiat, and EU/UK statutory withdrawals |
| Coin quantity — the exact amount of coin received | The same asset they sent, whatever it is worth now | Customer | B2B and crypto-native contexts where the invoice was denominated in coin and the terms say so |
Neither is universally correct, and no settled case law says which satisfies “all payments received” when the payment was a volatile asset. Deciding case by case is what is certainly wrong. Pick one, put the sentence in your checkout terms before the first order, and apply it every time. Our checkout policy template has wording to adapt.
Step 3: decide who pays the network fee
- Statutory withdrawal in the EU or UK. The consumer must not incur a fee as a result, so the network cost is yours. On ERC-20 that is two cents. On Tron at $2.11–4.36 a send it is a real line item at hundreds of returns a month, and an argument for defaulting checkout to the network you refund on cheaply.
- Voluntary return outside that window. You may net the actual network cost, but disclose the figure before you send and record it as a deduction.
- Anything beyond the chain cost is a restocking fee. Label it as one. There is no outbound gateway charge to pass on: Aurpay’s 0.8% is taken on the inbound payment, which also means it does not come back. Budget a refunded order at order value plus 0.8% plus the network fee.
Step 4: the refund record
A refund on chain is a disposal of property, not a payment reversal. IRS Notice 2014-21 is explicit: virtual currency “is treated as property,” basis is fair market value in USD “as of the date of receipt,” and you have gain or loss on disposal. So a refund three weeks after the order can produce a taxable gain even though you just gave money back.
| Field to record when you send | Why it exists |
|---|---|
| Order ID and inbound transaction hash | The only link between two unrelated transactions |
| Asset and network, inbound and outbound | Same-means-of-payment evidence |
| Coin received, fiat value at receipt date | Cost basis under Notice 2014-21 |
| Coin refunded, fiat value at refund date | Disposal value, and the gain or loss |
| Refund basis applied | Proof the policy was applied consistently |
| Destination address and how it was verified | Your defence in a later dispute |
| Network fee paid and who absorbed it | Deduction audit trail |
| Outbound hash, approver, reason code | Proof of payment and internal control |
All eight are free at send time and expensive a quarter later. Our first 30 days operations playbook covers where this sits in daily reconciliation.
Cross-border: customs values, screening and the return leg
The customs value is the fiat price, not the coin amount. US appraisal works from transaction value, the price actually paid or payable in dollars, and foreign-currency conversion runs on CBP’s proclaimed and certified rates under 19 CFR Part 159 Subpart C. There is no proclaimed rate for BTC, because it is not a foreign currency. So the figure on your commercial invoice or CN22 is the fiat price displayed at checkout — not the crypto amount, and not the fiat value at ship date. CBP’s informed compliance publication is the reference for your freight forwarder.
Your only geographic signal is the shipping address. A card payment hands you a billing country, an issuing-bank country and an AVS result before you accept it. An on-chain payment hands you an address and an amount. So restricted-destination screening runs against the shipping address, and it runs before you fulfil rather than before you accept payment, because once the transaction is on chain you cannot decline it. Put that check in the release gate beside the confirmation check, and document what a failed check means: a refund under the procedure above, not a silent cancellation.
The return leg has two costs and only one is new. Duty and VAT recovery runs through the same channels it always did. New is that the refund is an outbound transfer with a network fee, on top of return freight. On a $60 order refunded over Tron, the network cost alone can be 4% to 7% of order value — an argument for a store-credit option on low-value international orders. Our guide to cross-border stablecoin payments covers the settlement side.
Underpaid, overpaid and late orders
These arrive at your fulfilment desk looking like fulfilment problems, but they are payment problems, and the fix belongs upstream of the packing bench. One point is worth carrying over here because it changes what you tell a picker: most underpayment is a wallet or exchange netting its withdrawal cost out of the amount sent, so the shortfall is a roughly fixed dollar figure rather than a percentage. A percentage tolerance band is therefore the wrong instrument, because 1% under-covers a $30 order and over-covers a $3,000 one. Set the band in dollars, per network, and hold anything outside it rather than part-shipping.
One rule has no exceptions: never manually mark an order paid without seeing the transaction confirmed at your threshold. It is the first control bent on a busy day. The thresholds themselves, the overpayment cases where refunding costs more than the amount refunded, and what is actually recoverable when a customer picks the wrong network, are set out in our SOP for underpaid, overpaid and wrong-network payments.
The one-page version
- Set a release threshold per network and value band.
- Screen the shipping address at the release gate, not at payment.
- Price in fiat and keep the fiat reference value on the order for the customs form.
- Verify every refund address by signature or test transfer.
- Refund in the same asset on the same network, on a stated basis, absorbing the network fee on statutory returns.
- Record the eight refund fields as you send.
If you are choosing or replacing a gateway, weigh the fulfilment layer in the decision. Direct-to-wallet settlement removes the intermediary that could freeze a payout, and it also means refunds are yours to run: more control, more procedure. Our Shopify gateway comparison and WooCommerce setup walkthrough cover which parts an integration handles for you. Aurpay settles BTC, Bitcoin Lightning, ETH, USDT and USDC on ERC-20 and TRC-20, and DAI on ERC-20 straight to your wallet at a flat 0.8% per transaction, with no contracts or banking details required. What it will not do is hold your money — which is the point, and the reason the procedure above is yours to own.

