How to Accept Crypto Payments: An Operations Guide

Who this guide is for—and who needs a different plan

This guide is for merchants, SaaS companies, marketplaces, fintechs, PSPs, and other lawful businesses adding on-chain payment acceptance to an existing order or invoice flow. It is written for product, engineering, operations, finance, security, and compliance teams that need one shared launch checklist.

It is a good fit when customer demand is known, the business can name a payment owner, and there is a clear reason to collect a particular asset on a particular network. It is not a substitute for a treasury strategy, a custody design review, local legal advice, or a rescue plan for a business that cannot already reconcile its conventional payments. If there is no evidence that customers want the method, run a limited discovery test before building a large integration.

Do not use this guide to move money for third parties, obscure source of funds, avoid sanctions or tax controls, or make an unsupported authorisation claim. The legal treatment can change with the activity, jurisdiction, custody arrangement, and flow of funds. FinCEN’s 9 May 2019 guidance, for example, distinguishes between some users and money-transmission business models in the United States; it also says that fact patterns not specifically covered may still carry obligations.

Choose the operating model before choosing an API

There are three common models. None removes the merchant’s responsibility to understand the customer journey, books and records, contractual allocation of risk, and local obligations. The practical decision is which functions the business will operate and which it will buy.

Ask each shortlisted provider for an exact description of custody, supported network-token pairs, quote expiry, underpayment and overpayment handling, confirmation policy, webhook authentication, retry behaviour, settlement options, refunds, data exports, geographic restrictions, incident communications, fees, and contract terms. “Supports USDC” is not precise enough: the network and token contract matter.

Implementation checklist: from order to reconciled settlement

1. Define the payment job and owner

Write a one-page operating brief before implementation. Name the customer segment, sales channel, average and maximum order value, product-delivery timing, accepted currencies, supported countries, refund policy, settlement objective, and internal owner. Decide whether the flow is one-time checkout, an invoice, a reusable payment link, a subscription, a deposit account, or infrastructure embedded for another business. Those are different jobs and should not share a vague “paid” status.

Set success measures for the first 30 days: eligible checkout sessions, customer selection rate, completed payments, time to authoritative completion, expired or mismatched payments, support contacts, refunds, and reconciliation exceptions. A low conversion rate may reflect weak customer demand; it may also reflect an unsuitable network, wallet friction, or a quote window that expires too quickly.

2. Select exact assets and networks

Create an allowlist of network-token pairs. Record the native asset or token contract, decimals, display symbol, explorer, minimum and maximum amount, and whether the network has the finality behaviour and operating support the business expects. The ERC-20 specification, created 19 November 2015, makes clear that token name, symbol, and decimals are optional interface functions; systems should not treat a ticker symbol alone as asset identity. The specification also requires callers to handle a returned false value rather than assume every token transfer succeeded.

Keep the first launch deliberately narrow. Adding another network changes deposit detection, fee funding, address format, confirmation logic, support scripts, and treasury routes. Adding a stablecoin on another chain is an integration change, not merely another label in a dropdown.

3. Design quote, address, and expiry rules

Create orders and payment instructions from the business backend, not from values supplied only by the browser. Store the internal order ID, checkout or invoice ID, quote asset and amount, payment asset and amount, network, destination, expiry time, and customer reference. If conversion is involved, record which price source and timestamp produced the quote and what happens after expiry.

Prefer a unique payment identifier that can be joined to the order without guessing. Depending on the network and provider, that may be a unique address, memo or tag, checkout session, or a combination of fields. Define underpayment, overpayment, duplicate payment, late payment, unsupported token, and wrong-network states before production. Sending support staff to a block explorer with no order context is not a reconciliation process.

4. Define pending, confirmed, and final

A transaction hash means a transaction was observed; it does not automatically mean the order is safe to fulfil. The Bitcoin Developer Guide’s payment-processing section says zero-confirmation transactions generally should not be trusted without risk analysis and explains why higher-value transactions may need more confirmation depth. Ethereum uses a different proof-of-stake finality model: the Ethereum protocol documentation distinguishes inclusion, justification, and finalisation through checkpoint votes.

Set a policy per network and risk tier. Consider transaction value, whether delivery can be reversed, fraud exposure, observed network conditions, and the provider’s status definition. A low-value digital item and a high-value irrevocable service do not need identical release rules. Record both the raw network observation and the business decision state so changes in confirmation depth do not silently rewrite history.

5. Use a server-side source of truth

Do not fulfil from a customer’s success-page redirect. The browser can close, retry, or present stale state. Poll an authenticated API or process a signed webhook on the server. Verify the signature against the raw request body, enforce a timestamp or replay window if the scheme supports one, store the provider event ID, and make the handler idempotent. A duplicate event should return the existing result rather than ship the order twice.

Separate event receipt from fulfilment. Persist the event, acknowledge it promptly, and let an internal worker transition the order after validating the expected asset, network, amount, destination, and final status. Retain failed events with a reason and retry path. Public hosted-checkout documentation follows this pattern: create the session from a secure backend, retain the session identifier, and use webhooks as the source of truth. Its payment webhook reference also says not to fulfil from the browser redirect alone.

6. Reconcile the commercial and on-chain records

Finance needs a joined record, not a wallet balance. For every payment, retain the order or invoice ID, quoted and received assets and amounts, network, addresses, transaction hash, observed and final timestamps, fees, exchange-rate reference where used, settlement asset and amount, accounting entry, refund or adjustment, and exception owner. Make exports deterministic so the same payment does not appear under a new identifier after a retry.

