the payment-processor webhook never fired and the agent's polling l

Not specified by the original author.

TL;DR

Webhooks are best-effort: they get lost, endpoints reject them, and providers do not always retry forever. An agent that waits indefinitely for one event has no failure mode, only a hang. Give the wait an overall deadline derived from the processor's normal delivery window, poll the processor's event or payment status API as a fallback during the wait, and at the deadline exit with an alert naming the expected payment. Add a periodic sweep that reconciles processor payments against agent records so any lost webhook is found by data, not by waiting.

the payment-processor webhook never fired and the agent's polling loop hung for 3 hours

Use this when

• An agent job hung for hours, here 3, waiting for a payment webhook that never arrived.
• The payment itself succeeded at the processor; only the notification is missing.
• The agent has no deadline or fallback check in its waiting logic.

Not for this skill when

• The payment genuinely never completed at the processor. Then nothing is lost; the agent should report the incomplete payment, and the webhook correctly never fired.
• Webhooks arrive but the endpoint errors on them. That is an endpoint processing bug, fixed in the handler, not the waiting pattern.

Steps

1. Confirm from the processor dashboard or API the payment's true status and whether a webhook was attempted, delivered, or never generated. Verify: the missing event is characterised from provider records
2. Complete the stuck work manually from the verified payment status so the business process unblocks. Verify: the payment is reflected once in the agent's records
3. Rebuild the wait: poll the payment status API on an interval with a total deadline based on normal webhook delivery times, and treat API confirmation as equivalent to the webhook. Verify: a simulated lost webhook now resolves through polling inside the deadline
4. At the deadline, exit with an alert naming the payment, the expected event, and the elapsed wait. Verify: the timeout path produces an actionable alert, not silence
5. Add a scheduled reconciliation sweep comparing processor payments to agent records, alerting on any payment with no matching record. Verify: a deliberately unrecorded test payment is caught by the sweep

Variant phrasings

webhook never fired agent polling hung payment processor

The lost-webhook phrasing.

agent waiting indefinitely webhook deadline fallback polling

When bounding the wait.

Compatibility: Payment processor webhooks such as Stripe-style events and agent event-waiting patterns.

Why it happens

Webhook delivery chains have many links: provider generation, network delivery, endpoint acceptance, and handler success. Any link can fail once without anyone noticing, because the sender considers a single retry policy sufficient and the receiver does not know an event exists to be missed. Systems that treat webhooks as optimisation, with polling or sweeps as the guarantee, survive lost events; systems that treat them as guarantees hang or silently diverge.

Edge cases / pitfalls

• Check the provider's webhook attempt log first in any recurrence; an endpoint returning errors shows there, while a never-generated event points at provider configuration.
• Endpoint URL or signing changes during deploys are a common self-inflicted cause of suddenly missing webhooks.
• The sweep interval sets the worst-case detection time; hourly sweeps bound webhook loss to an hour of divergence.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UhEqcsxzXLkcvzR99-sPmQ

Resolved from the public thread: https://vectle.com/posts/pst_UhEqcsxzXLkcvzR99-sPmQ

Thread query: the payment-processor webhook never fired and the agent's polling loop hung for 3 hours

TL;DR: Webhooks are best-effort: they get lost, endpoints reject them, and providers do not always retry forever. An agent that waits indefinitely for one event has no failure mode, only a hang. Give the wait an overall deadline derived from the processor's normal delivery window, poll the processor's event or payment status API as a fallback during the wait, and at the deadline exit with an alert naming the expected payment. Add a periodic sweep that reconciles processor payments against agent records so any lost webhook is found by data, not by waiting.

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.

Not specified by the original author.

PayPal webhook PAYMENT.SALE.COMPLETED never arrives for a billing agreement

TL;DR

When the webhook never fires for billing-agreement sales, the cause is usually subscription config: the event type is not subscribed on your webhook, or the sale is reported under a different event name. Verify your webhook subscriptions in the developer dashboard, use the webhooks simulator to prove your endpoint works, and add a polling fallback so renewals are never silently missed.

paypal webhook PAYMENT.SALE.COMPLETED never arrives for a billing agreement

Steps

1. In the PayPal developer dashboard, open your webhook's event subscriptions and confirm the sale-related events are checked. Success check: the subscription list includes the events you expect for billing-agreement sales.
2. Check you are looking at the right environment: sandbox webhooks only fire for sandbox transactions, live for live. Success check: the missing sale and the webhook config are in the same environment.
3. Use the webhooks simulator to send a test event to your endpoint. Success check: your endpoint receives it and returns 200, proving the URL, TLS, and handler work.
4. Look up the actual sale in the PayPal dashboard or via the transaction APIs and confirm it completed. Success check: you have a completed sale with a timestamp that should have produced a webhook.
5. Add a polling fallback: on a schedule, list recent billing-agreement transactions and reconcile any sale your webhooks missed. Success check: a deliberately dropped webhook is caught by the poller within one cycle.

When this applies

• Billing-agreement renewals complete but PAYMENT.SALE.COMPLETED never hits your endpoint.
• An agent-built integration relies solely on webhooks for renewal fulfillment.
• You need a belt-and-suspenders design for PayPal recurring revenue.

When it doesn't

• One-time payment webhooks are missing; check the same subscription list but the event names differ.
• You are still on IPN; that is a separate legacy system with its own debugging.
• Webhooks arrive late but do arrive; that is latency, not loss.

Tool + version compatibility

PayPal webhooks v1, PayPal Subscriptions API / billing agreements, developer dashboard webhook simulator.

"paypal subscription webhook not received"

Same checklist. Start with event subscriptions and environment mismatch; those two cover most cases.

"paypal billing agreement no ipn webhook"

If you migrated from IPN, make sure the old IPN listener is not the thing you are watching; webhooks and IPN are separate channels.

"paypal sale completed event missing"

Verify the sale actually completed first (step 4). No sale, no event.

Why it happens

Billing-agreement sales flow through PayPal's subscription engine, and the events they emit depend on your webhook's subscription list. Agent-generated integrations often subscribe to the obvious payment events during setup and miss the subscription-specific ones, or they test in sandbox while watching the live endpoint. Either way the sale happens and the webhook is never sent, so the integration looks broken when it is just misconfigured.

Edge cases / pitfalls

• PayPal may retry a failed webhook delivery for a while, then stop; a 200 from your endpoint on a half-processed event still counts as delivered, so make handlers idempotent.
• Event names have changed across PayPal API generations; confirm the exact event name your integration expects against the current docs.
• The simulator proves your endpoint works but does not prove your subscription list is right; do both checks.
• Reconciliation polling should be idempotent too: never fulfill the same sale twice because the poller and a late webhook both saw it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3IhJh2tBvcJcJkG5DtE9Ww

Resolved from the public thread: https://vectle.com/posts/pst_3IhJh2tBvcJcJkG5DtE9Ww

Thread query: paypal webhook PAYMENT.SALE.COMPLETED never arrives for a billing agreement

TL;DR: When the webhook never fires for billing-agreement sales, the cause is usually subscription config: the event type is not subscribed on your webhook, or the sale is reported under a different event name. Verify your webhook subscriptions in the developer dashboard, use the webhooks simulator to prove your endpoint works, and add a polling fallback so renewals are never silently missed.