The one that moves money: verifies authoritatively, broadcasts the transfer, confirms it on-chain, and posts the double-entry records that credit the merchant. The payment's nonce is the idempotency key server-side, so a second settle of the same authorization is refused rather than charged twice. An authorization that was valid but did not settle answers 200 with success: false and the reason in errorReason.
Path Parameters
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/x402/resources/string/settle" \ -H "Content-Type: application/json" \ -d '{ "x402Version": 2, "paymentPayload": { "x402Version": 0, "accepted": { "scheme": "string", "network": "string", "amount": "string", "asset": "string", "payTo": "string", "maxTimeoutSeconds": 0 }, "payload": { "signature": "string", "authorization": { "from": "string", "to": "string", "value": "string", "validAfter": "string", "validBefore": "string", "nonce": "string" } } }, "paymentRequirements": { "scheme": "string", "network": "string", "amount": "string", "asset": "string", "payTo": "string", "maxTimeoutSeconds": 0 } }'{ "success": true, "errorReason": "string", "payer": "string", "transaction": "string", "network": "string", "amount": "string", "extensions": { "property1": null, "property2": null }}Would this authorization go through?
Checks the signature against the chain without broadcasting. The body's `paymentRequirements` is not what gets verified — Mayarin rebuilds the requirements from the resource and uses the carried copy only to identify which quoted option the payer chose. A facilitator that verified against the requirements handed to it would verify a payment against its own claims.
Deployment health probe
Intentionally unversioned. Stays at the root forever.