What the platform is

The Mastercard Payment Optimization Platform, usually shortened to POP, is Mastercard’s umbrella for network-side services that help merchants and acquirers turn declined authorizations into approvals. It sits inside the network rather than at the processor, which is the point: the network sees traffic from every issuer and every merchant, and can act on information no single processor has.

Mastercard positions the platform around three ideas: cleaning up authorization messages before they reach the issuer, giving merchants clearer advice when a decline does happen, and telling merchants when circumstances have changed enough that a retry is worth sending. Payment Alerts is the third of those.

Payment Alerts, step by step

Payment Alerts is the component that matters for recurring billing. Here is the sequence from the merchant’s side.

  1. A recurring Mastercard payment on one of your registered merchant IDs is declined for insufficient funds (51) or an exceeded amount limit (61).
  2. The network flags the decline and begins monitoring the card. Nothing is sent to the issuer or the cardholder; this is passive observation of network activity.
  3. When the network sees conditions that indicate a retry is more likely to approve, it generates a retry signal for that specific declined transaction.
  4. The signal is delivered to the merchant, together with the identifiers needed to match it to the original decline: the network transaction identifier, the card BIN and last four digits, the amount and the currency.
  5. The merchant retries through its usual processor. If the retry approves, monitoring ends. If a successful retry is observed independently before any signal, monitoring is cancelled. If the window closes with no recovery, monitoring expires.

The default monitoring window is 30 days. The whole thing is advisory: the network never initiates or authorizes a retry on the merchant’s behalf.

How it relates to Merchant Advice Codes

AT DECLINE

Merchant Advice Code 24–30

Returned inside the code 51 response. The issuer's estimate of when funds will be back: one hour to ten days.

Nature: an estimate, made once
LATER

Payment Alert

A separate message, sent when the network observes that conditions have changed and a retry is now more likely to approve.

Nature: an observation, when it happens

Mastercard also runs the Authorization Optimizer programme, which changes what an issuer sends back on an insufficient-funds decline. For recurring card-not-present transactions, participating issuers return a Merchant Advice Code from 24 to 30 with the code 51 decline, meaning retry after one hour, 24 hours, or 2, 4, 6, 8 or 10 days. This has applied in the United States since late 2023 and in Europe since early 2024.

The two work at different moments. The advice code is the issuer’s estimate at the instant of the decline. A Payment Alert is an observation made later, when something has actually changed. In a well-built retry policy you use both: respect the advice code’s wait time so you do not waste an early attempt, and act on the alert immediately when it arrives, because approval likelihood decays with delay.

Why the signal is different from a smart retry

Processor retry engines such as Stripe Smart Retries, Chargebee Revive and Adyen Auto Rescue predict a good retry moment from patterns in their own traffic. They are useful and you should keep them on. But they cannot see the cardholder’s account. Their only way to learn whether funds are back is to send an authorization and see what happens, and each of those attempts costs a processing fee, uses up one of the network’s permitted reattempts, and adds another decline to the card’s history if it fails.

A network signal is not a prediction. It is emitted from inside the network in response to observed conditions. It does not fire for every decline, and Mastercard does not guarantee approval when it does. But when it fires, the probability of approval is materially higher than a scheduled guess, and a retry that approves on the first attempt makes the rest of the schedule unnecessary.

How merchants receive it

Historically, receiving network signals meant a direct integration with Mastercard or an enterprise programme through a large acquirer. That is still the route for the largest merchants.

PaymentRetryAlert is a delivery layer for everyone else. You register your acquiring BIN and merchant ID, stand up one HTTPS endpoint, and receive each signal as a signed JSON webhook with a RETRY_NOW status, plus lifecycle notifications when monitoring starts, is cancelled or expires. Deliveries are HMAC-SHA256 signed, retried for up to 72 hours if your endpoint is down, and carry only the card BIN and last four digits, never a full card number.

You keep your processor and your existing retry tooling. The alert is an additional trigger, and if your own retry succeeds first the monitoring cancels itself. Pricing is a monthly minimum plus a percentage of the value of alerted transactions, charged per alert issued.

What it does not cover

Being precise about scope avoids disappointment.

  • Mastercard only. Visa, American Express and Discover declines are not monitored.
  • Codes 51 and 61 only. Do-not-honor, expired, fraud and other declines are out of scope; handle those with the rest of your retry policy.
  • Recurring, merchant-initiated transactions. Subscription renewals, memberships, instalments, scheduled collections and stored-credential recovery. Not one-off customer-present checkouts.
  • Territory limits. Availability depends on the transaction territory and the card-issuing country supported by Mastercard. Markets with on-soil processing requirements are excluded.
  • Advisory. No guarantee of approval, no retry on your behalf, no change to your authorization decisions or fraud controls.

Where to start

If insufficient-funds declines on Mastercard cards are a meaningful share of your failed recurring payments, the recovery calculator will give you a conservative estimate of what the signal is worth on your volume. The integration overview describes the webhook, the statuses and how to match an alert to the original decline.