Improving the customer’s experience via ML-driven payment routing

Co-Authors: Xianyun Mao, Stan Xu, Rachit Kumar, Vikas R, Xia Hong, and Divyakumar Menghani

As a LinkedIn member, you can subscribe to LinkedIn Premium on a monthly or annual basis. For our customers, we offer the same option for our Talent Solutions and/or Sales Navigator products. For each, LinkedIn offers subscription renewal payments. These subscription renewal payments used to go through a rule-based routing engine to selected payment gateways, which often resulted in a less-than-optimal experience. In this blog, we will discuss how we replaced the existing rule-based approach with an ML-driven engine to optimize for payment approval rates to create a more optimal customer experience.

Introduction

While the user experience may seem fast and smooth, the behind scene process is quite complex (as illustrated in Figure 1). When a member enters a credit card number, LinkedIn will choose a payment gateway and send the payment information to it. The gateway then encrypts and transmits the payment details and communicates the approval or denial decision back to LinkedIn and acquiring banks. If the transaction is successful, the acquiring bank will get the money from the account in the issuing bank. 

Figure 2 shows a few payment gateways LinkedIn currently works with. LinkedIn usually has two or more payment gateways to choose from for every transaction except Paypal and Alipay. If members/customers choose Paypal or Alipay, transactions are directly routed to those websites to complete the transaction. 

LinkedIn historically used a predefined routing ratio/rules to each gateway (such as Adyen and Paymentech in the US), and the transaction would be routed randomly following this ratio, which can be seen in Figure 3. Such rules are based on countries, currencies, transaction types, product types, card types, etc. For example, ads payments in the US are routed to gateway A and gateway B in a 40-60 split. The 40-60 split means the routing engine will choose gateway A 40% of the time and choose gateway B 60% of the time.

With this framework, the static rules failed to capture the temporal changes in approval rate across gateways, which led to a suboptimal overall approval rate, resulting in suboptimal purchase/renewal experiences. We had over 100 rules in the rule-based routing engine, and updating them manually was intractable and error-prone. 

Problem statement

The payment process is similar to the bottom of an iceberg in that it’s not commonly perceived as part of the member/customer experience. In most cases, both would simply assume their recurring subscription service will be charged successfully. The LinkedIn payment system has retry logic for recurring charges, meaning that LinkedIn may retry a failed recurring transaction at a different gateway and/or at a later time. If the charge fails, we will send a notification. However, if a response is not received in time, the service will be suspended and might eventually be canceled. Our goal is to improve the subscription renewal member and customer experience by building and using an adaptive, ML-based, payment routing to replace the rule-based process. By implementing a model-based approach, we can improve the member experience by lowering the chances of unintentional suspension and involuntary cancellation caused by avoidable payment gateway failures.

But how can a ML-based engine improve the transaction success rate and improve the member and customer experience? We model the routing task as a supervised learning problem to predict the best payment gateway using transaction parameters. This can drive a higher business impact than an existing static rule-based routing engine. To overcome the sample imbalance, we use the inverse probability weighting (wiki) to generate training datasets.   

A few payment industry leaders have implemented machine learning methods to increase the payment approval rate. Both Adyen and Dropbox used multi-armed bandits (MAB) framework. The highlight for the Adyen model is the epsilon-greedy implementation and for Dropbox, the model is to optimize for the best time to process a payment. We will discuss MAB more in the conclusion section.

• Adyen used contextual multi-armed bandits to optimize payment conversion rate (link)
• Dropbox applied machine learning to handle customer subscription payments (link)
• PayPal Network tokenization (hashing) improved the authorization rate by 50 basis points (link)
• Twilio increases its authorization rates by 10% with Stripe (link)

Our method

Inverse probability weighting 

The inverse probability weighting (IPW), also called inverse propensity scoring (IPS) is crucial to ensure good model performance. The approach allows the supervised learning model to overcome the sample imbalance problem (reference) and explore all gateways. In Figure 4, let us suppose we had an existing routing strategy of 40% to gateway A and 60% to gateway B. Let us also suppose gateway A had a 75% success rate and gateway B had a 60% success rate. By intuition, the new strategy should be to route more to gateway A because of the higher success rate. However, if we trained a supervised learning model on the testing/training data sampled directly from the observed data, the model tends to predict gateway B more often in a validation dataset. The bootstrap sampling with the IPW ensures supervised learning models to predict gateway A more often, which is the correct strategy. 

Bootstrap sampling based on IPW

We formalize the payment routing as a supervised learning problem as follows. Suppose there are K payment gateways, and when a transaction was routed, any gateway would yield a success or failure response. There are a set of input variables X such as currency, country, etc. Routing action a E{1, … K} for a given input value x EX produces a success with probability 0aE[0, 1]. The success probabilities (01 , …, 0K) can be learned based on most recent data. Table 1 defines the variables for the model.

