Choose one x402 payment option without mixing its terms
Guides
When a payment challenge offers several acceptable methods, select one complete requirement that your client understands. Never combine fields from different options.
An x402 payment-required response describes the protected resource and carries an accepts array. Each member of that array is a complete payment requirement. Several entries are alternatives offered by the server, not parts of a menu from which a client may assemble new terms.
First confirm that the resource matches the intended request. Then evaluate every offered requirement as one unit: scheme, network, amount, asset, recipient, timeout and the fields in extra. Discard an option when the client does not support or understand all payment-relevant fields. A familiar asset or lower amount does not make an otherwise unsupported option safe to authorize.
After choosing an option, place that same payment requirement in the accepted field of the payment payload and create the scheme-specific authorization for it. Do not take the network from one entry, the amount from another or replace the advertised recipient. Mixing fields creates a payment the server did not offer and removes the basis for a reliable pre-signing review.
The payment flow also matters. The protocol requires clients to skip options with an unrecognized payment flow. Where the same request offers both an authorization flow and a flow that commits funds before resource execution, the specification recommends preferring authorization. That choice keeps the advertised ordering between verification, execution and settlement intact.
Use the current live challenge for the actual authorization. A discovery document or directory can show that a service supports a payment method, but it is not a substitute for the payment requirements returned for the exact request. If the chosen option changes or disappears, stop and obtain a fresh challenge instead of signing cached terms.
Keep the exact request, the selected requirement, the signed payload and the payment response together. These records show which alternative the client chose and what the payment layer reported. The API result and its delivery remain separate evidence and should not be inferred from the existence of an acceptable payment option.