Recordkeeping requirements differ by jurisdiction and activity. As one public U.S. example, the IRS digital-assets page tells taxpayers to keep records of receipts and other dispositions, including fair market value in U.S. dollars for digital assets received as income or payment in the ordinary course of business. That is not a global accounting rule; finance teams should confirm valuation, tax, revenue recognition, and retention policy with qualified advisers in each relevant jurisdiction.

7. Test exceptions before live funds

A production-readiness test should include more than a happy path. Run controlled cases for a valid payment, expired quote, late payment, underpayment, overpayment, duplicate event, delayed event, invalid webhook signature, wrong token, wrong network where safely testable, provider API timeout, chain reorganisation or status regression where the integration exposes it, refund approval, failed refund, settlement delay, and export replay.

Give support an authenticated view of the same state used by engineering and finance. A useful runbook says what the customer sees, what the operator checks, who can approve an exception, and what evidence is retained. Set alert thresholds for unprocessed webhooks, deposits not matched to orders, rising confirmation time, settlement ageing, and reconciliation imbalance. Run a small live pilot with order limits and an explicit rollback plan before broad release.

Security, financial-crime, and treasury controls

Key and access control: if the business controls private keys, document generation, storage, access, backup, recovery, rotation, revocation, and destruction. The NIST Key Management Guidelines, updated 8 December 2025, provide a general framework for managing cryptographic key material. Apply separation of duties, least privilege, hardware-backed controls where appropriate, transaction limits, and tested recovery procedures to the actual wallet design.

Financial-crime risk: map screening and review to the business’s obligations, customer profile, transaction pattern, source of funds, geography, and service model. The FATF virtual-asset red-flag report, published 14 September 2020, highlights factors such as anonymity-enhancing features, geography, unusual patterns, transaction size without a logical business explanation, sender or recipient profile, and source of funds. A flag should lead to a documented review process; it is not proof of wrongdoing on its own.

Treasury: decide whether the business will hold the received asset, convert it, or settle into another asset or fiat currency. Document exposure limits, approved venues and counterparties, liquidity timing, weekend coverage, fees, slippage, depegging scenarios, wallet funding for network fees, and who can initiate or approve transfers. Do not describe a stablecoin as being without risk merely because it tracks a reference currency.

Refunds: do not blindly return funds to the transaction’s sending address; it may belong to a custodial wallet or shared exchange infrastructure. Collect the destination through an authenticated support flow, verify the asset and network, apply approval limits, screen where required, and link the outgoing transaction to the original order. State whether network fees and exchange-rate changes affect the refund amount before the customer pays.

Data and incident response: minimise personal data copied into blockchain-adjacent systems, set retention and access rules, and keep secrets out of logs. Prepare contacts and playbooks for compromised API credentials, suspected wallet compromise, provider outage, delayed finality, incorrect asset configuration, sanctions alert, and accounting imbalance. Rehearse at least one webhook outage and one emergency key or credential rotation.

Provider evaluation criteria

Score providers against the intended operating model, not a generic feature count. Require written, current answers and test the claims that matter in a sandbox or limited pilot.

• Coverage: exact countries, customer types, networks, token contracts, payout or settlement assets, and known restrictions.
• Funds flow: who receives, controls, converts, and settles funds at each step; whether balances are custodial; and how insolvency or safeguarding risk is addressed contractually.
• Payment state: quote expiry, confirmation and finality rules, late or mismatched payments, chain reorganisations, and manual-review states.
• Developer controls: authentication, idempotency, webhook signing, retries, event ordering, rate limits, test environment fidelity, versioning, and incident status communications.
• Operations: searchable transactions, role-based permissions, export fields, audit logs, refund controls, support hours, and escalation service levels.
• Compliance evidence: entities involved, registrations or authorisations that are publicly verifiable and relevant to the service, customer due-diligence responsibilities, screening controls, data handling, and prohibited activities.
• Commercials: transaction, conversion, settlement, withdrawal, network, refund, minimum, and support fees; reserve or hold terms; settlement timing; and contract termination rights.
• Resilience: dependency map, recovery objectives, status history, data export on exit, and the business’s fallback if the service is unavailable.

For teams considering a processor-led route, Radom’s public crypto payments product page and technical documentation can be evaluated against the same checklist. Confirm current eligibility, supported methods, pricing, terms, and operational fit directly; this guide does not imply availability for every business, asset, or jurisdiction.

When crypto payment acceptance works—and when it does not

It tends to work when customers already hold the supported asset, conventional cross-border collection is awkward, the order value justifies the workflow, and the business can operate reconciliation and customer support. It can also suit a platform that needs programmable payment status and has a clear settlement plan.

It may not work when demand is speculative, customers must first navigate a costly acquisition step, the business needs card-style consumer protections, refunds are frequent, price or network-fee uncertainty damages the offer, local rules or provider policy do not support the activity, or the finance team cannot close the ledger. Adding another payment rail does not cure weak product demand.

Practical next steps

1. Write the one-page operating brief and name accountable owners across product, engineering, finance, security, compliance, and support.
2. Select one customer segment and a narrow allowlist of network-token pairs.
3. Compare the three operating models and document the functions retained by the business.
4. Build the state model, reconciliation fields, refund path, and risk controls before polishing the checkout screen.
5. Run the exception test matrix, then a limited live pilot with value caps, daily reconciliation, and rollback criteria.
6. Review completion rate, exceptions, support effort, treasury exposure, and customer demand before expanding coverage.