Handle bill payment API rate limits without duplicate orders
Budget requests across catalogue refreshes, purchase workers and status checks, and handle rate-limit responses without blindly repeating payment requests.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
A polling loop that looks harmless with one pending purchase can consume your request budget when many orders are waiting. Plan for catalogue reads, purchases and recovery work to share the available API capacity.
Read the response, then schedule work
The rate-limit reference documents X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Use the values returned by the environment and key you are actually calling. Treat a missing or malformed header as unknown capacity, not as an unlimited allowance.
When a request receives 429, read a valid Retry-After value and delay further attempts appropriately. Set a bounded fallback when the header is absent or invalid, and spread resumed work rather than releasing every queued request at the same instant.
| Work | A practical way to reduce requests |
|---|---|
| Product browsing | Share a bounded server-side catalogue cache |
| Receipt refreshes | Read your saved order state first |
| Pending status checks | Schedule checks per order with a next-check time |
| Webhook processing | Apply verified events to the existing order |
| Reconciliation | Page through a deliberate window and deduplicate records |
Give purchase recovery its own rule
A generic retry helper should not replay every HTTP operation using the same policy. A failed catalogue GET and a purchase whose response was lost have different consequences.
Before retrying an uncertain purchase, use its saved external reference to look up the existing transaction. Keep the local order and reference stable. A 429 response is not a delivery confirmation, and a timeout while reading a response does not prove that no order was created.
Use a shared scheduler or durable queue when several workers use the same key. Reducing each worker's rate independently may still exceed the combined budget. Avoid creating extra keys purely to evade a limit; discuss legitimate capacity needs with the RizPay team.
Preserve room for recovery
Choose a polling interval that your business can sustain when transactions stay pending longer than expected. Prefer webhooks for updates, with a bounded reconciliation process for missed deliveries. Keep operational headroom for support lookups instead of allowing a catalogue refresh to consume all available requests.
Test a short burst of throttled reads, a missing retry header and several workers resuming together. Confirm that the scheduler slows down, pending orders remain visible and no rate-limit handler creates a second local order.
Track throttled requests and the age of unresolved orders together. A lower request count is useful only if customers can still learn what happened to their purchases.