14. Transaction Routing
Many merchants add multiple aggregators, acquiring banks, wallets and other payment service providers. Merchant can have either integration with aggregators only or have combination of integration with aggregators and direct integration with banks, wallets.
Adding multiple payment service providers is a good strategy as it allows merchant to,
- Increase payment coverage (more payment methods, banks for users)
- Avail better commercials on payment methods from different payment providers
- Avail offers such as cash backs and discounts that boosts sales
Most importantly, merchant can reduce dependency on single payment provider. As they say, “don’t put all your eggs in single basket”
When you add multiple aggregators/bank PGs, they bring along some challenges w.r.t. payment page design, card vault strategy and transaction routing. We have covered first two points, so let’s jump to ‘transaction routing’
How do you route the transactions
Before you set any routing logic, decide on what is the objective you wish to achieve
- Backup / failover mechanism
- Better conversion
- Optimise commercials by routing transaction through cheapest payment service provider
- Fulfilling volume commitment (To get better rates you might committed volume to payment service provider)
Some of the possible routing logics:
I have seen various types of routing logics set by merchants. Some have clear purposes and some are random… Here is the list of possible logics (practical and theoretical)
a. Business Line Based
Merchant can configure different aggregators for different internal business lines or product lines.
Example: All B2C transactions go through one aggregator and B2B transactions processed through another aggregator.
b. Channel based
Merchant can have channel wise routing for website, m-Site, mobile App
Example: All website transaction routed to Aggregator A but all mobile App transactions to Aggregator B.
c. Round Robin method:
Send one transaction to aggregator A, next one to B, next to C so on. Logic doesn’t serve any purpose except merchant wants to keep every aggregator happy by giving piece of action
d. Keep ‘passing’ until fails
Send transaction to aggregator A till one transaction fails and then start sending transaction to aggregator B till one transaction fails and then bring back A again and so on. This is crude way of performance based routing logic
e. Primary and Retry
Aggregator A acts as primary for all transactions and backup aggregator B is called in only when user of failed transaction try to make another payment.
f. Performance Based
Measure the performance of aggregators and acquiring banks that are integrated and route the transaction through gateway who is performing better
Example: Start with 50:50 volume and based on performance make it 90:10 (keep 10% volume so you can measure performance of other aggregator). If aggregator A’s performance drops then start routing volumes to B till 10:90 split.
g. Payment Method Based:
Merchant can use different aggregators to process different payment methods. It can be at various levels (broad or granular)
- Send All cards to Aggregator A and net-banking to aggregator B
- In net-banking, do bank level routing
- In Cards, do granular level routing at card type (Credit, debit), card scheme (Visa, MasterCard, RuPay) and issuer level
Reason: Different aggregator + acquiring banks tend to provide better success rate for particular payment mode. (E.g. Aggregator A may be good in RuPay but other aggregator process other cards better). So set the routing accordingly and keep trying different combinations until get optimal success rate
h. Commercials Based:
It is possible that one aggregator can provide better rates on few payment methods compared to others. Also, it is possible to get differential pricing for On-Us and Off-Us transactions from acquiring banks/aggregators.
Example 1: Let us say merchant has good commercials on net-banking from aggregator A and good rates on credit cards from aggregator B. Then route the transactions accordingly
Example 2: On-Us Off transaction: Aggregator/acquiring banks can provide differential rates for On-US off transaction so route card transaction accordingly
i. Volume Based
- Transaction count based: Volume is split among aggregators based on transaction count (assuming ticket size is same). Typically works well if 50:50 split between two aggregators but not ideal for complicated volume split cases.
Example: If need to send 20% volume to A, 30% to B and 50% C then 2 transactions to A, next 3 to B and next 5 to C and then start over again. But requires additional logic to remember last aggregator used and its count.
- Timer based: Build a timer based logic that can use current time stamp. As this model is built on probabilities so works better (i.e. split is more accurate) if transactions are continuous and not sporadic. E.g. Works better for Swiggy but might not for Urban Ladder
Example: 5% of volume to A, 25% to B and 70% to C. In that case, take current timestamp and do mod 100 and if that number is less than 5 then send to A, if number is less than 30 then send to B and rest will go through C.
- Payment method wise split: Merchant knows the volume across various payment methods and split payment methods such a way to fulfil volume commitment.
Example: Visa Cards and few net-banking constitute 50% of volume. So if volume is to split 50:50 between to aggregators then route all Visa Cards and selected bank through aggregator A and rest through B.
Important Note: Irrespective of what routing logic you develop, make sure for every payment method you configure a primary and secondary aggregator/acquiring bank so you have fail safe mechanism in place
Performance based logics are based on hypothesis that as ‘n-1’ transaction was successful on aggregator so transaction ’n’ will be successful. Think about it…
Routing logic is not a sprint but a marathon, one has to keep fine tuning with various combinations until you achieve the objective and that also consistently.
