This page is the seller side: your endpoint gets paid. For the opposite direction — paying an external MPP merchant through the Router — see the MPP rail. Only the wire format is shared.
What the buyer sees
An unpaid request gets an RFC 7235 challenge instead of your content:method="nevermined" is the point. MPP lets a seller register a custom payment method, and paying a Nevermined endpoint is a credit burn against a plan, not a token transfer — so there is no wallet, no signature and no on-chain settlement in the buyer’s half. The access token is the payment instrument.
The three endpoints
Your endpoint does not implement the protocol. It calls three routes, and the backend holds every secret:
A buyer mints their access token at
POST /api/v1/mpp/permissions, the MPP counterpart of the x402 route.
The signing secret never leaves the backend. A challenge cannot be minted at your edge, which is deliberate: it means an integration ships no secret in any binary, and a compromised seller process cannot forge challenges for anyone else.
Minting a challenge
challenge verbatim as your WWW-Authenticate header. It is HMAC-bound, so any edit invalidates it.
Settling
resource and httpVerb must match the values the challenge was issued for. That pair is sealed into the challenge and re-asserted here, so a credential minted for a cheap endpoint cannot be spent at an expensive one on the same plan. A mismatch is refused.
Binding a challenge to one request body
Optional, and off unless you ask for it. Pass adigest when you mint the challenge, and the digest of the body you actually received when you settle:
BCK.MPP.0005 and nothing is burned.
Both must be formatted sha-256=<base64>. A challenge minted without a digest binds no body — that is the seller’s choice at mint time, and not something a buyer can downgrade by omitting bodyDigest.
What the receipt says — and what it deliberately omits
ThePayment-Receipt attests the settlement and nothing else:
Behaviour worth knowing before you integrate
Settling twice burns once. The challenge id is the burn’s idempotency key, so a retried settle is absorbed and returns success without moving credits again. That is what makes a settle safe to retry when the response is lost. A failed settle leaves the credential spendable. Nothing is consumed and no receipt is minted, so the buyer is never charged for a request you could not serve. Every challenge is unique. Two identical requests produce two distinct challenges. Since the id doubles as the settlement id, sharing one would collapse two payments into a single burn. Credits are protocol-independent. The same request burns the same credits whether it was paid over MPP or x402 — the two protocols share one meter and one delegation budget.Protocol isolation
An MPP access token and an x402 one are byte-identical on the wire. What separates them is the EIP-712 domain they are signed under, and that is fixed by the endpoint that minted them — it is not a value a caller can select. The consequence is the property the design exists for: a token minted for MPP is refused by the x402 routes, and an x402 token is refused by the MPP routes. Posting a token to the wrong family of routes fails closed.Operator configuration
MPP needs two deployment values, set where your other secrets live — never in application code:
When either value is missing, the MPP routes answer
BCK.MPP.0002 and the rest of the API is unaffected — a missing value degrades one protocol instead of causing an outage.
Environments
Current scope
MPP support is the Nevermined custom method — a buyer pays with a Nevermined delegation, framed as MPP. Not yet supported:- Stock MPP clients paying with native
evmorstripemethods - Sessions, subscriptions and metered streams — a challenge advertising one is refused rather than approximated
- MPP over MCP or A2A transports