Payment Processing for Crypto Merchants: Business Models, Fiat Flows and Provider Eligibility

Separate your own sales proceeds from customer balances and other sellers’ money. A shop selling its own equipment may want a checkout that accepts crypto and converts the proceeds. A platform enabling someone to buy crypto needs to identify the seller of that asset and the parties handling the fiat payment and delivery to the wallet.

An exchange or brokerage adds deposits, conversion or trading and withdrawals. A custodial service holds or controls assets for customers. A marketplace may collect proceeds owed to other sellers. A company converting its own treasury funds has a different purpose again. These distinctions describe flows to explain, rather than legal classifications or statements that a route is permissible.

Use the table to prepare an application. If the product performs several roles, show each flow instead of choosing the least complicated label. Explain when money becomes the company’s own proceeds and when an obligation to a customer or seller remains. A provider cannot assess an omitted activity from a familiar crypto logo on the website.

Stripe’s stablecoin-payment documentation describes checkout acceptance with completed payments credited to a local-currency Stripe balance. Its current business-location guidance lists the US and identifies private preview for businesses in the EU, Hong Kong, Mexico and Switzerland. Customer reach is broader than merchant eligibility. A preview listing needs confirmation of access for your account. [1]

Stripe’s fiat-to-crypto onramp is a separate product. Stripe describes itself as merchant of record for those onramp transactions, with specified identity, sanctions, fraud and dispute responsibilities, and requires an onramp application. That description does not approve every activity of the platform embedding it. [3]

BitPay’s Merchant and Donee Terms describe Acceptance Services for goods, services and eligible donations, expressly distinguishing them from an exchange or custody service. Coinbase Business, by contrast, describes a business account with payments, conversion and custody-related functions; its public FAQ currently lists US and Singapore availability. These services should be compared against the function you need rather than treated as interchangeable crypto gateways. [4][7]

A provider’s ability to accept a stablecoin payment for a merchant does not mean it will process every exchange, wallet or financial-service business. Stripe’s US-linked restricted-business page lists cryptocurrency exchanges and wallets under limited-availability activities. BitPay’s merchant terms list activities such as cryptocurrency sale/trade and e-wallets as requiring express authorisation within its restricted-business section. These are the providers’ published restrictions, not a finding that your applicant qualifies. [2][4]

Submit the actual product, legal entity, website, customer locations and funds flow before treating a technical feature as an available acquiring route. Explain custody or control of keys, whether customers retain balances, who may initiate withdrawals and whether third parties receive proceeds. Include the evidence and permissions the provider asks for; an approval on one flow should not be silently extended to another.

Country, asset and network support need separate answers. A provider may serve a merchant entity in one country, receive payments from a wider set of buyers and still support only specified assets, chains or bank destinations. Ask about the combinations you intend to use, including the payout beneficiary, rather than relying on a total count of supported countries or currencies.

Keep an order record connected to the provider invoice and, where relevant, the chain transaction. The customer’s wallet showing a transfer does not by itself establish that the provider matched the correct asset, network, amount and invoice or credited the merchant account. Decide which provider-confirmed state releases goods or access and what happens to exceptions.

BitPay’s notification guidance says that its IPNs are not signed and should trigger a separate invoice-status verification through its API. It also says that paid alone is not a payment guarantee; order handling should use the documented confirmed or complete state, with continuing monitoring where appropriate. Follow the supported verification process rather than trusting an incoming payload to release stock. [6]

Make fulfilment safe when the same notification arrives again. Link it to the existing order and current invoice state, so the application cannot dispatch twice. Keep pending, expired, underpaid or otherwise exceptional payments out of the normal paid-order queue until the provider’s records resolve them. Agree the operational rule with the provider instead of assuming every asset becomes final after the same number of confirmations or minutes.

There are several milestones after the buyer pays: provider recognition, any conversion, ledger credit, settlement initiation and receipt at the bank or wallet. Record the amount and currency at each stage. If your costs are in fiat, a crypto balance may still need conversion and a supported withdrawal before it can pay a supplier.

