Decline Recovery Core Concepts

Not all payment declines are the same. They generally fall into two categories:

• Soft Declines: These are often temporary issues where a retry might be successful. Examples include insufficient funds, temporary network issues, or generic bank declines (like "Do Not Honor" which might be a temporary flag). Xelf focuses heavily on recovering these.
• Hard Declines: These indicate a more permanent issue with the payment method, such as a stolen or lost card, an invalid account number, or a closed account. Retrying these is usually futile and can incur unnecessary fees. Xelf helps identify and avoid retrying hard declines.

Understanding this distinction is crucial for an effective recovery strategy.

When a transaction is declined by the initial PSP and submitted to Xelf, it enters a recovery lifecycle:

• Submission: You submit the details of the declined transaction to Xelf via our API.
• Analysis: Xelf's AI analyzes the decline code, transaction history, payment method details, and other data points to determine the likely cause and optimal recovery strategy.
• Recovery Attempt(s): Based on the analysis and your configured rules, Xelf may initiate one or more recovery attempts. This could involve intelligent retries with the same or different PSPs, using updated card information, or employing different routing logic.
• Outcome: Each recovery attempt results in a success or failure. The overall status of the decline is updated accordingly.
• Notification: You are notified of the final outcome via webhooks or by polling the API.

Simply retrying a declined transaction immediately is often ineffective. Xelf's Intelligent Retries use a data-driven approach:

• Optimal Timing: Retrying at specific intervals (e.g., after a few hours for suspected insufficient funds) can increase success.
• Dynamic Routing: If a decline seems PSP-specific, retrying with an alternative PSP can be effective.
• Cost Optimization: Avoiding retries that are unlikely to succeed or that incur high fees.
• Customizable Logic: You can configure retry rules based on decline codes, transaction value, customer segment, and other business parameters.

The goal is to maximize approval rates while minimizing costs and customer friction.

Issuing banks and payment processors return Decline Reason Codes (e.g., "05 - Do Not Honor", "51 - Insufficient Funds", "14 - Invalid Card Number"). These codes provide valuable, albeit sometimes cryptic, information about why a transaction failed.

Xelf helps by:

• Normalizing Codes: Mapping diverse codes from various PSPs to a standardized set where possible.
• Informing Strategy: Using these codes as a key input for analysis and retry logic. For example, a "Do Not Honor" might be retried, while a "Lost/Stolen Card" would not.
• Providing Insights: Analytics on decline codes help you understand common failure points in your payment process.

Two key technologies help reduce declines related to card details:

• Network Tokens: These are tokens issued by card networks (Visa, Mastercard, etc.) that replace the actual card number. They can improve approval rates and security, and often update automatically when a card is reissued.
• Account/Card Updater Services: Services (often provided by PSPs or third parties) that proactively check with card issuers for updated card numbers or expiration dates for vaulted cards.

Xelf Processing leverages these technologies where available to ensure payment credentials are as up-to-date and secure as possible, reducing declines from outdated information.

Understanding your decline patterns is essential for optimization. Xelf provides analytics and reporting features that allow you to:

• Track overall decline rates and recovery rates.
• Break down declines by reason code, PSP, card type, currency, region, etc.
• Measure the effectiveness of different recovery strategies.
• Identify trends and anomalies that may require attention.

This data empowers you to make informed decisions to improve your payment success rates over time.

Stay informed about the status of your decline recovery attempts in real-time using webhooks. Xelf can send notifications to your server for events like:

• decline.submitted_for_recovery
• decline.recovery_attempt_successful
• decline.recovery_attempt_failed
• decline.recovery_completed_successful
• decline.recovery_completed_failed

Using webhooks allows you to automate downstream processes, such as updating your internal order status or notifying customers.