We're Building Payment Systems Without the Receipts

Last year, I spent three weeks debugging a payment flow that "worked" in staging but mysteriously failed for certain merchants in production. The logs showed the transaction went through. The database confirmed the charge. But when the merchant disputed it, we couldn't prove what security checks had actually run—or whether they'd run correctly. We had the receipt, but not the evidence of how we'd validated it. That experience stuck with me, and it's exactly why this piece on agent payments and custody splits hit so hard.

The problem isn't unique to my case. As we move toward AI-driven payment systems and automated agent transactions, we're repeating the same mistake at scale: we're standardizing the handshake while ignoring who's actually keeping score. And when disputes happen—and they will—that gap becomes catastrophic.

The Easy Part: Making the Handshake Work

Let me be clear: the x402 protocol work is solid. When the Linux Foundation, Google, AWS, Visa, and Mastercard align on a standard, that's genuinely important infrastructure. It's the "SSL for AI commerce" comparison—and I'd argue it's apt. We need a common language for how agents request payment and how systems authorize it.

The spec is done. The interoperability layer is getting there. Major players are implementing. From a pure connectivity standpoint, this is winning.

But here's what I've learned from five years of building payment systems: standardizing the handshake is the easy part because it's what everyone agrees needs to happen. The hard part—the part that actually matters when something goes wrong—is what happens after the handshake completes.

The Missing Piece: Independent Verification

The article makes a distinction I think about constantly now: detection is not assurance.

A payment can go through (detection). That's trackable. But whether every security policy was correctly evaluated? That's assurance. And right now, x402 and similar protocols handle the first part well. The second part is a mess.

The historical parallel is perfect. When the Federal Reserve created a clearing layer, they didn't just improve the check format. They created an independent record. Banks could reconcile against the Fed's books, not against each other's claims. The ledger wasn't written by one party testifying about what they did—it was written by a neutral observer.

In modern payment systems, we need the same separation. The party that runs a security check shouldn't be the sole authority on whether that check was valid. That's like asking a student to grade their own exam and calling it independent verification.

The Real Problem: Single-Hat Ledgers

Where I diverge from most solutions I see: we keep building systems where the same entity provides both execution evidence ("the payment went through") and assurance evidence ("the payment was valid"). Those are different things, and they require different verification models.

Here's what I'd want in production:

Structured attestation records: Document not just that a check ran, but what evidence supported it—the observed data, the matched rule, the policy version, the exact timestamp.

Reproducibility as the standard: An independent verifier should be able to take those same inputs and reach the same verdict. If they can't, that's a critical problem, not an edge case.

Provenance binding: Each security decision should be traceable back to the rule, the evidence, and the verifier. Not "trust me, I ran the check." More like "here's the evidence, here's the rule version, here's who verified it—now you verify it too."

// Example: What a verification attestation might include
const paymentAttestation = {
  transaction_id: "txn_abc123",
  settled: true,
  settlement_evidence: { /* on-chain proof */ },
  security_checks: [
    {
      check_type: "fraud_detection",
      verdict: "passed",
      confidence: 0.98,
      rule_version: "policy_v2.1.4",
      policy_hash: "sha256:...",
      verifier_id: "verifier_alpha",
      evidence_inputs: { /* what the rule evaluated */ },
      timestamp: "2024-01-15T10:23:45Z",
      reproducible: true // can another verifier get the same result?
    }
  ]
};

This isn't just better for disputes. It's foundational for auditability, compliance, and—honestly—for building systems you can actually trust.

What I'm Thinking About Now

The article points out that assurance layers always arrive later than handshake protocols. I believe that. But I also think it's a mistake to treat it as inevitable or acceptable. We should be designing the assurance layer alongside the handshake, not bolting it on years later when regulators demand it.

For anyone building payment systems or agent infrastructure right now: start thinking about this. How will you prove your security checks were correct? Not just that they ran—that they ran correctly. What would independent reproducibility actually look like in your system?

Because the handshake is indeed the easy part. Everything else is the actual work.

Source: This post was inspired by "The handshake is the easy part. Agent payments still haven't named the custody split." by Dev.to. Read the original article