Recibo

Demo

About

x402 gives AI agents a clean rail for machine-to-machine micropayments. What it does not give them is a receipt. Once an x402 payment settles, it settles. If the service took the money and never responded, the paying agent has no reversal path, no on-chain record of what was actually delivered, and no audit trail of what it spent. At one payment per API call, an agent making thousands of calls a day is running blind. The ecosystem is building the payment rail. Nobody is building the receipt. Recibo puts escrow between the agent and the provider. The x402 payment settles into an escrow account rather than going straight to the provider. The provider then has to prove delivery: Recibo computes a sha256 hash of the response body and anchors it on Hedera Consensus Service. Only then are the funds released. If the provider fails to deliver, the escrow reverses itself and the payer is refunded automatically, with the failure reason recorded on-chain. Every state transition — HELD, DELIVERED, RELEASED, REFUNDED — is anchored as an immutable message on a public HCS topic before the response is returned. The audit trail can be independently verified at hashscan.io without trusting our server. The refund path is not an edge case here. It is the product. A payment protocol without a reversal path is incomplete, and Recibo is the layer that completes it.

How it's made

Node/Express server using @x402/express with the ExactHederaScheme, settling through the Blocky402 facilitator on Hedera testnet. Client side uses @x402/fetch. Ledger interaction is via @hiero-ledger/sdk (the Hiero rebrand of the Hedera SDK — worth noting, since most tutorials still reference @hashgraph/sdk and the import silently fails). Three Hedera testnet accounts: payer, provider, and an escrow account that holds funds between payment and delivery. The x402 payment requirement's payTo points at the escrow account rather than the provider, which is the single change that makes reversal possible. The escrow core exposes four operations — hold, proveDelivery, release, refund — with enforced one-way state transitions. Any invalid transition throws. "Verifiable delivery" is deliberately narrow: sha256 of the response body and nothing else. No arbitration, no voting, no LLM judgment. That constraint kept the design honest and shippable in a weekend. Every transition anchors a message on HCS via TopicMessageSubmitTransaction. consensusTimestamp comes from getRecord() rather than getReceipt() — a non-obvious detail that costs an hour if you get it wrong. The HCS sequence number, not the local clock, is the canonical ordering of events. Read-only dashboard in Next.js 15 with 3-second polling, showing live escrow state, event timelines, and HashScan links per transaction. Two Hedera-specific things made this viable. First, gas is sponsored by the Blocky402 facilitator, so the paying agent never needs HBAR for fees. Second, a refund costs roughly $0.0001 — on an expensive L1, reversing a micropayment would cost more than the payment itself, and the product simply would not exist. Known scope limits, documented rather than hidden: escrow state is in-memory and resets on restart, there is no automatic timeout sweep, and allowedAssets restricts which asset can be paid but not the amount.