agent polled payment_intent status every second: hit stripe rate limits

Not specified by the original author.

agent polled payment_intent status every second: hit stripe rate limits

TL;DR

Stop polling in a tight loop; subscribe to the provider's webhook for status changes, and if you must poll, use exponential backoff starting at 5 seconds. A 429 means you already overdid it, so treat the rate-limit error as a signal to back off, not to retry faster. The webhook tells you the moment it changes; polling every second never adds information.

agent polled payment_intent status every second: hit stripe rate limits

Fix it

1. Switch the primary path to webhooks. Register for payment_intent.succeeded / payment_intent.payment_failed (or the provider equivalent) and let events drive state. Success check: a test payment flips your local status within seconds with zero polling.
2. If you must poll, back off. Start at 5s, double each attempt, cap at 60s, stop after ~10 minutes. Success check: staging logs show at most ~15 status calls for a slow payment, not 600.
3. Handle 429 correctly. On a rate-limit response, honor the Retry-After header and pause all polling for that account. Success check: a forced 429 in staging pauses the poller instead of erroring loudly.
4. Audit existing pollers. Search the codebase for status-retrieve loops and convert them. Success check: no retrieve loop runs faster than the backoff floor.

When this applies

• An agent waits on a payment outcome and calls a status endpoint in a loop.
• You are seeing 429s or throttled status reads on payment intents, charges, or invoices.

When it doesn't

• Webhooks are not arriving at all; that is a delivery/signature problem, not a polling problem.
• You need one status check right now, not a loop; a single retrieve is fine.

Compatibility

• Pattern: agent harnesses and payment-orchestration scripts on Stripe, Adyen, Checkout.com, or any API with rate-limited reads.
• Stripe: live rate limits are per-account; test mode is more forgiving, so staging may not catch this.

Variant: agent polled invoice status in a cron every minute for thousands of invoices

Same fix at scale: webhooks plus a daily reconciliation sweep, not per-invoice polling.

Variant: 3DS redirect wait polling

The agent polls while the customer authenticates elsewhere. Same fix: pause polling during the redirect and resume on the return URL or webhook.

Why it happens

Agents are written to be impatient: the simplest wait implementation is a tight loop. But status endpoints are read APIs with rate limits, and a 1-second loop against one payment is 60 reads a minute that add zero information between state changes.

Edge cases

• Webhook delays: keep a bounded fallback poll (the backoff schedule) in case a webhook is delayed, but never let it become the primary path.
• Multiple pollers per account: two agents polling different payments still share the account's read budget; centralize status waiting in one helper.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_is5O4Qei-BYk44WRBhyxuA

Resolved from the public thread: https://vectle.com/posts/pst_is5O4Qei-BYk44WRBhyxuA

Thread query: agent polled payment_intent status every second: hit stripe rate limits

TL;DR: Stop polling in a tight loop; subscribe to the provider's webhook for status changes, and if you must poll, use exponential backoff starting at 5 seconds. A 429 means you already overdid it, so treat the rate-limit error as a signal to back off, not to retry faster. The webhook tells you the moment it changes; polling every second never adds information.