ArcPay

Accepting stablecoins sounds simple until you build it. You need to watch chains for confirmations, handle a customer paying twice or paying the wrong amount, produce a receipt someone's accountant will accept, reconcile settlement, and expose all of it to a merchant who does not want to think about any of it. Most teams rebuild that whole stack badly, in-house.

I wanted to understand payment infrastructure properly, and reading about it does not work. Building the boring parts — idempotency, verification, reconciliation — is what actually teaches you why payment systems are shaped the way they are.

A payment gateway with the developer surface a payments product needs: idempotent APIs so a retried request never charges twice, on-chain transaction verification, settlement tracking, payment receipts, payment links and QR flows, and a merchant dashboard that makes the state of every payment legible.

1. 01Merchant creates a payment intent
2. 02Customer pays via link, QR or direct transfer
3. 03On-chain verification confirms amount and recipient
4. 04Idempotency key resolves duplicates and retries
5. 05Settlement tracked and receipt issued
6. 06Merchant dashboard reflects final state

• End-to-end product and engineering
• API design — idempotency and verification model
• Merchant dashboard
• Circle ecosystem integration and listing

• React
• Node.js
• Express
• PostgreSQL
• Supabase
• REST APIs
• Arc
• Tempo testnet
• x402
• CCTP
• Circle
• Stablecoins

Idempotency is the whole game and it is deceptively hard. A network retry, a double-submitted form and a genuine second purchase look nearly identical at the API boundary, and getting that wrong in a payments system is the one bug you cannot apologise your way out of.

Payment infrastructure is mostly about what happens when things go wrong. The happy path took a fraction of the time; the rest was retries, partial payments, wrong amounts, chain reorgs and reconciliation — which is exactly why the category is defensible.