How PaymentRetryAlert works

Overview

PaymentRetryAlert tells you when to retry a Mastercard payment that was declined for insufficient funds. It is built on the Mastercard Payment Optimization Platform (POP) — Payment Alerts: the Mastercard network passively observes activity on the declined card and, when conditions suggest a retry is likely to approve, we deliver a RETRY_NOW webhook to your endpoint. You submit the retry through your existing processor, gateway, or acquirer — nothing in your payment routing changes.

Alerts are advisory. PaymentRetryAlert never initiates, authorizes, or retries a payment on your behalf, never guarantees approval, and does not replace your fraud controls or retry strategy. You decide whether, when, and how each transaction is retried.

How it works

1. A recurring Mastercard payment on one of your registered MIDs is declined for insufficient funds or an exceeded amount limit.
2. The decline is flagged and the card is monitored across the Mastercard network — for up to 30 days by default (configurable). You receive a MONITORING_STARTED notification.
3. When network activity meets the retry criteria, a RETRY_NOW signal is triggered.
4. We deliver a signed webhook notification to your endpoint.
5. You match the alert to the original declined transaction and retry immediately through your existing payments stack — the sooner you retry after the alert, the higher the approval chance.

If you (or the customer) independently retry successfully in the meantime, monitoring is cancelled automatically and you receive MONITORING_CANCELLED. If the window closes without a recovery, you receive MONITORING_EXPIRED.

Scope & eligibility

Covered declines

Monitoring covers Mastercard authorization declines with these ISO 8583 response codes:

Supported transaction types

Recurring merchant-initiated transactions (MITs): subscription renewals, recurring billing, membership renewals, installment and scheduled collection attempts, stored-credential payment recovery, and other merchant-initiated recovery scenarios.

Out of scope

• Card networks other than Mastercard, and decline reasons other than codes 51 and 61
• Automatic retries on your behalf — alerts are advisory only
• Authorization decisions, approval guarantees, or fraud/risk decisioning
• Markets with on-soil processing requirements (for example, India)

Notification statuses

Lifecycle statuses are free and exist for reporting and reconciliation. Handle or log every status even if only RETRY_NOW triggers action.

Matching an alert to the original decline

To act on an alert you need to find the original declined transaction in your system. Store these fields when a recurring Mastercard payment declines with code 51 or 61, and match on them when the alert arrives:

• financialNetworkTransactionIdentifier — the network's unique ID for the declined transaction (DE63SF01 Banknet reference). The strongest key if your processor exposes it.
• financialNetworkProductCode — DE63SF01 financial network code.
• financialNetworkSettlementDate — DE15 settlement date.

If your processor doesn't surface network identifiers, a composite fallback works well in practice: match on acquirerMerchantId + cardBin + cardLastFourDigits + transactionAmount + transactionCurrency, scoped to declines within your monitoring window, using transactionTime to disambiguate.

Delivery & retries

For each notification we attempt delivery up to 20 times over 72 hours. A delivery counts as failed on any non-2xx response or after a 30-second timeout. Retry intervals follow this sequence:

10s → 30s → 2m → 5m → 30m → 4h ×4 → 8h → 12h ×4

• X-PRA-Attempt tells you which attempt a delivery is (starting at 1).
• Retried deliveries carry the same notificationId and body — deduplicate on notificationId.
• A RETRY_NOW is most valuable immediately; if your endpoint was down and the alert arrives on a late attempt, use notificationTime to decide whether it is still worth acting on.

Monitoring controls

Monitoring window

After an eligible decline, the card is monitored for up to 30 days by default. The window is configurable per MID during onboarding — align it with your billing cycle and dunning period so alerts arrive while a retry is still commercially useful.

Duplicate decline prevention

A repeat decline for the same card, MID, and amount within an active monitoring window does not start a new session — you won't receive duplicate alert streams for the same failed payment, and you are never billed twice for the same recovery opportunity.

Self-retry detection & early cancellation

If a successful authorization for the same card, MID, and amount is observed — for example, your scheduled retry got there first, or the customer updated and paid — monitoring is cancelled immediately and a MONITORING_CANCELLED notification is sent. You keep running your existing retry strategy alongside PaymentRetryAlert; the two do not conflict.

Billing

Usage accrues per RETRY_NOW alert delivered, at progressive volume rates on monthly alerted transaction value, with a $100 monthly minimum that includes usage. Lifecycle notifications (MONITORING_STARTED, MONITORING_CANCELLED, MONITORING_EXPIRED) and test alerts are never billed. Paused MIDs accrue no usage. See pricing for rates and worked examples.

Security & data

• No full card numbers. Alerts carry the BIN and last four digits only; no cardholder data is stored at rest by the service.
• Monitoring happens inside the Mastercard network via passive observation of transaction traffic, aligned with ISO 8583 and PCI-DSS. We never see or touch your authorization traffic.
• Transport security. All webhook delivery and API traffic is TLS 1.2+; deliveries are HMAC-SHA256 signed with per-account secrets and replay-protected timestamps.
• You stay in control. No transaction is ever initiated or authorized on your behalf; alerts are advisory and you own every retry decision.

Questions or integration help: support@paymentretryalert.com.

Full integration reference

PaymentRetryAlert is in a limited beta. The pages above describe how the service works, what it covers and how alerts behave, so you can assess fit and plan the integration. The full reference is shared with beta participants during onboarding and covers:

• Authentication and API keys
• Registering merchant IDs via the dashboard or POST /v1/merchant-ids
• Configuring your webhook endpoint and rotating the signing secret
• The complete alert payload reference, field by field
• HMAC-SHA256 signature verification with worked examples
• Sending signed test alerts before go-live
• A copy-paste prompt so a coding agent can build the integration from /llms.txt