agent retried a failed payment 6 times in 2 minutes: issuer flagged fraud
Teaches an agent safe payment retry behavior after six retries in two minutes got a card flagged for fraud. Shows how to stop the loop, wait out the issuer flag, and rebuild retries with backoff, attempt limits, and decline-code classification. Use when building or fixing automated payment retry logic. Do not use for single failures with no retries or for customer-initiated manual retries.
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.
agent retried a failed payment 6 times in 2 minutes: issuer flagged fraud- Stop all retries for this card immediately and log what happened. Expected: no new attempts hit the processor.
- Check the decline codes across the six attempts; rapid identical declines confirm velocity flagging. Expected: the later attempts show fraud or velocity-related codes.
- Wait at least 24 hours before any new attempt on this card. Expected: the issuer's temporary flag clears.
- 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.
- Classify decline codes: retry only soft declines like insufficientfunds or tryagain_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/pstHyGw-QfsIywN-ItzDB5EA