Skip to main content

​
What it is

The Payment Gateway is a self-hosted x402 facilitator and agentic payment gateway that takes a stablecoin payment from intent to a signed, offline-verifiable proof across seven chains. 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 no-PII settlement receipt that is content-addressed and signed with the operator’s own Falcon-1024 key, verifiable offline against a published key, 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.

One engine, every chain

A single gateway engine and a single service port. Every chain ships in the one bundle and is discovered automatically when the engine starts; enable the networks you settle on and leave the rest idle.

Settlement and finality

Confirms a payment is included, succeeded, reached the right recipient, for the right amount, in the right asset, with each network’s distinct finality model applied, not a one-size “is it mined”.

Signed, no-PII evidence

Each settlement produces a no-PII receipt carrying amounts, refs, and hashes but never personal data; every receipt is post-quantum signed with the operator’s own key and verifies offline with no service running.

Self-hosted, no lock-in

Runs as one process on your infrastructure. Bring your own chain RPC endpoints. Nothing leaves your network, and the receipts verify long after the service is switched off.

​
Agentic payment protocols

The gateway settles three agentic payment protocols on the same verify-then-prove engine across the seven chains, so a payment negotiated by an agent settles and is receipted the same way a direct payment is:
  • x402. POST /v1/x402/requirements returns a spec-v1 402 Payment Required body for an intent; POST /v1/x402/verify confirms settlement and returns the receipt as proof. The settlement is signed with the operator’s own Falcon-1024 key on the evidence ledger, verifiable offline against the published key, with no shared secret.
  • MPP. The x402 intent extension (charge or recurring subscription).
  • AP2. Renders a merchant CartMandate’s price as a W3C Payment Request and binds the cart_id into the receipt, so the settlement proof commits to the cart it paid.
In every case the gateway is the settlement-proof layer beneath the protocol: it verifies the on-chain settlement and records the evidence to a hash-chained ledger, signed with the operator’s own Falcon-1024 key and verifiable offline. Mandate bounds, consent, and agent negotiation stay in the protocol layer.

​
A2A discovery, and where agent-to-agent settlement lives

The gateway is also an A2A-compatible payment agent (Google Agent2Agent, serving both v0.3 and v1.0.1 clients from the same endpoint via A2A-Version negotiation, over HTTP+JSON and JSON-RPC): other agents discover it at /.well-known/agent.json and send it verify-payment, create-checkout, or check-status tasks, which settle over x402, MPP, or AP2 on one of the seven chains exactly as above. The public AgentCard is served on your own domain and can be signed with a key you control (A2A spec section 8.4), so a counterparty verifies the card is really yours against your own JWKS. This is an agent asking your gateway to run a payment. Genuine agent-to-agent settlement between two peer agents, where the two agents are themselves the counterparties and no operator settles on their behalf, is Agent Mesh: included in this bundle and federation-allocated (see Agent Mesh: agent-to-agent settlement you allocate below). The seven-chain settlement engine runs x402, MPP, and AP2; peer agent-to-agent is Mesh.

​
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 hash-chained, Falcon-1024 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. Agent Mesh is the agent-to-agent counterpart. It settles a single payment between two autonomous agents that are parties to it, and structurally refuses to settle for third parties. Payment Rails is the operator tier: it runs payments at scale on behalf of others. The two compose, because an Agent Mesh execution reference is exactly the evidence Payment Rails consumes, so an agent that outgrows agent-to-agent settlement has a clean path here.

​
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 in the append-only, hash-chained ledger, signed with the operator’s own Falcon-1024 key. 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 evidence ledger and signed with the operator’s own Falcon-1024 key (NIST Level 5) through Substrate 2, by an on-box signer that picks up each new settlement within seconds. 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.

​
Export and verify a receipt

algovoi-receipt <tx_id> emits a single settlement’s portable receipt. A standalone verifier ships alongside it and checks that receipt with stock open-source tools only: integrity is a SHA-256 over the receipt’s canonical bytes checked against its content_hash (Python hashlib), and the Falcon-1024 signature is checked with pqcrypto (pip install pqcrypto). No AlgoVoi software and no canonicaliser are needed to verify, so an auditor confirms a settlement offline, against your published key, with tools they already trust. The export is read-only and never touches the signing daemon.

​
Agent passports: a federated issuer you run

