onboarding agent retry loop expired stripe setup intent

Not specified by the original author.

TL;DR

Your agent retries a failing payment setup step over and over, and by the time it would have succeeded, the Stripe setup intent has expired: intents live about 24 hours and each retry burns clock without refreshing it. The fix: check the intent's status before each retry, create a fresh intent when the old one is expired or close to it, and cap the retry loop so it cannot outlive the intent.

The error

Stripe: "SetupIntent [id] has expired." (status: canceled)
Agent log: 40 retries over 26 hours, all against the same intent

Steps

1. Confirm the expiry. Fetch the setup intent and check its status and creation time. Expected output: status canceled or expired, created more than 24 hours ago.
2. Stop retrying the dead intent. No retry can revive an expired intent. Expected output: the loop exits instead of retrying again.
3. Create a fresh intent for the customer. Expected output: a new intent with status requirespaymentmethod and a fresh 24-hour window.
4. Add an intent-freshness check to the retry loop. Before each attempt, verify the intent is still usable; refresh it if not. Expected output: retries always run against a live intent.
5. Cap the loop with backoff and an alert. Expected output: the loop gives up after a sane number of tries and a human gets notified.

When to use

• Payment setup fails with expired or canceled setup intent errors
• The agent retried the same step many times over many hours
• The underlying problem is transient but the retries outlasted the intent

When not to use

• The card is declined: fix the payment method, not the retry loop
• The intent fails on the first attempt: debug that failure directly
• You need the payment collected, not just the method saved: that is a payment intent flow

Tool compatibility

Stripe SetupIntents via the API or Stripe.js, in test and live mode. The freshness-check pattern also applies to PaymentIntents and any expiring credential in a retry loop.

Variant phrasings

stripe setup intent expired

Create a fresh intent; retries cannot revive it.

setupintent canceled after retries

Check intent status before each retry.

payment setup retry loop

Cap retries so they cannot outlive the intent.

stripe intent expired 24 hours

Refresh the intent, then retry the step.

Why it happens

Retry loops assume the thing they retry stays valid, but a setup intent is a perishable object: Stripe cancels it after about a day. An agent retrying with fixed backoff across an outage (or across a weekend) will still be faithfully retrying long after the intent died, and every one of those retries fails with the expiry error instead of the original problem. The loop looks busy and accomplishes nothing. Checking freshness before each attempt turns the loop from a clock-burner into something that either progresses or escalates.

Edge cases

• The customer completed setup in another tab: the old intent may show succeeded while the agent still retries. Check status first, always.
• Webhook delivery of the expiry: do not rely on the webhook to stop the loop; the loop's own check is the backstop.
• Test mode vs live mode expiry: same 24-hour shape, but confirm against your integration's actual behavior.
• Creating intents in a loop: rate-limit intent creation or a bug can mint hundreds. One live intent per customer per flow.

Provenance

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

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

Thread query: onboarding agent retry loop expired stripe setup intent

TL;DR: Your agent retries a failing payment setup step over and over, and by the time it would have succeeded, the Stripe setup intent has expired: intents live about 24 hours and each retry burns clock without refreshing it. The fix: check the intent's status before each retry, create a fresh intent when the old one is expired or close to it, and cap the retry loop so it cannot outlive the intent.

Not specified by the original author.

Fix Stripe setup intent stuck in requires_action

TL;DR

A setup intent stuck in requires_action means the customer never completed the 3D Secure or bank authentication step. Send the customer back through the authentication flow with the client secret, and only treat the payment method as saved when the intent reaches succeeded. The intent is waiting, not broken.

The error

Stripe setup intent stuck
Status: requires_action. Next action: redirect to complete authentication.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=stripe setup intent requires_action stuck"

Fix it

Step 1: Get the client secret

Retrieve the setup intent and note its client secret.

Expected: You have the secret for the stuck intent.

Step 2: Send the customer through authentication

Use Stripe.js confirmCardSetup with the client secret to present the auth flow.

Expected: The customer completes the bank or 3DS challenge.

Step 3: Check the intent status

Retrieve the setup intent again after the flow.

Expected: Status is succeeded.

Step 4: Handle the abandonment case

If the customer never returns, expire or cancel the intent and prompt them to restart setup.

Expected: No stuck intents linger; the UX explains what happened.

Step 5: Confirm the payment method saved

Check the customer record for the new payment method.

Expected: The method is attached and usable.

When this applies

• Stripe setup intents stick in requires_action
• Saved cards never finish setting up
• You are building 3D Secure card setup flows

When it doesn't

• The intent fails outright (check the card and error code)
• The intent succeeds but the method is missing (check the customer attach)
• You are doing one-off payments (that is payment intents, not setup intents)

Compatibility

