# agent retried a failed payment 6 times in 2 minutes: issuer flagged fraud

TL;DR: six retries in two minutes looks exactly like card testing to an issuer, so it flagged the card for fraud. Stop retrying, wait, and rebuild your retry logic with backoff: max two to three attempts, spaced minutes apart, never on hard declines. Aggressive retries turn a soft decline into a blocked card.

```text
agent retried a failed payment 6 times in 2 minutes: issuer flagged fraud
```

1. Stop all retries for this card immediately and log what happened. Expected: no new attempts hit the processor.
2. Check the decline codes across the six attempts; rapid identical declines confirm velocity flagging. Expected: the later attempts show fraud or velocity-related codes.
3. Wait at least 24 hours before any new attempt on this card. Expected: the issuer's temporary flag clears.
4. Rewrite the retry policy: max three attempts, exponential backoff starting at minutes not seconds, jitter between attempts, and an idempotency key per logical payment. Expected: code review shows the new limits.
5. Classify decline codes: retry only soft declines like insufficient_funds or try_again_later, never hard declines. Expected: a decline-code allowlist in your config.

When this applies:
- Agents or cron jobs retrying payments in tight loops
- Load tests accidentally pointed at live keys
- Webhook handlers that retry on every delivery

When it doesn't:
- A single failed payment with no retries (just fix the underlying decline)
- Customer-initiated retries spaced by human action

Compatibility: any card processor; Stripe idempotency keys; applies to Stripe, Adyen, and direct acquirer integrations alike.

### too many payment retries flagged as fraud
Back off, wait 24 hours, rebuild the policy.

### issuer blocked card after repeated retries
Only the customer calling their bank clears a hard block; your code cannot.

### payment retry loop triggered fraud detection
Your retry loop and an attacker's script look identical to the issuer.

Why it happens: issuers run velocity checks that count attempts per card per minute. A burst of identical attempts matches the signature of stolen-card testing, so the issuer blocks first and asks questions later. Your retry loop and an attacker's script look identical from their side.

Edge cases: idempotency keys prevent double charges but do not prevent velocity flags; the attempts still count. Test mode does not enforce velocity checks, so this only ever appears in production. If the card is now hard-blocked, only the customer calling their bank clears it.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HyGw-QfsIywN-ItzDB5_EA