x402 vs. MPP: Match the Payment Contract to Your Paid API

Imagine adding a paid data endpoint for an agent whose wallet already holds the accepted token. Your server returns HTTP 402. The agent recognizes that payment is required. Neither fact establishes that it can parse your offer, construct the required proof, or present evidence your API will accept.

For an API owner comparing x402 vs MPP, the useful decision starts with that exchange. Shared status codes and wallet balances do not make payment integrations interchangeable. Conversely, different exchanges do not force an exclusive choice: a client can implement more than one.

Evaluate the caller and endpoint together, including what happens after payment. A compatible payment path still needs customer authorization, duplicate-charge controls, and a way to recover work when the response disappears.

Identify The Contract Behind The Endpoint

Three objects need separate names before their fields can be compared.

Open Machine Payments Protocol, or MPP, uses an HTTP payment-authentication framework. The Payment HTTP Authentication Scheme draft, draft-httpauth-payment-01, is dated October 26, 2026. It is work in progress, not an adopted RFC. Its core exchange delegates payment-method-specific proof and settlement behavior to separate definitions. Supporting that authentication framework does not establish support for every method offered through it.

x402 protocol v2 over HTTP combines core payment types with an HTTP representation. The x402 v2 specification separates those types from scheme/network logic and transport. A scheme describes payment behavior; a network identifies where the relevant mechanism operates. The HTTP headers are another part of the contract. Knowing one does not establish support for the others.

GOAT Flow's documented MPP Crypto profile is a concrete implementation interface. Its API payment contract uses JSON challenge and verification endpoints, followed by a signed receipt presented to the merchant API. Clients and verifiers must match the deployment. The MPP name does not, by itself, establish conformance to the open draft or compatibility with an arbitrary MPP SDK.

These are comparison objects, not three equivalent standards. Stripe is a provider, Tempo and Base are networks, and GOAT Flow is a commerce product; none of those labels substitutes for an endpoint's payment contract. The open MPP draft does not carry a core wire-version field equivalent to x402's x402Version. Record the draft revision separately, and distinguish it from method versioning when checking implementation support.

For selection, record the transport revision, method or scheme, network and asset, client implementation, endpoint configuration, and application authorization requirements. That record identifies the integration you are evaluating more precisely than either protocol name alone.

Follow The Challenge Through To The Receipt

Read the exchange in both directions. The object announcing a price, the proof returned by the caller, and the evidence accompanying success have different jobs.

In the open MPP draft, required challenge parameters include id, realm, method, intent, and request. The request contains method-specific data serialized using JSON Canonicalization Scheme and encoded as unpadded Base64url. The credential uses the Payment scheme followed by encoded JSON containing the challenge and a method-specific payload; the server must validate the challenge's binding to its payment terms. Optional expiry, digest, opaque correlation data, and credential-header selection have their own rules. The method still determines what payment proof satisfies the request.

In x402's v2 HTTP transport, PAYMENT-REQUIRED carries a PaymentRequired object. Its x402Version identifies v2, and accepts contains payment alternatives. Requirements include scheme, network, amount, asset, payTo, and maxTimeoutSeconds. The client selects a supported requirement and returns a PaymentPayload, including the accepted requirement and scheme-specific payload, in PAYMENT-SIGNATURE. The settlement result travels back in PAYMENT-RESPONSE. A v1 example using X-PAYMENT is not this v2 exchange.

GOAT Flow's Crypto buyer flow starts differently. The challenge request supplies merchant_id, route_canonical, request_canonical, and payer_addr. The buyer saves the challenge ID, MAC, order ID, quoted terms, and expiry. After the transfer, verification submits challenge_id, payer_addr, tx_hash, and mac. A successful verification returns the signed receipt; the buyer then sends it as Payment-Receipt: <body>.<signature>.ed25519 on the protected API request.

That last direction matters. The open draft's response receipt reports a successful payment using fields such as method, timestamp, and reference. GOAT's request receipt is evidence the merchant middleware evaluates before admitting the protected operation. x402's response contains settlement information. A common word, or even a common header name, does not make those objects interchangeable.

