DEV Community: Prakash Shinde

7 Lessons from Building a Non-Custodial Crypto Checkout

Prakash Shinde — Fri, 11 Sep 2026 12:12:31 +0000

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:

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.

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:

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. 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:

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.

Talent Is Everywhere. The Missing Layer Is Infrastructure.

Prakash Shinde — Mon, 07 Sep 2026 20:13:22 +0000

Talent is everywhere. Opportunity, trust, and infrastructure are not.

I spend a lot of time thinking about capable security researchers, developers, and independent builders who can solve difficult problems but still struggle to turn that ability into a credible identity, reliable opportunities, and direct payment.

At the same time, founders and teams struggle to discover trustworthy talent, evaluate real ability, pay people across borders, and respond calmly when a security incident happens.

We usually treat these as separate product categories. I see them as one unfinished system:

learn -> prove -> build trust -> find opportunity -> get paid -> stay protected

That pipeline is the reason I am building four connected ventures.

1. Security learning should resemble real work

Cybersecurity cannot be learned through theory alone. People need safe environments where they can investigate, make mistakes, understand consequences, and develop judgment.

That is the purpose of hacking.community: connect realistic ethical-hacking practice with CTFs, jobs, and bug-bounty opportunities.

The important output is not only a score. Good practice should help someone explain:

what they found,
how they approached the problem,
which trade-offs they considered,
and what they learned.

Those are the signals that begin turning practice into proof of work.

2. Proof of work should be portable

A resume tells a reader what someone claims to know. Proof of work shows how that person thinks and what they can produce.

Developers and security researchers already leave useful evidence across the internet: repositories, write-ups, vulnerability disclosures, projects, technical discussions, and community contributions. The problem is that this evidence is scattered across platforms and difficult to evaluate as one professional story.

whomi.bio is being built around a simple idea: technical identity should be based on live evidence, not only titles and certificates.

The design challenge is not merely aggregation. A useful profile must provide context without pretending that every signal has equal value. A repository, a responsible disclosure, and a community answer each demonstrate something different.

This matters most for independent talent whose ability is stronger than their access to conventional credentials or professional networks.

3. Global work needs transparent payment rails

Finding an opportunity is not the end of the journey. Getting paid across borders introduces a new set of delays, restrictions, and costs.

For freelancers, agencies, creators, and internet businesses, payment infrastructure should be understandable and direct. People should know which network they are using, where funds are going, and which fees may apply.

crypt.pe is my work toward non-custodial crypto payments for global commerce. It focuses on payment links, invoices, and integrations while keeping control of funds with the recipient.

One important product principle is precise communication. "No platform fee" does not mean "no fee of any kind" when blockchain network fees can still apply. Infrastructure earns trust by making those distinctions obvious.

Payments should not require people to surrender control simply to participate in the global economy.

4. Incident response should reduce noise

Every digital system eventually faces risk. A breach, impersonation attempt, extortion message, or exposed account can quickly become both a technical problem and a human crisis.

The first response should be calm, discreet, and evidence-led:

Preserve what matters.
Limit further damage.
Avoid public speculation.
Communicate only what is necessary to the right people.

HackAstra focuses on this part of the journey: practical, discreet incident response for people and organizations that need help without unnecessary noise.

Trust here depends on confidentiality, careful communication, and realistic expectations—not dramatic promises.

The products are connected by transitions

The four ventures are not identical, and they do not need to become one monolithic platform.

They serve different transitions in the same journey:

hacking.community turns learning into demonstrable practice.
whomi.bio turns scattered work into a credible technical identity.
crypt.pe turns global work into direct payment.
HackAstra protects that progress when security fails.

This is also an architectural lesson: products can form an ecosystem without sharing one codebase, one interface, or one business model. The connection can live in the user journey, the trust model, and the handoff between tools.

What I want to learn in public

I am still testing where the real friction lives. On DEV, I plan to share practical lessons about:

building realistic environments for security learning,
using proof of work as a professional trust signal,
designing non-custodial payments without hiding risk or fees,
responding to security incidents with discretion and clarity,
and connecting multiple products without losing focus.

I will share decisions, mistakes, and useful frameworks—not manufactured success stories.

Talent is already everywhere. The challenge is building infrastructure that allows it to be learned, recognized, trusted, paid, and protected.

That is the system I am working toward.

You can explore the four ventures and their current progress at whomi.bio/prakash.

If you are building tools for independent technical talent, I would be interested to hear which part of this pipeline you think is most broken today.