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

Peace be with you,% username%!

In this series of posts I want to talk about some aspects of the implementation of the payment system (and if you are lucky, two), which really had the honor to work 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 this idea only as a user of WebMoney and payment terminals. However, desire + money did the trick and development began.

For starters, what was generally understood as a payment system and how development began.
UPD:
The second part!

The customer wanted the site. No less no less than a site with blackjack and whoresviral wallets, from which one could pay for various services, as well as transfer money to each other. Coverage was planned on the scale of one particular city, no significant loads were planned, therefore we did not bother with high performance and megastability like clustering. And without it there was a lot of 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 were not able to connect directly to FreeBSD from MS SQL Server. In addition, it was planned to write an external module for the DBMS, responsible for the part with cryptography, which put an end to the choice of OS for it.

The key issues for me during development were security issues, as the system worked with what no, but still money.
Almost immediately, the following simple WEB server <-> DB server operation scheme was born:

• The web server has access only to allowed stored procedures in one single database. No SELECT \ INSERT \ DELETE. Only a call of several storages and all .
• All the storages available to the web server, except Auth (login, pass), take the session ID as the first parameter (and first check its survivability), which returns to Auth as hash (random ()) and lives only a few minutes after inactivity.

Thus

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

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

As a first approximation, a safe “three-link” without a “three-link” was obtained, which was quite convenient to steer and which met good, in my opinion, safety criteria. The problems were only when a new storage was added and I forgot to set the permissions for the web server account for it in the parking lot) I had to

think over the database structure (uninteresting) and the system of protecting virtual wallets.

If the habrasociety is interested, in the following parts I will talk about:

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