So you have done with building your online service or a product. The very last feature is to have online payment system for your customer to pay you. This is last feature, but very crucial one. You may use online payment service such as chragebee, chragify , recurly etc and integrate with your system. But wait, they charge you more and the fact is you end up paying more in long run.
Think of it; you can build your own, fully controlled online payment system by using payment gateway from the bank where you hold business account. Yes, it’s safe if you consider 5 things described in this blog. Read them and get your developer to follow them during development.
Save your order with the payment gateway response
Every order or subscription done at your website is being saved in database. Your developer includes business relevant information such as subscription end date or number of pieces ordered in the database. However, he may miss out with the key information – payment gateway response.
Payment gateway response is information given out by the payment gateway for every transaction – be it successful or failure. This is very important information at times. In fact, during a dispute between you and your bank this information is a key. Hence make sure that your developer saves it in the database.
Keep it safe and trustworthy
Your customers are cautious when they swipe card online. They don’t enter their card details if they don’t feel safe at your website. It’s a psychology – you can’t help with. But you can still get them pay you by using hosted payment gateway.
When you integrate hosted payment gateway your customers are redirected to page on a bank website – say HDFC page. Your customer has to enter their card details in that page. Many feel safe to do it there. Yes, you will have to compromise on the user experience for some time. Once your service or product gains some trust in the market, you may ask customer to pay you directly on your site.
Save failed transactions
It’s a mistake that every developer makes. They don’t save the failed transaction into database. Failed transaction information don’t fell worthy for them. But it’s worthy information for a business to have.
Transaction may fail for many reasons – canceled by user, wrong card details, no balance. But it’s best to know what happened.
Keep a track on failed transactions
This is an extension of the above. Ask your developer not only log the failed transaction but also email it to you. This way, you know who have tried to buy your product or service. You may pitch in again offline asking them what went wrong and request them to try it one last time.
Transaction failed? Try again
Even you can automate try again request if your payment gateway information is distinct for every failed reason. Few payment gateways give failure code in its response. They are unique and describe the reason for failure.
If the reason is something other than purposeful cancelation by your customer then you can offer them one more chance to pay you. That way your customer needs to start over the buying process.
Bonus: Record the cancellation policy along with the order
Customers are wiser than you. Most of the time they are right or some time you don’t have enough information to back you up. This actually happened with one of my client. Quit often my customer used to change the cancellation policy on the website. However he didn’t keep a track of them.
One of his customer argued that cancellation policy has changed after she has booked at the website and hence her order don’t fall under new cancellation policy. My customer had very less information and ended up paying more along with losing the business.
Overnight we built a new feature to address this. The solution was simple. I just recorded the current cancellation policy along with the order. Now my client has enough information. Get this done from your developer, in case he hasn’t done that.