How Things Stood
A smooth and stable payment system is an essential part of any online casino to make sure that the player has a happy and profitable experience. Any faults with a payment system, however small, can knock their confidence and cause them to play elsewhere.
In heavily loaded systems, when the player makes a payment, a problem might arise where there is a double money charge, and twice the amount is debited from users. This scenario happens due to the parallel processing of the same request.
In order to avoid this problem, you need to develop a stable system for checking limits, so that a transaction is completed with an optimistic payment blocking feature. This makes sure that just one payment is processed, and the player has nothing to worry about.
However, many customers are initially unaware of such problems, believing that the payment has gone through as expected. This can cause some nasty surprises. Thanks to our experience in dealing with this sort of problem, we were able to suggest that such a problem may well arise more frequently in other highly loaded systems.
By identifying the problem before it becomes a major issue, we are often able to solve it before users have the misfortune of running into it.
How our experience has helped us in the past:
We have a large bank of experience in working with payment rates, and in previous projects, we have encountered problems that usually appear in highly loaded systems. This means that we can accurately predict when systems aren't well-equipped enough to avoid these problems. When we do, we can counteract the problems before they even happen.
An example of this is when cases have almost parallel processing of the same request when a bet is under operation. Such transactions may result in double charges or debits. To avoid this, all limit checks are carried out within the transaction, and the transaction needs to be carried out with an optimistic payment blocking tool to exclude double charges.
In the past, we have also seen cases when the proxy server doubles certain requests due to a failure. This ends up with them arriving with a microsecond delay, and only thanks to our protective measures, a double charge is not issued.
We have also had a case when we worked with a casino integration module with a wallet service. In the event of a disconnection during a transaction in the wallet system, we checked after a while whether an operation with the specified ID exists in the wallet system.
If they could not find it, they repeated it. According to protocol, the wallet service responds with the code 200 in case of success and 404 if the transaction is not found. It turned out that the transaction verification server was available through the proxy and the service itself broke down and responded with the code 500, service unavailable, and the proxy returned 200 — service unavailable due to incorrect settings. Since then, we have used the rule that the decision should be based solely on the response body.