x402 payment requirements · Updated
When an x402 payTo address changes: what to compare.
A different recipient deserves attention, but the change alone does not explain why it happened. Compare the complete requirement, its observation time, and the resource before your payment policy decides what to do.
Read the illustrated evidence exampleA five-part comparison
Start with the whole requirement.
A payTo value only makes sense beside its network, asset, amount, scheme, and resource. Keep the challenge your client actually received, including its timestamp, so you can compare it with a saved observation instead of comparing an address in isolation.
| Field | Earlier observation | New challenge | What the difference tells you |
|---|---|---|---|
| Resource | /v1/resource | /v1/resource | The comparison still concerns the same endpoint path. |
| Network | eip155:8453 | eip155:8453 | No payment-network change appears in this example. |
| Asset | synthetic token 0x…C3 | synthetic token 0x…C3 | The same illustrative contract identifier appears on the listed network. |
| Amount | 1000 atomic units | 1000 atomic units | No amount change appears in this example. |
payTo | 0x…A1 | 0x…B2 | The advertised recipient differs. The evidence does not supply the reason. |
All abbreviated addresses are display-only synthetic identifiers. They are not usable payment instructions.
payTo- The recipient advertised by that payment option. A difference shows that the client was asked to pay a different recipient value.
- Network + asset
- The settlement context. The same address text on another network, or the same ticker for another asset identifier, is not the same payment option.
- Amount
- The amount is part of IFF's full option fingerprint. A changed amount with the same scheme, network, asset, and recipient can be classified as
amount_onlyby preflight comparison. - Resource
- The endpoint URL selects the IFF record and comparison scope. A different host or path should be inspected as a different resource. It is not part of IFF's payment-option fingerprint.
Context before conclusions
A change can be routine.
Providers can rotate a treasury address, migrate custody, change an asset or network, update a price, or deploy a new resource path. A cached or delayed challenge can also make a valid transition look inconsistent for a short time. Those are possibilities to investigate, not explanations established by IFF.
diverged means at least one option your client supplied did not match the recent observed option union. amount_only means every supplied option matched an observed scheme, network, asset, and recipient, while at least one differed in amount. The broader payee classification means at least one supplied option had no match for its non-amount fields; it does not claim that the recipient alone changed.
A stale observation adds another limit. IFF still compares the new requirement with the latest observation window and reports matches_last_observed, but the verdict remains stale. That can tell you whether the terms match the last saved evidence; it cannot make old evidence current.
What the record contains
Use history to establish sequence, not motive.
The latest public evidence card shows the current saved payment options and observation time. Its requirements.current and requirements.history blocks summarize consecutive fingerprint runs with first-seen, last-seen, and observation counts. The public history identifies that a normalized option set changed; it does not expose a plain-text before-and-after explanation or attribute the change to an operator.
- Match the exact resource.Compare the same normalized public HTTPS endpoint, including its path.
- Check the timestamps and freshness.An older challenge and a newer observation may describe different legitimate states.
- Compare all advertised options.Option order and duplicate entries do not create a different normalized set, while scheme, network, asset, recipient, and amount do.
- Separate ownership from requirements.A verified ownership dimension records origin control. It does not prove control of a payment address, and an observed-tier card can have unverified ownership.
- Apply your own hold or escalation rule.Ask the provider through a separately trusted channel when a change exceeds your policy.
Your payment policy decides
What these observations do not prove.
A matching requirement is evidence of consistency with recent observations. A changed requirement is evidence of a difference. Neither result proves payment safety, recipient ownership, authorization, confirmed fraud, service delivery, settlement, or the correctness of a paid response.