x402r extends the x402 payment protocol with secure, escrow-based refund capabilities for internet-native payments.
import { registerEscrowEvmScheme } from "@x402r/evm/escrow/server";
import { refundable } from "@x402r/helpers";
... registerEscrowEvmScheme(server, { networks: NETWORK_ID }); app.use( paymentMiddleware( { "GET /weather": { accepts: [ refundable({ scheme: "escrow", price: "$0.01", network: NETWORK_ID, payTo: account.address, }, operatorAddress),
],
description: "Weather data",
},
},
server,
),
);Read the original article
Comments
By satring 2026-03-1313:49 This fills a real gap. Right now x402 and L402 are both fire-and-forget: the client pays, the server delivers (or doesn't), and there's no recourse if the response is garbage or never arrives. For small amounts that's tolerable, but as agents start chaining multiple paid API calls in a single workflow, the failure modes compound fast.
A few questions: How does the arbitration layer handle the case where "delivery" is subjective? For a data API, you can verify the response isn't empty, but validating that the data is correct or fresh is harder. Does x402r define what constitutes a valid delivery, or is that left to per-service SLAs?
Also curious whether this works across payment protocols. L402 (Lightning macaroons) has a different settlement model than x402 (USDC on Base), so the refund mechanics would differ. Does x402r handle both, or is it x402-specific?
