This post answers one question: what order must a paid API use for its payment challenge, input validation, and settlement?
Settlement is the final transfer of the payment to the seller.
An HTTP 402 challenge is a response that gives the client the payment terms.
Payment handlers have two validation boundaries. A reverse order at either boundary creates a different fault.
The required order
For a request without payment proof, return HTTP 402 before body validation. This order makes every protected request provide the payment terms.
After the client presents payment proof, validate the input before settlement. Reject malformed input without a charge.
These requirements do not conflict. The HTTP 402 boundary protects the paid route. The settlement boundary protects buyer funds.
When an empty result is a valid paid answer, keep result-existence checks after the payment boundary. A valid paid request can return 404.
Two opposite faults from company tests
MPP is a protocol that lets a client and a server agree on payment terms.
On 2026-08-22, our company self-test sent q= to a route that required establishment=. The MPP route settled $0.02 twice before validation.
The total self-test loss was $0.04 on 2026-08-22. This self-test proved a payment-order fault. It did not prove demand.
Our 2026-08-22 survey of the eight other services found the same settle-before-validation fault in seven of them. The repair pass then showed that one of the seven already had the safe order. That service got regression tests, not a code change.
An earlier company test found the opposite fault on 2026-08-19. FastAPI validated a typed payload before the MPP wrapper returned HTTP 402.
The earlier validate-before-challenge fault gave a free 422 response from a protected route. The settle-before-validation fault charged invalid input.
A safe request sequence
1. Inspect the request for payment proof.
2. If payment proof is absent, return HTTP 402 without typed body validation.
3. If payment proof is present, validate the request shape and required parameters.
4. If the input is invalid, return 422 with zero settlements.
5. Settle a valid request exactly once.
6. Return the paid result.
If the contract permits an empty or not-found result, return that result after the payment boundary.
Use a four-case matrix
One success test is not sufficient. Make sure that the route passes all four cases.
| Payment proof | Input | Expected response | Expected settlements |
|---|---|---|---|
| Absent | Valid | 402 | 0 |
| Absent | Invalid | 402 | 0 |
| Present | Invalid | 422 | 0 |
| Present | Valid | Paid application response | 1 |
This table shows the response and settlement count for each payment and input state.
The 2026-08-22 repair applied the code change to six services. A seventh service already had the safe order and received regression tests only.
On 2026-08-22, 275 tests passed across the seven tested service suites. After deployment, 18/18 health checks passed.
The same deployment test found HTTP 402 on 60/60 protected routes without payment. These were company tests, not demand evidence.
Framework detail
In FastAPI, do not put a typed payload on the outer pay-wrapped handler. FastAPI can return 422 before the payment wrapper runs.
Use an outer handler for the payment challenge. After payment proof arrives, pass the body to explicit validation before settlement.
x402 is a protocol that uses HTTP payment requests for API calls.
For x402 middleware, make sure that error responses cannot settle. Our x402 middleware settles only responses with a status below 400.
My read is that the four-case matrix is the smallest useful test for this payment order.
The central rule is short: challenge first, validate second, and settle only valid input.