One endpoint, two answers, decided by the PAYMENT-SIGNATURE header. Without one: a 402 whose PAYMENT-REQUIRED header quotes the full outstanding amount — an authorization for less than what is owed is refused, and the remedy is a new 402 for the whole balance. With one: verify, settle, and answer 200 naming the payment intent the settlement created.
A payable's price is held in a quote row for a short window together with the exact rails it offered, which is what the 409 and 410 are about.
Path Parameters
Value in
- "invoice"
- "link"
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/x402/payables/invoice/string"{ "paymentIntent": "string", "payable": { "kind": "invoice", "id": "string" }}Every listed obligation an agent can pay
Invoices with an outstanding balance and fixed-amount payment links, across every merchant, newest first — what an agent reads before it has met anyone. Each entry carries the price a `402` would actually quote, so a reader deciding whether to pay need not ask each one. Draft, void and paid-in-full invoices, disabled and expired links, and open-amount links never appear and never quote, listed or not.
Which rail to pay on, and why
The ordering inside a `402` already carries the answer, but an agent reading `accepts[0]` cannot see what the order was based on. This is that reasoning in the open: median headroom, how many settlements it is over, and whether the choice was a choice at all. _Headroom_ is the seconds an order had left before its deadline when it landed. `unobserved: true` means no rail had enough observations and the first accepted rail was taken.