application/problem+json on 402, the buyer attaches a crypto credential (challenge-bound signed transaction), and a facilitator broadcasts settlement and returns a signature the seller records on the receipt.
Use MPP when you want RFC 7807-shaped errors, body-carried challenges (instead of x402 PAYMENT-* headers), or a separate settle round-trip to your facilitator.
How Leash detects the rail
@leashmarket/core classifies the unpaid 402 via detectProtocol: x402 carries the offer in PAYMENT-REQUIRED; MPP carries it in application/problem+json with type: "https://paymentauth.org/problems/payment-required" and a challengeId.
@leashmarket/buyer-kit runs this automatically — a single buyer.fetch(url, init) can settle either rail.
Seller surfaces
| Surface | x402 | MPP |
|---|---|---|
@leashmarket/seller-kit | createSeller + @x402/hono | createMppSeller (Hono), challenge issuance + credential verify + facilitator client |
| Hosted payment links | Default protocol: "x402" on POST /v1/payment-links | Set "protocol": "mpp" — see Payment links |
| Runner endpoints | EndpointV1 default payment_protocol: "x402" | payment_protocol: "mpp" on the stored descriptor |
POST /mpp/settle facilitator step instead of wiring through an x402 PAYMENT-RESPONSE header.
Receipts
MPP settlements produceReceiptV02 with v: "0.2" and protocol: "mpp" (see Receipt V2 schema): fields such as mpp_challenge_id, mpp_settlement_tx, and optional tx_sig mirror the on-chain proof. Legacy ReceiptV1 remains valid for historical x402-only traffic — use parseReceiptAny / receiptProtocol in @leashmarket/schemas when ingesting mixed feeds.
Facilitators
Your facilitator must exposePOST /mpp/settle compatible with Leash’s MPP client. x402 HTTPS facilitators are not drop-in substitutes for MPP settle — configure both when you run dual-protocol traffic. See Run a facilitator.
See also
- Payment links —
protocolfield on create/update - Receipt concept — v0.1 vs v0.2
@leashmarket/mcp-core—leash_pay_payment_linkandleash_create_payment_link(protocoloption)
