Settles the given invoice. How it settles is chosen by the X-Adaptyv-Payment-Method request header:

The payment rail is pinned when the experiment is created, and an explicit X-Adaptyv-Payment-Method cannot switch it: a header naming a rail other than the pinned one is rejected with 409 — retry with the pinned rail. Header-less discovery is the deliberate exception: a caller with a machine payment policy is offered every machine rail this deployment serves and commits by sending one rail's credential, which may be a machine rail other than the pinned one (they share a Stripe account, so the pin has already decided everything it decides). Omitting the header is therefore not a way to reach the pinned rail, and a caller with no machine policy falls through to the hosted invoice — which on a crypto-pinned quote is the absent-header 409 in the table above.

This is the only endpoint that settles an invoice. The flow is two steps: POST /quotes/{quote_id}/confirm issues the invoice and returns a payment pointer to this route, then POST /invoices/{invoice_id}/pay settles it.

Send the first call with the method header and no credential. It answers 402, and the challenge is carried in the response headers, not the body — PAYMENT-REQUIRED for x402-exact, WWW-Authenticate for mpp-spt.

That challenge is the whole handshake: it carries every parameter needed to produce the credential — for mpp-spt, the amount, currency, seller-network id, expiry, and accepted payment-method types to mint the shared payment token against. There is no separate endpoint to fetch them from, and there cannot usefully be one: the credential must echo the challenge it answers, so parameters obtained without taking a 402 cannot be settled here.

Both mpp-spt and x402-exact settle over the API directly with these headers; the MCP server's pay_invoice tool is one client of this route, not the only way to reach the rail.

Repeat the call with the signed credential to settle — PAYMENT-SIGNATURE for x402-exact, Authorization for mpp-spt — and the response is 200 with the paid invoice. Repeating it again is safe: an invoice that is already paid answers 200 with already_paid: true and settles nothing.

When the settlement can be named, the response carries settlement_reference. Treat it as optional even on a settling response.

The payment.methods array on the confirm response lists the methods this environment accepts; a value outside that list is rejected with 400.

{
  "hosted_invoice_url": "https://invoice.stripe.com/i/acct_1234/test_5678",
  "id": "in_1OqLk2LkdIwHu7ix6OboRpXl",
  "settlement_reference": {
    "tx_hash": "0x9c2f1a7e5b0d4c3a8f6e2d1b0a9c8f7e6d5c4b3a29180f7e6d5c4b3a29180f7e"
  }
}