Ask HN: How do you verify crypto payments in your app?

[Sem_pre]

I'm building a SaaS that accepts USDC payments. Simple requirement: customer sends stablecoins, I need to know when they arrived and the amount matches. Current options seem to be:

1. Payment processor (Coinbase Commerce, NOWPayments) — handles everything but takes 0.5-1% per transaction. On a $10k payment that's $50-100 just for confirmation.

2. DIY with Alchemy/Infura webhooks — poll for Transfer events, match amounts, track confirmations, handle reorgs, build retry logic. Took me ~2 weeks and it's still brittle.

Is there a middle ground? Something that just does the verification part — "tell me when X amount arrived at Y address" — without the custody/checkout/fee overhead? Curious how others are handling this, especially on L2s like Base where tx costs are negligible but verification infra is the same complexity as mainnet.

[QBitFlow]

Hey — this is exactly the problem I've been solving with QBitFlow (https://qbitflow.app). Full disclosure: I'm the founder, but your post describes our use case so precisely I'd feel weird not chiming in.

The short version: QBitFlow is non-custodial — we never touch your funds. Instead of the processor model (Coinbase Commerce, NOWPayments) where they receive payments and forward them minus fees, customers pay directly to your wallet. Smart contracts handle the authorization and verification logic on-chain.

For your specific case (one-time USDC payments with verification):

• Customer sends to your address, smart contract confirms amount + receipt • You get webhooks/API callbacks when payment is confirmed — no polling Transfer events yourself, no reorg handling, no retry logic • Works on Ethereum and Solana today (more chains coming, L2s on the roadmap)

On fees: we charge 1.5% flat normally, but I can offer you 0.75% for 6 months (extendable) since you'd be an early adopter. Compare that to the 0.5-1% you'd pay Coinbase Commerce/NOWPayments — except they also custody your funds and add withdrawal friction. At 0.75% on your $10k example, that's $75 vs building and maintaining your own brittle webhook infra.

You can try the full flow in test mode without spending anything: https://qbitflow.app/docs?section=test-mode — takes about 5 minutes to see if it fits your setup. I'm also happy to do a full onboarding walkthrough if you want to go deeper.

And honestly — even if QBitFlow isn't the right fit for your stack, I'd love to hear your feedback. You've clearly thought about this problem more than most, and that kind of input is gold for us at this stage.

Happy to answer any technical questions here or via email.

[Sem_pre]

Cool to see another founder tackling this — respect the hustle.

I think we're solving different slices of the same problem. QBitFlow wraps authorization + verification in smart contracts. What I ended up building is just the verification primitive: "did X USDC land at Y address?" — no smart contract, no percentage fee, $0.05 flat.

For someone who wants a turnkey checkout flow, QBitFlow makes sense. For someone who already handles their own payment UX and just needs reliable confirmation, that's where paywatcher.dev fits.

On the $10k payment: $0.05 vs $75 is a pretty different cost structure. But it's also a different scope — apples and oranges to some degree.

Would genuinely be curious what others here prefer: full-stack payment handling or composable primitives?

[QBitFlow]

Fair point — and honestly, paywatcher.dev looks clean for that use case. If all you need is "did the money arrive?" then $0.05 flat is hard to argue with.

You're right that it's apples and oranges. The way I see it: paywatcher solves verification, QBitFlow solves the billing lifecycle (authorization, recurring charges, cancellation, merchant dashboard). Different layers of the same stack.

Which actually makes me wonder — have you thought about integrations? A developer could use paywatcher for one-time payment confirmation and QBitFlow for subscriptions, depending on the use case. Or we could even use paywatcher as a verification layer under the hood for chains we don't natively support yet.

To your question: I think the answer is "both, depending on the builder." Someone spinning up a weekend project with a tip jar wants a primitive. Someone running a SaaS with MRR tracking and automated renewals wants the full stack. The market is big enough for both approaches.

Either way — cool to see someone else building in this space. Would be happy to chat offline if you ever want to explore how the tools could complement each other.

[Sem_pre]

Appreciate the thoughtful response — and yeah, the integration angle is interesting. PayWatcher as a verification layer for chains QBitFlow doesn't natively cover yet makes a lot of sense architecturally. Keeps your stack lean while expanding chain support.

The primitive vs. full-stack split maps well to how developers actually buy tools: start with the smallest thing that solves the immediate problem, then add layers as complexity grows. Tip jar → PayWatcher. SaaS with MRR → QBitFlow. Both valid.

Happy to explore the integration idea — [e-mail] if you want to take it offline.