Receipt contents also differ. Open MPP's core success receipt includes status, method, timestamp, and reference; it is not defined as GOAT's three-part signed admission token. The x402 settlement response includes success, transaction, and network, with error information for relevant failures. Preserve each object's meaning in your purchase record rather than normalizing all of them to a boolean.

For GOAT, GET:api:data is an example registered route identifier, not a literal resource URL. Prices and recipients come from server-configured route terms, not arbitrary buyer-selected values. Distinct paid operations therefore need explicit configuration and purchase binding, not merely a matching URL string.

Base64 and Base64url are packaging choices, not substitutes for proof verification. Renaming a header cannot supply missing challenge validation, change a payment method, or turn a settlement response into another system's admission credential. Building a GOAT client or verifier from scratch also requires the complete deployment-approved MAC, response, and signed-payload schemas; the visible envelope is not that complete implementation contract.

Locate Settlement And Resource Admission Separately

After identifying the messages, determine which actor can commit payment and which can authorize work. Verification, settlement, and delivery should not collapse into a single "paid" flag.

The x402 v2 core describes several flow models. In its authorization flow, the sequence is verify, execute the resource, settle, then respond. In an upfront flow, settlement precedes resource execution. An escrow flow places settlement steps on both sides of resource execution. A particular scheme and implementation must support the selected model; the existence of these models in the specification does not establish that every SDK or provider implements all of them.

For x402 facilitator operations, /verify is read-only, while /settle commits payment state. The facilitator role can be implemented through an external service, a self-hosted facilitator, or logic integrated into the resource server. Choosing x402 does not require one named hosted provider. It does require deciding who performs those operations and what your application does when that dependency is unavailable.

The ordering changes operational exposure. Executing expensive work before settlement completes differs from requiring payment first and then recovering a failed delivery. Neither ordering eliminates the need to reconcile payment and work. Match the flow to the endpoint's cost and delivery behavior rather than assuming every x402 request follows one sequence.

Open MPP separates its authentication framework from concrete payment methods. Its HTTP example verifies and settles payment before returning the successful resource response, but the method supplies the actual verification and settlement semantics. That example is not a universal chain-finality or response-time guarantee.

For body-bearing requests, the draft recommends digest binding. Its challenge identifier must bind the required terms and relevant optional fields; HMAC is a recommended construction, not the only permitted one. Keep that server challenge binding separate from the payment method's cryptographic proof. Neither should be inferred solely from a method name.

GOAT Flow's documented Crypto profile is a prepayment path: the buyer transfers to the configured merchant recipient; Core verifies payment evidence and issues a receipt; the merchant API verifies that receipt and applies its access checks before returning the resource. Core's payment verification does not take over the API's responsibility for customer access or delivered results.

Cryptographic scope is equally important. For the x402 exact EVM EIP-3009 path, the signed transfer authorization includes from, to, value, validAfter, validBefore, and nonce. Verification checks the signature, payment requirements, token, network, and validity conditions. Those transfer fields do not themselves sign an arbitrary HTTP body, query, or customer identity. Other transfer methods have separate rules.

Likewise, a GOAT route receipt does not automatically bind every request parameter. The application must connect verified payment evidence to the purchase and operation it is about to deliver. Payment verification establishes its defined payment fact, not that the caller owns every resource reachable through the route.

Keep Authentication And Delivery Intact On Retries

Preserve ordinary customer authentication while adding payment. In open MPP draft-01, a challenge can select Payment-Authorization, allowing the caller to retain a Bearer credential in Authorization. If the challenge omits that selection, the Payment credential uses Authorization. A client cannot silently choose a different field and assume the server will interpret it correctly.

Merchant administration is separate again. GOAT's authenticated merchant API uses X-API-Key, X-Timestamp, X-Nonce, and X-Sign with server-side HMAC signing. Those credentials are not the buyer's MPP payment proof and should not be distributed to agent customers to satisfy a challenge.

