One endpoint can accept either MPP or x402. For example, GET /api/report sells a report for 0.01 USDC. An unpaid request receives both payment choices. The buyer chooses one, submits its payment credential to the same URL, and receives the report after that payment succeeds.

The Node.js example below composes the existing Express adapters for a fixed-price GET request. Keep the Seller client configuration from Accept MPP and Accept x402: options contains your Sandbox environment and Seller API key; secretKey is the MPP challenge-signing secret. The x402 route advertises 0.01 USDC using the balance scheme, with its matching facilitator and registrations. Use one Express app.

Set resourceUrl to the full public URL of this report endpoint. Keep the same MPP method, realm, and secret for challenge generation and credential verification. Run application authentication and input checks before this route. This example is application wiring, not a combined-protocol SDK helper.

import { Mppx } from 'mppx/express';
import { Mppx as MppxServer } from 'mppx/server';
import { inflow, paymentHttpTransport } from '@inflowpayai/mpp-seller';
import { paymentMiddlewareFromConfig } from '@x402/express';
import type { RequestHandler } from 'express';

const method = inflow(options);
const realm = 'report-service';
const payments = Mppx.create({
  methods: [method], realm, secretKey, transport: paymentHttpTransport(),
});
const challenges = MppxServer.create({
  methods: [method], realm, secretKey, transport: paymentHttpTransport(),
});
const terms = {amount: '0.01', currency: 'USDC'};
const mppPayment = payments.charge(terms);
const mppChallenge = challenges.charge(terms);
const x402Payment = paymentMiddlewareFromConfig(
  {'GET /api/report': route}, [facilitator], registrations,
);
const report: RequestHandler = (_request, response) => {
  response.set('Cache-Control', 'no-store');
  response.json({report: 'Your sample report is ready.'});
};

app.get('/api/report', async (request, response, next) => {
  response.set('Cache-Control', 'no-store');
  const authorization = request.get('Authorization') ?? '';
  const hasMpp = /^Payment(?:\s|$)/i.test(authorization);
  const hasX402 = request.get('Payment-Signature') !== undefined
    || request.get('X-Payment') !== undefined;
  const duplicate = ['authorization', 'payment-signature', 'x-payment']
    .some(name => (request.headersDistinct[name]?.length ?? 0) > 1);
  if (duplicate || (hasMpp && hasX402)
    || (request.get('Payment-Signature') !== undefined
      && request.get('X-Payment') !== undefined)) {
    response.status(400).json({error: 'Send one payment credential.'});
    return;
  }
  if (hasMpp) return mppPayment(request, response, next);
  if (hasX402) return x402Payment(request, response, next);

  const unpaid = await mppChallenge(new Request(resourceUrl));
  if (unpaid.status !== 402) throw new Error('Expected an MPP challenge.');
  const challenge = unpaid.challenge;
  if (challenge.status !== 402) {
    challenge.headers.forEach((value, name) => response.set(name, value));
    response.status(challenge.status).send(await challenge.text());
    return;
  }
  const header = challenge.headers.get('WWW-Authenticate');
  if (header === null) throw new Error('Missing MPP challenge header.');
  response.append('WWW-Authenticate', header);
  return x402Payment(request, response, next);
}, report);

Without a payment credential, the MPP handler builds a challenge and the x402 adapter produces the 402 response, retaining the MPP header. With a credential, only the selected adapter runs. Keep response.json so the MPP Express adapter can attach its receipt. Do not also register the x402 middleware globally for this route.

Keep the setup guides’ startup checks and Express error handling. Other languages need the same request selection and combined unpaid response; the four-language examples below show the alternative with separate endpoints, not a shared combined-adapter API.

Advertising both protocols puts both sets of payment terms in one HTTP response. More methods, currencies, networks, and longer descriptions can increase the headers enough to exceed a web server, reverse proxy, or client limit. The application may generate a valid 402 response while the buyer receives a proxy error instead.

Check the unpaid response through the same public hostname and proxy path that buyers use. If it fails there but succeeds directly against the application, inspect the proxy logs for an oversized upstream response header. For example, NGINX can report upstream sent too big header and return 502. Its proxy_buffer_size setting controls the buffer that normally holds the upstream response headers.

Response-header limits are separate from limits on incoming request headers. Raising a request-header limit does not fix an oversized 402 response. Check the components you actually deploy; there is no single header-size budget that every deployment shares.

You can keep one endpoint by advertising only the payment options your product needs and configuring adequate response-header capacity. If that is impractical, expose separate MPP and x402 endpoints for the same product. Each then advertises only its own protocol’s choices. Test those responses too: a long list of options can exceed a limit even with one protocol.

Separate endpoints are an alternative when combined response headers are too large for your deployment. Both routes below sell the same report for 0.01 USDC and call shared report-generation code. The buyer chooses one URL and makes one purchase.

These routing fragments replace the report route registration in the two setup guides. Keep their client initialization, configuration checks, and server lifetime management. The shared report code only generates a response; it does not create an order or perform another irreversible operation.

report := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Cache-Control", "no-store")
    w.Header().Set("Content-Type", "application/json")
    fmt.Fprintln(w, `{"report":"Your sample report is ready."}`)
})
opaque := base64.RawURLEncoding.EncodeToString([]byte("GET /api/mpp/report"))
mppPaid, err := mppClient.Protect(mppseller.Route{
    Realm: "report-service", SecretKey: secret,
    Offers: []mppseller.Offer{{Charge: &mpp.ChargeRequest{
        Amount: "0.01", Currency: "USDC",
    }}},
    Opaque: &opaque,
}, report)
if err != nil {
    return nil, err
}
resource := xhttp.Newx402HTTPResourceServer(
    xhttp.RoutesConfig{"GET /api/x402/report": route},
    foundation.WithFacilitatorClient(facilitator),
)
for _, registration := range registrations {
    resource.Register(registration.Network, registration.Server)
}
if err := resource.Initialize(ctx); err != nil {
    return nil, err
}
mux := http.NewServeMux()
mux.Handle("GET /api/mpp/report", mppPaid)
mux.Handle("GET /api/x402/report",
    nethttp.PaymentMiddlewareFromHTTPServer(resource,
        nethttp.WithSyncFacilitatorOnStart(false))(report))

const report: RequestHandler = (_request, response) => {
  response.set('Cache-Control', 'no-store');
  response.json({ report: 'Your sample report is ready.' });
};

app.use(paymentMiddlewareFromConfig(
  { 'GET /api/x402/report': route },
  [facilitator],
  registrations,
));
app.get('/api/mpp/report',
  payments.charge({ amount: '0.01', currency: 'USDC' }),
  report,
);
app.get('/api/x402/report', report);

def report_data() -> dict[str, str]:
    return {"report": "Your sample report is ready."}


app.middleware("http")(
    payment_middleware({"GET /api/x402/report": route}, resource)
)
terms = mpp_seller.charge_request({"amount": "0.01", "currency": "USDC"})


@app.get("/api/mpp/report")
@pay(
    intent=mpp_seller, method=mpp_seller.method, request=terms,
    realm="report-service", secret_key=secret,
)
async def mpp_report(
    request: Request, credential: Credential, receipt: Receipt,
) -> JSONResponse:
    return JSONResponse(report_data(), headers={
        "Payment-Receipt": receipt.to_payment_receipt(),
        "Cache-Control": "no-store",
    })


@app.get("/api/x402/report")
async def x402_report() -> JSONResponse:
    return JSONResponse(report_data(), headers={"Cache-Control": "no-store"})

use axum::{Json, Router, routing::get};
use inflow_mpp_seller::Offer;
use inflow_x402_axum::PaymentLayer;
use serde_json::json;

fn report_data() -> serde_json::Value {
    json!({"report": "Your sample report is ready."})
}

pub fn report_router(offer: Offer, layer: PaymentLayer) -> Router {
    let mpp_routes = Router::new()
        .route("/api/mpp/report", get(mpp_report))
        .with_state(offer);
    let x402_routes = Router::new().route(
        "/api/x402/report",
        get(|| async {
            (
                [("cache-control", "no-store")],
                Json(report_data()),
            )
        }).route_layer(layer),
    );
    mpp_routes.merge(x402_routes)
}

On a combined endpoint, select the payment integration from the submitted credential. With separate endpoints, select it from the route. Keep free endpoints outside both payment integrations.

Compose the adapters as alternatives, as in the combined example above. Simply running the two standalone middleware functions in sequence does not advertise both choices: the first can finish an unpaid request before the second runs. A paid request must not then face a second payment requirement.

Do not automatically retry a purchase through the other protocol after a payment failure. A timeout can leave the first payment’s outcome unknown. Resolve that outcome before inviting another payment, even if the other route is available.

Keep the product, quantity rules, and price in your application. Both protocol integrations should use those same decisions. Convert the price separately through each protocol’s helper, as described in Prices and offers.

• Configure both integrations for the intended seller and environment. Two integrations in one application do not automatically share payment configuration.
• Run your application’s authentication, authorization, and input checks before accepting payment. A valid payment is not permission to access another customer’s report.
• Share the code that produces the purchased result. Keep payment credentials and receipt handling in the selected protocol’s integration.
• Preserve the payment-result headers and prevent shared caches from serving paid responses to other buyers. The examples use Cache-Control: no-store for report responses.

For an order that can be paid through either protocol, use the same application purchase reference. Check whether that purchase is already paid or being processed. Independent payment identifiers do not prevent two separate requests from purchasing or fulfilling the same order twice.

The integrations on these setup pages do not run payment and application code in the same order.

A read-only report function can serve both paths. Creating an order, shipping goods, or granting a lasting entitlement needs a separate delivery decision. Choose when that work becomes final and how a buyer recovers a paid result after a failed response. See Deliver paid results.

Test both payment choices, then check that the integrations do not interfere with each other. Retain your project’s tests for permissions, pricing, delivery, and retries.

• Request the combined endpoint without payment. Confirm one 402 response with both protocols’ payment terms and no paid report. If using separate endpoints, confirm that each advertises only its own terms. Repeat through the public proxy path to catch header-size limits.
• Complete one controlled Sandbox purchase through each protocol. Check the amount, seller, result, and protocol-specific payment receipt or response. Confirm that the other payment integration did not execute.
• Submit an invalid credential for each protocol. On the combined endpoint, also send both credentials or duplicate payment headers. Confirm rejection without returning the report or trying another payment path.
• Test failed settlement, a lost response, and a repeated purchase request. Confirm that an uncertain outcome does not create a second payment through the other route.
• Request a free endpoint and an unknown path. Confirm that the free endpoint remains free and the unknown path does not become a paid route.
• If both protocols can pay for one order, test simultaneous requests against that order. Confirm that your application prevents duplicate fulfillment across protocols.

Use the payment commands from Accept MPP and Accept x402, with the same URL for a combined endpoint, or the corresponding URL for separate endpoints. Execute payment tests only with approval for the test account, amount, and environment.