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

# Funds-Available Retries

> Retry a recurring payment declined for insufficient funds the moment the card network signals the money is there, instead of waiting for the next scheduled attempt.

A card declined for insufficient funds is not a lost customer. The money simply isn't in the account yet, and the value of a retry depends almost entirely on when it runs. Card networks watch the declined card and tell PayNext once funds are likely available again, so the retry lands at the moment it can succeed.

PayNext receives these signals **directly from the card network** through a dedicated notification channel, not through your processor. Nothing about them depends on which processor took the declined payment, and there is nothing for you to send, poll, or forward.

Funds-available retries sit on top of your existing [dunning schedule](/guides/platform/subscriptions#automatic-retry). They change **when** an attempt runs, never how many attempts a subscription gets.

<Note>
  Today these signals come from Mastercard only, so coverage is limited to Mastercard cards. Nothing in the API is Mastercard-specific except the field names.
</Note>

## When a Signal Arrives

A signal is raised for a recurring card payment that was declined for insufficient funds. Both conditions have to hold—a customer-present checkout decline or any other decline reason produces nothing.

A signal is a suggestion, not an instruction. PayNext decides what to do with it based on the state of the subscription at that moment:

| Subscription status                                     | What happens                                                                |
| :------------------------------------------------------ | :-------------------------------------------------------------------------- |
| `past_due`                                              | The current recovery attempt runs early, in place of the next scheduled one |
| `cancelled` because retries ran out                     | The card is charged; on success the subscription resumes                    |
| `active` or `trial`                                     | Nothing—something already collected                                         |
| `cancelled` for any other reason                        | Nothing—an insufficient-funds signal is not permission to charge again      |
| `scheduled_for_cancellation`, or no subscription at all | Nothing                                                                     |

## Read the Outcome on a Payment

`payment_details` carries the signal on both sides of a recovery: the declined payment that was signalled, and the charge that signal created.

On the **declined** payment:

| Field                            | Description                                                                                                                                                   |
| :------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `mastercard_pop_notification_id` | The most recent signal raised against this payment. Mastercard re-signals the same decline, and each signal overwrites this value—it is not a stable join key |
| `mastercard_pop_outcome`         | What that signal led to: a retry, or the reason there wasn't one                                                                                              |

On the **retry** payment:

| Field                                  | Description                                                                         |
| :------------------------------------- | :---------------------------------------------------------------------------------- |
| `mastercard_pop_retry_of_payment_id`   | The declined payment this charge is recovering                                      |
| `mastercard_pop_retry_notification_id` | The signal that created this charge. Written once, so this is the stable identifier |

## See It in the Dashboard

Open a payment in **Dashboard → Payments**. The timeline shows when a signal arrived and what was decided, and a retry payment names the declined payment it came from.

Under **More filters → Mastercard Payment Alerts**:

* **Payment Alert Received** — payments a signal arrived for
* **POP Retry Payment** — payments created by a signal
* **POP Outcome** — what each signal led to, including the reason for a skip

## Enable Funds-Available Retries

Signals are enabled per merchant account and need no integration work. Contact your PayNext representative to turn them on.