Free, browser-based workflows for teams building agent payments on x402, the protocol that turns HTTP 402 Payment Required into a machine-native rail. Each one handles a specific job: decoding and linting an x402 payment payload, recomputing the EIP-3009 or Permit2 signature evidence behind a payment, validating an A2A or AP2 payment mandate, reconciling a batch of agent micropayments, or picking the settlement rail for an agentic checkout. Everything runs locally in your browser. There is no backend, no signup, and no data leaves your machine. Every result carries a hash, so a counterparty can rerun the same workflow on the same inputs and confirm they get the same answer.
Written for engineers wiring agents to pay and be paid, and for the platform, payments, and risk reviewers on the other side of their integrations: facilitator and merchant teams accepting agent traffic, agent-framework builders, and settlement-ops desks that have to answer for the batches. This is an independent project by Post Oak Labs, not an x402 product.
x402 is a protocol for native payments over HTTP, built around the long-unassigned 402 Payment Required status code. A server that wants payment answers with a 402 carrying payment details; the paying agent returns with signed payment credentials in the PAYMENT-SIGNATURE header; the server (or its facilitator) verifies and settles, then serves the response with a PAYMENT-RESPONSE receipt. Version 2 of the spec defines the settlement field shapes this page's workflows check.
Two authorization primitives carry the crypto. EIP-3009 TransferWithAuthorization lets a payer sign an EIP-712 typed-data authorization that a token contract executes, which is the rail underneath the exact scheme. Permit2 is the sibling path: the payer signs a Permit2 typed-data message (witnessed or unwitnessed) that binds the destination, and a spender contract moves the funds. Permit2 carries both the exact and the upto scheme, because its signed amount is a ceiling the settlement can stay under. Both produce signatures an independent party can verify by recomputation, which is exactly what the evidence workflows on this page do: recompute the digest, recover the signer, and check the domain, nonce, and validity window against expectations, entirely offline.
Settlement evidence is the third leg. An onchain event proves occurrence; the workflows here produce the hash-bound artifacts (a spend-evidence pack, a reconciled batch, a Merkle-root receipt) that let a reviewer say what occurred, by which rail, with which finality expectation.
Four nodes recompute, from caller-supplied fields only, the cryptography an x402 payment stands on. Each one runs offline: no chain contact, no facilitator, no network. What each recomputes:
Recomputes the EIP-712 typed-data digest for an EIP-3009 TransferWithAuthorization struct from the caller's domain and struct fields: the domain separator, the struct hash, and the resulting digest to compare against the payment payload.
Recovers the ECDSA signer address from an EIP-712 digest and a signature supplied in (r,s,v) or (r,s,yParity) form, normalizing the recovery id across signature forms, so a reviewer can confirm which address authorized the payment.
Checks an EIP-3009 authorization's domain separation and replay-defense fields against caller-supplied expectations: the expected chain id and verifying contract as separate mandatory policy parameters, plus the nonce and the validity window.
Recomputes the Permit2 typed-data digest a payer's wallet signs for an x402 payment, across the single-item message shapes the exact and upto schemes use, including the witnessed transfer that binds the destination.
Six nodes cover the protocol surface around the signatures: the wire payloads, the mandates that authorize an agent to pay, the settlement economics, and the batch arithmetic.
Decodes base64 PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE headers, lints an exact-scheme PaymentPayload with EIP-3009-style authorization fields, and walks the HTTP 402 request, verify, and settle flow across the scheme and network matrix.
Validates the A2A x402 extension that carries crypto-payment authority inside an AP2 mandate: the extension declaration in the A2A agent card, the payment-authority scope, the settlement-rail binding, and the exact-scheme fields.
Validates the shape of a Cloudflare deferred x402 scheme handshake: the 402 offer fields (scheme, id, termsUrl), the RFC 9421 HTTP Message Signature covered-component coverage, and the settlement-reference id.
Correlates a built AP2 CartMandate against an x402_spend_evidence pack: whether the cart total matches the x402 authorization's value, and whether the cart's merchant matches the evidence.
Recommends a settlement rail and finality expectation across x402 (HTTP 402), Stripe USDC, card, ACH, and SWIFT, with per-transaction cost, eligibility scoring, and micropayment support.
Reconciles an x402 V2 batch settlement of off-chain payment vouchers against the onchain batch total: the recon verdict, per-voucher amounts, the settlement-risk window of unredeemed vouchers, and an educational Merkle root.
Each workflow composes the nodes above into one decision. Seven of them had no hub page before this one; they are listed in full here. Four more touch x402 on their way somewhere else and are cross-linked to the hubs that own them, so nothing moved.
Every workflow above composes nodes that emit OpenChainGraph artifacts with the following properties.
execution_hash over its inputs, processing parameters, and outputs. Either party in a bilateral workflow can rerun verify_execution_hash to confirm the node was run as claimed, without sharing internal policy or configuration.
x402_spend_evidence for the EIP-3009 rail and its Permit2 siblings) that a downstream agent or human reviewer can check step by step.
For the vendor side of this protocol, the AgentCore x402 page maps the field names of the OpenAI Cookbook example for AWS AgentCore Payments onto these same verifiers, field by field; this page stays protocol-level and links that mapping rather than repeating it. The Arc hub carries the x402-native evidence workflow alongside Arc's own rails, the Token Standards hub owns both Permit2 evidence pipelines, and the Tempo hub owns the Tempo checkout.