Skip to content
Independent crypto magazine Updated Publish with us
MustangCoinCrypto explained, without the hype

Explainers for people who hold keys, pay fees and read the fine print.

Policy & Payments

How Merchants Accept Crypto

The two basic options for a merchant to accept cryptocurrency payments are either to receive the funds directly into a wallet the merchant itself controls, or to use a third-party payment processor…

Published Reading time 4 minDesk MustangCoin editorial

Recruit-AirPay-Device-Japan-National-Stadium
Photo: RuinDig/Yuki Uchida / Wikimedia Commons, CC BY 4.0

The two basic options for a merchant to accept cryptocurrency payments are either to receive the funds directly into a wallet the merchant itself controls, or to use a third-party payment processor that will settle the payment in local currency. Each choice comes with tradeoffs the merchant must evaluate.

When a merchant accepts payments directly, it usually does so by giving the customer a wallet address and waiting for an on-chain transfer. That requires the merchant to manage its own wallet and private keys, to verify incoming funds and settle them into an operating account, and to decide how much on-chain confirmation to wait for before shipping the goods. Once the payment is received and confirmed, the transaction is irreversible: crypto payments are final.

Using a processor, the merchant gives the customer a checkout that does approximately the same thing. The payment is quoted in the currency of the customer's choice, accepted in the same currency, and settled in the merchant's preferred local currency after the checkout completes and the payment is confirmed by the blockchain. The processor assumes the risk of price volatility, processes refunds if needed, and handles the accounting paperwork for the transaction.

These two options mean merchants must choose between accepting payments at the minimum cost or else relying on a processor to handle the payments for them in exchange for a fee.

In the processor-held quote window, the exchange rate is normally locked for a few seconds or minutes. If the checkout isn't completed in that time, the payment price reverts to what's current when the checkout completes. This gives the customer a moment to decide, but it also shifts the risk of price change onto the processor.

After the customer makes a payment, the merchant doesn't release the goods for shipping until a predefined number of confirmations have been added to the transaction on its native chain. This is a standard policy to protect against a kind of attack called a double-spend.

A transaction on Solana reaches economic finality 32 slots after the transaction’s own slot, which at typical slot times amounts to about ten seconds 1. The same transaction on the Arbitrum Rollup would take somewhere between 5 and 15 minutes for full settlement 2. A merchant monitoring confirmations against that risk profile might let a $10 order ship after one confirmation on each, but decide to wait for 3 on Solana and 5 on Arbitrum for a $1000 payment.

The term "finality" refers to the time at which a newly written transaction can be assumed irreversible: miners are not likely to add a later transaction that rewrites the old one's history, and collaboration between miners to attempt that kind of rewrite is impractical, because the network's protocol treats all miners as incentivized to accept the longest, latest write.

On Solana, Arbitrum, and Stellar, this kind of rewrite is very unlikely because their consensus models reach economic finality within seconds of settling a transaction on the chain. However, on a probabilistic consensus model like Bitcoin or Ethereum, a deep confirmation queue increases the amount of processing power needed to maintain that kind of rewrite, but doesn't render a further rewrite impossible 9, 10, 11, 12. A merchant using a probabilistic network might therefore decide to trust the transaction as final only when a higher portion of the network's hashing power has been employed in its favor, and wait a longer time before accepting it as accepted.

Another factor that moves the acceptable confirmation mark is the merchant's familiarity with the payment provider— whether a processor or its own hot wallet.

Stablecoins like USD Coin are used to avoid the fluctuation risk inherent in quoting an exchange rate at checkout: since USD Coin is defined strictly as an exchange of value with the US Dollar, the value of a stablecoin generally holds steady, and any newly added fee for the stablecoin's blockchain's approvals reflect movement in the network more than change in the stablecoin's value.

Moreover, rollup networks and low-fee chains can reduce the practical cost to low enough that even small transactions can settle safely

Processor and wallet flows are very different from the post-purchase chargeback model of card networks. Reversals and refunds still happen the way they would for a fiat payment, but.

The major change in the merchant's operational flow is an added step of confirming each payment onchain—and that flow is constrained by the merchant's chosen risk tolerance for each chain. Solana's 10-second finality is far faster than Ethereum's 15-minute confirmation, which means a pair of wait times that vary from 15 seconds on Solana to 45 minutes on Ethereum, all else equal.

A Stablecoin payment is a push, not a pull: the customer sends the funds from its wallet to the merchant on the merchant's terms. A merchant process could automatically receive the payment into a hot wallet, check the signature, verify the stablecoin denomination, tally the payment in the ledger, and fulfill the order with all that accomplished autonomously and in seconds, if fully automated.

But onchain payment has additional compliance ramifications: the ledger of payments the merchant makes becomes public on the blockchain, and various governmental bodies will likely see that as a money transmitter record that must be filed and reported. A processor with banking or financial services relationships will also need to comply with those regimes, and that might add a bit of data-sharing friction to the fulfillment process.

In conclusion, onchain payments are practical enough to be used for everyday retail, but they do shift some logistical flows from payment processing to fulfillment: the payment amount must be checked manually, and the fulfillment should not begin until a merchant-defined depth of confirmation is reached.