7 Lessons from Building a Non-Custodial Crypto Checkout

The easy version of a crypto checkout generates an address, displays a QR code and waits for a transaction. The production version has to answer much harder questions: who controls the money, which network the customer used, whether the amount is correct, when the payment is final, and what the merchant's software should do when any step is repeated.

Those questions shaped CRYPT.PE. We set out to build payment software that could coordinate a transaction without becoming the custodian of the merchant's revenue. The payer sends on-chain to a wallet configured by the recipient. CRYPT.PE creates the order, locks the expected amount, watches the network, matches the transfer and reports the result, but the funds do not pass through a CRYPT.PE balance.

That sounds like a simple architectural choice. In practice, it changes almost every product and engineering decision downstream.

1. settlement destination is the architecture

"Non-custodial" should describe the money flow, not the marketing page.

In a custodial flow, the payment first reaches infrastructure controlled by the processor. The merchant sees an internal balance and later asks for a withdrawal or payout. In a wallet-direct flow, the receiving address belongs to the merchant from the beginning. Payment and settlement are the same on-chain event.

This removes the platform withdrawal step, but it does not remove responsibility. The merchant must configure addresses they control. The checkout must make the asset and network unmistakable. The monitoring system must be able to prove that the expected transfer reached the configured destination.

The most useful question when evaluating any provider is therefore not "does it support crypto?" It is: where does the first irreversible payment land, and who controls that wallet?

For a fuller comparison of the two models, see custodial vs non-custodial crypto payment processors.

2. an address is incomplete without an asset and network

Crypto interfaces often treat a wallet address as if it were the whole destination. It is not.

The payer also needs to know the exact asset and network. USDT on Tron is not USDT on Ethereum. Even when address formats look compatible, the receiving wallet or merchant workflow may not support the route the customer picked.

We learned to treat the network label as primary payment information. It belongs beside the amount and address, not in a tooltip. A checkout should repeat the selected network, warn about incompatible transfers and keep the QR code tied to the visible selection.

This is not merely educational copy. It is error prevention. A normal card checkout can reject an invalid entry before money moves. An on-chain transfer may be irreversible, so the interface has to prevent the mistake earlier.

3. a transaction hash is not enough to identify a payment

A transaction hash proves that a transaction exists. By itself, it does not prove that the right invoice was paid.

The matching engine needs a complete expected-payment record:

That record must survive refreshes and retries. A payment detected on-chain should not be bound to two invoices, and a customer pasting the same transaction hash twice should not create two successful orders.

The broader reference architecture is covered in crypto payment gateway architecture.

4. payment states should be boring and explicit

The customer sees a QR code and a success screen. The system sees a state machine.

A useful minimum is:

1. created — the order exists and the quote is active;
2. detected — a candidate transfer has appeared;
3. confirming — the transfer is included but has not reached the required confidence;
4. paid — the order can be fulfilled;
5. expired — no valid payment arrived before the quote ended;
6. review — an underpayment, overpayment or ambiguous transfer needs attention.

Collapsing all of this into "pending" creates bad support conversations. Merchants need to know whether the customer has not sent anything, whether the chain is still confirming, or whether the payment arrived with the wrong amount.

The interface should use plain language, while the API and webhook payload preserve precise machine states. Good infrastructure makes the exceptional cases visible without making every customer learn blockchain terminology.

5. webhooks are a security boundary

A webhook is not trustworthy because it contains a plausible JSON body. Anyone who discovers an endpoint can send a request to it.

Our integration pattern signs webhook deliveries with HMAC. The merchant recomputes the signature from the timestamp and raw request body using a secret stored on the server, compares it in constant time, and rejects stale timestamps. Only then should the application parse the event and update an order.

The receiver must also record the event identifier. Webhook delivery can be retried; processing the same confirmed-payment event twice should be harmless.

The implementation details are available in the CRYPT.PE API guide and API documentation.

6. retries need stable identity

Customers double-click buttons. Browsers retry requests. Mobile connections disappear after the server succeeds but before the response reaches the screen.

