ALGORITHM FOR CONNECTING ONLINE PAYMENT SERVICES FONDY, LIQPAY AND THEIR IMPLEMENTATION

Abstract

The work describes the algorithms for connecting the two most common payment services in Ukraine - Fondy and LiqPay - to software tools (websites, mobile applications with Internet connection). Currently, such a topic is quite relevant, since not only the domestic economy, but also the world economy is actively transitioning to cashless payments. And this, in turn, poses challenges not only to economists, but also to information technology specialists. Now it is difficult to imagine a catalog site or a service site without online payment for purchased goods. Using non-cash payments, it is possible to pay almost everything: from goods to utilities and administrative fines. The purpose of our research is the development of an algorithm for connecting online payment services to websites and mobile applications connected to the Internet, and the software implementation of such an algorithm. Each service for making online payments has documentation and a set of development tools, utilities and documentation that allows you to create applications based on a certain technology or for a certain platform (SDK). SDKs typically have test credentials and test keys to enable test payments. Analysis of the scheme by which funds are debited from the client shows that two main methods must be implemented for the site server. These methods are: creation of a web form to proceed to the next stage of filling in payment details and receiving webhooks (a mechanism for sending requests when events occur in the system) from the service server. In our work, we describe a method for generating a web payment form and a method for processing webhooks. The proposed software solution is only a wrapper that facilitates the interaction of the payment service with the code by providing the opportunity to connect several services and combine them under one interface. This in turn removes the direct dependency on a specific SDK implementation. It also makes sense to write a similar interface for sites with one payment service, as there are often customers who, for certain reasons, decide to replace the payment service on their site. If a similar interface is implemented there, then replacing the payment service practically boils down to the implementation of several methods from the interface with the new SDK. And this will not bring changes to the already working logic with orders.