## TL;DR

Stripe exposes the next retry on the invoice as next_payment_attempt, a timestamp your support tools and customer emails can read directly. With Smart Retries the time adapts to decline signals; without it, the schedule follows your configured intervals. Read next_payment_attempt instead of guessing, and tell the customer the exact date.

## Error

```text
```text
"next_payment_attempt": 1728000000
"attempt_count": 2
```
```

## Steps

1. Retrieve the failed invoice and read next_payment_attempt and attempt_count.
   Expected: You have the exact next retry time and how many tries have happened.
2. Convert the timestamp to the customer's timezone for any customer-facing message.
   Expected: The date you quote matches the customer's calendar.
3. If next_payment_attempt is null, retries are exhausted or disabled: check the subscription and dunning state.
   Expected: You know whether to expect another attempt or to act manually.
4. For support scripts, quote the date and the update-payment link together.
   Expected: The customer can either wait or fix it now.
5. If the schedule looks wrong, check whether Smart Retries is enabled and what the configured policy is.
   Expected: Misconfigurations surface instead of staying mysterious.

## When to use

- Support needs the next retry date
- You display retry timing to customers
- Retries seem to have stopped unexpectedly

## When not to use

- You want to change the retry policy (different setting)
- The invoice is in draft (nothing retries drafts)
- You need manual retry control (use pay-now flows instead)

## Compatibility

Stripe Billing; next_payment_attempt on invoice objects. Smart Retries on Billing Scale.

## Variant phrasings

### ### Stripe next_payment_attempt null

### ### when does Stripe retry failed invoice

### ### invoice retry timing Smart Retries

## Root cause

Stripe computes the next attempt from your retry policy plus decline-code intelligence, and publishes it on the invoice so every system reads the same truth. Guessing from policy docs goes stale; the field is the schedule of record.

## Edge cases

- Manual payments reset the retry state; next_payment_attempt updates accordingly
- Customer-initiated pay-now attempts do not consume the scheduled retry
- Timezone bugs in support tooling are the top cause of wrong dates quoted to customers

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5qnT-g6c7G_jRKfZ1CY2Nw