Stablecoin payments that reconcile themselves.
Accepting a stablecoin payment is a short integration. Surviving a reorg, a partial payment, a webhook your merchant missed and a month-end close that has to balance is the actual work.
Why crypto payments break at month end.
Taking the payment is the easy half. Every problem below shows up later, in reconciliation or in a support ticket, which is why they are usually discovered after launch rather than during it.
A customer pays the wrong amount, twice, on a chain you did not expect
Real payers underpay, overpay and pay late. Intents need a declared tolerance band and typed exception events, so an overpayment routes to a refund and an underpayment issues a top-up against the same intent instead of becoming a manual investigation.
A reorg un-confirms a payment you already told the merchant had succeeded
Confirmation cannot be one global number. It belongs per network and per amount band, with watchers tracking a reorg-safe cursor and emitting a compensating event rather than quietly mutating a settled payment.
Webhooks force every integrator to build their own deduplication
At-least-once delivery without a stable key makes double-fulfilment the merchant's problem. Each event carries an idempotency key, retries with backoff, and logs every attempt so a merchant outage can be replayed rather than reconciled by hand.
Balances are derived from a chain read at display time
Two reads a second apart disagree, and the merchant notices. All movement is recorded in a double-entry ledger with enforced invariants; chain state is an input to it, never the number anyone is shown.
Gas makes per-payment economics unpredictable
A fee that exceeds the payment is not a rounding error. Settlement batches by threshold and value band with cost estimated before a sweep, and low-value payments route to cheaper networks by policy rather than by hope.
One degraded RPC provider stalls settlement everywhere
Shared infrastructure couples networks that have no business being coupled. Watchers are isolated per network, so a provider having a bad day on one chain does not hold up payouts on the others.
How we build one.
A payment system is a ledger with chains attached. The ledger is the part that has to be right; the chains are inputs to it.
- 01
Payments API
Payment intents, refunds, idempotent mutations, signed webhooks and a delivery log that can be replayed.
- Idempotency keys
- Signed webhooks
- 02
Chain watchers
Per-network listeners with their own confirmation policy, reorg handling and backfill, isolated so one provider cannot stall the rest.
- Reorg-safe cursor
- Backfill
- 03
Settlement engine
Sweep policy, conversion routing, gas estimation and payout batching, so per-payment cost is modelled rather than discovered.
- Batching
- Value-band routing
- 04
Ledger
Double-entry recording of every movement with balance invariants enforced, and breaks raised as exceptions rather than absorbed.
- Double-entry
- Invariants
- 05
Networks
Per-network address derivation and asset configuration, added as a config change rather than a rewrite.
- EVM
- Solana
- Address derivation
- 06
Checkout and dashboard
Hosted checkout, merchant-facing reporting and an API console, with every failure state designed rather than defaulted.
- Next.js
- API console
We have already built this.
FLOWPAY is our stablecoin payments console: payment intents with tolerance and typed exceptions, per-network confirmation policy, reorg-safe watchers, replayable signed webhooks, batched settlement with gas estimation, and a double-entry ledger that reconciles. It is a MaatX demonstration rather than a client deployment, and the mechanisms above are running in it.
Questions we get asked.
Do you hold funds or act as a payment processor?
No. We build the infrastructure; custody, licensing and the regulatory position stay with you or with a provider you choose. That distinction matters legally and we will not blur it — if your model requires holding customer funds, that needs counsel before it needs engineering.
Which chains and stablecoins?
The demonstration covers Ethereum, Polygon and Solana, and adding a network is a configuration change rather than a rewrite because address derivation and confirmation policy are per network by design. Which assets to accept is usually decided by where your customers already hold balances.
What happens when a payment arrives after the intent expires?
It is accepted as a typed exception rather than lost. Late and partial payments resolve against the same intent — a top-up link for an underpayment, a refund path for an overpayment — because the alternative is a support ticket and a manual transfer.
What does an engagement look like?
Usually Discovery and Architecture first, to settle confirmation policy, the ledger model and the exception paths. Those three decisions shape everything else, and reversing them after launch means re-reconciling history.
What it costs, and what you are agreeing to.
The commercial answers in one place, so none of them has to wait for a call.
Typical route in
Blockchain Engineering
Typically $25,000–120,000
Scoped per system
The contract is one layer of eight. Most of what decides whether an on-chain system survives production lives in the indexing, the risk model and the reconciliation.
A starting point for the scope described, not an estimate for your project. Ongoing engineering runs at $75 per hour blended.
Who owns what you build?
You do. On full payment of the fees for an engagement, the intellectual property in everything built specifically for you is assigned to you.
Our pre-existing tools, libraries and internal infrastructure stay ours — but where a deliverable uses them, you get a perpetual, worldwide licence to run, modify and extend it. Nothing we hand over needs us to keep operating it. Open-source and third-party components keep their own licences, and we tell you which ones and what they require.
We also will not name you as a client, describe your project, or publish a case study about it without your written agreement.
What happens if it does not work out?
Either of us can end an engagement with 30 days written notice, or immediately if the other commits a material breach and does not remedy it within 15 days. You pay for work properly performed up to that point, and we hand over completed work along with every deliverable you have paid for.
Two limits worth stating before you ask. We are engineers, not advisers: nothing we deliver is legal, regulatory, tax or financial advice, and a system built to your specification is not an opinion that it is lawful in your jurisdiction. And where our work includes reviewing or auditing code, the findings cover the scope and time agreed — an absence of findings is not a guarantee that nothing is there.
What do you need from me to start?
Not a specification. Discovery exists precisely because most people do not have one — an idea, or a technical problem you cannot yet size, is enough to begin.
What the work does assume: timely access to the people, systems, credentials and environments it touches; decisions and approvals at roughly the pace the timeline assumes, since delays on your side move both dates and cost; and that you have the right to give us whatever you give us, including data, code and third-party material.
Why you rather than the alternative?
Against hiring a senior engineer in-house: sourcing one takes months and commits you permanently. Discovery runs 1–3 weeks, and you keep the architecture whichever way you then go — including if the answer is to make that hire.
Against the cheapest contractor available: you will pay less per hour. Our argument is that the architecture decision is the one that is expensive to reverse, which is why we sell it first, separately, and at a price you can say yes to before committing to a build.
Against a larger firm: there is no account layer. The people who scope the work are the people who build it.
And when not to hire us: if a no-code or off-the-shelf tool still fits what you are doing, stay on it. We are worth paying once you have hit a ceiling you cannot engineer around from where you are.
These are summaries. The binding version of the ownership, exit and liability terms is in our Terms of Service. A person reads every enquiry. We usually reply within a few hours.
Start a technical assessment
Taking stablecoin payments and needing them to reconcile like payments rather than like transfers?
Send us the architecture or the problem. We will come back with the technical risks we can see and a sensible path forward, free, and tell you if we are not the right people for it.