The information provided is valid for any payment system. This includes for DSS PCI systems, simple acquiring (accepting payments by bank cards), virtual payment systems (Yandex.Money, WebMoney, Robocash, etc.).

Discussion of the article “Compromised transactions of RBK Money payers” showed the critical ignorance of some commentators. Usually, the light of knowledge in ignorance causes fear and irritation, which is interesting to track by comments. I tried to clarify there in the discussions, for which I paid.

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

Characters

There are three of them.
1. The user is generally a live person who uses the services.
2. Online store (IM) - browser CMS or APP with the 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 the legal entity is a commercial organization). The owner of the IM must enter into a legal agreement 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. It must be owned by a financial institution (a legal entity that has legal capacity to carry out this type of activity).
')

User action

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

MI actions

1. IM allows the user to place an order. This is usually one or more ordered goods and services. The goods and services should be clearly marked with the price and terms on which they are sold.
2. IM forms an invoice.
3. MI sends the user to the UA, while informing the invoice data for payment - the identifier, the amount.
4. MI receives a notification from the PS about the success or failure of the payment. For this, a special message is sent - past the user! The user does not know about this message. The message format is usually XML or JSON.
5. IM responds to the PS about the successful receipt of notification of the status of payment. The PS will not accept the money if the IM does not work, or does not wish 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. MI welcomes the user after visiting the PS, informing the status of the account for payment. In this case, the MS informs the IM number of the account - in the link or in the data received by the POST. User must be logged in! It is not necessary to report invoice data to pay to unauthorized persons (nonsense, which was discussed in the notorious comments!). The authorization mechanism should be programmed in such a way that if an unauthorized user gets to the invoice page for payment, he should receive an “Access denied” message and an invitation to log in. Authorization for success must return (or not lead) 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. If the authorized user does not own the account (and is not an employee of the MI), instead of the data, show him ACCESS DENIED.

PS actions

1. Accept the user from the MI along with the account data for payment.
2. Accept payment from the user, in accordance with the data of the invoice for payment (amount, valid until, currency).
3. Report to IM about the success or failure of payment (this is a message for IM, and not for the user!).
4. Receive a message from the IM that the IM has successfully received and confirmed the message about the success of the payment! If the IM does not respond, the PS will not accept payment from the user (will refund the money and notify that payment is denied).
5. Inform the user about the success or failure of the payment (this is a message for the user, not for MI!).
6. Return the user to the MI by transferring the account number (so that the user can get to the necessary page of the MI website).

Invoice for payment

Add this entity to your CMS if it does not already exist.

The invoice must have required properties:
1. Identifier. This is usually a positive integer. MI must necessarily inform his PS when requesting payment action!
2. Date when account is created
3. The 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 to ensure safety.
6. Sign of the validity of the account.
7. Other data.

In IT, besides the invoice, there are other entities: an order, order statuses (sometimes it is not a separate entity, but simply denormalized data), goods and services in the order.
No need to make an order and an invoice for payment by one entity. There are technological reasons for this, use 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 invoice, and this is normal;
- the results of malfunctions (including problems of a non-technical nature) and break-ins are well documented. Logs do not store user data (userdata). And in this essence they are just there;
- other reasons known to developers.

Small offtopic.

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

MI actions with account 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 content of the order is changed and it has not yet been paid - a new invoice must be created for payment, and the old one is declared invalid.
3. Changing the status of the account for payment, in accordance with the signal received from the PS. The invoice must be valid (the date of the invoice creation and the validity period or the validity date of the invoice are checked - this can be done either way). In this case, the IM receives a message from the PS in JSON, XML format or a POST data packet. This message page (imposed in HTML, DOC, PDF, RTF) is by no means affected. Moreover, it is generally not intended for people.
4. Account page for the user. Must be protected by user session. On this page, the user who owns the account (or an employee of the IM) can see information about the status of the account: paid, unpaid, unsuccessful payment, expired, etc.
When the account status changes, the trigger should trigger, which should change the status of the order. This makes it possible to process the online store and its related modules: CRM, warehouse, etc.

Security

1. The user must be authorized in the MI before payment.
2. It is good when user actions in IM are hidden from prying eyes via SSL.
3. Messages exchanged between PS and IM are accompanied by hashes, salted secret codes, which are unique for each IM partner of PS. The hashes are generated from the account data. Thus, an attempt to distort the data of the original IM account will lead to failure of payment.
4. All personal data, including information about the status and other details of 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 there disclosed.

Sources

Here are the promised branches.
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