Any company that accepts payments over the Internet or allows clients to recharge within the service faces the problem of accepting payments. There is already a solution – you can connect to a payment service provider that will take on this task. It is quite easy to set up the work if you do not have that many transactions and a limited set of payment methods (for example, only bank cards).
Difficulties begin when the service scales – the number of transactions and payment methods grows, and you need to receive payments from other countries. The larger the scale, the more nuances, and tasks appear that need to be solved and may not be evident at first sight. This article collects all the challenges you may need to cope with when developing a payment gateway.
Payment gateway development: API connection
You may take off-the-shelf processing services and connect to them via APIs. When the client needs to pay for goods or deposit funds into his account, he is shown a processing form where he needs to enter his card data. The service handles all data processing, storage and encryption, and exchange of information with banks, and it responds to the company whether the payment went through or not. This is a convenient and standard solution.
Unfortunately, connecting to the processing service’s API with a single line of code is impossible. Usually, this is a complicated API with different methods of exchanging information: whether a payment was made or not, whether the money arrived or not, whether there is a connection breakdown, and so on. And all the nuances have to be considered because you need a stable solution for transporting money. How difficult is it to connect a processing service? Without the proper experience, it is difficult to consider all the nuances that may arise when connecting. Even with an experienced development team, this can take two or three weeks.
Payment gateway development: payments from other countries and additional payment methods
Different banks and payment systems charge different fees. And by controlling what bank the payment goes through, you can manage the amount of commission. By guiding the client differently, you can vary the commission, for example, from 2% to 10%. Naturally, the client will be happy with a lower commission. Here you have to use payment routing.
The processing service partially assumes this function in terms of selecting banks. But, for example, one service works better with Europe banks, another with USA banks, the third with a particular type of payment system. At this stage, it is necessary to connect several services, and it is up to the company to choose through which service to carry out the payment. When working with different jurisdictions, there are other nuances. For example, different countries prefer different methods of payment.
You can solve the routing problem by using a “layer” that determines which country the customer is from. That way, you can choose the best processing option with lower fees. And the company does not always benefit from the lowest commission for the client.
For example, you can pay with e-money directly through the payment gateway or the processing service working with it, but with a higher fee. And then you have to decide which method of payment is more reliable at the moment. The ultimate goal is to maintain superb reliability, throughput, and user convenience.
When working with bank cards, there is the concept of cascading. The point of cascading is that there is a queue of banks inside one gateway, and depending on the conditions, they process the transaction in a certain order. Firstly, it allows you to reduce fees. Secondly, it adds reliability: if suddenly one bank fails to process a transaction, another one will connect. Often the processing service takes over the cascading function. But the company must be given a specific set of payment methods according to the client’s characteristics – platform, country, etc.
When should you think about routing? It is unlikely that a small online store that does not have a massive flow of orders needs it. Suppose the volume of transactions is in the tens or even hundreds of millions of dollars, and losses on commissions are becoming tangible. In that case, it is already possible to introduce such a system. If there is an initial understanding that a large volume of funds will go through your service, then it is possible to build such functionality immediately.
Payment gateway development: who stores the data
The fee still depends on whose side the customer’s bank card data is stored. The system that stores this data must be PCI DSS certified. If it is not, you could get a fine from Visa or Mastercard, or they could even shut you down. You can entrust data storage to a payment system, which will charge you an additional fee. This makes sense for services with a small volume of transactions because certification is quite a costly process. But as soon as the commission volume exceeds the certification budget, it is worth thinking about your storage system.
Payment gateway development: fault tolerance and speed of operation
When a client enters his card data and presses the “Pay” button, many operations are going on in the system:
- Processing service requests bank
- Bank replies
- You request the service
- It replies to you
- You tell the system to update the account
- System updates it
- System sends a text message to the user
Ideally, less than a second should pass for the client with such a volume of operations. The person presses the button, pays, checks the bill, and it’s already updated. And now imagine that 30,000 such transactions take place a minute, which is a tremendous amount of information.
Conclusion: can you use an off-the-shelf solution?
With the growth of volumes, some new challenges and tasks must be solved. And it’s good if the team that handles such a project in your company has a wealth of experience. Financial interaction with the client is one of the essential parts of any business. And mistakes by developers can lead to losses and negativity on the part of clients.
If the volume of transactions is small, connecting one processing service with minimal effort is probably possible. But our experience shows that if you are talking about a growing volume of transactions and the number of jurisdictions from which payments are made, you have to develop a payment gateway. But you can’t do a project in a couple of months, considering all the nuances.
