back to articles

published 2026-05-13

x402-signals v0.2.0 is now tagged.

The spec is a small CC0 convention for x402 services to publish fulfillment, refund, and operational state in machine-readable form. It is meant for the part x402 itself does not define: what a paying agent should do after settlement if fulfillment is delayed, fails, or needs recovery.

The v0.2.0 tag is here: github.com/sF1nX/x402-signals/releases/tag/v0.2.0. The versioned spec is here: v0.2.md at v0.2.0.

What changed in v0.2.0

v0.2.0 folds in structured feedback from the first public field implementation.

The five material changes:

  1. refund_policy.type is now outcome-scoped. A provider can say a delivered topup is non-refundable, while a failed-before-delivery topup is automatically refundable.
  2. refund_policy_by_state lets providers declare per-state overrides, for example FULFILLMENT_FAILED -> automatic.
  3. refund_contract is an optional top-level discovery block describing how an agent invokes the refund action.
  4. Refund lookup accepts transactionHash alongside paymentId, which matters when the original HTTP 200 response is lost but the on-chain settlement is known.
  5. Providers using automatic refunds should still expose a refund_endpoint, so agents can reconcile, retry idempotently, and recover from lost responses.

For v0.1 readers, this is intended to be a semantic-clarification and additive-field release. Existing parsers can ignore the new fields and still read the base fulfillment_policy, refund_policy, and signals blocks.

First field implementation

ReloadPI / api.reloadpi.com is the first public field implementation cited in the spec.

The implementation report covers eSIM, voucher, and topup flows on Base mainnet. During the second-round review, ReloadPI updated its live /.well-known/x402 document to the v0.2 refund_policy_by_state pattern and reported zero field-shape or state-transition mismatches against the draft.

That matters more than a clean abstract design. The useful test here was concrete: three independent carrier-rejected topup orders, each settled at $1.61 and then refunded, for $4.83 total refunded across three clean cycles. v0.2 models that as FULFILLMENT_FAILED -> automatic refund, not as a retry loop and not as a blanket product-category policy.

Release references

Why x402station cares

x402station.io is a pre-payment safety layer. Agents call Preflight before signing PAYMENT-SIGNATURE, but pre-payment checks are only half of the failure story.

Once a payment settles, agents still need predictable post-settlement semantics: status lookup, fulfillment state, refund availability, and a recovery path when a response is lost. x402-signals is the small public vocabulary we want providers and agent frameworks to be able to share without a private integration per merchant.

The project remains open for concrete counter-examples: field-shape mismatches, state-transition mismatches, and voucher or topup cases that do not fit the current model.

Provenance

Published by x402station.io. Primary references are the v0.2.0 tag, the versioned v0.2.md spec, the public implementation review thread, and the ReloadPI public x402 service. This post is release context for a CC0 technical convention, not a merchant certification.

back to articles4 total · published 2026-05-13