September 14, 2011

– Credit Cards, ATM Cards, Debit Cards, Net
Banking, IVR Payments, Mobile Payments, Cash
Cards and COD.

• As the industry has grown, so has fraud.
• If there is no customer trust while making online payments, eCommerce dies.
• There is belief that to combat fraud one must put in more and more authentication processes.
• Can we walk the fine line between simplifying the online payment process and preventing fraud from taking place?

Simple Transaction Process
Better Usability
Credit Card = VBV / MSC
ATM Card = ATM PIN
Net Banking = Password + Second Factor
IVR = OTP
Fraud Prevention Process
Barriers to Complete

Simple Transaction Process
Better Usability
Credit Card = VBV / MSC
ATM Card = ATM PIN
Net Banking = Password + Second Factor
IVR = OTP
Card Companies
Regulator
Banks
Fraud Prevention Process
Barriers to Complete

Net Banking User Name
/ Net Banking Password
OTP to Regd.
Mobile Phone
Wait for OTP /
Enter OTP #
16 digit ATM Card #
/ ATM PIN #
Enter Random Numbers on Grid printed
Behind the Debit Card

Simple Transaction Process
Better Usability
Fraud Prevention Process
Barriers to Complete

Click to Buy
Enter ID Password
Done

• Transaction Failed / Account Debited
• Transaction Cancelled/ Refund Awaited
• Transaction Modified / Partial Refund Awaited

A look at the issues with Net Banking …
• Browser compatibility:
Payment pages on many bank websites are not cross browser compatible.
This is true with some of the popular browsers as well. This leads to customer not being able to complete the transaction.

Technology and Access Issues …
• Any-time Status Query: Due to multiple hops involved in a netbanking transaction there is a possibility of transaction dropping.
• Currently we have to rely upon the reconciliation sheets which are delivered on the next business day.
• This not only leads to loss of business for some merchants
(especially merchants who give immediate product/service delivery against payment)
• This is also in conflict with the whole idea of real-time online payments processing.
• This can be avoided if the Server to Server “Any-time Status
Query” facility is provided by the banks.

Communications and Technology Issues …
• Reason codes for failures: If a transaction is declined by a bank the exact reason for failure is not provided. For instance, if a customer is trying to make a payment and his transaction is declined due to insufficient funds or invalid credentials, payment service provider is not sending us the status indicating so.
• Multiple charge for a single transaction: Some banks charge multiple times for a single transaction due to flaws in their banking solutions/processes.
• Scaling Issues: Core Banking Solutions of some banks cannot keep up with the increase in transaction load and require down time rescues frequently.

• No Downtime intimation: There are some banks which have frequent downtimes. Information related to these downtimes is not always intimated to the service providers/merchants. This leads to customer dissatisfaction. If we are informed about the downtimes beforehand we can take an informed action.
• Poor Support: Currently the level of support for transactions related queries offered by banks is minimal. This creates problems for payment service providers/merchants to address the customer queries.

R EFUND PROCESS FOR DEBIT CARDS / NET BANKING IS INEFFICIENT
AND LARGELY MANUAL …
Charging process
1. Requests charging
2. Initiate charging
3. Process charging
30 sec - 3 mins
Customer
6. Ack 5. Ack 4. Ack
7 days or more!!
PG Merchant Bank
Refund process
Customer
1. Requests refund
Merchant
2. Initiate refund
PG
3. Bank informed through bank specific process
Batch processing done adding to delay
Bank
4.
Approval sent to branch manager
5. Manual refund into account
Branch manager
4. Some banks refund directly into account
Customer account

CAUSING INCONVENIENCE TO THE CUSTOMER AND
THE MERCHANT ALIKE
Customer
• Takes long time
• Opaque process – no visibility on status of refund
• Unreliable process due to manual intervention at several stages
Merchant
• Opaque process – cannot help the customers in case things get stuck
• Requires huge effort to follow refund bankspecific refund processes and follow up with individual banks in case of discrepancies

• Transaction ID for Refunds: Some banks do not ask for the transaction ID at the time of refunding the transaction. All they need is the amount to be refunded and the customer account number to which the amount is to be credited.
• Ideally, we feel that any refund should be mapped to a transaction ID and as a 3 rd party payment service provider we should not be required to maintain customer account numbers for each transaction.
• This process reduces security and is highly susceptible to error, both human and system.

• Cap on Refunds: Many banks allow multiple refunds to be initiated for a single transaction. Each bank has its own way of handling multiple refunds. However, we have noticed that some banks do not have a check to ensure that the sum of all refunds initiated against a transaction does not exceed the transaction amount.

• Refund Acknowledgement Reference Number: There are many banks which do not provide acknowledgement
/confirmation of refunds processed.
• Not all banks which provide acknowledgements share the refund reference number. Refund reference number is essential as it is a concrete proof of refund being processed.
Moreover, we too can map the refund reference number to the transaction ID in the system.
• For eg. Syndicate Bank has a very good refund process in place.
They accept refund requests through an API. Moreover, the amount is credited into the customer’s account and refund reference number is provided instantly

– Payment pages must be compatible with all popular browsers.
– Automate all key manual processes. Provide facility to query the status of any transaction at any time.
– Implement API calls for refunds.
– Appropriate reason codes must be provided by the banks.
System flaws like multiple charges for a single transaction must be addressed on priority.

– Provide refund reference numbers for every refund.
– Cap refund amount to the transaction amount.
– Allow multiple refunds on a single transaction without any charge for refunds .
– Upgrade and scale up the Bank’s software and hardware to ensure minimal drop in transactions.

– Implement best practices for better communication with the Merchants and PG Intermediaries.
– Put in the requisite resources in terms of manpower and processes to improve service levels.
– Reduce Refund turnaround time from current average of
3-4 days to 1 day. Automation will help tremendously.
• Proper process to communicate any downtime must be implemented.
• Ideally all banks must provide 24x7 support for all the issues.
Taking these measures will help improve customer confidence and help eCommerce grow

DEBIT CARD NET BANKING
ACCOUNT
IVRS
ATM CARD
VBV / MSC
Password +
2 nd Factor OTP
ATM pin
RUPAY
Your
Bank
Account
Password +
2 nd Factor
MMID +
IMPS Pin IMPS
If everything is ultimately hitting the bank account, why not have a strong, unbreakable, Single Authentication PW across all instruments? Till then …