Payment System in INDIA (Part 3)

two-step-authentication

By now i understand we know about Payment Gateways, its categories and the integration types. How about Authentication techniques used by different PGs?

We all know modern techniques says its good to have 2 factor authentication to know the confidentiality or trustworthiness to recognize a user but the same way it goes to the online payment also here 2 factor authentication means the confidentiality and validity of the payment transaction done by the customer.

First Factor Authentication

Most of the PGs expect a Form to be POSTed to them with hidden params like merchantTxnId, amount, productInfo, cardType, cardNo, CustomerEmailID, CustomerPhoneNo, ExpiryDate, ExpiryYear, currency, returnURL etc. (Never trust a PG integration where they as you to send these parameters in query string) In the first factor Authentication PG checks the following -

• CC/DC belongs valid card brand type VISA, MASTER, MAESTRO (Mostly this check should be done at client side by using Luhn’s Algorithm and on server side usinghttp://www.binlist.net/ or http://www.bindb.com/)
• Card is already expired or NOT (Mostly this check should be done at client side based on card expiry MONTH and YEAR)
• CVV no. is entered VALID or NOT
• The requested merchant is KNOWN to PG and POSTed parameters have VALID values

First Factor Authentication depends on various encryption or hashing mechanism shared by PGs to the merchant also for which they share a “SecretKey” or a “CheckSum” or a “Hash Sequence” with the merchants to secure the data to be POSTed to the PG i have personally integrated various PGs and we have different Payment Managers class files to take care of the encryption/hash creation based on the secret key for PAYU, CCAVE, CITI, AXIS, ICICI3DMOTO, CTRUS, AMEX etc but the one which i personally like is of JusPay PG Integration where -

• They create an order id (server-server call) based on all the data they require with customer identification, amount, transaction no etc.
• Pass this newly created order id as one of the POST parameter to JusPay
• During First Factor Authentication they verify the request param which was sent via POST matches with the data you had sent earlier during the order creation or NOT.
• This takes away the encryption/hashing logic from merchant end to the PG end and is secure enough to verify the data (any tempering with the POST params results into First Factor Authentication Failure)

Other PGs use the merchant checksum/SALT to create a hash_sequence which is used to verify the authenticity of the values passed by the help of PG’s private KEY/SALT.

second-factor-authentication

Second Factor Authentication

Mostly the PGs capture/enroll the money after First Factor Authentication + Bank 3D secure process [Debit Flow depends upon the Issuer Banks] Once the payment is done. So we have 3 important numbers to look for i.e.

1. merchant order id (merchant end)
2. PG transaction id (PG end) and
3. Bank reference number (Bank end)

You can say there will be a one to one mapping with each one of the numbers.

Once the payment is done most of the PG provides a verify_payment or verification call to justify whether the payment is successful and the money has been debited or NOT. To do that you may need to make a server-to-server call (in some cases Web Request call passing PG transaction id because that is what they understand) to check the payment status. This call is very useful as it gives you the proper verification response where you can check the following -

• Is the same amount deducted for which the order was created? (helps to prevent man-in-middle attack)
• What is the Bank reference number which can be use to do reconciliation later?
• If Failed, what was the exact reason the payment failed for eg. customer declined the payment, card abandoned, issuer bank din’t authenticate etc.

My request to all the Dev team out there to make sure the Second Factor Authentication is taken seriously and implemented with care. Logging is must for both First Factor Authetication (Request/Response) and Second Factor Authetication (Request/Response) Why?

Because for Cancellation/Refund you need to pass the “PG Transaction ID” which comes as a part of the First Factor Authetication Response. Some PGs provide you the APIs to cancel_refund based on merchant order id also but its NOT full proof if you have multiple PGs integrated.

Hope this POST is NOT so encrypted as the PG POST parameters but together we can build the payment system simple, safe and secure.

“Happy Payments”