Network Retry Signals

Sandbox support

Network Retry Signals helps recover lost revenue from declined transactions by sending you notifications informing you when a transaction has succeeded on that card. The card networks track activity, such as successful approvals on the same card at other merchants for similar amounts or greater, to identify optimal retry windows.

Declined transactions impact all businesses to some degree and are often caused by temporary issues, such as insufficient funds. They can negatively impact revenue, support costs, customer loyalty, and brand trust. To prevent these issues, most solutions retry the payment based on some kind of static schedule, without any signal that the retry will succeed. Network Retry Signals fills this gap. It uses card network intelligence to determine when a retry is more likely to succeed.

• Increase approval rates

  Retry when the network has seen the card succeed, instead of on a fixed schedule.

• Maximize revenue recovery

  Recover payments that would otherwise be written off after a temporary decline.

• Mitigate excessive retry fines

  Fewer blind retries means fewer network penalties for repeatedly retrying declined cards.

• Prevent service disruptions

  Keep subscriptions and services running without asking customers to update their payment details.

How it works

After a monitored decline, Mastercard and Visa watch the card for successful approvals elsewhere. When they see one, Evervault sends you a signal to retry the payment.

1. 1.

   Configuration

   Network Retry Signals is configured per merchant. To onboard your merchant, use the Network Retry Signals Enrolment API. Then, configure a webhook endpoint in the Dashboard and subscribe to the payments.network-retry-signals.signal event.

2. 2.

   Network Monitoring

   After enrollment, Mastercard and Visa monitor declined transactions on that MID to identify the optimal moment for a retry.

3. 3.

   Retry signals

   When the network sees a successful transaction on the same card, Evervault sends a signal event to your webhook endpoint so you can retry the payment.

Network Retry Signals Enrolment API

Enroll your merchant IDs (MIDs) with the Network Retry Signals Enrolment API. One request enrolls up to ten identifiers for one merchant, on Visa, Mastercard, or both. Each identifier is one of the following:

• A networkMid, when you know the MID
• A list of up to 50 networkTransactions, when you don't know the MID. We recommend providing at least three.

For a list of transactions, Evervault locates the MID or MIDs that the transactions were processed on and enrolls each one. To find the transaction IDs, see Locating a transaction ID. The timestamp of each transaction is optional, but it helps the network find the MID.

From the time of onboarding, it can take up to 3 weeks before the networks track the MID and you start receiving notifications.

1curl -X POST 'https://api.evervault.com/payments/network-retry-signals/onboarding' \
2  -H 'Content-Type: application/json' \
3  -u '<app_id>:<api_key>' \
4  -d '{
5    "merchant": "merchant_123456789098",
6    "identifiers": [
7      { "network": "visa", "networkMid": "000000000007777" },
8      {
9        "network": "mastercard",
10        "networkTransactions": [
11          { "networkTransactionId": "MCC123456789012345", "timestamp": "2026-10-20T14:03:00Z" }
12        ]
13      }
14    ]
15  }'

The response has one enrollment in accounts for each identifier, in the same order as the request. Store the id of each enrollment and use it to retrieve the enrollment and check its status.

1{
2  "merchant": "merchant_123456789098",
3  "accounts": [
4    {
5      "id": "network_retry_signals_enrolment_4f0178a44fea",
6      "network": "visa",
7      "networkMid": "000000000007777",
8      "locatedMids": [],
9      "status": "in-progress"
10    },
11    {
12      "id": "network_retry_signals_enrolment_1bcd286c8e11",
13      "network": "mastercard",
14      "networkTransactions": [
15        { "networkTransactionId": "MCC123456789012345", "timestamp": "2026-10-20T14:03:00Z" }
16      ],
17      "locatedMids": [],
18      "status": "in-progress"
19    }
20  ],
21  "missingForBoarding": {
22    "visa": ["contact.phoneNumber", "contact.name"]
23  }
24}

A list of transactions can belong to more than one MID. Each located MID is enrolled separately and has its own status in locatedMids, so one MID can start receiving signals while another is still being enrolled.

Each MID and transaction can be part of only one open enrollment. If a request includes one that's already being enrolled, the API returns a 409 error that points to the identifier, and doesn't create any of the enrollments in the request.

Visa merchant details

In addition to the existing details provided when creating a merchant, Visa requires the merchant's business phone number and a contact name. Set them in the contact attribute when you create or update the merchant, before you enroll the MID.

If they're missing, the enrollment is still created, and missingForBoarding lists the merchant attributes to set. An open enrollment can't be sent again, so contact Evervault support to complete it.

Only production apps can be onboarded. Calling the Enrolment API with a Sandbox app returns a 403 response. To test your integration in a Sandbox app, simulate a signal instead.

Supported merchant countries

Merchants must be registered in one of the following markets.

Network monitoring

The network scans its own network for failed transactions associated with your enrolled MID. If a monitored MID receives a 51 or 61 decline code, the network monitors the payment instrument involved in the declined transaction.

