Handling 402, 429 and 422 from a verification API cleanly
The three status codes you will actually hit in production, what each means, and the right client behaviour for each.
402, top up needed
A 402 means your prepaid balance cannot cover the call. In production this should never surprise you: watch the balance, alert at a threshold, and auto-pause non-critical batch jobs before it hits zero so real-time onboarding keeps working.
On the client, a 402 for a real-time check is a "try again in a moment" for the user while operations top up, not an error to show them.
429, slow down
A 429 carries a retry-after. Respect it. Implement exponential back-off with jitter for batch work, and a short bounded retry for real-time. If you see sustained 429s in real-time flows, your concurrency is too high for your plan: fix the config, do not just retry harder.
422, bad input or unverifiable
A 422 splits two ways: your parameters were malformed (fix your code) or the identifier is structurally fine but could not be verified (invalid PAN, cancelled GSTIN). The response body tells you which. Malformed-input 422s should be caught in testing; unverifiable 422s are a user-facing decline.