BIN-BASED Routing in Payment

Om Vikram Thapa
4 min readAug 4, 2019

Lot of people ask this what is BIN and why it is required to do BIN based routing in payment system? This article shows how we can enhance the Success Rates of particular Bank cards by identifying their BINs and routing it via selective Payment Gateways. Lets understand few terminology before going into details.

“Bank Identification Number” (BIN) is the first 6 digit numbers of your Credit or Debit Cards also known as “Issuer Identification Number” (IIN). A Credit/Debit card may vary from 16 to 19 digit numbers out of which the first 6 digit always refers to BIN.

First question should be How can we validate the card details?

Various card type VISA/MASTER/MAESTRO/AMEX/RUPAY etc can be recognized and validated by using Luhn’s Algorithm (to know more about it read below article)

https://en.wikipedia.org/wiki/Luhn_algorithm

Mostly this algorithm is used by many e-commerce sites at client side to validate card’s details in their respective payment page. Once validated its easy to go for payment.

Now since we have validated the card details How can we know about the Issuer Bank of card ? The answer is BIN. BINs are used to know about card types as well as Issuer Bank Name. Please check the following -

bin-db-and-binlist

Finally the most important question -

How to Route cards to a PG based on BIN?

The answer lies in how many PG integrations you have and do you really want to do BIN based routing (for this you need to have proper data of Issuer Bank with different PG and their success rates, the decision to choose BIN based routing also depends upon the Commercials of each unique PG). Lets take a small case scenario, for which based on historic data we found out that -

  • HDFC Bank Cards gives good success rates with HDFC PG Integration
  • ICICI Cards works well with ICICI MOTO PG Integration
  • Rest lets NOT take RISK and send them to PG aggregators like PAYU or CCAvenue or BILLDESK or CITRUS etc.

Step 1 : We applied Luhn’s algo to validate the card details on client side

Step 2 : We used bindb or binlist to find the respective Issuer Bank of card

Step 3: Before sending the payment request to any PG we apply choose the preferred PG for the BIN i.e. if it is HDFC Bank credit card lets use HDFC PG or if it is ICICI Bank debit card lets use ICICI MOTO PG or if it is XYZ Bank credit/debit card lets NOT take risk and use any one of the PG aggregator like PAYU/CCAVENUE/BILLDESK/CITRUS etc.

Remember to Update the DB Correctly: Since you have chosen to use BIN based routing the payment transaction database should be properly updated with the correct “PG Used” which was used to process the payment request because till the time the card details was NOT pushed to your system you never knew which PG is going to be under action due to this Routing Logic.

Most of the PG Aggregators use different ways of Routing the cards to different Payment Gateways due to commercials and Success Rates reasons for eg.

  • Currency Based Routing Logic (For eg. Singapore Currency to BrainTree PG and US Dollar to WorldPay PG)
  • Dynamic PG Switching Logic (Based on the traffic of payment request and Default PG success rates for last 100 transactions if the PG Success rates are low, switch the PG to another Alternative PG and route all payment request to the Alternative PG)

If your organisation is working on creating a Payment System or Payment Platform then you will certainly come to a situation where you feel a need of “BIN based routing” to increase the Success Rates. Here in redBus we do apply these logics in real time to get good payment experience also this saves a lot of money for us because Direct Issuer Bank PG Integrations gives good success rates and ask lower TDRs too.

Once your organisation crossed the international boundaries like redBus (South East Asia + Latin America) you might want to look at “currency based routing”.

We have been doing experimentation with BIN, Currency, Dynamic Switching Logic but in all these exercise we should always remember that the customer payment experience SHOULD NOT be altered. Customers are looking for safe and secure payment experience and Organisation is looking for successful payment records.

We as Engineers need to make balance between customer payment experience along with successful payment records

Thank you for the patient reading of the POST, keep an eye for MORE. Comment/Share Feedback if you want to know more..Happy to Help.

--

--