Network Retry Signals

When a recurring card payment is declined for a temporary reason, the immediate question is when do I retry? The customer might be short on funds, might have a new card they haven’t activated yet, or might have a short-term block on their card. Most billing platforms answer the question with a schedule, either fixed intervals or a model trained on past results. Either way, it’s a guess. Nobody tells you when the problem has cleared.

Network Retry Signals replaces the guess with a signal from the card network. When a card you couldn’t charge is used successfully somewhere else, we send you a webhook. That’s a strong sign the card is working again, and the moment to retry.

In this post, we’ll cover:

• Why soft declines are worth retrying, and that timing is everything

• Which declines Network Retry Signals helps with

• Why today’s retry logic is a guess

• What mistimed retries cost you

• How Network Retry Signals works

• Who it’s for

TL;DR: Network Retry Signals sends a webhook when a card you couldn’t charge is used successfully elsewhere on the Visa or Mastercard network, a strong sign the card will now go through. Visa monitors cards declined for any reason. Mastercard monitors cards declined for insufficient funds or a spending limit. You enroll your merchant account with one API call, retry only when you receive a webhook, and pay only when a signal fires.

Soft declines are worth retrying, and timing is everything

Recurring businesses charge stored cards without the customer present. These are merchant-initiated transactions (MITs). That’s what makes retrying possible: you can try again without asking the customer to do anything. It’s also why timing is your problem, but not every decline is worth retrying.

• Hard declines are permanent: The card is closed, expired, lost, or stolen. Retrying won’t work, and on some codes it triggers network fees. Network Tokens and Card Account Updater fix these by refreshing the card details instead.

• Soft declines are temporary: The card and account are fine, but the issuer refused this attempt. A later retry has a real chance.

Which declines Network Retry Signals helps with

Some soft declines clear on their own, but you can’t predict when. Insufficient funds is the most common: one Evervault customer told us it made up 34% of all their declines. For declines like these, knowing the card has just worked somewhere else is a better guide than any retry schedule. Network Retry Signals covers the following decline reasons, depending on the card network.

On Visa and Mastercard:

• Insufficient funds: The balance or available credit was too low at that moment.

• Exceeds withdrawal amount limit: The cardholder hit a spending limit.

On Visa only:

• Exceeds withdrawal frequency limit: The card has been used too many times in a short period, so the issuer is blocking further payments for now.

• Blocked first use: The card was new and hadn’t been activated when you tried to charge it. If it’s then used successfully elsewhere, the customer has most likely activated it.

• Suspected fraud: The issuer flagged the payment as possible fraud, which often puts a temporary block on the card.

• Invalid or restricted service code: This can mean a few things, but it’s often a short-term block on all transactions.

Why today’s retry logic is a guess

Most failed payments go into a dunning cycle and are retried on a fixed schedule, for example every three days for 30 days, in the hope that the money arrives in time for one of the attempts.

More advanced billing platforms and PSPs use machine learning to pick the timing instead. Their models look at which days worked before, how each issuer behaves, and what happened with similar cards. That’s a step up, but it’s still a prediction about a group of customers, applied to one person.

Neither approach knows the one thing that decides the outcome: does this cardholder have funds right now? A schedule tuned to the 1st of the month is wrong for anyone paid weekly, biweekly, on benefit dates, or by gig platforms with no fixed payday. And no schedule knows when a customer activates their new card, or when their issuer lifts a block.

What mistimed retries cost you

• Revenue: Every retry that lands on an empty account uses up part of the dunning window. If the window closes, the subscription is canceled, even though the customer never meant to leave. This is involuntary churn.

• Authorization fees on failed retries: Each retry is a normal authorization, so it costs the same whether it succeeds or not. A long dunning cycle that never succeeds costs you a fee on every attempt and recovers nothing.

• Fees for too many retries: Visa and Mastercard limit how often you can retry a declined card, and charge a fee for every attempt over the limit. Many PSPs bundle these fees into their statements, so merchants often don’t know they’re paying them.

How Network Retry Signals works

Visa and Mastercard see every payment on their networks. So they can tell when a card you couldn’t charge has just been approved by another merchant, which is a strong sign a retry will go through now. Network Retry Signals passes that signal on to you.

1. Enroll your merchant account: Call our onboarding API with the merchant ID (MID) of each account you want to enroll. If you don’t know a MID, send us any Mastercard network transaction ID from that account and we’ll find it for you. You don’t send any card numbers, and you don’t change how you process payments.

2. The card network monitors declined cards: When a payment is declined for one of the supported reasons, the card’s network watches that card for 30 days. There’s nothing for you to submit. Repeat declines for the same card and amount don’t start a new monitoring period, and monitoring stops if the payment succeeds another way, for example if the customer pays manually.

3. You get a retry-now webhook: When the card is approved elsewhere, we send a webhook in real time. It includes the:

   • Network

   • Amount

   • Currency

   • Time of the original decline

   • Network transaction ID

   • Card BIN

   • Last four

   • Masked card number (or the token BIN and last four if the payment used a network token).

4. You match it and retry: The webhook doesn’t include your own payment reference, because the card network never sees it. Match the signal to the failed payment using the network transaction ID, timestamp, amount, and card details, then retry through your PSP. Check early that your PSP gives you the network transaction ID, since that makes matching much easier.

There are no rules, thresholds, or schedules to set up with us. The signal either fires or it doesn’t.

Who it’s for

Network Retry Signals works best when:

• Most of your payments are recurring charges on stored cards, such as subscriptions, memberships and installments.

• You keep serving the customer while you retry, and customers are self-serve, so there’s no account manager chasing payment.

That makes it a strong fit for payment companies and platforms with subscription businesses, and for verticals like gaming, where businesses mix recurring and one-off payments but most revenue is recurring.

It’s not the right fit if most of your payments are customer-initiated one-offs, or if you collect recurring payments over bank rails like ACH or Direct Debit.

Getting started

Network Retry Signals is in preview on Visa and Mastercard.

Read the docs

Register for the preview