# Fix setup agent re-running a failed Stripe checkout in an infinite loop

## TL;DR
The agent loops on the failed checkout because it retries the same payment without classifying the failure. Stop the loop, classify the Stripe error, and only retry transient failures with backoff. Card declines need the customer, not another attempt.

## The error
```text
Setup agent failed
Re-running failed Stripe checkout in an infinite loop. Same payment intent retried hundreds of times.
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=setup agent failed re-running failed stripe checkout in an infinite loop"
```

## Fix it

### Step 1: Halt the checkout loop

```bash
Pause the setup agent.
```

Expected: Retries stop.

### Step 2: Read the Stripe error

```bash
Retrieve the payment intent and read the last error code and type.
```

Expected: You know whether it is transient or terminal.

### Step 3: Classify before retrying

```bash
Retry only transient errors with backoff; route card errors to the customer.
```

Expected: Each failure type gets the right response.

### Step 4: Add a retry cap

```bash
Hard-cap retries per checkout and alert on exhaustion.
```

Expected: No checkout retries forever.

### Step 5: Resume and verify

```bash
Resume the agent and simulate a failed checkout.
```

Expected: It retries bounded times or routes to the customer correctly.

## When this applies

- Agents loop on failed Stripe checkouts
- Checkout retries never stop
- You are building checkout agents

## When it doesn't

- The checkout API call is malformed (fix the call)
- Checkouts fail for all customers (check the Stripe config)
- You need dunning (that is a billing flow concern)

## Compatibility

Stripe payment intents and checkout. Agent retry logic.

## Variant phrasings

### agent infinite loop stripe checkout

Same loop. Classification plus caps breaks it.

### stripe checkout retry forever agent

Forever retries are always a bug. Bound them.

### setup agent retrying failed payment

Failed payments need triage, not blind retries.

## Why it happens

Stripe errors split into transient (network, 429) and terminal (card declined, invalid request). Agents that retry everything identically loop forever on terminal errors. The retry policy must read the error type first.

## Edge cases

- Use idempotency keys so retried checkouts do not double-charge
- 3DS-required checkouts need the customer; the agent cannot complete them alone
- Log the error code with each retry so loops are diagnosable

## If it still fails

- Reproduce with a minimal run: one user, one file, one step.
- Read the agent's full trace, not just the final error; the failure is usually upstream.
- Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
- Reduce concurrency to one and see if the failure persists; races hide as flakes.
- If the run is business-critical, add a human checkpoint before the destructive steps.

## Prevention

- Checkpoint long runs so any failure resumes instead of restarting.
- Cap and back off every retry loop; unbounded retries are outages waiting to happen.
- Validate inputs at each pipeline stage; fail fast with clear errors.
- Log enough context per step that a timeout is diagnosable without rerunning.
- Give destructive steps a human checkpoint or a dry-run mode.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YIFLPnO-JoyXolga7S75rg