How payment systems are created: part one
In the summer of 2009, Mail.Ru announced the launch of a new payment system created by its own developers (recall that prior to this, technological and service support for the project Money Mail.Ru was provided by the MoneyMay payment system). The new project was to, among other things, offer the portal users a single, convenient and secure mechanism for paying for the services of various services of the company - from entertainment projects (Games, Applications in My World) to e-commerce projects (Goods, Real Estate, Newsletters).
A year has passed. Money@Mail.Ru continues to develop, increasing the number of financial instruments for both users and stores. For users, this includes the possibility of transfers within the system, payment for various services and goods (from paying for numerous games, cellular communications, the Internet and utility services to purchasing clothes and tickets), the ability to enter from bank cards and output to virtual Visa cards. The stores are actively developing tools to automate the reception of payments or to replenish users' accounts — many functions of the payment system are available through the API.
In addition to these explicit functions, there are also technological ones, which are much less frequently discussed, but which are no less significant for the company as a whole. For example, the services of the portal and stores connected to Dengam@Mail.Ru have the opportunity to accept payments from users who keep their electronic means in other payment systems - WebMoney, Yandex.Money and several others. An equally important part of the system is the processing of sms, through which visitors from many countries can pay for the services of various services of the portal without having to open an account in the payment system.
With this article we open a whole cycle of stories about how our payment system works from the inside, what tools we use to ensure its reliable operation, how we work with dozens of external systems, what problems we have had to face, how we solved them, and what conclusions we made . In addition to technical articles, we will try to talk about how to expand the financially active audience of your online stores and social networking applications with the help of our payment system. If you are interested in any other topics regarding Deneg@Mail.Ru, ask, we will try to highlight.
')
The task of starting work on a new project was assigned to our department at the end of 2008. At that time, payment systems were not related to the types of projects that Mail.Ru used to develop, launch and successfully operate. However, at the stage of setting the problem there was an understanding of what had to be taken into account and implemented in the development process.
We called these requirements "MMM" (this is, of course, a joke ) by the first letters. Here they are:
It is no secret that sometimes the project “shoots” unexpectedly for the people who created it, gets a large number of users, and developers are faced with the problem of how to quickly cope with sharply increased loads. Placing a memcache project on it, raising master-slave replication — these concepts are familiar to many people who tried to do something so that the project did not slow down. Unfortunately, even with these simple methods, it is usually impossible to help quickly - you need to learn the components of the system to go to the cache, use one database server for writing and lots for reading, and so on. Quickly providing good horizontal scaling (scale-out) is not always a trivial task . And we did not want to face a week or a month after the launch, in order to accomplish this task we would have to rewrite a project that would not cope with its main task, electronic payments, all this time. Therefore, already at the design stage of the system, it was necessary to lay the foundation for simple scaling of Deneg@Mail.Ru.
Again, it is no secret that sometimes the code that works perfectly with apples refuses to work when bananas appear in the warehouse it serves. Well, the work with different entities is not provided in the code! In many cases that have been seen, the problem was often solved by the institution for oranges of a new set of tables, similar to “apple”, and by copying previously written code with the replacement of $ iApples by $ iBananas . In other cases, the solution of the problem was more adequate - additional fields appeared in the database, classes were inherited from the already prepared ones with the addition of some new methods and properties (for example, the “peel” attribute for an apple is treated quite differently than for a banana). But even this solution sometimes required quite large changes in the code. Therefore, multicurrency should be put into the system immediately.
The most mysterious property at first glance, but the explanation is very, very simple. We call a storefront an entry point into the system that can work with settings independent of the main entry point - from a different domain address and its own currency to its user authorization method and its interface. Launching such a new storefront should also be very simple - it is not more difficult to add a couple of lines to the system configuration files and, if necessary, new user interface templates.
Of course, this is not all the requirements for the payment system, but they are the ones that most influenced the system architecture. The new project was supposed to be quite flexible and resilient.
Did we manage to do this? Yes, it was possible to the full.
Now, according to our estimates, we can easily scale the system to hundreds of nodes literally by simply installing and configuring new hardware and entering information about the nodes into the project configuration.
We can process all currencies in the world (national banks, ay!) Without thinking about how the system will behave. In order not to be unfounded - now the system already uses several currencies (oh, those legal problems!).
Well, as an example of windows you can give a version of the site for debugging stores, which uses a test currency; Mobile version of the site , which has its own set of actions available and its own templates. Another example is a showcase for the operation of stores with an API, where the authorization method is used, which is different from the one with which the portal users are identified in Money@Mail.Ru. The launch of these windows for the system really looked just like the appearance in the configuration files of the blocks with the description of windows and a couple of folders with templates. Exactly the same way, we can provide, for example, the work on our engine of the payment system Money@Vkontakte.Ru or anyone else who expresses such a desire.
I think many people wonder how, from a technical point of view, we managed to implement all this. Therefore, in the next article we will talk about the tools and technologies that allowed us to make our payment system as it is, as well as focus on the overall architecture of the project. Stay with us!
Team Deneg@Mail.Ru
A year has passed. Money@Mail.Ru continues to develop, increasing the number of financial instruments for both users and stores. For users, this includes the possibility of transfers within the system, payment for various services and goods (from paying for numerous games, cellular communications, the Internet and utility services to purchasing clothes and tickets), the ability to enter from bank cards and output to virtual Visa cards. The stores are actively developing tools to automate the reception of payments or to replenish users' accounts — many functions of the payment system are available through the API.
In addition to these explicit functions, there are also technological ones, which are much less frequently discussed, but which are no less significant for the company as a whole. For example, the services of the portal and stores connected to Dengam@Mail.Ru have the opportunity to accept payments from users who keep their electronic means in other payment systems - WebMoney, Yandex.Money and several others. An equally important part of the system is the processing of sms, through which visitors from many countries can pay for the services of various services of the portal without having to open an account in the payment system.
With this article we open a whole cycle of stories about how our payment system works from the inside, what tools we use to ensure its reliable operation, how we work with dozens of external systems, what problems we have had to face, how we solved them, and what conclusions we made . In addition to technical articles, we will try to talk about how to expand the financially active audience of your online stores and social networking applications with the help of our payment system. If you are interested in any other topics regarding Deneg@Mail.Ru, ask, we will try to highlight.
')
As the Steel Was Tempered
The task of starting work on a new project was assigned to our department at the end of 2008. At that time, payment systems were not related to the types of projects that Mail.Ru used to develop, launch and successfully operate. However, at the stage of setting the problem there was an understanding of what had to be taken into account and implemented in the development process.
We called these requirements "MMM" (this is, of course, a joke ) by the first letters. Here they are:
- M scalability
- M Ultimate Currency
- M nogovitrinnost
Scalability
It is no secret that sometimes the project “shoots” unexpectedly for the people who created it, gets a large number of users, and developers are faced with the problem of how to quickly cope with sharply increased loads. Placing a memcache project on it, raising master-slave replication — these concepts are familiar to many people who tried to do something so that the project did not slow down. Unfortunately, even with these simple methods, it is usually impossible to help quickly - you need to learn the components of the system to go to the cache, use one database server for writing and lots for reading, and so on. Quickly providing good horizontal scaling (scale-out) is not always a trivial task . And we did not want to face a week or a month after the launch, in order to accomplish this task we would have to rewrite a project that would not cope with its main task, electronic payments, all this time. Therefore, already at the design stage of the system, it was necessary to lay the foundation for simple scaling of Deneg@Mail.Ru.
Multicurrency
Again, it is no secret that sometimes the code that works perfectly with apples refuses to work when bananas appear in the warehouse it serves. Well, the work with different entities is not provided in the code! In many cases that have been seen, the problem was often solved by the institution for oranges of a new set of tables, similar to “apple”, and by copying previously written code with the replacement of $ iApples by $ iBananas . In other cases, the solution of the problem was more adequate - additional fields appeared in the database, classes were inherited from the already prepared ones with the addition of some new methods and properties (for example, the “peel” attribute for an apple is treated quite differently than for a banana). But even this solution sometimes required quite large changes in the code. Therefore, multicurrency should be put into the system immediately.
Polygamy
The most mysterious property at first glance, but the explanation is very, very simple. We call a storefront an entry point into the system that can work with settings independent of the main entry point - from a different domain address and its own currency to its user authorization method and its interface. Launching such a new storefront should also be very simple - it is not more difficult to add a couple of lines to the system configuration files and, if necessary, new user interface templates.
Of course, this is not all the requirements for the payment system, but they are the ones that most influenced the system architecture. The new project was supposed to be quite flexible and resilient.
Did we manage to do this? Yes, it was possible to the full.
Now, according to our estimates, we can easily scale the system to hundreds of nodes literally by simply installing and configuring new hardware and entering information about the nodes into the project configuration.
We can process all currencies in the world (national banks, ay!) Without thinking about how the system will behave. In order not to be unfounded - now the system already uses several currencies (oh, those legal problems!).
Well, as an example of windows you can give a version of the site for debugging stores, which uses a test currency; Mobile version of the site , which has its own set of actions available and its own templates. Another example is a showcase for the operation of stores with an API, where the authorization method is used, which is different from the one with which the portal users are identified in Money@Mail.Ru. The launch of these windows for the system really looked just like the appearance in the configuration files of the blocks with the description of windows and a couple of folders with templates. Exactly the same way, we can provide, for example, the work on our engine of the payment system Money@Vkontakte.Ru or anyone else who expresses such a desire.
I think many people wonder how, from a technical point of view, we managed to implement all this. Therefore, in the next article we will talk about the tools and technologies that allowed us to make our payment system as it is, as well as focus on the overall architecture of the project. Stay with us!
Team Deneg@Mail.Ru
Source: https://habr.com/ru/post/107184/
All Articles