fix: forward x402 v2 extensions in payment payload

[ygd58]

Closes #196

Problem

When an x402 server returns a 402 response with extensions (e.g. Bazaar discovery metadata), OWS was silently dropping the field. X402Response had no extensions field so it was lost during deserialization, and PaymentPayloadV2 had no extensions field so it could never be included in the payment signature header sent back to the server.

This caused services using the Bazaar extension to never appear in CDP or PayAI Bazaar discovery when payments were made through OWS.

Fix

• Add extensions: Option<serde_json::Value> to X402Response
• Add extensions: Option<serde_json::Value> to PaymentPayloadV2
• Thread extensions through parse_requirements → build_signed_payment → build_evm_exact so it is included in the v2 payment payload

Tests

Added two unit tests:

• build_evm_exact_v2_forwards_extensions — verifies extensions are present in the v2 payload
• build_evm_exact_v2_no_extensions_is_none — verifies None when not provided

All 67 existing tests continue to pass.

[vercel]

@ygd58 is attempting to deploy a commit to the MoonPay Team on Vercel.

A member of the Team first needs to authorize it.

[0xultravioleta]

Thanks for this. #197 is implementing the same change (forwarding the x402 v2 extensions field through the payment payload) and it came in a bit earlier, so to avoid two near-identical diffs the plan is to move forward with #197.

The two implementations are basically equivalent, the only real difference is the tuple ordering in parse_requirements. Nothing here is wasted. Closing this as a duplicate of #197 to keep things tidy. The branch stays, so you can reopen anytime if needed. You have several other PRs open that are a better use of the review cycles, so this just keeps things tidy. Thanks.