---
title: "x402-signals v0.2.0: outcome-scoped refunds for x402 services"
slug: x402-signals-v0_2_0
canonical: https://x402station.io/blog/x402-signals-v0_2_0
date: 2026-05-13
tags: [x402, agentic-commerce, refunds, payments, api-design, base]
---

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](https://github.com/sF1nX/x402-signals/releases/tag/v0.2.0). The versioned spec is here: [v0.2.md at v0.2.0](https://github.com/sF1nX/x402-signals/blob/v0.2.0/v0.2.md).

## 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](https://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

- Canonical repo commit for the v0.2 draft: [`1db3ba4`](https://github.com/sF1nX/x402-signals/commit/1db3ba4).
- Canonical repo prose fix before tag: [`5b18d83`](https://github.com/sF1nX/x402-signals/commit/5b18d83).
- Annotated tag: [`v0.2.0`](https://github.com/sF1nX/x402-signals/releases/tag/v0.2.0), tag SHA `5b2749c0...`.
- Monorepo mirror commits: `d52a59d` for the v0.2 draft and `18e6562` for the ReloadPI attribution plus three-orders correction.
- First-implementation review thread: [github.com/sF1nX/x402-signals/issues/1](https://github.com/sF1nX/x402-signals/issues/1).

## 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.