Skip to content
MaatX
All work
Paymentslight interfacedemo

FLOWPAY

Stablecoin Payments Infrastructure

Global payment infrastructure powered by programmable digital money.

FLOWPAY
FLOWPAY, stablecoin payments infrastructure — product interface

Accept stablecoin payments that reconcile themselves, settle predictably, and behave like a payments API rather than a wallet.

  • Payment intents
  • Double-entry ledger
  • Reorg-safe watchers
  • Signed webhooks
  • Multi-chain

Merchant accounts, payment links, settlement and treasury for stablecoin payments across Ethereum, Polygon and Solana — with a developer API that behaves like a payments API, not a wallet.

Explore the system Discuss your use case
Product overview

What the product is built around.

FLOWPAY models a payment as an intent with a lifecycle, not a transfer. The intent knows what was owed, what arrived, on which chain, and what still needs to happen — so reconciliation is a property of the system rather than a spreadsheet the merchant maintains.

Payment intents, not addresses

Each payment is a first-class object with an expected amount, accepted chains, expiry and a deterministic lifecycle the merchant can query.

Exactly-once webhooks

Delivery is at-least-once over the wire with an idempotency key, so integrators can be correct without building their own dedup layer.

Settlement as policy

Merchants declare a settlement currency, threshold and schedule. Sweeps and conversions execute against that policy automatically.

The problem

What makes this hard.

Accepting stablecoins is technically simple and operationally painful. A merchant does not want a wallet address — they want an invoice that reconciles, a settlement they can forecast, a webhook that fires exactly once, and a refund path that works when the customer paid on the wrong chain.

  • 01

    Under- and over-payments are common and nothing handles them automatically

  • 02

    The same customer pays on three different chains and reconciliation breaks

  • 03

    Webhooks fire more than once, or not at all, and merchants build their own dedup

  • 04

    Gas volatility makes the true cost of a payment unpredictable

  • 05

    Treasury is left holding volatile balances with no sweep policy

The solution

What the system does.

FLOWPAY models a payment as an intent with a lifecycle instead of a transfer to an address. The intent knows what was owed, what arrived, on which chain and what still has to happen, so reconciliation is a property of the system rather than a spreadsheet the merchant maintains. Under- and over-payments are typed events with resolution paths, and settlement runs against a declared policy.

  • Payment intents with expiry, tolerance and multi-chain acceptance

  • Under- and over-payment handled automatically with top-up or refund

  • Signed, replayable webhooks with idempotency keys so integrators stay correct

  • Double-entry ledger with enforced invariants — never a live chain read

  • Settlement by threshold and schedule with cost estimated before the sweep

Product interface

FLOWPAY, as working interface.

Rendered UI, not a mockup. Switch between screens, and try ⌘K for the command palette.

DEMO
FLOWPAYPayments
All paymentsSucceededPendingExceptionsRefunds● LIVE
FLOWPAY

Volume, success rate and settlement latency across every network.

Volume (30D)

$18.61M

+24.1% m/m

Payments

42,918

99.4% success

Avg settlement

11.4s

−2.8s vs last month

Exceptions open

18

0.04% of volume

Payment volume

30D
$18,612,840+24.1% vs prior 30 daysprev period
W1W2W3W4

Volume by network

30D$18.6M
  • Ethereum41.9%
  • Polygon33.3%
  • Solana24.7%

Success rate

Excludes customer-abandoned intents
99.4%30D
  • Below target≤ 960
  • Watch≤ 985
  • On target≤ 995
  • Exceptional≤ 1000
System architecture

How it is put together.

Chain watchers are isolated per network so one degraded RPC provider cannot stall settlement on the others.

  1. 01

    Checkout & Dashboard

    Hosted checkout, merchant dashboard and the developer API console.

    • Next.js
    • React
    • TypeScript
  2. 02

    Payments API

    Payment intents, refunds, idempotency, signed webhooks and delivery logs.

    • Node.js
    • REST
    • HMAC
    • Idempotency keys
  3. 03

    Chain Watchers

    Per-network listeners with confirmation policy, reorg handling and backfill.

    • Go
    • WebSocket
    • Reorg-safe cursor
  4. 04

    Settlement Engine

    Sweep policy, conversion routing, gas estimation and payout batching.

    • Rust
    • Queue
    • Fixed-point maths
  5. 05

    Ledger

    Double-entry ledger recording every movement with balance invariants enforced.

    • PostgreSQL
    • Double-entry
    • Append-only
  6. 06

    Networks

    Ethereum, Polygon and Solana with per-network address derivation.

    • EVM
    • Solana
    • HD derivation

