Juspay's AIOps solution to reduce passive churn

Introduction

For the past few weeks, we’ve been building a Juspay AIOps solution aimed at reducing passive churn. In this post, we’ll dive into how Juspay integrates with a business’s existing payment infrastructure without any reengineering, manages all recurring payment functionalities, and helps prevent passive churn.

Juspay seamlessly works across acquirers/PSPs, subscription providers, and various payment methods. It ingests data from multiple sources and considers diverse permutations to identify the optimal retry construct, frequency, and timing for transactions. Whether a business uses a single PSP or a multi-PSP setup, Juspay adapts accordingly.

The problem

“Recurring transaction retries are ineffective without considering the diverse parameters. And, there are too many parameters to be considered.”

Most businesses today embed a recurring payment model into their operations, from auto-shipments and auto-fulfill to subscriptions. A critical component in these models is successfully charging customers at regular intervals (weekly, bi-weekly, monthly, etc.). When a recurring transaction fails, the business risks involuntary churn due to payment failure.

When a transaction fails, merchants receive an error response from their acquirer. Networks like Visa have standardized these decline codes. A few common ones include:

• Code 57 – Transaction Not Permitted to Cardholder
• Code 51 – Insufficient Funds
• Code R0 – Stop Payment Order
• Code 01 – Refer to Issuer
• Code 05 – Do Not Honor

There are over 70 such error codes across card networks. Here’s where complexity begins: U.S. issuers, of which there are over 80, have each engineered their internal systems (risk checks, fraud detection, etc.) uniquely. This means that each issuer can map several errors to a single error code, creating inconsistent error responses across issuers and card bins. As a result, merchants often receive bundled error messages, losing critical details in the process.

To Elaborate:

• Code 05 (Do Not Honor) could signify insufficient funds, suspicious activity triggering fraud alerts, daily transaction limits, and more.
• Code 57 (Transaction Not Permitted to Cardholder) could indicate card restrictions, suspected fraud, or configuration issues.

Additionally, networks have categorized these card decline codes from Category 1 to Category 4, restricting how frequently merchants can retry certain error codes and imposing penalties for breaches. For example:

• Category 1 errors can never be retried, with penalties of $0.10 to $0.15 per retry attempt.
• Category 2 to Category 4 errors can be retried fewer than 16 times within 30 days, or else penalties of $0.10 to $0.15 per retry apply.

Acquirers further complicate the process by appending their own interpretations to the errors they receive from issuers, often differing in how they classify issuer error codes. Some acquirers may also provide additional insights from the networks, while others might present merchants with a masked version of decline codes, obscuring key information.

The Challenge

Even when merchants get accurate error codes, crafting the right retry strategy is a daunting task. It requires taking into account: Payment method type, Card bin and region, Credentials, Customer history, Transaction amount, Network rules, Retry count and frequency, Day and time of retry, Penalties, Trade offs, Transaction engineering possibilities, and more
Without a robust strategy in place, many merchants default to a retry-at-will approach, accepting whatever outcome they get.

Juspay is designed to tackle this challenge by engineering the retry strategy in a data-driven, intelligent way, minimizing churn while avoiding penalties.

Solution

Juspay resolves involuntary churn by addressing two key areas: Feature Engineering and Retry Engineering.
Feature Engineering:

This includes standalone features that merchants can leverage for immediate benefits, as well as changes they can implement to improve transaction success rates.

1. Transaction Design: It’s important to ensure that transactions are correctly labeled, especially for recurring payments. The right parameters must indicate that the transaction is a Merchant Initiated Transaction (MIT), which signals to issuers that it falls under specific recurring billing terms.

2. Keep Card-on-File Updated: If you’re using a processor token (i.e., a token tied to a specific payment processor), it’s essential to subscribe to the card updater services offered by major networks. These services-Visa Account Updater (VAU), Mastercard Automatic Billing Updater (ABU), Discover Card Account Updater, and American Express Cardrefresher-ensure stored card information is automatically updated, reducing the likelihood of failed transactions due to changes in card details (like new card numbers or expiration date changes). Access to these services is typically available through your payment processor or acquiring bank and may require enrollment depending on your provider’s terms.