The rails run a federated agent-passport issuer on your own infrastructure, on by default. A passport is a Falcon-1024 signed credential that says an agent is authorised to act, bounded by the scopes, spend limit, spend window, and expiry you set when you issue it. The passport verifies offline against the issuer’s published key and can be revoked, so a counterparty confirms an agent is still authorised without calling you.
  • Self-provisioning issuer. On install the rails generate the issuer’s own Falcon-1024 keypair, hold the secret key in a 0600 key file that never enters the environment, and derive a stable issuer identity did:key:passport-<kid> from the public key. Nothing is supplied by AlgoVoi.
  • Federated by design. The issuer publishes its DID and public key to the federation registry that ships with the bundle, so any verifier in the mesh checks a passport against the issuer’s published key rather than a shared secret. This is why the federation validator is in the estate: passports are issued and verified across issuers, not just within one box.
  • Revocable, with a CRL. Revoking a passport is scoped to the owning tenant and publishes to a content-addressed revocation list; a verifier that pulls the CRL fails a revoked passport closed. A verify portal link renders the same check for a human.
The whole lifecycle (issue, list, verify, revoke, CRL, verify portal) is driven from an Agent Passport tab in the operator control panel, so an operator runs it without touching the API. There is no separate purchase: the passport issuer is part of the rails bundle.

​
Agent Mesh: agent-to-agent settlement you allocate

Agent-to-agent settlement is included in the bundle and federation-allocated: you create members in the operator panel and allocate each one a post-quantum Mesh licence, with no per-agent fee and nothing to buy separately. Two agents then verify each other’s passports, agree which chain to settle on, and settle once as a single content-addressed reference that anyone can recompute offline.
  • You allocate, protected by a root-signed delegation. On install the rails provision a federation key of your own and receive an AlgoVoi root-signed, name-constrained certificate that scopes it to your own DID namespace. You mint member licences under that namespace; a licence for any DID outside it is refused by every verifier. The federation secret stays in a 0600 key file that never enters the environment.
  • Agent-to-agent only, by construction. Every member licence names its holder’s own agent DID, so the mesh settles only transactions that member is a party to. It will not settle between two third parties; that is a payment rail, which is the rest of this bundle. Allocating keys and settling on behalf of others stay cleanly separate.
  • One reference, every chain, verified offline. The agents each sign the chains they accept, bound to the session, and settle only on a chain both signed for. The result is one execution_ref that binds both passports, the two-party set, the agreed chain, and the amount, and recomputes offline with no AlgoVoi service in the trust path. The chain only carries a 32-byte anchor, so one integration works on every chain you touch.
Allocation is one click in the operator panel: pick a merchant, allocate its Mesh licence, and the panel returns the licence key and a one-line offline install. Two-agent settlement quickstarts ship in the bundle under examples/mesh_a2a/. There is no separate purchase and no per-transaction fee: the individual Agent Mesh product is for a single agent boundary, while the rails bundle lets you allocate Mesh to your whole federation.

​
Seven chains, one bundle

All seven chains ship in the one bundle and each 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 chain takes its 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. Every network is present out of the box, so there is no per-chain integration to add.
Five of the seven chains have been validated end to end on live networks (Base, Algorand, VOI, Hedera, Stellar): a real on-chain settlement detected and turned into a receipt that verifies offline in the Command Center. Solana and Tempo are validated against their settlement logic and go live with a keyed RPC endpoint for those networks.
These seven are the chains the gateway settles and verifies x402, MPP, and AP2 on: it detects the on-chain transfer and applies that network’s finality rules, which needs a per-chain verifier. Peer Agent Mesh settlement is not limited to these seven: because Mesh only writes a 32-byte anchor and never verifies the payment on-chain, two agents can anchor a Mesh reference on any chain they both agree on, Arc included. The two are different jobs: the rails verify a settlement on the seven chains; Mesh records an agreed reference on whichever chain the agents pick.

​
One engine, one port

All seven chains run in one engine 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 handler. Every network lives in the same service; there are no extra 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.

​
White-label: your own domain and identity

You run the rails on your own domain, and they present as you, not as us. One setting, GATEWAY_PUBLIC_URL (which the installer sets to your domain), reconfigures every public surface to your identity with no per-endpoint configuration:
  • the A2A agent card and its signature,
  • the did:web document (did:web:pay.yourco.com),
  • the RFC 9116 security.txt contact,
  • the compliance attestation and its operator identity,
  • the x402 and MPP discovery documents.
No AlgoVoi identity, endpoints, or references appear anywhere on your deployment. The agent card can be signed with a key you generate and hold, verifying against your own JWKS. Set your organisation name or security contact with a single optional variable each, or leave the sensible per-domain defaults. It is a genuine white-label deployment out of the box.

​
Install in five minutes

One command brings the whole stack up under systemd behind automatic TLS:
Every service installs as a hardened, auto-restarting systemd unit behind Caddy with HTTPS: automatic Let’s Encrypt when you set a domain, or a self-signed certificate for an air-gapped install. The payment rails own port 443, so agents, payers, and facilitators reach you at https://your-domain with no port; the operator and control panels sit on separate ports so admin traffic never contends with live transactions. The bundle ships GO-LIVE.md, A2A-AGENT-CARD.md, and the full operator control panel guide with the walk-through, and starts on SQLite so you are live in five minutes.

