The trust layer that makes every payment provable.
11PQ Gateway seals every transaction with a post-quantum signature and a tamper-evident proof that anyone can verify independently, running on top of the card rails you already trust.
ML-DSA-65 NIST FIPS 204Independently verifiableTamper-evident auditPatent pending
11PQGATEWAY
1111 PQ11 SEAL 2048
POST-QUANTUM SECURED
SIGNED ML-DSA-65
Proof verifiedoffline, no gateway access
Built and verified
Post-quantum signing live
Standalone verifier shipping
Independent pen test & production boarding next
What it is
An attestation layer, not another gateway.
11PQ sits on top of a processor and adds the one thing the rails underneath do not: cryptographic, future-proof, audit-grade proof that a transaction happened exactly as recorded. It can seal a payment it routes, or attest one a platform already processed, so it wraps an existing stack without changing the money path. It holds no funds and is not an acquirer.
Post-quantum signed
Every receipt is signed with ML-DSA-65, the NIST-standardized post-quantum signature (FIPS 204), so proofs stay trustworthy long after classical cryptography is retired.
Tamper-evident audit
Every event is hash-chained to the one before it and enforced append-only at the database. Any alteration breaks the chain and is immediately detectable.
Independently verifiable
Anyone holding a receipt can confirm it offline with the public key, without trusting or contacting the gateway. We ship a standalone verifier for exactly this.
The wrapper
Built to wrap a whole platform, not just one gateway.
11PQ is a post-quantum wrapper designed to sit over a processor's entire book of business. That is what makes it a fit for a platform, not a point tool, and it is the lowest-risk way for a processor to adopt post-quantum proof.
Wrap, don't re-route
Attestation mode produces a post-quantum proof for a transaction the platform already processed, with no change to the authorization path. A first phase keeps the existing processor and adds verifiable evidence as an overlay.
Multi-tenant keys
Each client holds its own signing identity, bound to that client and rotatable on a schedule. Historical receipts stay verifiable after a key retires. One platform, many banks and PayFacs, cryptographically separated.
Independent anchoring
The head of the evidence chain is anchored to an independent RFC 3161 timestamp authority. A third party can confirm the records existed at a given time, so the operator is out of the trust boundary for its own timeline.
HSM and KMS ready
The signer is pluggable and drops into a bank's hardware security module or key service without changing the integration, which is exactly what a bank security review will ask for.
Why now
The migration is mandated. The trust gap is real.
NIST has finalized the post-quantum signature standard, and the payment ecosystem must migrate its cryptography. At the same time, regulated institutions increasingly need transactions they can prove, not just trust. 11PQ answers both today, on top of the rails already in production.
Future-proof
Standards-based post-quantum protection applied now, ahead of the ecosystem-wide migration, not a multi-year research program.
Harvest now, decrypt later
Attackers can record encrypted payment traffic today and decrypt it once quantum capability exists. Settlement records stay valuable for years, so protection has to start before the machine does.
Provable
Audit-grade, independently verifiable proof of every transaction reduces dispute, audit, and reconciliation burden.
Low-risk
A layer on top of existing processors. It adds trust without replacing the rails, so adoption risk stays low.
NIST FIPS 204 ML-DSA-65FIPS 180-4 SHA-256NIST IR 8547 classical signatures retired after 2030EU DORA tamper-evident records
Agentic commerce
Proof for the age of AI-initiated payments.
Payments are initiated by more parties than ever. With Visa Intelligent Commerce and Mastercard Agent Pay now live, AI agents act for cardholders alongside wallets and platforms. Every new channel raises the same question for issuers and regulators: who authorized what. 11PQ gives every transaction, whatever initiated it, a signed and tamper-evident record that answers it.
Any initiator
Agent, wallet, platform or terminal, the proof is the same. The record binds the transaction to its merchant and its moment, independent of the channel.
Answers "who authorized what"
As agent-initiated volume grows, so do disputes and audit questions. A verifiable receipt per transaction is the evidence issuers and regulators will ask for.
Complementary, not competitive
11PQ is infrastructure that sits on top of the networks and processors already in production. It adds a trust layer they do not have, and competes with none of them.
How it works
Every payment, sealed in-line.
On a card-not-present payment, the request flows through the gateway pipeline and out to the processor, while 11PQ produces the signed receipt and the tamper-evident audit record.
01
Validate
Schema and idempotency. No double-charge.
02
Tokenize
Card vaulted at the processor. No PAN stored.
03
Route
Out to the processor and card networks.
04
Normalize
Clean result and decline codes.
05
Audit
Hash-chained, append-only record.
06
PQ sign
ML-DSA-65 receipt. Verifiable proof.
The audit layer
A chain that cannot be edited without showing it.
Every event in a transaction's life, authorize, capture, refund, void, settle, is written to an append-only ledger. Each record carries the hash of the record before it, back to an all-zero genesis, and is individually signed with ML-DSA-65. Alter, insert, or delete any record and the chain breaks at that exact point, which the independent verifier detects and locates.
Hash-chained
record_hash = SHA-256( prev_hash : payload_hash ). Each link commits to the entire history before it, so the past cannot be rewritten.
Append-only
Updates and deletes are blocked at the database by a trigger. The ledger only ever grows, and every row is signed.
Located, not just detected
A broken link does not fail silently or vaguely. The verifier names the exact sequence number where the evidence was altered.
genesis prev=000...000 signed seq 1 authorize prev=hash(genesis) signed seq 2 capture prev=hash(seq 1) signed seq 3 settle prev=hash(seq 2) signed # change one byte in seq 2 and seq 2..n no longer verify
See it for yourself with the Tamper a record check in the live verifier.
The verification demo
Prove a transaction without trusting us.
This is the part that lands in a technical review: a bank or auditor can verify a receipt entirely on their own, offline, using only the public key. Three steps.
1
Retrieve the receipt
Pull the full signed receipt for a payment through the authenticated API.
GET /v1/payments/:id/receipts # signature, key_id, alg, fields
2
Verify offline
Run the standalone verifier with the receipt and the public key. No gateway access.
Confirm the audit ledger links unbroken from genesis. Any tampering fails.
verifier chain ledger.json VERIFIED from genesis breaks: 0
Live in-browser verifierReal ML-DSA-65No server callDemo keypair
pq11-verify — running in your browser, public key only
# A real post-quantum verifier is running on this page. # Pick a check below. Nothing is sent to any server. # loading ML-DSA-65 verifier...
This runs the real NIST FIPS 204 ML-DSA-65 verification in your browser, using only the public key. The receipts and ledger below are signed with a clearly labeled demo key, never the production signing key. That is the point: you can confirm the math without trusting us, and without any access to the gateway.
Verify it yourself
Take the exact artifacts the panel above checks. Download the signed receipt, the public key, and the hash-chained ledger, and verify them offline on your own machine, with no access to the gateway.
Processor-agnostic layer on proven infrastructure.
The audit income layer
Every signature is a new line of income.
Every transaction through the layer produces one post-quantum signature, and each signature is a verifiable unit of evidence. That turns processing volume already flowing today into a metered income layer on top of the rails, with no new switching infrastructure and no funds held.
1 transaction → 1 post-quantum signature → 1 verifiable evidence unit → 1 billable event. The same volume a processor already moves becomes a new, high-margin revenue line.
Metered
Verification as a service
A public endpoint that verifies any 11PQ receipt and audit chain, priced per call, for issuers, auditors and relying parties.
Metered
Attestation events
Each wrapped, anchored transaction is a billable evidence event, countable from the ledger with no change to the money path.
Per merchant
Audit-grade export
A signed, offline-verifiable proof bundle a merchant can hand to a bank, auditor or regulator in a dispute.
Tier
Premium security tier
A post-quantum ready tier priced above standard processing, a direct answer to a bank's own PQC migration requirement.
Licence
Platform licence
White-label the wrapper inside a processor's platform under an annual enterprise licence.
Share
Revenue share and services
Resell to banks, ISOs, PayFacs and fintechs under a revenue share, plus integration and onboarding.
Who it's for
Built for the institutions that have to prove it.
Banks
Audit-grade assurance
Provable transactions that cut dispute and audit cost, future-proof cryptography ahead of the mandated migration, and enable high-assurance verticals. Board your own merchant identifier and run it on your terms.
Processors & ISOs
A differentiating layer
Offer merchants a post-quantum, independently verifiable trust layer competitors do not have. Add it on top of the existing stack with low integration risk.
Networks
Future-proof trust
A working, standards-based attestation layer that strengthens the network's core promise of trust, verifiable by issuers, acquirers, and merchants alike.
Standards and conformance
Built on published standards, stated honestly.
The cryptography is standards-based, and we separate what is implemented today from what is on the roadmap. We do not claim validations we have not completed.
Implemented
FIPS 204
ML-DSA-65, the NIST post-quantum signature on every receipt and ledger record.
Implemented
FIPS 180-4
SHA-256 for content hashing and the append-only hash chain.
Implemented
RFC 3161
Independent trusted-timestamp anchoring of the chain head to a third-party authority.
Implemented
RFC 8032
Ed25519, retained only for backward compatibility with pre-cutover receipts.
Roadmap
FIPS 203
ML-KEM hybrid key exchange for quantum-safe transport, protecting data in transit.
Roadmap
FIPS 140-3
Validated signing via an HSM or key service, dropped in through the pluggable signer.
Driver
NIST IR 8547
The PQC migration timeline. RSA, ECDSA and EdDSA are deprecated after 2030, disallowed after 2035.
In progress
SOC 2, PCI, pen test
Independent penetration test, SOC 2 and PCI validation of the gateway are the production gates.
For your technical team
Questions a reviewer will ask.
Is this a gateway or a network?
Neither replaces what you have. 11PQ is a trust and attestation layer that sits on top of a processor. It can execute the payment or attest one your platform already processed, adding the post-quantum proof and tamper-evident audit either way. It is not an acquirer and holds no funds.
What post-quantum standard does it use?
ML-DSA-65, the NIST-standardized post-quantum digital signature defined in FIPS 204. The signed bytes bind the algorithm, key identifier, and version, so a receipt cannot be silently re-signed under a different scheme.
How can a transaction be verified independently?
Each receipt can be retrieved in full and verified offline with the public key using our standalone verifier. It checks the signature, recomputes the content hashes, confirms the key binding, and validates the audit chain from genesis, with no access to the gateway.
Is it in production?
It is built, deployed on dedicated infrastructure, and verified end to end, running on Visa Platform Connect through a Visa-owned processor. Post-quantum signing is live. An independent penetration test and processor production boarding are the next milestones. We do not claim certifications we have not completed.
Does it replace our processor?
No. It is processor-agnostic and rides on top of proven rails. Additional processors or bank rails can be added through adapters without a rewrite.
Is the cryptography FIPS-validated?
The implementation follows the NIST FIPS 204 standard. The library itself is not a FIPS 140-3 validated module; migration to validated signing, such as a hardware security module or validated key service, is on the roadmap.
Request access
See it prove a transaction, live.
We will walk your technical team through the architecture, run the verifier in front of you, and scope a test merchant integration.
