Crypto payment and wallet integration

What this actually solves

Three business problems bring people to this page, and all three are ordinary. The first is customers in markets where card payments are expensive, slow or unreliable, who are already asking whether they can pay another way. The second is chargebacks — a merchant tired of shipping goods and then losing both the goods and the money months later. Settled crypto payments cannot be reversed, which removes that particular loss and, in fairness, removes your customer's protection too. The third is cost, and the honest version is that it depends entirely on your processor, your currencies and your volumes — we price both routes before you commit.

What makes this the safest place to start in this whole category is what you are not doing. You are not launching a token. You are not writing a contract that holds anyone's money. You are not custodying keys. A hosted processor does the dangerous part, and your application does what it already does for cards — create a payment, send the customer somewhere to pay, and update an order when told it is done. The entire risk of the project concentrates into one small piece of code, the webhook handler, and that is where the engineering attention belongs. Failures in a crypto checkout trace back to that endpoint being trusted more than it deserved.

How the integration runs

1. Processor selection and the pricing question. We choose between hosted processors such as NOWPayments and Coinbase Commerce, or a self-hosted BTCPay Server if you have a specific reason to hold custody, based on your currencies, markets and settlement preferences. Then the question everyone forgets — your prices are in dollars and the payment arrives in crypto, so which moment's exchange rate applies and for how long is that quote held before it expires. Two to four days.
2. Checkout flow and order states. Payment creation, redirect to the processor's hosted page, return handling, and an order state machine that includes awaiting payment, pending confirmations, underpaid, overpaid, expired and paid. Those middle states are where real payments live for minutes at a time, and a system that only knows unpaid and paid will lie to your staff and your customers. Three to five days.
3. The webhook handler, built properly. The signature is verified against the shared secret using the raw request body before anything parses it as JSON, because parsing first is what silently breaks verification, and a broken check still looks like a working one. Delivery is made idempotent by a unique database constraint on the processor's event id, not by application logic alone, so the same event arriving five times or twice simultaneously cannot mark an order paid twice. Confirmation thresholds are configured per currency, with anything below the threshold held in a pending state. Under and overpayment are handled as explicit outcomes with a tolerance you set. Every raw event is logged for later reconciliation. Four to eight days.
4. Adversarial testing on the sandbox, then one real payment. The test plan is deliberately hostile — a replayed webhook, a webhook with a tampered signature, a duplicate delivery of the same event id, an underpayment inside and outside tolerance, and a payment that arrives after the quote expired. Only when all of those behave correctly do we run a small genuine payment on mainnet with our own funds before handing over. Three to five days.
5. Reconciliation, refunds and handover. An accounting export that ties each order to its transaction hash and settled amount, a written refund procedure since refunds are a manual outbound payment rather than a button, and a handover paragraph in plain language your support team can actually use when a customer asks for their money back. Two to four days.

What moves the price

What you are integrating into. A hosted checkout dropped onto a Shopify or WooCommerce store sits at the bottom of the range. A custom SaaS with subscriptions, seat changes, proration and dunning sits at the top, because recurring billing in an irreversible payment rail is a genuinely harder problem than one-off orders.

How many currencies and chains you accept. Each additional asset brings its own confirmation threshold, its own fee behaviour and its own accounting treatment, and the same stablecoin on three different networks is three configurations, not one.

How deep the reconciliation has to go. Marking orders paid is the easy half. Feeding settlement data into your accounting system so month-end closes without anyone reading a block explorer is the other half. The range is $1,000–$10,000 over 2–6 weeks, and wallet sign-in is scoped and quoted separately from checkout.

What usually goes wrong

The webhook is believed because it says paid. That endpoint is a public URL on the open internet, and anybody who finds it can post a convincing JSON body to it announcing that order 1042 is settled. The only thing separating a real notification from a forged one is the signature, and it has to be verified against the raw body before the body is parsed — verifying after JSON parsing usually fails silently in exactly the way that looks fine in testing. Every integration we take over gets checked for this first.

The handler is not idempotent, so one order ships twice. Processors retry deliveries by design, not by fault, and a retried event will arrive after a timeout, after a deploy, sometimes concurrently with the original. If the only protection is an if-statement checking whether the order is already paid, two simultaneous requests will both pass it. The protection has to be a unique constraint in the database on the event id, so the second write fails at the storage layer rather than depending on timing.

The order is marked paid at zero confirmations. The payment appears, the code sees it, and goods are released before the network has agreed the transaction is final. On a fast chain the window is small and on a slow one it is not, and a low-value order and a high-value order should not use the same rule. Confirmation counts are configured per currency with an explicit pending state in between, and that threshold is a commercial decision we put in front of you rather than a default we choose silently.