For protected GOAT routes, authenticate the customer and validate request ownership before payment middleware consumes the receipt. Then check receipt-dependent business conditions before delivering work. Middleware signature, merchant-audience, route, and expiry checks do not establish that a submitted payer address belongs to the authenticated customer. Route matching is not automatic comparison of the current user, query, or body with the purchased operation.

Replay control also has several layers. The open MPP draft requires single-use payment proofs and concurrent at-most-one payment/delivery behavior; those are implementation obligations, not evidence that a particular deployment's storage is atomic. Payment nonce and expiry checks do not replace a durable purchase record or once-only fulfillment logic.

Consider an illustrative paid-report request. The buyer authorizes payment, but a response is lost. First determine which response disappeared: payment verification or the merchant's report response. Those losses require different recovery operations.

For the x402 exact EIP-3009 path, a broadcast transaction whose confirmation cannot be established may produce settlement_pending with its transaction hash. Reconcile that transaction before trying payment again. In GOAT's Crypto profile, 202 pending_inclusion or pending_finality means honoring Retry-After and retrying verification with the original challenge and transaction, not sending another transfer. An expired challenge or already-claimed transaction likewise requires reconciliation; it does not prove no payment occurred.

If payment was verified but the report response disappeared, a consumed receipt is a delivery-recovery problem. GOAT's simple receipt store consumes before the handler runs. A handler failure does not automatically restore that receipt. Use a durable shared store across replicas, retain consumption records through their required lifetime, and recover saved results through authenticated purchase lookup rather than deleting a consumed key.

Verification recovery is bounded too. GOAT can retain a pending challenge through its configured grace period and return a cached receipt for a successful challenge while that receipt remains valid. This does not promise indefinite recovery after replay-store eviction. Before any transfer, an expired unpaid challenge can be replaced; after broadcast, or when the outcome is uncertain, reconcile the original purchase first. Keep the application purchase and delivery records usable even when the payment credential's recovery window has closed.

Even the documented two-phase framework adapter commits non-5xx responses, including a business rejection such as 403. Do not assume every rejection releases a reservation. Design authorization, reservation, result persistence, and recovery together; neither a valid receipt nor a two-phase interface certifies exactly-once external effects.

Filter By Provider, SDK And Actual Cost Scope

With the exchange and recovery obligations clear, SDK and provider choices become concrete constraints.

The x402 reference implementation documents TypeScript packages, Python x402, and Go /v2 support, plus hosted, self-hosted, and integrated facilitator choices. Match the chosen package's mechanisms to the offered requirements. A public testnet quickstart is not an implicit production-mainnet service agreement.

For open MPP, mppx documents TypeScript client/server methods and a CLI. GOAT's deployment-specific middleware example instead targets an approved, matched 1.0.0 build. Obtain the approved package and dependency lockfile for that environment rather than treating an example version or publishing configuration as proof of public-registry availability. These published descriptions are not an attestation of the latest installed releases.

Provider rails have their own scope. As documented on November 3, 2026, Stripe's stablecoin machine-payment table lists MPP with Tempo/USDC.e and Solana/USDC, and x402 with Base/USDC. Stripe's stablecoin activation requires review and approval. Its published US availability excludes New York; businesses outside the US must request access for the supported countries. Those geographical descriptions do not establish approval for a particular account. Card/SPT access has separate conditions. In the same dated documentation, Stripe sets a 0.50 USD minimum for card payments through Shared Payment Tokens (SPTs) and a 0.01 USDC minimum for stablecoin payments. MPP sessions allow sub-cent work increments but retain a 0.01 USDC minimum settlement amount. These are Stripe service minimums, not fees, protocol-wide minimums, or GOAT limits. Check the intended per-call price against the selected method's minimum; sub-cent session usage does not imply sub-cent settlement. These are Stripe service boundaries, not an exhaustive list of either protocol's payment methods. Stripe also documents settlement into its fiat balance, which is not a universal MPP outcome.

Stripe's hosted Tempo fee-payer option has narrower conditions: mppx 0.9.2 or later, live Tempo deposit-address integration, a deposit address and API key belonging to the same account, and no Connect integration for that option. Sponsoring a transaction's fee does not remove the API price or establish zero total cost.