​
Custody and payout

The gateway does both halves of a payment: it detects and proves inbound settlement, and it signs and broadcasts outbound payouts. Custody is operator-held: the signing key for each chain lives on your own infrastructure, supplied by environment and never by AlgoVoi, and a payout is fail-closed if no key is configured. POST /v1/payouts signs and broadcasts on the chain you name and returns a no-PII gateway_payout receipt (Falcon-signable, offline-verifiable) that folds into the Command Center next to your settlement evidence. Operator-held custody is available across all seven chains; an HSM or KMS-backed signer (the key never leaving the HSM) is the same interface, offered as a per-deployment option. Optionally, a payout can be bound to an authorizing decision: configure the gateway to sign a payout only against a fresh, valid ALLOW from the Spend Guardrail for that exact amount and destination. The authorizing decision is recorded in the payout receipt, so the evidence chain shows authorized then settled as one provable sequence, and a payout with no valid authorization is refused.

​
Defence in depth

The rails ship with a three-layer defence that is active by default the moment the service starts: you do not switch it on, and an operator can pause any layer if it ever conflicts. Every layer runs on your own infrastructure, and every decision it makes is Falcon-1024 signed and offline-verifiable, the same evidence discipline as the payment receipts themselves. The three layers compose. Edge Sentinel makes the runtime admission decision; its block decisions feed the fail2ban jail, so a repeat offender is dropped at the perimeter rather than re-evaluated on every request; and Substrate Guard bounds what any request can submit to the engine in the first place.

​
Operator security console

A Security tab in the operator control panel shows the live state of all three layers on one screen: which are active, the fail2ban jail status, and the list of currently banned IPs. Each layer can be paused and resumed from the panel, and every change is written to the signed audit chain. The panel drives fail2ban over a group-readable command socket, so no sudo is involved and the hardened, NoNewPrivileges systemd units stay intact.

​
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 the operator’s own Falcon-1024 key through Substrate 2, and canonicalised with JCS (RFC 8785) so the evidence is canonical and content-addressed. 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.

​
What’s in the bundle

One licence installs the whole stack as a single encrypted, offline-verifiable .algv:
  • The payment rails engine across all seven chains: intent lifecycle, settlement and finality detection, operator-held payouts, and the x402, MPP, and AP2 settlement protocols, with A2A discovery, on one port.
  • The post-quantum Substrate 2 core: Falcon-1024 signing, JCS canonicalisation, and the receipt formats every settlement is signed with by the operator’s own key.
  • The full keystone estate: a federated agent-passport issuer with its own operator panel area (issue, verify, revoke, CRL), the passport-to-journey lifecycle, the federation validator, the zero-knowledge receipt service, and delegation refs.
  • Agent-to-agent Mesh, federation-allocated: allocate post-quantum Mesh licences to your own federation members from the panel, with no per-agent fee, protected by an AlgoVoi root-signed name-constrained delegation. Two-agent settlement quickstarts ship under examples/mesh_a2a/.
  • An active-by-default three-layer security suite: a fail2ban perimeter firewall (L0) fed by runtime block decisions, Substrate Guard input-bounds and UTF-8 admission (L1), and Edge Sentinel runtime IP, geo, ASN, rate and replay protection with Falcon-1024 signed decisions (L2), all visible and controllable from a Security tab in the operator panel.
  • Evidence and retention: Command Center ingest and the hash-linked retention chain, so every settlement folds into one offline-verifiable posture.
  • White-label deployment: one setting reconfigures every public surface to your identity: did:web document, A2A agent card (signed with your own key against your own JWKS), x402 and MPP discovery documents, security.txt, and compliance attestation. No AlgoVoi identity, endpoints, or references appear anywhere on your deployment.
  • Operator-held custody and outbound payouts: sign and broadcast payouts across all seven chains. The signing key lives on your own infrastructure; an HSM or KMS-backed signer (key never leaves the HSM) is the same interface. Optionally bind each payout to a Spend Guardrail ALLOW decision for that exact amount and destination, recorded in the receipt as an authorized-then-settled provable sequence.
The multi-tenant control plane, operator panel, and per-tenant isolation run it all. It starts on SQLite for a five minute install and upgrades to PostgreSQL by import when you scale.

​
Get the bundle

The rails ship as one self-hosted bundle: the gateway engine (intent lifecycle, signed settlement evidence, the service, and the plugin framework), all seven chains, the full keystone estate, the active-by-default three-layer security suite, and the post-quantum Substrate 2 core, on a one-time perpetual licence. It is self-hosted and is not distributed on public package registries.

Buy the Payment Rails bundle

One licence installs the whole stack with every chain. Buy it on the AlgoVoi store. For enterprise terms, email us.