Without idempotency, a retry can create another payment order with a different amount, address or expiry. The customer then sees one checkout while the merchant's system expects another.

The fix is to give each payment attempt a stable idempotency key. Repeating the same attempt returns the same result. A genuinely new attempt—after an expired quote, for example—gets a new identity.

This is unglamorous infrastructure, but payment systems earn trust through boring behavior under repetition.

7. no-code and API flows must agree

We initially thought about payment pages, invoices, products and API orders as separate features. They are better understood as different ways to create the same payment object.

A freelancer may start with an invoice. A creator may share a product link. A WooCommerce store may create an order through a plugin. A SaaS product may call the API directly. After creation, every path still needs the same network selection, amount locking, chain monitoring, confirmation logic and receipt.

Keeping those paths on one underlying model reduces inconsistent behavior. It also lets a business start without code and adopt automation later without learning a different payment system.

what this meant for CRYPT.PE

CRYPT.PE is fully bootstrapped and has taken no outside funding. That constraint has been useful: features have to remove a real obstacle to getting paid.

We prioritized direct wallet settlement, readable network labels, exact-amount invoices, payment matching, signed webhooks, verifiable receipts and integrations that fit an existing checkout. We did not want a long feature list built on top of a platform balance the merchant still had to withdraw.

The result is software around the payment rather than a new owner of the payment. Merchants configure wallets they control; customers pay those wallets; CRYPT.PE observes and coordinates the workflow.

a practical evaluation checklist

Before connecting any crypto gateway to a business, ask:

• Who controls the receiving wallet?
• Does the checkout show the asset and network together?
• How is the fiat or crypto amount locked, and for how long?
• What happens after an underpayment or overpayment?
• How many confirmations are required for each network and risk level?
• Are webhooks signed, timestamped and safe to retry?
• Can one transaction ever satisfy more than one order?
• Does the gateway expose a verifiable on-chain receipt?
• Are platform fees separated clearly from blockchain network fees?
• Can the business export enough data to reconcile orders and payments?

If a provider cannot answer those questions clearly, a polished QR code is not enough.

compare crypto payment gateways

Architecture, custody, settlement and pricing differ significantly between providers. Use these focused comparisons to check the tradeoffs that matter for your own workflow:

• CRYPT.PE vs Coinbase Commerce
• CRYPT.PE vs BitPay
• CRYPT.PE vs NOWPayments
• CRYPT.PE vs CoinGate
• CRYPT.PE vs Stripe Crypto
• Best crypto payment gateways in 2026
• View all crypto gateway comparisons

the next lesson comes from real use

The product is live, but payment infrastructure is never finished. The hardest lessons come from real merchant flows: a customer choosing the wrong network, a delayed confirmation, a retry at the wrong moment, or an accounting process that needs one more reliable field.

If you run an online store, freelance internationally or build a SaaS product, the most valuable feedback is specific: where did the payment flow create doubt, and what information would have removed it?

Start with the complete merchant guide, explore the developer documentation, or create a CRYPT.PE page and test the flow with a small payment.

Disclosure: Prakash Shinde is the founder of CRYPT.PE. CRYPT.PE is a non-custodial software service and charges 0% platform transaction fees; blockchain network fees may still apply. This guide is educational and is not financial, legal or tax advice.

frequently asked

What makes a crypto checkout non-custodial?

The payment settles to an address controlled by the merchant rather than to a balance controlled by the payment platform. The gateway can coordinate and verify the payment without holding the funds.

Why is the network part of the payment destination?

The same asset can exist on multiple networks. The payer must use a route that the receiving wallet and merchant support; an address alone does not communicate that requirement safely.

Why do payment webhooks need signatures?

An unsigned request can be forged. A signed webhook lets the merchant verify that the message came from the expected service and that its body was not altered.

Can a non-custodial gateway still provide invoices and order tracking?

Yes. Custody and workflow are separate. Software can create orders, lock amounts, watch networks, match transactions and issue receipts while settlement goes directly to the merchant's wallet.