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 never 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. 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, and the monitoring system must be able to prove 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?
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 the exact asset and network: USDT on Tron is not USDT on Ethereum, and even when address formats look compatible, the receiving wallet 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 educational copy — it is error prevention. A 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:
| field | why it matters |
|---|---|
| recipient address | proves where the transfer landed |
| asset and network | prevents cross-chain ambiguity |
| locked amount | distinguishes the invoice from unrelated transfers |
| creation time | prevents an old transaction from satisfying a new order |
| order identity | binds one payment to one merchant workflow |
| confirmation state | separates detected, confirmed and final outcomes |
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.
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:
- created — the order exists and the quote is active
- detected — a candidate transfer has appeared
- confirming — the transfer is included but has not reached the required confidence
- paid — the order can be fulfilled
- expired — no valid payment arrived before the quote ended
- 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.
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.
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 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, and 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 — not a long feature list built on top of a platform balance the merchant still has 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. 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.
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:
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.
