Payment Gateway

​

What it is

The Payment Gateway is a self-hosted service that takes a stablecoin (or native-asset) payment from intent to signed, audit-ready proof. You run it on your own infrastructure: it holds no account with us, makes no outbound call to us, and never phones home. It does three things end to end:

1. Creates a payment intent for a specific network, asset, amount, recipient, and your own order reference, and hands back the receive address to show your customer.
2. Watches that chain for the matching settlement, applying the finality rules of that specific network, and resolves the intent to a clear status.
3. Emits a signed settlement receipt that is no-PII, offline-verifiable, and folds straight into the Compliance Command Center evidence chain.

It is built on the same Substrate 2 crypto core as the rest of the suite, so a settled payment becomes evidence that is unforgeable today and stays unforgeable after the migration to post-quantum cryptography.

​

How it differs from Settlement Verification

Settlement Verification is a read-only OEM SDK you embed inside your own product to answer “did this settle and finalise”. The Payment Gateway is a service you run: it owns the whole intent lifecycle (create, watch, resolve, attest), produces the signed evidence chain, and is the surface a full-custody payout phase plugs into. If you only need to confirm an arbitrary settlement inside your own backend, the SDK is the lighter fit. If you want a gateway that runs the payment from request to proof, this is it.

​

The intent lifecycle

You describe the payment you expect; the gateway resolves what actually happened on-chain to one of a small, closed set of outcomes: Matching is by exact recipient, asset, and amount, so a transfer to a different address simply never qualifies (the intent stays pending) rather than being mistaken for payment. When a qualifying transfer finalises, the gateway records a settlement entry and signs it. There is no ambiguous “probably paid”: the outcome is explicit, and the proof of how it was reached travels with the receipt.

​

The settlement receipt

Each resolved settlement is written to an append-only, hash-chained ledger and signed with Falcon-1024 (NIST Level 5) through Substrate 2. A receipt is:

• No-PII by construction. It carries the network, asset, amounts (as exact integer minor units, never lossy floats), confirmations, finality, your order reference, and content-address hashes. It never carries names, emails, or any personal data. The payer and recipient appear only as hashed references, not raw addresses.
• Offline-verifiable. Anyone you hand the exported pack to can verify every signature and the full chain with no service running and no network access. A single altered byte breaks verification.
• CCC-ingestable. The receipts export as a pack that drops straight into the Compliance Command Center, where they appear in the consolidated posture as “Payment Gateway · settlement receipts” alongside the rest of your evidence estate. Settlement evidence sits next to your sanctions, retention, and audit evidence in one auditor pack.

​

Chains, each its own add-on

Every chain is a separate add-on that registers itself with the engine on install. Coverage is deep where generic multi-chain tooling is thin: the long-tail asset and finality semantics are handled correctly per network. Each add-on takes its chain RPC or indexer endpoint from configuration (bring your own node, with sensible public defaults), applies that network’s confirmation and finality rules, and feeds the same engine and the same receipt format. Adding a chain is installing its add-on, not rewriting your integration.

​

One engine, one port

However many chain add-ons you license, the gateway runs as one process on one port (8090). You do not get a service per chain. A request names its network, and the engine routes it to the matching add-on. Installing more chains adds capabilities to the same service; it does not add ports, processes, or moving parts to operate. See the ports and interfaces reference for where it sits in the suite. The service exposes a small, stable HTTP surface: create an intent, check an intent, list the installed chains, report health, and export the signed settlement pack for the Command Center. There is no SDK to adopt and no shared library to pin; any backend in any language talks to it over plain HTTP.

​

Custody and payout

The gateway ships today as the receive-and-verify spine: it detects and proves inbound settlement. Full custody (holding keys, signing, and broadcasting outbound payouts) is the defined next phase. The service and the per-chain add-ons are built around that surface from the start, so custody is an upgrade to the same product, not a different one. Because moving funds carries real key-management and regulatory weight, the custody phase is delivered with an explicit key-custody model (operator-held or HSM and KMS-backed) agreed per deployment.

​

Cryptography

• Detection reads each chain’s native signatures (Ed25519, secp256k1, and so on): classical cryptography inherent to the chains, not something the gateway supplies or replaces.
• The receipts it produces are post-quantum signed with Falcon-1024 through Substrate 2, and canonicalised with JCS (RFC 8785) so the signed bytes are identical on every implementation. A settled payment becomes evidence that survives the post-quantum migration.

​

Who it’s for

• Merchants and platforms that want to accept stablecoins across several chains on their own infrastructure and keep an audit-grade record of every settlement.
• PSPs and marketplaces reconciling inbound settlements across heterogeneous networks who need one engine and one evidence format rather than one integration per chain.
• Regulated and agentic systems that must prove, offline and after the fact, that a payment finalised on-chain, to whom, and for how much, without exposing any personal data in the proof.

​

Get the Payment Gateway

The Payment Gateway is a separately-licensed add-on to the AlgoVoi suite. The gateway engine (intent lifecycle, signed CCC settlement evidence, the service, and the plugin framework) comes with your first chain; each additional chain is its own licensed add-on, so you license exactly the networks you settle on. It is self-hosted and is not distributed on public package registries.