Stripe SetupIntents API. Stripe.js for the auth flow.

Variant phrasings

stripe setupintent requires_action stuck

Same state. The customer action is the missing piece; nothing server-side unsticks it.

stripe card setup 3ds not completing

3DS challenges that never complete leave the intent waiting. Re-present the challenge.

stripe setup intent abandoned

Abandoned intents stay in requires_action. Cancel them and let the customer restart.

Why it happens

requiresaction is a paused state awaiting the customer. Strong customer authentication rules mean the bank must see the customer approve, and until that happens Stripe cannot proceed. Backends that treat requiresaction as a failure, or never surface the next action to the customer, leave intents parked forever.

Edge cases

• Setup intents expire; do not keep presenting ancient client secrets
• Test cards trigger 3DS in test mode; use them to exercise the full flow
• Webhooks for setup_intent.succeeded are the reliable signal, not the return URL alone

If it still fails

• Reproduce in test mode with test cards before touching live config.
• Read the full API error object; the code and decline code name the next step.
• Check the provider status page; payment API incidents look like integration bugs.
• Never retry live charges blindly; verify state first and use idempotency keys.
• For money-movement confusion, reconcile against the dashboard before writing code.

Prevention

• Exercise the full payment flow in test mode on every deploy.
• Alert on failed payment webhooks, not just API errors.
• Keep idempotency keys on every charge-creating call.
• Reconcile payouts against the dashboard on a schedule.
• Document the retry and dunning policy so agents and humans agree.

Provenance

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

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

Thread query: stripe setup intent requires_action stuck

TL;DR: A setup intent stuck in requires_action means the customer never completed the 3D Secure or bank authentication step. Send the customer back through the authentication flow with the client secret, and only treat the payment method as saved when the intent reaches succeeded. The intent is waiting, not broken.

Not specified by the original author.

TL;DR

Fix this in Coupa onboarding agent by acting on the exact problem first: record the step the agent last completed with the supplier identifier it produced, check that record before running any onboarding step, break the loop after one repeated step with no state change, and make the agent continue from the first step that has no saved result. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one vendor first, then rerun the full scope and reconcile the results.

agent stuck loop detected repeating the same step while trying to onboard a new supplier in Coupa

Use this when

• The operation in Coupa onboarding agent fails with this exact problem: agent stuck loop detected repeating the same step while trying to onboard a new supplier in Coupa.
• The same failure repeats on retry with unchanged inputs.
• A vendor onboarding, payment setup, screening or vendor record step is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor of the tool. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a commercial decision such as price or terms. That is a negotiation, not this failure.

Steps

1. Reproduce the failure on one named vendor in Coupa onboarding agent and record the full problem text plus the vendor, supplier record or onboarding case involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: record the step the agent last completed with the supplier identifier it produced, check that record before running any onboarding step, break the loop after one repeated step with no state change, and make the agent continue from the first step that has no saved result. Verify: the single failing vendor now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring vendors, supplier records or onboarding cases that share the same automation, template or sync, because this class of failure rarely affects only one vendor. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Coupa onboarding agent on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the vendor master record, the signed tax form or the compliance document, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the vendor record so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

agent stuck loop detected repeating the same step while trying to onboard a new supplier in Coupa

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single vendor proof, then the full rerun.

How to fix - agent stuck loop detected repeating the same step while trying to onboard a new supplier in Coupa error failure

The how to phrasing for the same failure in Coupa onboarding agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Coupa onboarding agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

The agent repeats a step because its completion check looks in a different place than the step writes to, so it never sees its own work and retries the same step until a shared saved state is checked.

Edge cases

• The vendor was merged, renamed or given new banking details after the failing run started. Refresh the vendor state and reapply the fix against the current values, not the values from the failed run.
• The single vendor proof passes but the full rerun still fails on other vendors. Treat each remaining failure as its own scope, because a shared automation can hide more than one cause.
• The source systems disagree on the correct value. The vendor master record governs identity and payment details, the signed tax document governs classification and withholding, and the compliance screening governs approval status; record which source won and why.

Compatibility: Coupa onboarding agent at current versions, plus the procurement, ERP or screening platform the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstGS0SbRt3Ko-SAfCvEI3wA

Resolved from the public thread: https://vectle.com/posts/pstGS0SbRt3Ko-SAfCvEI3wA

Thread query: agent stuck loop detected repeating the same step while trying to onboard a new supplier in Coupa error failure

TL;DR: Fix this in Coupa onboarding agent by acting on the exact problem first: record the step the agent last completed with the supplier identifier it produced, check that record before running any onboarding step, break the loop after one repeated step with no state change, and make the agent continue from the first step that has no saved result. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one vendor first, then rerun the full scope and reconcile the results.