Carding Forum
Professional
- Messages
- 2,788
- Reaction score
- 1,363
- Points
- 113
There are different ways to "monetize" a project. But they have one thing in common - how money moves from the user's wallet to the organization's account. Today we will tell you about how payments are accepted at Badoo and what you can find on the payment gateway market. We warn you right away that in the article you will not find specific figures on the company's turnover, but everything else will be no less interesting.
For us, billing is everything related to receiving money from users: price configuration, payment acceptance page, direct acceptance and processing of payments, provision of paid services, various promotions and, of course, monitoring of all of the above.
Initially, as in all startups, we did not have paid services. The first serious steps towards monetization began back in 2008, despite the fact that the site was officially launched in 2006. France was chosen for the experiments, and payment was accepted only via SMS. The very acceptance of payments was organized on files. Each request was written to a separate file, which was then transferred by bash scripts from one folder to another, which meant a change in processing statuses. The database was only used to keep track of successfully processed transactions. This scheme successfully worked for a little over a year, after which it became difficult to maintain, and we decided to abandon the files and rewrite everything using the database.
The development of the new version went quite quickly, since there were not many countries where paid services were available. But it was designed only to accept payments via SMS, because of this, we even still have several funny artifacts, for example, the MSISDN fields (phone number) and short code (short number to which paid SMS is sent) in the table of processed payments.
We now accept payments almost all over the world. Every second, users are trying to pay for something on the website or in applications for all popular mobile platforms. And if you put it on a card, you get a picture "View of the Earth from space at night":
We have about 50 payment methods available, provided by different partners. The most popular are bank cards, SMS & Direct billing and purchases in mobile applications.
Among them there are also exotic ones, for example, direct debiting from the account of an Internet provider or payment through a landline phone. And once we received a payment via regular mail!
All payment systems allow accepting payments from their users. It is convenient to do such direct integrations as long as there are not a lot of them and you are connecting well-known systems with debugged processes. But when you need to enter local markets, problems begin to appear. It is becoming more and more difficult to maintain a “zoo” of different APIs, regulatory requirements differ, a popular local payment system may refuse to work with foreign clients at all at low turnovers, or signing a contract and settling legal problems may take a long time. Despite such difficulties, local payment systems can pleasantly surprise you with their conversion. For example, Holland, which we considered not very promising, after connecting the popular iDeal payment method in this country, began to bring in 30-40% more money.
If there is demand, there will be supply. There are many aggregator companies on the market, or, in other words, payment gateways ( eng.payment gateway), the purpose of which is to unite all popular payment systems, including local ones, under a single API. Having made one such integration, we are able to accept payments through dozens of payment systems around the world. You don't even have to make a payment page on your website, but use the ready-made one provided by the aggregator and adjust only the design for yourself. Particularly advanced companies allow you to upload your CSS and JS files, change images, translation texts, and even register the resulting page on your subdomain, for example, payments.example.com. This gives a very rich opportunity for "customization", and the user gets the feeling that he is not leaving your site. We do not use this opportunity at home, since we simultaneously work with several aggregators,
Which way to use - direct integration or through an aggregator - depends primarily on the size of the commission. The more your customers use the payment system, the more profitable it can be to save on commissions and connect to it directly. The second important factor is the quality of the API, usability and stability. Here aggregators allow you to smooth out rough edges, and sometimes provide a more stable service than direct connection.
Payments via SMS and direct debits from the mobile phone balance stand apart. They are under very tight control in many countries, especially in Europe. Local regulators or the state itself may have special requirements for how the payment page should look or what the text of sent SMS messages should be. Changes in such requirements should be monitored and changes should be made in time on your website. For example, in Belgium there is a rule that a short number must be written in white on a black background, and its cost must be indicated next to it.
The type of SMS billing is also different - MO (Mobile Originated) or MT (Mobile Terminated). With MO billing, everything is quite simple: the user sent an SMS to a short number, we received money. There are several options for MT. Payment does not take place at the moment the user sends an SMS message, but after he receives a special paid SMS from us. That is, the fact of payment is the notification received from the aggregator that the paid SMS has been successfully delivered. The main goal of this approach is to add additional verification before sending a paid SMS message to the user and to prevent errors related to incorrect text in the SMS. For this, payment takes place in two phases. The first - the user expresses a desire to pay for something, the second is a confirmation. For example, the payment process might look like this:
Fortunately, there are aggregator companies in the SMS payments market that are worth using. For a modest, and sometimes not very, they deprive you of the "pleasure" of dealing with such details. Another nice bonus is that they often take on some of the responsibilities of supporting end users. Users start writing about their problems directly to the owner of the short number, i.e. aggregator.
Badoo is powered by PHP + MySQL, so we use the same technologies to process payments. The code runs on a separate server group that is allocated from the shared pool. Inside, we divided it into several more logical subgroups: servers for processing incoming requests, servers for background operations and collecting statistics, database servers, servers for processing bank card payments. The latter are separated into a separate group because they must comply with the PCI DSS security standard developed with the participation of Visa, MasterCard, American Express, JCB and Discover for organizations that operate or store bank cardholder data.
To process payments, we use two database servers with MySQL from Percona, working in master-masterreplication. The main load goes only to one of them, the second is used for "hot" replacement in the event of an accident or to replace the main one (for the duration of its maintenance, for requests from the monitoring system or statistics collection).
The entire billing system can be conditionally divided into several large parts:
Connecting a new payment method to the system is just about creating its plugin. He is responsible for all interactions between us and the payment gateway, which are of two types: when we are the initiator (pull request) and when the initiator is the aggregator (push request). For pull requests, HTTP is usually used as the protocol, pure or as a transport for JSON / XML or SOAP. The concept of REST API, which has recently become popular, has not often come across to us, only from new companies on the market, for example, British GoCardless, or from old ones who decided to rework their API, for example, PayPal. For push requests, SOAP is practically not used (of those who offer such a format for push notifications, only Qiwi is easily remembered). Basically, pure HTTP is used, or it is also used as a transport for all the same JSON and XML.
After the API is implemented, the testing phase begins. There have already been articles on Habré about how our development and automation process looks like. But there are some peculiarities for billing, mainly related to the fact that we have to test not just our code, but also interaction with aggregators. It is very convenient if they have a test environment for this, which completely emulates the real acceptance of payments. If it does not exist, we make stubs that emulate the behavior of the aggregator. This makes manual testing easier for us and allows us to write autotests that check the entire payment process. Here's an example of what one of the stubs looks like.
After the test environment, you need to check how everything will work in life, make a real payment. But SMS payments often require approval from regulators or carriers, which can take several months. In order not to upload the semi-finished code to production servers, we came up with such a thing as External Shot. This is our usual Shot, which is a directory with a task branch and is intended for testing it on production servers, but in addition to the local domain, it has an additional external address where anyone can go and see the changes made. For safety reasons such "shots" are not created for every task, but only in those cases when it is really necessary. We give links to them to our partners, and they can check the changes made at any time of the day or night.
After the new integration is laid out on production servers, the stage of its operation and support begins. Technical support takes about 60-70% of our time.
This includes, firstly, the analysis of complaints from users. All simple situations are resolved by the first line support team, who also translates complaints for us from different languages into English. Therefore, only the most difficult cases that really require the attention of developers come to us.
The second component of technical support is fixing bugs or making changes to existing integrations. Errors occur for various reasons. For example, due to inattentive reading of the documentation or gaps in it. Once, we even had to use the chat logs with the aggregator developer instead, because the documentation for their new system was not yet ready. There were cases when the aggregator without notification changed the interaction protocol or its parameters. Another time, the acquiring bank turned off our gateway, and we had to urgently redirect traffic to another location. As it turned out later, it was an ancient server from the 80s, which, according to the bank, shouldn't have processed anything at all. In general, you don't have to get bored, especially considering that every minute of downtime is a lost profit.
To solve such problems, we write detailed logs of the application. It includes not only errors, but also all interactions with aggregator systems or just important events that occur during the execution of queries. Each request has its own unique identifier, which can be used to find all related records and restore the progress of its processing. This is especially useful when you have to deal with errors that have passed several weeks or months.
This is how billing is organized at Badoo. Of course, there are still many interesting topics that we plan to talk about in the future, such as monitoring, PCI DSS certification and processing of payments by bank cards. If you have any questions or suggestions on the topic of future articles, welcome to the comments.
(c) Anatoly Panov
Lead developer
What is billing
For us, billing is everything related to receiving money from users: price configuration, payment acceptance page, direct acceptance and processing of payments, provision of paid services, various promotions and, of course, monitoring of all of the above.
Initially, as in all startups, we did not have paid services. The first serious steps towards monetization began back in 2008, despite the fact that the site was officially launched in 2006. France was chosen for the experiments, and payment was accepted only via SMS. The very acceptance of payments was organized on files. Each request was written to a separate file, which was then transferred by bash scripts from one folder to another, which meant a change in processing statuses. The database was only used to keep track of successfully processed transactions. This scheme successfully worked for a little over a year, after which it became difficult to maintain, and we decided to abandon the files and rewrite everything using the database.
The development of the new version went quite quickly, since there were not many countries where paid services were available. But it was designed only to accept payments via SMS, because of this, we even still have several funny artifacts, for example, the MSISDN fields (phone number) and short code (short number to which paid SMS is sent) in the table of processed payments.
We now accept payments almost all over the world. Every second, users are trying to pay for something on the website or in applications for all popular mobile platforms. And if you put it on a card, you get a picture "View of the Earth from space at night":
We have about 50 payment methods available, provided by different partners. The most popular are bank cards, SMS & Direct billing and purchases in mobile applications.
Among them there are also exotic ones, for example, direct debiting from the account of an Internet provider or payment through a landline phone. And once we received a payment via regular mail!
Bank payments
All payment systems allow accepting payments from their users. It is convenient to do such direct integrations as long as there are not a lot of them and you are connecting well-known systems with debugged processes. But when you need to enter local markets, problems begin to appear. It is becoming more and more difficult to maintain a “zoo” of different APIs, regulatory requirements differ, a popular local payment system may refuse to work with foreign clients at all at low turnovers, or signing a contract and settling legal problems may take a long time. Despite such difficulties, local payment systems can pleasantly surprise you with their conversion. For example, Holland, which we considered not very promising, after connecting the popular iDeal payment method in this country, began to bring in 30-40% more money.
If there is demand, there will be supply. There are many aggregator companies on the market, or, in other words, payment gateways ( eng.payment gateway), the purpose of which is to unite all popular payment systems, including local ones, under a single API. Having made one such integration, we are able to accept payments through dozens of payment systems around the world. You don't even have to make a payment page on your website, but use the ready-made one provided by the aggregator and adjust only the design for yourself. Particularly advanced companies allow you to upload your CSS and JS files, change images, translation texts, and even register the resulting page on your subdomain, for example, payments.example.com. This gives a very rich opportunity for "customization", and the user gets the feeling that he is not leaving your site. We do not use this opportunity at home, since we simultaneously work with several aggregators,
Which way to use - direct integration or through an aggregator - depends primarily on the size of the commission. The more your customers use the payment system, the more profitable it can be to save on commissions and connect to it directly. The second important factor is the quality of the API, usability and stability. Here aggregators allow you to smooth out rough edges, and sometimes provide a more stable service than direct connection.
SMS payments
Payments via SMS and direct debits from the mobile phone balance stand apart. They are under very tight control in many countries, especially in Europe. Local regulators or the state itself may have special requirements for how the payment page should look or what the text of sent SMS messages should be. Changes in such requirements should be monitored and changes should be made in time on your website. For example, in Belgium there is a rule that a short number must be written in white on a black background, and its cost must be indicated next to it.
The type of SMS billing is also different - MO (Mobile Originated) or MT (Mobile Terminated). With MO billing, everything is quite simple: the user sent an SMS to a short number, we received money. There are several options for MT. Payment does not take place at the moment the user sends an SMS message, but after he receives a special paid SMS from us. That is, the fact of payment is the notification received from the aggregator that the paid SMS has been successfully delivered. The main goal of this approach is to add additional verification before sending a paid SMS message to the user and to prevent errors related to incorrect text in the SMS. For this, payment takes place in two phases. The first - the user expresses a desire to pay for something, the second is a confirmation. For example, the payment process might look like this:
- we send an SMS to a short number, respond to an incoming SMS with a specific text or without it;
- send SMS to a short number, enter the received PIN-code on the website;
- we enter the phone number on the site, get the PIN-code, enter it on the site.
Fortunately, there are aggregator companies in the SMS payments market that are worth using. For a modest, and sometimes not very, they deprive you of the "pleasure" of dealing with such details. Another nice bonus is that they often take on some of the responsibilities of supporting end users. Users start writing about their problems directly to the owner of the short number, i.e. aggregator.
Technical details
Badoo is powered by PHP + MySQL, so we use the same technologies to process payments. The code runs on a separate server group that is allocated from the shared pool. Inside, we divided it into several more logical subgroups: servers for processing incoming requests, servers for background operations and collecting statistics, database servers, servers for processing bank card payments. The latter are separated into a separate group because they must comply with the PCI DSS security standard developed with the participation of Visa, MasterCard, American Express, JCB and Discover for organizations that operate or store bank cardholder data.
To process payments, we use two database servers with MySQL from Percona, working in master-masterreplication. The main load goes only to one of them, the second is used for "hot" replacement in the event of an accident or to replace the main one (for the duration of its maintenance, for requests from the monitoring system or statistics collection).
The entire billing system can be conditionally divided into several large parts:
- Core. This includes basic entities such as Order , Payment , Services and the rules for their accounting and provision, various infrastructural things.
- Aggregator plugins. Everything that is responsible for communication between us and the payment system.
- The page for choosing and paying for services.
Connecting a new payment method to the system is just about creating its plugin. He is responsible for all interactions between us and the payment gateway, which are of two types: when we are the initiator (pull request) and when the initiator is the aggregator (push request). For pull requests, HTTP is usually used as the protocol, pure or as a transport for JSON / XML or SOAP. The concept of REST API, which has recently become popular, has not often come across to us, only from new companies on the market, for example, British GoCardless, or from old ones who decided to rework their API, for example, PayPal. For push requests, SOAP is practically not used (of those who offer such a format for push notifications, only Qiwi is easily remembered). Basically, pure HTTP is used, or it is also used as a transport for all the same JSON and XML.
After the API is implemented, the testing phase begins. There have already been articles on Habré about how our development and automation process looks like. But there are some peculiarities for billing, mainly related to the fact that we have to test not just our code, but also interaction with aggregators. It is very convenient if they have a test environment for this, which completely emulates the real acceptance of payments. If it does not exist, we make stubs that emulate the behavior of the aggregator. This makes manual testing easier for us and allows us to write autotests that check the entire payment process. Here's an example of what one of the stubs looks like.
After the test environment, you need to check how everything will work in life, make a real payment. But SMS payments often require approval from regulators or carriers, which can take several months. In order not to upload the semi-finished code to production servers, we came up with such a thing as External Shot. This is our usual Shot, which is a directory with a task branch and is intended for testing it on production servers, but in addition to the local domain, it has an additional external address where anyone can go and see the changes made. For safety reasons such "shots" are not created for every task, but only in those cases when it is really necessary. We give links to them to our partners, and they can check the changes made at any time of the day or night.
Support and operation
After the new integration is laid out on production servers, the stage of its operation and support begins. Technical support takes about 60-70% of our time.
This includes, firstly, the analysis of complaints from users. All simple situations are resolved by the first line support team, who also translates complaints for us from different languages into English. Therefore, only the most difficult cases that really require the attention of developers come to us.
The second component of technical support is fixing bugs or making changes to existing integrations. Errors occur for various reasons. For example, due to inattentive reading of the documentation or gaps in it. Once, we even had to use the chat logs with the aggregator developer instead, because the documentation for their new system was not yet ready. There were cases when the aggregator without notification changed the interaction protocol or its parameters. Another time, the acquiring bank turned off our gateway, and we had to urgently redirect traffic to another location. As it turned out later, it was an ancient server from the 80s, which, according to the bank, shouldn't have processed anything at all. In general, you don't have to get bored, especially considering that every minute of downtime is a lost profit.
To solve such problems, we write detailed logs of the application. It includes not only errors, but also all interactions with aggregator systems or just important events that occur during the execution of queries. Each request has its own unique identifier, which can be used to find all related records and restore the progress of its processing. This is especially useful when you have to deal with errors that have passed several weeks or months.
This is how billing is organized at Badoo. Of course, there are still many interesting topics that we plan to talk about in the future, such as monitoring, PCI DSS certification and processing of payments by bank cards. If you have any questions or suggestions on the topic of future articles, welcome to the comments.
(c) Anatoly Panov
Lead developer