Table 1: The relationship between payment routing terminology and variables used in the model

We implemented a bootstrap sampling method using the IPW as follows: 

for a = 1, …., K gateway do 

      Generate J* samples of (x, r) with replacement from the data {X, R, A=a}

   end for

Let {A’, X’, R’} be the collection of sampled (a, x, r). The action-reward pair (a, x) is recoded to y as follows to train a (K+1)-class classification model y = f(x). The (K+1) classes correspond to the K gateways and the failure state. When the model makes a prediction, the best predicted gateway is the gateway with the highest predicted score; please note we ignore failure state in the prediction to ensure only eligible actions are taken (failure is not an action). An alternative to ignoring the failure state in the prediction is to discard the declined transactions in the recoding step. Both of these approaches have merits but for this, we chose to ignore failure state.  

J* was 2,000,000 in our model. 

Model

After we generate sampled data {A’, X’, R’} based on IPW sampling, we proceed to model training. We leverage the following features directly from the internal database as the source for training feature sets and output labels. In this modeling process, we denote routing actions, y, as labels. Currently, we use US data only and deployed the model in the US market only. Independent variables X are as follows:

1. Transaction type: type of transactions. e.g., recurring charge, authorization, debit
2. Card type: indicator for the form of card used. e.g., credit card, debit card or others
3. Payment instrument type: type of the payment instrument, which helps to distinguish between credit card and other card payments such as bank debits (i.e. sepa direct debit) or digital wallet
4. Product family: corresponding to the product being purchased
5. Credit card network/brand/schema: the card network. e.g., Visa, MasterCard, American Express, etc.
6. Countries and currencies are not used in the US model. However, they will be used in future global models.

We chose a multiclass softmax logistic regression as our model because of low serving cost. 

Deployment and model refresh

The multi-class model returns an array of approval probability scores for all qualified gateways. We then rank the probability and pick the top one as the primary routing decision.  

To onboard the model to production, we published the model for engineers to integrate it with the payment routing system. Engineers bifurcated the existing routing logic into two routing engines, with one using the existing rules and the other using the model as the routing decisions. We set up an A/B test to monitor the performance of multiple key payment metrics and evaluated the performance of the model. The payment approval rate of the model-based engine showed statistically significant lift. Figure 5 shows the delta of approval rate between the model-based engine and the rules-based engine over time. Vertical error bars are the 95% confidence intervals.

After rolling out the model, we refreshed it on a periodic basis. The model refresh was based on the routing data since the previous model update. 

Conclusion

In this post, we introduced an ML-based payment routing engine to improve the customer experience by lowering the chances of unintentional suspension and involuntary cancellation caused by avoidable payment failures. We implemented a IPW based sampling approach and a supervised learning model based on the sampled training data to solve merchant payment routing. For the research community, we are excited to share the first reported (to our best knowledge) success story of IPW based sampling in the payment space. The approach can be generalized for any online merchant because the model inputs are commonly used by the most popular payment gateways. It can also be expanded and applied to all the decision points in the payment routing pathways (from merchants, to gateway/processor, and to acquisition banks).    

In the future, we’re looking forward to potential improvements such as using a different cost function, which will allow us to train the model to minimize the cost with a constrained approval rate. We also want to include more predictors in the model such as time of transaction and issuing banks. 

We are interested in exploring alternative methodologies. One idea is to build one propensity model per gateway and unify the model outcomes to predict the best gateway for a given transaction. Another idea is to use a reinforcement learning (RL) approach such as MAB as mentioned in the previous section. MAB has great potential to learn from non-stationary settings (the underlying approval rate of gateways change over time) and require minimal model refresh. 

Acknowledgements

We would like to acknowledge Suhil Srinivas, Ganesan Venkatasubramanian, Jenie Gao, Raj Vuppala, Sohaib Waheed, Bryan Ng, Leticia Cheng, Rahul Todkar, and Ya Xu for their leadership in this cross-functional initiative. We would like to thank all of the contributors who assisted with smart payment routing from the Go-to-Market Data team (Sal Duran, Mohan Kumar Puttasiddaiah), the LinkedIn Business Platform (LBP) Eng team (Xin Sun, Jun Ma, Chanh Nguyen, Priyanka Shree, Shuosheng Huang, Yujun Xie, Tim Tan), the Product team (Piyush Keshri, Raj Khare, Shaheen Shah), the LBP Business Operations Team (Anu Gururajan), the Payment Operations & Partners Team (Michelle Brumwell), India DS team( Deepti Rai, Hitesh Manwani, Raghu Yalamanchili), the ProML team (Jiang Zhu, Shadow Zhao), FP&A team (Priscilla Tam, Andrew Ahn, Joanna Ronquillo), Go-To-Market Data team (Anbang Xu, Changshuai Wei) and many others.