November 17, 2009 at 03:26The architecture of the electronic payment acceptance system on the site
For many projects, the moment comes when you want the site to be profitable.
And not only in the form of payment for advertising banners or contextual advertising, but also in the form of money from their visitors.
It does not matter what they offer - a cool special effect on the avatar, a T-shirt with the symbols of the project or access to private messages of the first beauty of the site. It is important how to get paid for it. And it is desirable immediately, until the user changes his mind to spend his hard-earned money.
Such a restriction immediately leads to the deletion from the list of payment methods of filling out a receipt at Sberbank. Yes, this is also a method, but the method is not fast. Especially if the courtyard is late in the evening, the user relaxed over abottle of beer with a cup of tea. What a Sberbank, take it warm, warm!
What methods of organizing the reception of more or less instant payments come to mind in the first place? Personally, I just came to mind three at once:
Payments via SMS are a big commission, but almost every user has a mobile phone.
Plastic cards are not widespread (yes, yes, the residents of Default City, beyond MKAD there is also life ready to pay!), But the commission is minimal.
Electronic money - a lot of different systems, technical and legal difficulties of connecting, but the audience is large! And how to replenish!
Without stopping in this article on the first two methods, I want to talk about organizing the reception of electronic currencies on the site. Such as WebMoney , Yandex , Dengi@Mail.ru,and the like. The implementation of the work in each case does not bother us, you can read about this in the documentation for these payment systems (PS), and in various kinds of success and failure stories.
The main idea that should arise after reading the article (and I hope it will arise) is that having correctly designed the payment acceptance system, connecting each new system will not be difficult.
I’ll make a reservation right away, hereinafter under the “account” I will understand not account , but rather invoice . And for convenience, so as not to be confused between the user’s account, which contains information about payments, the size of the user's balance of payments, etc., and the invoice for payment of something, the latter will be called an “order” or “order”.
In general, the payment systems that I happened to encounter are divided into two types:
Therefore, let's talk about the second.
A typical scenario for working with such systems from the point of view of the seller looks like this:
Since we are talking about payments, it’s clear that some kind of billing will be required to account for user payments / applications. It can be arbitrarily complex or simple, for us it can be a “black box”: we will need only two things from it: the amount of the application and its number.
I think you should not specifically discuss why this number should be unique, right?
The remaining data from billing (for example, some textual description of the service) is optional.
How to correctly write billing is a speech for a whole group of articles, so now it’s not about him.
Whoever wants, questions about billing can ask me in private or by mail.
So, let's start with the general architecture.
As it does not seem strange, the recipe for a payment acceptance system architecture according to the described scenario is very, very simple. We need: the
order queue - 1 pc.
queue processing dispatcher - 1 pc.
general library of work with applications - 1 pc.
general web interface library - 1 pc.
general library of work with payment systems - 1 pc.
libraries of work with specific payment systems - N pieces, by the number of systems.
Now more about each of the parts.
1. What is the application queue?
Everything is simple - this is a table of applications of various statuses (in the simplest approximation - “paid”, “unpaid”, “in processing”). We will need it both in order to save information about the application, and in order to understand which applications need to be sent to the dispatcher for processing.
Readers who already recognize the words “normalization” and “relational database” will object that there should be more tables, but I argue that one is enough.
2. Queue processing manager.
This is a certain script launched in the background as a daemon or simply by crown, it doesn’t matter.
Its task is to process the order of applications, contact payment systems and change the status of applications.
3. Library work with applications.
In fact, this is a library for working with a queue (read the "database"). From it you need only a few functions:
4. The web interface.
For what it is needed, it is understandable - to display information about the order to the user and so that the user can click on the "Pay" button.
From this library, it is necessary for it to be able to give the same data from several formats: at least html and json / xml. HTML is understandable for what, and JSON is used to use AJAX and not overload pages. In principle, it is possible without it.
From the web interface you need only 4 functions:
5. Libraries for working with specific payment systems (BPS) should be able to
6. From the general library of work with payment systems (OB), you will also need a little:
How will the described work scenario change in the new terminology?
0. initialization by the user of the payment process.
The web interface displays a list of available payment systems and payment information.
The user presses "Pay", an application is created with the status of "new", information about it falls into the queue. At this moment, the user will receive a message “All will be, wait,” and check from time to time the status of the application. Here we will need the same data about the application in JSON - while we draw the user on the screen all kinds of hours, progress bars, etc., using AJAX we interrogate the queue about the status of the application.
1. formation of an application based on the data of our billing, signature of the application with a secret key or certificate.
2. sending data to the payment system and receiving the order number in their accounting system
3. saving this number in our system.
The dispatcher removes the order with the status of “new” from the queue, sets it to the status “in processing”, transfers the data to the OB, receives the data necessary for sending to the PS. It sends them, receives a response, gives it to OB, that in BPS and receives the order number. It saves the order number and payment URL in our turn, puts the application status “ready for payment”.
At the next poll, the user queues are thrown to the URL to continue payment. What he will do there is his business. In case he realizes that he does not have this electronic currency, on the page with the status of the order we will give him a link to delete the application and create a new one with the ability to choose a different currency.
4. Interrogation of the payment system for changes in the status of the order.
Periodically, the dispatcher receives a request in the status of "ready for payment" and checks its status in the payment system. If the status does not change, put the application aside until better times.
In a good way, you need to take into account the "expiration date" of the application so as not to interrogate the payment system indefinitely.
5. Change the status of the application in our system, the provision of services to the user.
As soon as the status has changed, depending on the response of the payment system, the dispatcher marks the application as “paid” or “rejected”. She will not get to the dispatcher anymore. Now, background billing scripts will receive information that the bill has been paid and will provide the user with the ordered service.
Why is the described system good?
1. It allows you to perform all operations with the user extremely quickly.
Saving the application in the queue, receiving data about the application by a unique number is a very quick operation.
All slow work is done by the dispatcher in the background.
2. It scales well.
We can organize dozens of queues using various partitioning methods.
Tens and hundreds of demons to process each queue or status, or currency.
3. She is simple.
Connecting a new payment system is just adding a new library, which should be able to only 4 things described above.
I don’t voice specific implementation details in this article - the tools are unimportant.
It can be Perl or PHP, or Python for the web / database.
It can be MySQL, or SQLite, or Oracle, or PosgreSQL for queuing.
It can be file_get_contents (), LWP :: UserAgent or CURL for working with HTTP.
You can double the interval of request status polling in the payment system. You can in 3.14159 ...
Implementation is yours.
upd: The full text (including with diagrams and additions) is available on my website
And not only in the form of payment for advertising banners or contextual advertising, but also in the form of money from their visitors.
It does not matter what they offer - a cool special effect on the avatar, a T-shirt with the symbols of the project or access to private messages of the first beauty of the site. It is important how to get paid for it. And it is desirable immediately, until the user changes his mind to spend his hard-earned money.
Such a restriction immediately leads to the deletion from the list of payment methods of filling out a receipt at Sberbank. Yes, this is also a method, but the method is not fast. Especially if the courtyard is late in the evening, the user relaxed over a
What methods of organizing the reception of more or less instant payments come to mind in the first place? Personally, I just came to mind three at once:
- sms
- plastic cards
- electronic money
Payments via SMS are a big commission, but almost every user has a mobile phone.
Plastic cards are not widespread (yes, yes, the residents of Default City, beyond MKAD there is also life ready to pay!), But the commission is minimal.
Electronic money - a lot of different systems, technical and legal difficulties of connecting, but the audience is large! And how to replenish!
Without stopping in this article on the first two methods, I want to talk about organizing the reception of electronic currencies on the site. Such as WebMoney , Yandex , Dengi@Mail.ru,and the like. The implementation of the work in each case does not bother us, you can read about this in the documentation for these payment systems (PS), and in various kinds of success and failure stories.
The main idea that should arise after reading the article (and I hope it will arise) is that having correctly designed the payment acceptance system, connecting each new system will not be difficult.
I’ll make a reservation right away, hereinafter under the “account” I will understand not account , but rather invoice . And for convenience, so as not to be confused between the user’s account, which contains information about payments, the size of the user's balance of payments, etc., and the invoice for payment of something, the latter will be called an “order” or “order”.
In general, the payment systems that I happened to encounter are divided into two types:
- independently informing the seller of the fact of payment (usually by sending some data in the background to a pre-agreed URL).
- and systems that need to be interviewed about payment status.
Therefore, let's talk about the second.
A typical scenario for working with such systems from the point of view of the seller looks like this:
- user initialization of the payment process, saving the application for payment
- generating an application based on our billing data, signing the application with a secret key or certificate
- sending data to the payment system and receiving the order number in their accounting system
- saving this number in our system
- survey of the payment system regarding the change in the status of this order
- changing the status of the application in our system, providing services to the user
Since we are talking about payments, it’s clear that some kind of billing will be required to account for user payments / applications. It can be arbitrarily complex or simple, for us it can be a “black box”: we will need only two things from it: the amount of the application and its number.
I think you should not specifically discuss why this number should be unique, right?
The remaining data from billing (for example, some textual description of the service) is optional.
How to correctly write billing is a speech for a whole group of articles, so now it’s not about him.
Whoever wants, questions about billing can ask me in private or by mail.
So, let's start with the general architecture.
As it does not seem strange, the recipe for a payment acceptance system architecture according to the described scenario is very, very simple. We need: the
order queue - 1 pc.
queue processing dispatcher - 1 pc.
general library of work with applications - 1 pc.
general web interface library - 1 pc.
general library of work with payment systems - 1 pc.
libraries of work with specific payment systems - N pieces, by the number of systems.
Now more about each of the parts.
1. What is the application queue?
Everything is simple - this is a table of applications of various statuses (in the simplest approximation - “paid”, “unpaid”, “in processing”). We will need it both in order to save information about the application, and in order to understand which applications need to be sent to the dispatcher for processing.
Readers who already recognize the words “normalization” and “relational database” will object that there should be more tables, but I argue that one is enough.
2. Queue processing manager.
This is a certain script launched in the background as a daemon or simply by crown, it doesn’t matter.
Its task is to process the order of applications, contact payment systems and change the status of applications.
3. Library work with applications.
In fact, this is a library for working with a queue (read the "database"). From it you need only a few functions:
- application creation
- receiving information about the application
- Change in status and other application data
- receipt of an application from the queue
- delete application
4. The web interface.
For what it is needed, it is understandable - to display information about the order to the user and so that the user can click on the "Pay" button.
From this library, it is necessary for it to be able to give the same data from several formats: at least html and json / xml. HTML is understandable for what, and JSON is used to use AJAX and not overload pages. In principle, it is possible without it.
From the web interface you need only 4 functions:
- call function to create a request
- call function request data
- call of function of removal of the application
- and the basic function of error handling and data output in the desired format.
5. Libraries for working with specific payment systems (BPS) should be able to
- generate URL and data for the request to create an application in the PS.
- disassemble the response of the payment system and return the order number in the numbering of the payment system
- generate URL and data for requesting application status
- parse the response of the payment system and return the status of the application.
6. From the general library of work with payment systems (OB), you will also need a little:
- function for receiving from BPS the data necessary to create an application and forwarding this data to the payment system.
- function for transmitting a response to the BTS and receiving the application status from there
- function for working with general settings (for example, information about connected payment systems)
How will the described work scenario change in the new terminology?
0. initialization by the user of the payment process.
The web interface displays a list of available payment systems and payment information.
The user presses "Pay", an application is created with the status of "new", information about it falls into the queue. At this moment, the user will receive a message “All will be, wait,” and check from time to time the status of the application. Here we will need the same data about the application in JSON - while we draw the user on the screen all kinds of hours, progress bars, etc., using AJAX we interrogate the queue about the status of the application.
1. formation of an application based on the data of our billing, signature of the application with a secret key or certificate.
2. sending data to the payment system and receiving the order number in their accounting system
3. saving this number in our system.
The dispatcher removes the order with the status of “new” from the queue, sets it to the status “in processing”, transfers the data to the OB, receives the data necessary for sending to the PS. It sends them, receives a response, gives it to OB, that in BPS and receives the order number. It saves the order number and payment URL in our turn, puts the application status “ready for payment”.
At the next poll, the user queues are thrown to the URL to continue payment. What he will do there is his business. In case he realizes that he does not have this electronic currency, on the page with the status of the order we will give him a link to delete the application and create a new one with the ability to choose a different currency.
4. Interrogation of the payment system for changes in the status of the order.
Periodically, the dispatcher receives a request in the status of "ready for payment" and checks its status in the payment system. If the status does not change, put the application aside until better times.
In a good way, you need to take into account the "expiration date" of the application so as not to interrogate the payment system indefinitely.
5. Change the status of the application in our system, the provision of services to the user.
As soon as the status has changed, depending on the response of the payment system, the dispatcher marks the application as “paid” or “rejected”. She will not get to the dispatcher anymore. Now, background billing scripts will receive information that the bill has been paid and will provide the user with the ordered service.
Why is the described system good?
1. It allows you to perform all operations with the user extremely quickly.
Saving the application in the queue, receiving data about the application by a unique number is a very quick operation.
All slow work is done by the dispatcher in the background.
2. It scales well.
We can organize dozens of queues using various partitioning methods.
Tens and hundreds of demons to process each queue or status, or currency.
3. She is simple.
Connecting a new payment system is just adding a new library, which should be able to only 4 things described above.
I don’t voice specific implementation details in this article - the tools are unimportant.
It can be Perl or PHP, or Python for the web / database.
It can be MySQL, or SQLite, or Oracle, or PosgreSQL for queuing.
It can be file_get_contents (), LWP :: UserAgent or CURL for working with HTTP.
You can double the interval of request status polling in the payment system. You can in 3.14159 ...
Implementation is yours.
upd: The full text (including with diagrams and additions) is available on my website