The networks monitors linked payment credentials across their global networks. They track activity such as successful approvals on the same card at other merchants for similar amounts or greater, to identify optimal retry windows.

Duplicate decline prevention

When a repeat decline occurs for the same PAN, MID, and amount, the system doesn't initiate a new monitoring session. It also avoids new sessions if a decline occurs within an existing monitoring period. This avoids redundant tracking, minimizes system load, and reduces duplicate notifications.

Self-retry detection (auto-termination)

If a successful authorization is observed independently (e.g., the customer pays manually), the active monitoring session is canceled.

The retry signal event

Here is an example of a retry signal webhook event:

1{
2	"id": "webhook_event_0aa6ff0fee57",
3	"type": "payments.network-retry-signals.signal",
4	"data": {
5		"network": "mastercard",
6		"signal": "retry-now",
7		"amount": 12345,
8		"networkTransactionId": "W3T51Z",
9		"timestamp": "2026-02-04T13:53:47.314Z",
10		"currency": {
11			"alphaCode": "usd",
12			"numericCode": 840
13		},
14		"metadata": {
15			"notificationId": "M8OjZWZgRi0uZLa6PdB0CIavqctFyipx",
16			"acquirerMerchantId": "12354689987",
17			"cardBin": "5123456",
18			"cardLastFour": "9000",
19			"tokenBin": "5234567",
20			"tokenLastFour": "1234",
21			"maskedCardNumber": "512345XXXXXX9000"
22		}
23	}
24}

A retry signal webhook event has two sections: the signal status and transaction information, and card network-specific transaction metadata.

Signal status and transaction information

Card network metadata

Mastercard metadata

Signal statuses

Matching signals to failed transactions

To retry the failed transaction after a webhook signal, you can match on the following set of identifiers from your PSP:

• Transaction timestamp
• Network transaction ID
• Last four digits
• BIN
• Masked PAN

Here's an example handler that matches a retry-now signal to the declined payment and retries it.

1app.post("/evervault", async (req, res) => {
2  const event = req.body;
3
4  if (event.type === "payments.network-retry-signals.signal") {
5    const { signal, networkTransactionId, amount, metadata } = event.data;
6
7    if (signal === "retry-now") {
8      const payment = await db.payments.findDeclined({
9        networkTransactionId,
10        amount,
11        lastFour: metadata.cardLastFour ?? metadata.tokenLastFour,
12      });
13
14      if (payment) await retryPayment(payment);
15    }
16  }
17
18  res.status(200).send({ success: true });
19});

Testing

You can use Evervault's Sandbox apps to test your webhook handler without waiting for a real retry signal. Sandbox apps can't be onboarded with Mastercard. Instead, Evervault provides a simulate endpoint that sends a test signal to your registered webhook.

Simulate a signal

Make sure your Sandbox app has a webhook endpoint subscribed to the payments.network-retry-signals.signal event. Then, send a request to the simulate endpoint, authenticated with an API key that has the networkRetrySignals:create grant.

1curl -X POST 'https://api.evervault.com/payments/network-retry-signals/simulate' \
2  -H 'Content-Type: application/json' \
3  -u '<app_id>:<api_key>' \
4  -d '{
5    "networkMid": "12354689987"
6  }'

The endpoint returns the simulated signal with a 202 status, and Evervault delivers the same signal to your webhook as a payments.network-retry-signals.signal event. The signal has the same shape as a production retry signal event.

1{
2  "network": "mastercard",
3  "signal": "retry-now",
4  "amount": 48210,
5  "networkTransactionId": "K7Q2ZD",
6  "timestamp": "2026-10-27T12:00:00.000Z",
7  "currency": {
8    "alphaCode": "eur",
9    "numericCode": 978
10  },
11  "metadata": {
12    "notificationId": "a8Fk2LqP0zX4mT7vB1nR6sW9cY3hJ5dE",
13    "acquirerMerchantId": "12354689987",
14    "cardBin": "555555",
15    "cardLastFour": "4821",
16    "maskedCardNumber": "555555XXXXXX4821"
17  }
18}

Each simulated signal uses random values:

• The amount is between 100 and 100,000 minor units (1.00 to 1,000.00).
• The currency is USD, EUR, or GBP.
• The card details always use a card number, not a network token, so tokenBin and tokenLastFour are never present.

Because the values are random, a simulated signal doesn't match a payment in your system. Use it to check that your endpoint receives, parses, and acknowledges the event.

Locating a transaction ID

If you use a PSP, it typically provides this value when you inspect a transaction on its platform or through its APIs. Here's how to find it for some common PSPs.

Finding a transaction ID with Stripe

1. In the Stripe dashboard, navigate to Transactions and locate a transaction on the network you're enrolling.
2. Copy and search for the Payment and open it in the Workbench.
3. Locate the Charge associated with the Payment.
4. In the Workbench Inspector tab, find the network_transaction_id under payment_method_details.

Finding a transaction ID with Adyen

With Adyen you can use the Transfers API to locate a payment transfer on the network you're enrolling. In the response, locate the event containing a transactionId field. This is the network transaction ID.