When the gateway moved the money, who has the receipt?
Every transaction passing through a payment gateway flows through code the merchant cannot independently verify at the moment of execution. PCI-DSS audits configuration. Subresource Integrity verifies static script hashes. Fraud detection compares statistical patterns. Per-transaction code-and-data integrity is the gap none of those cover.
Per-transaction code integrity is the gap PCI-DSS does not cover.
The merchant runs a payment gateway. The gateway processes card data on behalf of the merchant on its way to the processor. PCI-DSS verifies the state of that environment during the audit window. Subresource Integrity verifies the hash of static scripts at the moment a browser loads them. Fraud detection compares the shape of transactions against statistical patterns. None produce a per-execution cryptographic record of what the gateway code actually did with each transaction.
Between audit windows, gateway code can be modified silently. Compromised dependencies, injected scripts on checkout pages, and server-side compromise of the gateway service itself are documented categories in public threat-intelligence reporting. AI-adaptive variants further mutate their signature per session, time exfiltration to mimic legitimate processor noise, and target only the subset of transactions that match a profile. The compromise surfaces as credibility collapse, not single-bug fix.
AAM closes the gap without coupling to any single gateway architecture. The audit primitive is content-addressed: the SHA-256 of the gateway code path executed, the SHA-256 of the inputs received, the SHA-256 of the outputs produced, the chain-of-command stamp identifying the gateway agent, and the side-effect record for the execution. Knox anchors each, aggregates the hourly Merkle root, and publishes the root to the Bitcoin blockchain. The gateway operator cannot silently rewrite a history that exists outside its own systems.
Every transaction at the gateway surface becomes a Knox event.
The gateway agent surface is small, structured, and content-addressable. Five interaction shapes map to canonical Knox event types — each with a chain-of-command stamp and content-addressed pointers to the underlying transaction artifacts.
The SHA-256 of the executable code path that ran at the moment of the transaction. The interpreter, the compiled binary, the loaded modules, and the active configuration are pinned. A silent modification of gateway code — through dependency compromise, injection, or server-side mutation — is observable as a divergence from the chain at the next anchor.
The SHA-256 of the inputs received by the gateway. Cardholder data is hashed under the operator's tokenization rules; non-PII inputs are full-hashed. The merchant retains a content-addressed proof of the inputs they intended without the chain ever seeing the raw card data.
The SHA-256 of the outputs produced — what was sent to the processor, what was logged to merchant systems, what was returned to the client. The processor, post-incident, can cross-check what it received against what the gateway claims to have sent. Divergence is detectable.
The chain-of-command stamp identifying the gateway agent that executed — build identifier, policy version, declared surface. The agent's claimed shape at the moment of the transaction is recoverable independent of any subsequent firmware or policy change.
The database write, external API call, or message published as a consequence of the execution. The narration that the transaction settled — the agent's claim that the side effect occurred — is cross-checked against the cryptographic commitment of what the side effect actually was. A claim of completion that does not match the side-effect record is detectable from the chain alone.
The questions are predictable. The records should be too.
Once a payment-related incident is being investigated, the same five questions arrive on every case. AAM primitives produce records architected to answer each one without re-trusting the gateway operator, the merchant, or the processor.
Was the gateway running the code the merchant approved at the moment of every transaction?
The code-fingerprint anchor commits the SHA-256 of the gateway code path at the moment of every transaction. A silent modification, between audit windows, is observable as a divergence from the chain at the next anchor.
Did the inputs the gateway received match what the merchant intended?
The input-commitment anchor pins the SHA-256 of the gateway's received inputs without recording the raw card data. Comparison against the merchant's intended-inputs record reveals injection, substitution, or tampering between the merchant's system and the gateway.
Did the outputs the gateway produced match what the processor received?
The output-commitment anchor commits the SHA-256 of the outputs the gateway claims to have produced. The processor, post-incident, cross-checks what it received against the chain. Divergence — an exfiltration to a third destination, a duplicate transmission, a silently rewritten output — is detectable.
Did the gateway agent claim the transaction settled when the side effect did not actually occur?
The side-effect-record anchor commits the actual database write, external API call, or message published as a consequence of the execution. A narrative claim of completion that does not match the side-effect record is detectable from the chain alone — without trusting the agent's own account of its work.
Can the chain be reconstructed if the gateway operator is gone, hostile, or no longer cooperating?
Every Knox anchor is content-addressed and Bitcoin-anchored. Reconstruction does not require the original gateway operator, the original processor, or the original merchant CMS to remain online or cooperative. The receipt outlives the gateway.
What composing AAM above a payment gateway gives you.
Gateway-neutral
Any payment gateway, authored by any operator, can be paired with Knox by instrumenting an emit path on the operator’s side. The gateway service does not need to know about Knox, consent to Knox, or be modified for Knox.
Independently verifiable
Anchors are published to the Bitcoin blockchain via OpenTimestamps. Verification does not require Bonis, the gateway operator, the processor, or the merchant to be online, in business, or cooperative. The receipt outlives the merchant of record.
Court-admissible architecture
Anchors and the affidavits derived from them are architected to meet the self-authentication requirements of FRE 902(13) and 902(14). Admissibility in any given matter remains a determination of the presiding court; the structural requirements are met by construction.
Post-quantum resilient
Gateway-class commitments may carry post-quantum signatures via Knox Agent #11 Layer 4 — ML-DSA-44 / 65 / 87 (NIST FIPS 204) and SLH-DSA-128s / 192s / 256s (NIST FIPS 205). Card-data exposure timelines extend across statutes of limitations; the audit chain remains verifiable under threat models that assume future quantum-capable adversaries.
Cross-checkable with processor logs
The processor’s own settlement record continues to operate as designed. The public-chain record provides an independent comparison point. Divergence between the two — silent rewrites, redactions, omissions, or unauthorized third-destination transmissions — is detectable rather than assumed.
Open-spec aligned
OpenTimestamps is an open protocol. Bitcoin is a public chain. The TLA+ specification of the Knox anchor pipeline is public source. The full audit path lives on open standards, with no proprietary gateway-specific lock-in.
The pattern is in the public threat-intelligence record.
The structural conflict — gateway operator as both code custodian and sole evidence custodian — is documented at the family level across years of public threat-intelligence reporting. The categories below are cited as public-record patterns, not as named breaches, named operators, or Bonis-relevant evidence. None implicates a Bonis prospect, partner, or customer.
Magecart-class web skimming
A multi-year category of attacks injecting scripts onto checkout pages that intercept card data at form-submit. The compromise vector varies — third-party tag managers, CMS plugins, content delivery networks — but the pattern is well-documented in public threat-intelligence reporting from multiple security vendors.
AI-adaptive injection
Variants documented in security industry reporting that vary behavior per session to defeat signature-based detection, time exfiltration to mimic legitimate processor noise, target only transactions over a value threshold, and skim only when fraud-detection signals are quiet. Lower visibility, higher value extraction.
Server-side gateway compromise
Beyond browser-side injection, the gateway service itself is a target — modifying transaction code in flight, copying card data as it passes through the processing pipeline before reaching the merchant or processor. PCI-DSS, Subresource Integrity, and browser-side monitors do not extend to this layer at runtime.
Phantom-completion at industrial scale
A compromised gateway agent that narrates the transaction as processed cleanly while skimming card data in transit is the same fabrication mode as an agent that narrates a side effect occurred when it did not. The cryptographic commitment of the actual side effect is what closes the gap; the narration is fabricable for free.
Independent runtime evidence is becoming required, not optional.
PCI-DSS v4.x
The Payment Card Industry Data Security Standard v4.0 — v4.0.1 the current revision — is in force, with merchant compliance milestones rolling through 2025 and 2026. The direction-of-travel of the standard is toward stricter integrity verifiability of payment-processing components.
PCI SSC · v4.0.1 · in forceFTC Section 5
The Federal Trade Commission’s consumer-protection authority under 15 U.S.C. § 45 reaches breach mishandling, deceptive security claims, and inadequate breach response. Per-transaction integrity evidence supports both compliance documentation and post-incident remediation.
15 U.S.C. § 45 · FTC enforcement · in forceState data-breach notification
All 50 states, the District of Columbia, Guam, Puerto Rico, and the U.S. Virgin Islands operate breach- notification statutes. Per-transaction commitment records accelerate breach scope determination — the question of which transactions were affected becomes resolvable from the chain.
50 states + DC + 3 territories · in forceEU GDPR Article 32 · NIS2 · DORA
EU Regulation 2016/679 Article 32 imposes integrity-and- confidentiality requirements on personal-data processing. Directive (EU) 2022/2555 (NIS2) imposes operational- resilience requirements on essential and important entities; payment service providers are governed by Regulation (EU) 2022/2554 (DORA) as lex specialis, while ICT service providers, digital-infrastructure operators, and managed service providers handling payment flows remain in NIS2 scope under Annexes I and II.
GDPR Art 32 · NIS2 · DORA · in forceOne HTTP call per transaction.
The operator does not have to wait for a Knox payments SDK to ship. The public anchor endpoint is already live, and any payment gateway that can issue an HTTP POST can pair its transaction surface with Knox today. The published agent-feed enumerates all five gateway event types as canonical anchored types.
Evidence layer, not enforcement.
Bonis does not access gateways, does not intercept transaction data, does not modify, block, or rate-limit payment traffic, and does not undertake any active disruption of any external system — including a system demonstrably compromised by an attacker agent. Knox is invitational: a merchant, gateway operator, processor, or third-party auditor who wants a tamper-evident per-transaction record instruments their own emit path. Bonis produces the audit primitive; lawful authority — courts, the Federal Trade Commission, state Attorneys General, PCI-DSS qualified security assessors, plaintiff counsel — decides what to do with the resulting evidence.