Payment handlers have two validation boundaries. Reversing 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
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 first fault gave a free 422 response from a protected route. The second 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 |
The 2026-08-22 repair applied this rule to seven services. The repair used no real payment.
On 2026-08-22, 275 tests passed across the seven repaired 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.
For x402 middleware, make sure that error responses cannot settle. Our x402 middleware settles only responses with a status below 400.
The central rule is short: challenge first, validate second, and settle only valid input.