What the product does.

The capability set the demonstration is built around.

Payment links

Hosted checkout and shareable links with expiry, multi-chain acceptance and branding.

Merchant accounts

Sub-accounts, role-based access, per-account settlement policy and limits.

Stablecoin acceptance

USDC, USDT and EURC across three networks with automatic chain detection.

Settlement engine

Threshold and schedule-based sweeps with conversion routing and cost estimates.

Treasury

Balance allocation across chains, float management and payout scheduling.

Transaction monitoring

Live payment states, exception queues and address risk screening.

API & webhooks

REST API, typed SDKs, signed webhooks with replay and delivery logs.

Engineering focus

Challenges, and the MaatX approach.

The problems that actually decide whether a system like this survives production — and how we address each one.

A customer pays the wrong amount, twice, on a chain you did not expect

Intents accept partial and excess payment within a declared tolerance and emit typed exception events. Over-payment triggers a refund path; under-payment issues a top-up link against the same intent.

Webhooks must be reliable without making integrators build dedup

Every event carries a stable idempotency key and is retried with exponential backoff. Delivery attempts are logged and replayable, so a merchant outage never loses an event.

Reorgs can un-confirm a payment you already told the merchant succeeded

Confirmation policy is per network and per amount band. Watchers track a reorg-safe cursor and emit a compensating event rather than silently mutating a settled payment.

Balances must never be derived from a chain read at display time

All movement is recorded in a double-entry ledger with enforced invariants. Chain state is an input to the ledger, never the answer the merchant sees.

Gas cost makes per-payment economics unpredictable on Ethereum

Settlement batches by threshold and value band, and cost is estimated before a sweep. Low-value payments route to cheaper networks by policy rather than by hope.

The stack behind it.

Payment intents & API

  • Node.js
  • TypeScript
  • REST
  • Idempotency keys
  • Intent state machine
  • HMAC-signed webhooks
  • Replayable delivery log

Chain watchers

  • Go
  • WebSocket subscriptions
  • Reorg-safe cursor
  • Per-network confirmation policy
  • Cursor backfill
  • HD address derivation
  • Provider failover

Settlement & treasury

  • Rust
  • Fixed-point arithmetic
  • Threshold sweep policy
  • Gas estimation
  • Payout batching
  • Conversion routing
  • Per-network float policy

Ledger & reconciliation

  • PostgreSQL
  • Double-entry ledger
  • Append-only journal
  • Balance invariants
  • Daily reconciliation
  • Exception queues

Networks & assets

  • Ethereum
  • Polygon
  • Solana
  • EVM
  • ERC-20 transfer decoding
  • SPL token accounts
  • USDC, USDT & EURC

Checkout & dashboard

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • Hosted checkout links
  • QR payment URIs

Platform & operations

  • Docker
  • Kubernetes
  • Redis
  • Kafka
  • OpenTelemetry
  • Structured audit logs
Product evolution

How it grows with the business.

The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.

MVP

One chain, one stablecoin, with the intent model and ledger correct from day one.

  • Single network and asset
  • Hosted checkout and payment links
  • Webhook delivery with retries
  • Double-entry ledger
Scale

Multi-chain acceptance with automated treasury and settlement.

  • Three networks with automatic chain detection
  • Settlement policy and conversion routing
  • Exception queues for under/over-payment
  • Developer API, SDKs and console
Enterprise

Platform-grade payments with sub-accounts and reporting.

  • Merchant sub-accounts with per-account policy
  • Recurring and metered billing on the same primitive
  • Reconciliation exports for finance systems
  • Regional on/off-ramp partners
Future expansion

Where it could go next.

Directions this system would extend into.

  • 01

    Recurring and metered billing built on the same intent primitive

  • 02

    On/off-ramp partners for local-currency settlement

  • 03

    Programmable escrow and milestone-based release

  • 04

    Merchant-facing dispute and chargeback-equivalent workflow

  • 05

    Account abstraction so customers pay without holding gas

PreviousATLAS RWAReal-World Asset InfrastructureNextNEXUSMultichain Infrastructure

Taking stablecoin payments and needing them to reconcile like payments rather than like transfers?

We built FLOWPAY to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.

Start a technical assessment How we engage

Or email business.maatx@gmail.com