AFFIXIO
ZK payments
Zero-knowledge payment eligibility
Some payment rules are predicates over sensitive attributes. Zero-knowledge circuits prove the rule without exporting the attribute values to every merchant. AffixIO uses Noir circuits and returns signed allow or deny at the boundary.
Definition
Zero-knowledge payment eligibility proves a payment policy predicate holds without revealing the underlying sensitive attributes to the verifier.
Field note. Raw eligibility data at checkout becomes a PCI and privacy liability. ZK proofs answer the question without retaining source fields.
Noir circuits for predicates
Encode the payment eligibility rule as a circuit. Prove it. Verify at the merchant or PSP boundary. AffixIO returns signed allow or deny with Merkle audit reference.
See the circuit catalogue for current predicates. Not every business rule is published as a circuit yet. Start with catalogue matches, then extend.
Stateless by design
The verifier learns the outcome, not the witness attributes. That matches the wider stateless verification model used across AffixIO gates.
Pair ZK eligibility with payment permission when the agent also needs spend authority.
Integration notes for ZK payment eligibility
Map ZK payment eligibility to a single verify endpoint even if multiple protocols feed the same checkout or tool surface. One permission layer reduces drift between AP2, UCP, and direct REST integrations.
Review deny rates weekly during pilot. Spikes often trace to policy drift or clock skew on expiry, not fraud.
Consent gap
Rules that expose too much
Merchants often only need to know that a payer qualifies. Shipping full account attributes answers that need by oversharing.
Attribute overshare
Balance bands, risk flags, or programme membership leak into merchant systems.
Inconsistent predicates
Each merchant re-implements rules differently.
Audit without raw data
Regulators may need proof the rule ran, not a copy of every attribute.
Edge deploy
Payment eligibility without exposing the underlying data
Merchants need yes-or-no payment eligibility, not copies of bank statements or benefit records. ZK circuits prove policy satisfaction while verify returns allow or deny only.
Select a predicate
From the circuit catalogue or agreed custom rule.
Issue the proof
Upstream holder of attributes proves the circuit.
Verify at pay
Merchant or PSP gates on allow or deny.
Retain audit refs
Merkle metadata without attribute dumps.
Verifier audit
Readiness checks for ZK payment eligibility
- List payment rules that currently expose attributes.
- Match rules to Noir circuits where available.
- Confirm zero PII at merchant verifiers.
- Test deny paths when predicates fail.
- Document circuit versions for auditors.
Operator FAQ
Questions on ZK payment eligibility
Which circuits?
See the circuit catalogue for current predicates.
Is ZK required for every payment?
No. Use it when attributes are sensitive and the merchant only needs the predicate outcome.
Does ZK replace payment permission?
No. Eligibility and permission are complementary gates.
Where are docs?
/docs/circuits and the sandbox.
Further reading
Pages that support ZK payment eligibility
Privacy and identity
More privacy and identity briefs
Prototype ZK payment eligibility
Exercise Noir eligibility circuits in sandbox, then wire verify to your payment boundary.