BitPay’s banking guide illustrates why the bank route matters. It lists a USD20 minimum for USD settlement by ACH to US banks and a USD10,000 minimum for USD wires to banks outside the US. Those are different documented routes, not one universal USD payout promise. Confirm the current route and minimum for your approved account before building a cash plan. [5]

Ask what fees, conversion rates, minimums, verification conditions and holds can affect each step. Who receives the settlement, what statement proves it was issued, and what will finance use to match it to the bank? Treat a scheduled settlement as a distinct record until the receipt has been reconciled.

Suppose a merchant issues 100 invoices at USD200 each. At the review point, 94 are complete and credited, four remain pending and two are expired without payment. Assume credited amounts have already been converted into USD at the values shown. For this example only, processing costs 1% of credited gross receipts, that fee is retained on refunded payments, and no other conversion, network, bank or tax adjustments apply.

Gross credited receipts are USD18,800, so the assumed processing charge is USD188. Two completed purchases are then refunded at their full USD200 pricing-currency value, making refunds USD400. Net credited receipts after these deductions are USD18,212. If USD16,000 has actually reached the bank, USD2,212 remains on the provider ledger.

The four pending invoices represent USD800 of unresolved invoice value. They are outside the credited receipts and are not extra bank cash. The two unpaid expired invoices add no receipts. These assumed states and fees illustrate the reconciliation; they are not provider pricing, measured payment outcomes or an estimate of future losses.

A refund expressed as the same fiat purchase value can differ from a refund of the same number of crypto units. Decide how the customer-facing policy, provider operation and finance record connect. A chain transfer being difficult to reverse does not resolve whether the merchant owes a commercial refund or how it will be funded.

BitPay’s merchant terms describe refund choices based on pricing-currency value or the crypto amount used for the invoice, with remittance in the original cryptocurrency. The terms also allow a request for bank funding if the merchant balance is insufficient. Confirm the applicable account procedure and charges rather than promising that every refund will return exactly the original units. [4]

Stripe’s stablecoin-payment documentation describes refunds going back as stablecoins to the original wallet. That is a property of the named product, not a universal rule for crypto processors. [1]

Keep the original order, payment, refund request and completed refund record together. Explain which value the customer can expect and how you will handle a failed or unresolved refund. Obtain advice on the obligations applying to the underlying sale where necessary.

Product changes can alter custody, integration and availability as well as the brand shown at checkout. Coinbase’s official transition notice set 31 March 2026 as the point after which the Commerce portal would be inaccessible and describes a move to Coinbase Business with a new operating model. An old Commerce tutorial or plugin listing should therefore not be treated as a current implementation plan. [8]

The current Coinbase Business FAQ independently lists US and Singapore availability. Confirm application approval and enabled functions against the actual business account. A feature described on the public site still needs the right geography, configuration and commercial terms. [7]

For any provider change, record what happens to existing invoices, refunds, wallet destinations, API access and statement history. Check whether an existing account or integration can be retained or must be replaced. Keep historical records needed to explain earlier payments even when new collections move elsewhere.

Give the provider a one-page description of the seller, buyer, asset sold, payment asset, network, custody/control, delivery and final recipient. Add expected monthly value, transaction count, typical and largest purchase, refunds, customer countries and required bank or wallet payout. Use compatible periods and currencies so the figures can be reconciled.

The underlying business remains important. A restricted product does not become acceptable merely because the buyer pays in crypto. Ask the provider to state which activity and flow it is considering and which evidence or conditions remain unresolved. Keep any actual licence or jurisdictional assessment tied to the responsible specialist; do not substitute the payment feature list for that work.

Before launch, test the permitted asset/network combination, an expired invoice, a delayed status, repeated notifications, the refund path and the first settlement reconciliation. Assign owners for customer support, wallet/account access, reconciliation and exceptions. Review access controls and recovery arrangements for the accounts and wallets used by the business. Do not place private keys or live credentials in a shared onboarding document.