The x402 protocol does one thing very well: it settles payments between agents and providers on Base mainnet, atomically, without a human in the loop. Payment goes in, settlement happens, done.

What it doesn’t define — intentionally — is what happens after settlement when the thing you paid for doesn’t arrive.

For human-facing commerce, the answer has always been: “email [email protected].” That’s not automation. That’s a human waiting in a queue.

For agentic commerce, that answer breaks everything.

The gap nobody talked about

When an agent pays for a mobile top-up and the carrier rejects it, what happens?

When an eSIM fails to activate because the ICCID hits a network edge case, what happens?

When a voucher delivery API returns a 5xx and the agent’s HTTP window has already closed, what happens?

Before we built x402-signals, the honest answer was: nothing automated. The settlement happened on-chain. The money moved. The product didn’t arrive. And there was no machine-readable way for the agent to know what its options were, or for the provider to automatically make it right.

That’s the gap. It sounds obvious in hindsight — hence the gravity analogy. But nobody had shipped a live implementation across multiple product types with real traffic until Reloadpi.

What we built

Reloadpi ships three digital goods product types: eSIMs, mobile topups, and gift vouchers. Each has different delivery mechanics, different failure modes, and different refund semantics.

We implemented the full post-settlement obligation stack:

Fulfillment signals at /.well-known/x402

Every Reloadpi product type advertises its fulfillment policy machine-readably. An agent can check before paying:

  • What’s the SLA for delivery?
  • Is this instant or async?
  • What happens if it fails — automatic refund, manual review, or none?

A state machine for order outcomes

Orders don’t just succeed or fail. They move through states: pending → processing → delivered (happy path), or pending → processing → failed → refunded (failure path). Each transition is explicit, auditable, and triggers the next automated action.

Per-product refund policy

This is the semantic change that drove x402-signals v0.2. Refund policy isn’t per-product-type — it’s per-outcome. A topup that fails carrier validation gets automatic refund. A voucher that’s been delivered and revealed gets none. These aren’t the same policy, even if they’re the same order flow.

The v0.2 refund_policy_by_state map lets providers express exactly this. We pressure-tested it against live traffic with zero field-shape mismatches.

txHash as refund auth

The x402 payment produces an on-chain transaction hash. We use that hash as the proof-of-payment for refund initiation. No account, no API key, no support ticket. The agent that paid can initiate recovery with the txHash alone.

Three on-chain refund transaction hashes from Reloadpi’s carrier-rejected topup flow are now cited as the reference implementation in x402-signals §8.3.

Lost-200 recovery

HTTP can drop a 200 response between the server sending it and the client receiving it. In traditional commerce, you reload the page. In agentic commerce, the agent has no page to reload — and may have no idea the order succeeded.

We built a txHash-based recovery endpoint. If the agent lost its 200, it can present the on-chain tx hash and retrieve its order status. No human, no ticket, no retry from scratch.

Why this matters for the x402 ecosystem

Bitrefill is the obvious comparison. They have brand, volume, and years of distribution. What they don’t have — yet — is a documented, battle-tested, machine-autonomous recovery loop across multiple product types, provably working at the protocol level.

The GitHub issue we raised on the x402-foundation repo — filed by AFX (x402station), who ran an external machine-to-machine test of our full flow — asks the TSC to consider whether refund and fulfillment semantics deserve canonical treatment in the Foundation spec. The fact that the issue exists, is open, and cites Reloadpi by name with on-chain evidence, is the kind of third-party validation that doesn’t come from marketing.

What an agent sees

When an agent browses Reloadpi via MCP or the public API, it sees a /.well-known/x402 manifest that tells it, before paying:

{
  "fulfillment_policy": {
    "esim": { "type": "async", "sla_seconds": 300 },
    "topup": { "type": "async", "sla_seconds": 180 },
    "voucher": { "type": "instant", "sla_seconds": 30 }
  },
  "refund_policy_by_state": {
    "failed": { "type": "automatic" },
    "carrier_rejected": { "type": "automatic" },
    "delivered": { "type": "none" }
  },
  "signals": {
    "status_endpoint": "/api/orders/{orderId}/status",
    "refund_endpoint": "/api/orders/refund"
  }
}

The agent knows its options before it spends a USDC. That’s agentic commerce done right.

The 28,000 SKU problem

We have roughly 28–30k SKUs across eSIM plans, topup operators, and voucher brands. Every one of them is browsable by an agent without a structured API query — the catalog is navigable like a human would navigate it, which means agents that don’t know exactly what they want can still discover.

That’s not a solved problem in this category. Most providers require agents to know the SKU before they can transact. We let them browse first.

What’s next

The x402-signals spec lives at sF1nX/x402-signals under CC0. Anyone building on x402 can implement it, reference it, or contribute to it.

Reloadpi is accessible via:

  • MCP — bring our catalog into Claude, Cursor, or any MCP-compatible agent
  • agentic.market — discovery layer for AI agents
  • Partner SDK — embed our catalog in your frontend with referral attribution
  • Direct API — api.reloadpi.com with x402 payment support

The vending machine runs itself. The recovery loop runs itself. The refunds run themselves.

That’s the point.