GOAT's profile requires enabled deployment and merchant MPP access, a registered priced route, allowed chain/Token and receiving configuration, a trusted receipt-verification key, and a shared durable store. Adding middleware does not enable the runtime or register the route. Those conditions need target-deployment confirmation, not inference from documentation examples.

For cost comparison, separate the API price, provider or facilitator charges, wallet funding and network fees, merchant service charges where applicable, and integration/recovery operations. Assign each cost to its payer and workload assumptions. Neither these documented interfaces nor a sponsorship feature establishes comparable total costs or latency. Rank prices or speed only with matched commercial terms and measurements, not protocol names.

Choose A Pairing And Set Migration Acceptance

Match The Caller You Need To Serve

Choose x402 v2 HTTP when the intended caller and seller implementation match an offered scheme, mechanism, network, asset, and flow. An x402-only client does not gain open-MPP challenge parsing simply because both endpoints return 402. If the scheme or settlement dependency is unsupported, the integration decision remains unresolved even when the caller has a funded wallet.

Choose an open-MPP implementation when the caller can handle the offered method and intent, the draft revision's challenge rules, and the selected credential field. Confirm the method-specific settlement behavior and provider conditions separately. "Supports MPP" without those details is not enough to select a private, authenticated API route.

For GOAT Flow's documented MPP Crypto profile, use a deployment-matched client and verifier, registered route terms, trusted key distribution, and the application access/recovery design described above. A generic open-MPP receipt parser is not a substitute for that agreement. Conversely, this profile description does not prove a deployment cannot offer another interface; evaluate any additional offer on its own documented contract.

Dual support is a legitimate alternative to forcing all callers onto one exchange. The mppx CLI documentation describes automatic protocol selection that prefers MPP when available, otherwise selects x402, and allows explicit protocol selection. It also documents EVM account reuse for those supported paths. That is evidence of a specific dual-speaking client, not translation between proof formats, guaranteed fallback after a failed charge, or interoperability with GOAT's profile. Account reuse still depends on the supported methods and implementation.

Record What Changes

Before replacing an endpoint's payment path, mark each integration element retained, changed, or unknown. Start with the challenge parser and encoding, proof construction, receipt direction and verification, settlement dependency, authentication headers, purchase/result identifiers, and error handling. Retain something only when the new contract actually preserves it.

A customer account or application purchase ID may remain useful across the change, but the payment evidence attached to it can require a different verifier. A wallet can remain the same while the asset, network, signing method, or funding requirements change. Record those distinctions explicitly instead of treating the migration as an endpoint URL update.

Rollback needs the same precision. Stop advertising a new exchange to new purchases without reassigning an in-flight purchase to the old one. Preserve its chosen protocol, original challenge or order identifiers, transaction evidence, and delivery state. Otherwise, returning traffic to the previous route can accidentally turn recovery of an existing payment into a second purchase.

For an adapter proposal, identify where it parses each offer, validates each proof, preserves the authorized terms, and records settlement and delivery state. Header substitution alone does none of those jobs. Obtain complete approved GOAT schemas and source/package revisions before constructing MACs or a new receipt verifier; do not substitute generic JWT assumptions for the three-part receipt format.

Leave Rollout Blocked Until Evidence Matches

Use the following as acceptance criteria to implement and verify, not as results already achieved by a named deployment.

Assign these checks to the client, payment integration, and API owners. For example, the client owns safe offer selection and preserving payment evidence; the payment integration owns its verification and settlement contract; the API owns customer access, purchase-to-result binding, and recovery of delivered work. The provider or platform operator supplies its account and deployment conditions. A single SDK installation cannot stand in for that combined evidence.

Keep unknowns visible in the migration record. Missing package provenance, an untrusted verification key, unconfirmed merchant enablement, or unresolved recovery behavior should leave the rollout blocked. Documentation can establish which integration to evaluate, but acceptance requires evidence for the actual pairing. Proceed with the matching path once those conditions are satisfied; otherwise retain the existing route or defer the change without creating a replacement payment for an uncertain purchase.