Merchant Invoicing & Accounting Layer for Crypto Payments

The commercial problem

A merchant who wants to accept crypto today has three choices, none of them good.

Option one: a hosted processor — Coinbase Commerce, BitPay, NOWPayments. The processor takes 1–2% per transaction, the merchant has counterparty exposure to the processor's solvency and policy decisions, and settlement times depend on the processor's internal sweep cadence. The merchant has effectively swapped Stripe for a smaller, less regulated Stripe.

Option two: roll your own. Engineering effort runs into the hundreds of hours per chain supported. Reconciliation, invoice numbering, multi-currency conversion at point of sale, and the basic accounting hygiene a finance team needs are all bespoke work.

Option three: just paste a wallet address into the email. Free, but accounting becomes a manual nightmare and there is no audit trail tied to a specific invoice.

What was missing in the market is a thin, neutral layer that sits between paste a wallet and pay a processor 1.5% — invoicing, reconciliation, and verification, with no custody and no per-transaction take.

The system shipped

A merchant-facing invoicing and accounting layer with three deployment modes:

• ·SaaS for merchants who want a hosted control panel
• ·Self-hosted open-source binary for merchants who want to run it on their own infrastructure
• ·White-label for platforms that want to embed the flow under their own brand

The merchant onboards with an email — no KYC, no application — connects an existing wallet (the keys never leave the merchant's possession), and generates payment links that watcher services verify against the chain. Because the merchant supplies their own wallet address, the layer is non-custodial by construction. There is no cash to seize, freeze, or lose.

Coverage at launch

Integrations shipped

• ·WooCommerce plugin — checkout integration for the largest open-source e-commerce stack
• ·REST API with webhook delivery for custom flows
• ·Programmatic payment-link generation for any platform that can hit a JSON endpoint

Architecture choices that mattered

Watcher-based verification, not custody. The merchant pastes a wallet address; the system runs watcher processes against the relevant chains and confirms invoice payment by reconciling on-chain transfers to the invoice's expected amount, asset, and address. The system never touches funds. This collapses the regulatory surface from money services business to software vendor in most jurisdictions — a deliberate design choice, not an accident.

Flat fee, not basis points. Merchants are sold on the unit economics. Every percentage charged on a stablecoin payment compounds against the merchant's actual margin; flat fees scale with infrastructure cost, not transaction value. The pricing model itself is a competitive moat: a hosted processor cannot match it without cannibalizing its own revenue.

Open-source core with optional SaaS convenience. A merchant who values control runs the binary themselves; a merchant who values convenience uses the SaaS. Both paths produce the same on-chain behavior, which means there is no commercial pressure to lock anyone into the hosted version. Trust is earned by making the alternative actually viable.

Privacy-preserving by default. No analytics SDKs, no behavioral tracking, no data resale. The merchant's invoice ledger is theirs.

Pricing model

Note that no tier charges per transaction. The economic model is subscription-style infrastructure access, not a tax on volume.

What this proves about the firm

We can ship a non-custodial payment system that is regulator-defensible. The watcher-and-wallet design is the same pattern we deploy on client mandates where the client cannot afford to be classified as a money transmitter.

We understand merchant economics. Flat-fee infrastructure with no take rate is what a CFO actually wants. Most processors will not build it because it kills their P&L; we built it because we are not a processor.

Open source is a commercial decision, not a philosophical one. A merchant who can self-host has no lock-in fear, which makes them more willing to adopt. The SaaS revenue comes from convenience, not captivity.

What we extract for client work

For corporates and regional conglomerates evaluating direct-merchant crypto acceptance, this reference establishes the production pattern: non-custodial, flat-fee, multi-chain invoicing with reconciliation hooks into existing accounting systems. A typical client engagement extends this with:

• ·ERP and accounting-system integration (NetSuite, SAP, Xero) for automatic invoice reconciliation
• ·Treasury wallet architecture with multi-sig governance and segregation of duties
• ·Jurisdiction-specific compliance overlays (FinCEN reporting in the US, MiCA disclosures in the EU, VARA registration in the UAE)
• ·White-label deployment under the client's brand

Engagement type: Pilot Launch (Package B) for a single-entity rollout, Transformation Program (Package C) for multi-entity or multi-jurisdiction.