3. Use Network Tokens: When merchants use network tokens (provided by Visa, Mastercard, etc.), the need for card-on-file updating services is eliminated. Network tokens are dynamic and automatically update when cardholder details change, such as card reissuance or expiration date updates. This reduces the likelihood of involuntary churn, as tokens remain valid, even after changes in the underlying card. Network tokens also provide greater flexibility for merchants with multi-PSP setups, allowing them to process recurring transactions across different payment service providers (PSPs) without disruption.

Retry Engineering:

This approach delves deeper into analyzing the reasons for transaction declines and devising a sophisticated retry strategy that takes into account a variety of parameters. Retry engineering is particularly useful in understanding the failure codes and messages and crafting a smart retry framework based on the following factors:

• Payment Method: Different methods (cards, wallets, bank transfers) may require different retry approaches.
• Issuer Bin: Factors like the issuer’s bank, type of card program, and card type (debit, credit, prepaid) influence retry strategies.
• Region: Retry strategies vary by region (North America, Europe, LatAm, etc.) due to local regulations and practices.
• Day & Time: Transactions could be more successful based on pay-day cycles (weekly, bi-weekly, monthly), as cardholders’ account balances tend to fluctuate.
• Credentials: Different credentials-network token, gateway token, clear PAN, older or newer PAN-might yield different retry success rates.
• Retry Frequency & Count: Structuring retries with optimal timing and limiting them to an acceptable number can reduce penalties while improving conversions.
• Penalties & Trade-offs: Category-1 error codes (non-retriable codes) may carry penalties if retried. Merchants must balance these penalties with potential benefits.
• Complete vs Partial Auth: Depending on the nature of the transaction, partial authorization (where only part of the transaction amount is approved) may be attempted.
• Ticket Size: Small versus large transactions may dictate different retry strategies.
• User History: A customer with a longer, more stable payment history may allow for more retries.
• Single vs Multi-PSP Setup: In multi-PSP setups, transactions may be orchestrated across different PSPs for higher success rates.

Example Retry Strategy:

Let’s explore a retry strategy for a transaction that fails with decline code 05 (“Do Not Honor”).

• First Retry: Depending on the payment method and issuer, the first retry might use a different payment credential (e.g., retrying with clear PAN if a network token was initially used).

• Second Retry: A second retry could occur after a 24-hour interval, allowing any fraud prevention systems or user behavior checks to reset.

• Third Retry: This retry can be timed to coincide with the cardholder’s payday, based on the region or issuer’s known cycles.

• Fourth Retry: A partial authorization might be attempted if the merchant’s MCC code permits it, and if the business strategy aligns.

In the flow outlined above, each retry attempt could either result in a success or a decline. If a decline occurs, the retry strategy is dynamically recalibrated based on the latest decline code. For merchants with a multi-acquirer setup, additional strategies may involve orchestrating retries across multiple PSPs to enhance the likelihood of successful authorization, while effectively minimizing penalties and managing risks

Engagement

With Juspay, we assist businesses by analyzing transaction data, retry logic, and error reports from PSPs and subscription engines, offering tailored recommendations. This empowers them with a clear understanding of their current business health, identifying the key drivers of passive churn and providing insights into the potential uplift that Juspay can deliver.

The beauty of the Juspay engine is that it seamlessly integrates without disrupting the existing transaction flow. Merchants don’t need to invest engineering resources in re-coding their payment stacks. Instead, Juspay operates as a parallel path, handling all recurring transactions independently with minimal effort on the merchant’s part.

We collaborate closely with merchant’s engineering and product teams, providing full support for integration with Juspay. Typically, we begin with an A/B test, progressively transitioning recurring transactions to Juspay in a controlled manner before full migration. Backed by over 12-years of expertise in payment processing and our ability to handle transactions at scale-125 million transactions per day-our engineering recommendations come with the assurance and reliability that only extensive experience can provide.