The information provided is true for any payment system. Including for DSS PCI systems, simple acquiring (accepting payments by credit cards), virtual payment systems (Yandex.Money, WebMoney, Robokassa, etc.).

The discussion of the article “RBK Money Payer Transactions Compromised” revealed the critical illiteracy of some commentators. Usually the light of knowledge in ignorance causes fear and irritation, which is interesting to track by the comments. I tried to clarify there in the discussions, for which I paid.

How to program secure payment acceptance? I will share experience, I will tell and show. For those in need, references to provs (evidence) are given at the end of the article.

Characters

There are three of them.
1. User - in general, a living person who uses services.
2. Online store (IM) - browser-based CMS or app with payment function. He must have an owner who has the right to engage in commercial activities (in accordance with the Civil Code of the Russian Federation - IP or legal entity - commercial organization). The owner of the IM must conclude a legal contract with the PS and fulfill the requirements of the latter for technical connection.
3. Payment system (PS) - a service that provides the ability to make payments. Its owner must be a financial organization (a legal entity having legal capabilities to carry out such activities).

User Actions

1. The user selects some goods or services in the IM.
2. The user expresses a desire to buy and pay for the purchase in the IM.
3. IM directs the user to the MS.
4. The user makes a payment in the PS. The user sees that the payment is successful or not successful.
5. The PS prompts the user to return to the IM.
6. If the payment was successful, the user can receive paid goods or services. If the payment was not successful, the user receives a notification.

IM actions

1. IM allows the user to place an order. Usually this is one or more ordered goods and services. Goods and services must clearly indicate the price and the conditions under which they are sold.
2. IM forms an invoice for payment.
3. IM sends the user to the PS, while reporting the account data for payment - identifier, amount.
4. IM receives a notification from the PS about the success or failure of the payment. For this, a special message is sent - by the user! The user does not know about this message. The message format is typically XML or JSON.
5. IM answers the PS about the successful receipt of the notification of the status of the payment. The PS will not accept money if the IM does not work, or does not want to recognize the success of the payment (for example, the account has expired, or other events have occurred that do not allow the IM to recognize this payment). I repeat - in this case, the PS will not accept payment from the user!
6. IM welcomes the user after visiting the PS, reporting the status of the account for payment. In this case, the PS informs the account number IM - in the link or in the data received by POST. User must be logged in! You should not disclose account data for payment to unauthorized persons (stupidity, which was discussed in the notorious comments!). You should program the authorization mechanism in such a way that if an unauthorized user gets to the account page for payment, he should receive a message “Access is denied” and an invitation to log in. If successful, authorization should return (or not lead away) to the current page of the site. If the authorized user is the owner of the account, then he has the right to view his page.

PS actions

1. Accept the user from IM along with the account data for payment.
2. Accept the payment from the user, in accordance with the account details for payment (amount, valid until, currency).
3. Report to IM about the success or failure of the payment (this message is for the IM, not for the user!).
4. Receive a message from IM that IM has successfully received and confirmed a message about the success of the payment! If the IM does not respond, the subscriber will not accept payment from the user (he will return the money and inform that the payment was refused).
5. Inform the user about the success or failure of the payment (this message is for the user, not for IM!).
6. Return the user to the IM, transferring the account number (so that the user can get to the desired page on the IM site).

Invoice for payment

Add this entity to your CMS, if it is not already.

The invoice for payment must have the required properties:
1. Identifier. This is usually a positive integer. IM must inform his PS when requesting payment action!
2. Date when the account was created
3. Time during which the account is valid. This is an optional feature, but it will avoid a lot of stupid situations.
4. Amount
5. User ID. Whose account is this? This is important information that is also used for security.
6. A sign of the validity of the account.
7. Other data.

In IM, in addition to the account, there are other entities: an order, order statuses (sometimes this is not a separate entity, but simply denormalized data), goods and services in an order.
No need to place an order and invoice for payment by one entity. There are technological reasons for this, user cases:
- the user can make several payment attempts;
- the validity (I mean the time of relevance) of the order may differ from the validity of the account, and this is normal;
- The results of malfunctions (including non-technical problems) and break-ins are well recorded. Logs do not store user data (userdata). And in this essence they are;
- other reasons known to developers.

A small offtopic.

If we talked only about programming IM, then it would be worth recalling the following.
1. Prices should be kept in the essence of “goods and services in order”. Prices are changing and this is normal. At the same time, old data should not suffer - prices that were in force earlier at the time of placing orders.
2. You can not do a real removal of goods and services in the IM. They should be displayed as connected data - for the correct display of old orders, when they were available, were in catalogs, etc.

IM actions with a bill payable

1. Creation. At this stage, the order must be fully formed, since data editing during the payment process is not allowed.
2. The invoice for payment should not be edited during the payment process. If the contents of the order are changed and it has not yet been paid, a new invoice must be created for payment, and the old one is declared invalid.
3. Change the status of the account for payment, in accordance with the signal received from the PS. The invoice for payment must be valid (the date of creation of the invoice and the validity period or the validity date of the invoice is checked - this can be done this way and that). In this case, the IM receives a message from the PS in the JSON, XML format or a POST data packet. This message is not affected by the page (made up in HTML, DOC, PDF, RTF). Moreover, it is not intended for people at all.
4. Account page for the user. Must be protected by user session. On this page, the user account owner (or IM employee) can see information about the status of the account: paid, not paid, failed payment, expired, etc.
When changing the status of the account, a trigger should be triggered, which should change the status of the order. This makes it possible to process the online store and related modules: CRM, warehouse, etc.

Security

1. The user must be authorized in the IM before payment.
2. It is good when the user's actions in the IM are hidden from prying eyes through SSL.
3. Messages exchanged between PS and IM are accompanied by hashes, salted with secret codes, which are exclusively unique for each IM - partner of the MS. Hashes are generated from account data. Thus, an attempt to distort the data of the original IM account will lead to a payment failure.
4. All personal data, including information about the status and other details of the accounts, must be protected by the user session! Protecting them with a single hash, as discussed in the notorious comments, is not enough. But the reasons are just revealed there.

Sources

Here are the promised bars.
Yandex.Money api.yandex.ru/money/doc/dg/concepts/About.xml
PayPal developer.paypal.com/webapps/developer/docs/classic/products
WebMoney wiki.webmoney.ru/projects/webmoney/wiki/Web_Merchant_Interface
Robokassa www.robokassa.ru/ru/Doc/Ru/Interface.aspx