> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bango.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retrying failed charges or refunds

> Understand how the DVM automatically retries failed charge attempts, and what happens if a payment remains unsuccessful.

## Overview

When a charge attempt to your billing system fails, the DVM doesn't give up immediately. It follows a **structured, time-based retry strategy** designed to maximize successful payment collection without flooding your system with excessive attempts.

<Info>
  Retries apply to any charge request that fails with a retryable error — including retryable reason codes and server-side errors (e.g. HTTP 500).
</Info>

***

## How retries work

<Steps>
  <Step title="Initial charge attempt fails">
    The DVM makes the initial charge request to your billing system. If it fails with a retryable error, the retry sequence begins automatically — no action is required from you.
  </Step>

  <Step title="First retry — 1 minute later">
    The first retry is attempted **1 minute** after the initial failure, giving transient issues (network blips, brief service unavailability) a chance to resolve quickly.
  </Step>

  <Step title="Subsequent retries — Fibonacci backoff">
    Each subsequent retry is spaced progressively further apart, following a **Fibonacci backoff sequence**. The gap between attempts increases over time, reducing pressure on your billing system while still persisting toward a successful collection.
  </Step>

  <Step title="Retry window closes at 24 hours">
    Retries continue for up to **24 hours** from the original failed attempt. If the charge has not been collected within this window, it is marked as **unpaid** and the retry sequence ends.
  </Step>

  <Step title="Next scheduled billing cycle">
    The DVM does not retry indefinitely beyond the 24-hour window. Instead, it waits for the **next scheduled billing event** for that subscription, at which point a fresh charge attempt is made as normal.
  </Step>
</Steps>

***

## Retry schedule at a glance

| Attempt | Time since initial failure |
| - | - |
| Initial attempt | T+0 |
| Retry 1 | T+1 min |
| Retry 2 | T+2 mins |
| Retry 3 | T+3 mins |
| Retry 4 | T+5 mins |
| Retry 5 | T+8 mins |
| Retry 6 | T+13 mins |
| Retry 7 | T+21 mins |
| Retry 8 | T+34 mins |
| Retry 9 | T+55 mins |
| Retry 10 | T+89 mins (\~1.5 hrs) |
| Retry 11 | T+144 mins (\~2.4 hrs) |
| Retry 12 | T+233 mins (\~3.9 hrs) |
| Retry 13 | T+377 mins (\~6.3 hrs) |
| Retry 14 | T+610 mins (\~10.2 hrs) |
| ⛔ Window closes | T+24 hrs |

<Note>
  Retry intervals follow a Fibonacci sequence (1, 1, 2, 3, 5, 8, 13…), meaning the gap between each attempt grows progressively. Up to **14 retries** are made within the 24-hour window.
</Note>

***

## After the retry window

If all retries are exhausted without a successful collection:

<CardGroup cols={2}>
  <Card title="Charge marked as unpaid" icon="circle-xmark">
    The charge status is set to `CHARGE_NOT_PAID`. No further retries are made for this charge event.
  </Card>

  <Card title="Renewal charges continue at next billing cycle" icon="rotate">
    The DVM does not block future renewal charges from occurring if a previous charge is unsuccessful.
  </Card>
</CardGroup>

***

## What this means for you

* **No action needed on failure** — the DVM handles retries automatically.
* **Your system won't be overwhelmed** — the Fibonacci backoff ensures retry frequency tapers off over time.
* **Predictable recovery** — if a payment fails, you can expect up to 14 retry attempts within 24 hours before the charge is marked unpaid.
* **Continuity at renewal** — a failed charge in one cycle doesn't permanently block collection; the next billing cycle triggers a fresh renewal charge.