Ask HN: How do you verify crypto payments in your app?
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.
(
6 comments
| on HN
)
If you ever want to accept micropayments alongside USDC (sub-$5 amounts where fees eat everything), Bitcoin Lightning via LNURL is worth a look. Zero fees, instant, no KYC. coinos.io provides free Lightning addresses. I use it for a small API service — [email protected] works as a payment address. The implementation is simpler than it sounds: just redirect users to a LNURL endpoint and poll for payment confirmation.
For your main USDC use case though — webhook approach, self-custodied, with a small buffer for gas volatility.
The edge cases pile up: reorgs on Base (rare but real), missed events when your webhook endpoint is down, distinguishing multiple payments of the same amount to the same address within a short window. All solvable, but each one is a weekend of debugging.
I ended up building a verification-only layer that handles the polling, confirmation, and webhook delivery. Non-custodial — never touches funds, just confirms "yes, X USDC arrived at Y address." Flat fee per verification ($0.05) vs rolling my own infra.
Still early but it's been solid for the use case OP described. Happy to share more if anyone's interested.
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.
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?
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.
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 — [email protected] if you want to take it offline.