# Fix activation agent stuck in retry storm after Stripe 429 on failed payment

## TL;DR
The agent storms because it retries a failing payment immediately and forever. Stop the loop, back off on 429, and treat payment failures as user-action-needed rather than retryable. Retrying a declined card faster does not make it succeed.

## The error
```text
Activation agent stuck
Retry storm after Stripe 429 on failed payment. Thousands of retries in minutes.
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=activation agent stuck in retry storm after stripe 429 failed payment"
```

## Fix it

### Step 1: Halt the retry loop

```bash
Pause the activation agent or its payment retry job.
```

Expected: Retries stop immediately.

### Step 2: Check the payment failure reason

```bash
Look up the payment intent to see why it failed: card declined, 429, or something else.
```

Expected: You know whether this was ever retryable.

### Step 3: Add backoff and a retry cap

```bash
Retry 429s with exponential backoff and a hard cap; do not retry hard declines at all.
```

Expected: Failures degrade gracefully instead of storming.

### Step 4: Route payment failures to the user

```bash
Mark the activation as action-needed and prompt the customer to fix payment.
```

Expected: The user, not the agent, resolves the payment.

### Step 5: Resume with monitoring

```bash
Resume the agent and watch retry metrics.
```

Expected: Retries stay bounded and 429s clear on backoff.

## When this applies

- Agents storm retries on Stripe payment failures
- Activation loops hammer the Stripe API
- You are building payment retry logic for agents

## When it doesn't

- The payment fails for a fixable API reason (fix the call)
- The 429 comes from a different API (pace that client)
- You need dunning flows (that is a billing product concern)

## Compatibility

Stripe API rate limits and payment intents. Any agent retry logic.

## Variant phrasings

### stripe 429 retry storm agent

Same storm. Backoff plus caps breaks it.

### activation agent infinite retry payment

Infinite retries are always a bug. Cap everything.

### agent retrying declined card

Declined cards never succeed on retry. Stop and ask the user.

## Why it happens

Payment failures split into retryable (429, transient) and terminal (declines, bad cards). Agents that retry everything immediately turn one failure into a storm, and the storm's own 429s look like more failures to retry. Classification plus backoff plus caps ends it.

## Edge cases

- Idempotency keys prevent double charges when retries do happen
- Distinguish Stripe 429s from card errors before choosing retry versus user action
- Alert on retry-cap exhaustion so stuck activations get human eyes

## 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_mz4ft9U8AqtCy_E7plvVRQ