The permitting agent’s payment tool receives HTTP 429 responses from the cashiering service. How should error handling respond?
Select an answer to reveal the explanation.
Short Explanation
A 429 means “slow down,” not “try harder in a tight loop.” Back off, respect the limit, then retry carefully. Pretending the payment cleared is how cashiers and residents get mismatched receipts.
Full Explanation
HTTP 429 from the cashiering service means the permitting agent’s payment tool is being rate-limited. Correct error handling applies backoff and respects retry-after or municipal API guidance instead of hammering the endpoint in a tight loop. Ignoring 429s with immediate duplicate payment attempts risks double submissions; treating rate limiting as payment success lies to residents; permanently disabling fee calculations after one 429 over-reacts to a transient control signal.
Ignoring 429 codes and immediately submitting duplicate payment attempts fails by concept: it both violates rate limits and endangers financial correctness. Disabling all fee calculations permanently after the first 429 converts a temporary throttle into an outage of core permitting capability. Treating rate limiting as success and telling the resident the payment cleared creates false confirmation, reconciliation failures, and trust damage.
Exam caveat: backoff should be combined with idempotency keys so a retried payment intent cannot charge twice when the first request actually succeeded. Surface a honest “payment system busy—retry shortly” message rather than silent looping.
Operational check: force 429 responses from a staging cashiering stub, confirm the tool backs off and honors retry guidance, and verify no success message or duplicate capture occurs until a true 2xx payment response is received.