Some aspects of the development of payment systems. Part I. Three-link without three-link

Peace to you,%% username!

In this series of posts, I want to talk about some aspects of the implementation of the payment system (and if there are two lucky ones) that have actually had the honor of working since the mid-2000s in one of the cities of our vast country.

What is PS in general, and by what principles should it work? I, like the customer, had an idea about this only as a user of WebMoney and payment terminals. However, the desire + money did its job and the development began.



For a start, what was generally understood by the payment system and how the development began.

UPD:

The second part!



The customer wanted a site. No more no less a site with blackjack and whores with viral wallets, from which one could pay for various services, as well as transfer money to each other. It was planned to cover on a scale of one separately taken city, no significant loads were planned, therefore, we did not bother with particularly high performance and megastability like clustering. And without this there were many interesting things.



The web server was FreeBSD with Apache, the database server on Windows with MySQL.

Unfortunately, Postgre at that time was (and still is) a dense forest for me, and we couldn’t connect directly to MS SQL Server directly from under FreeBSD. In addition, it was planned to write an external module for a DBMS that is responsible for the cryptographic part, which put an end to the choice of OS for it.

')

The key questions for me in the development were safety issues, because The system worked with no money, but all the same.

Almost immediately, the following simple scheme of the WEB server <-> DB server was born:

• A web server has access only to authorized stored procedures in one single database. No SELECT \ INSERT \ DELETE. Just call a few things and that's it .
• All storages available to the web server, except Auth (login, pass), take the session ID as the first parameter (and first of all check its survivability), which is returned to Auth as hash (random ()) and lives only a few minutes after inactivity.

In this way

• We are 100% protected from SQL inject
• 99% defended against an attacker in the event of a complete compromise of the web server (1% leave for holes in MySQL and the firewall). You can make the login account \ password for the web / qwerty database for the web server account and sleep well. Hacker loser will see only empty results
• All the logic of the system is implemented in storage, in fact, the web server only calls them and shows the decorated result to the user.

From the user's side, the traffic was protected by SSL with the certificate purchased from VeriSign.



In the first approximation, a safe “three-door” without a “three-door” was obtained, which was quite convenient to steer and which answered good, in my opinion, safety criteria. The problems were only when a new store was added and I forgot to set the rights for the web server account for it)



It was necessary to think over the structure of the database (uninteresting) and the system of protection of virtual wallets.



If it is interesting to the community, in the following sections I will talk about:

• Protect the client, in particular, about the EDS system using elliptic curves and screwing this whole miracle to MySQL.
• The prototype of the "farm payment modules".
• Development from scratch of the payment system for self-service terminals.