QIWI terminals. Alternative way
In truth, I have never dealt with QIWI payment terminals or software for them. Apparently, the stars so formed that my nearly five-year communication with payment machines began with an unknown basement type firm, where in 2006 five pink-colored iron friends were acquired. Nevertheless, seeing how much QIWI terminals are around, I think it will be interesting for their owners to read how I created my own network, with my terminal software, processing and monitoring, and maybe something to adopt.
Perhaps for someone it will be a revelation that 9 years ago not all machines had touch screens. Those that I acquired were arranged roughly like screens at ATMs — a conventional vandal-resistant screen, a separate digital block under the screen, and two rows of four buttons to the left and right of the screen. As a software, the program worked momentalka.exe, to which was attached an extensive manual of 15 A4 sheets, made in the best traditions of student work - 80% water for volume, 20% useful information. Unfortunately, this program has been lost beyond the prescription of time, and I will not be able to demonstrate its interface, a wretched little less than completely. In short, this is a set of jpg-pictures, where possible operators were hard-coded, and they were hard-coded in the program, and if I wanted to change, add or remove something, I myself was in for a severe disappointment. To the credit of the seller, I will say that before shipment on the main screen were exactly those operators that I needed.
At that time, the payment systems market was significantly less developed, and QIWI (and at that time, OSMP) was not the leader, mostly people used the e-port, which was later purchased by QIWI. Compared to QIWI, there were much more possibilities in the e-port: three formats of interaction with the server, the possibility of authorization via a pin code or digital signature to choose from, work via https.
There was no Internet in my machines: there were no 3G modems and generally no third-generation networks at that time in district towns, and the toad strangled to buy 10% of the cost of a GPRS modem. I purchased cheap motorolla E350L phones, the advantage of which was the presence of a USB port for communication and a separate power connector. There were some difficulties with them, but on the whole, the undertaking paid off.
')
They began on the first day of work. As it turned out, the protocol of work with the bill acceptor was worked out extremely crookedly, and often there was a situation when the bill acceptor reported to the host that the bill was not valid, but at the same time it was successfully swallowed. Or not swallowed, but chewed, but, in general, it does not matter: the client firmly believes that his money is about to come to the phone; I, as the owner, also count on it, but in the end we have a lost payment and unrecorded money in the bill acceptor’s steper. I had to compare the contents of the box with the logs of the bills received in the program and find these discrepancies. It often happened that the furious depositors informed us about the problems before we found the “left banknotes”.
The second unpleasant moment was associated with a complete lack of monitoring. Those. It was not possible to find out that the machine still stands in its place, didn’t chew the bill, didn’t freeze, and the Internet didn’t fall on it only indirectly - on occasional payments. At the same time, there was no big pattern between the missing payments and the operability of the terminal, and I often went to the point to come and find out that everything is in order with the machine gun.
Another disappointment was the Internet from the white-green operator. It seems to be the cheapest, but the billing threshold of 100kb at a price for traffic of 6 p / mb poured into 1000 rubles per month for the Internet. As a result, the stationary Internet was held on half of the machines, and on those where there was no such possibility - the operator was replaced, the Internet formally became more expensive, but in reality the Internet costs fell to 100 rubles per month.
One of the terminals was geographically located in the same building where my office was located, so a twisted pair was laid to it, and the terminal itself became the main experimental rabbit. Naturally, the native program from the terminal became the first victim of processing. For a short time, my friend and I investigated through the portmon the bill acceptor protocol, let me remind you that it was 2006, and we could not find any information on the Internet. Nevertheless, everything turned out, we were able to successfully accept banknotes. The second major refinement was the change of work with the e-port servers, we switched to the new protocol of the 2nd version and implemented the authorization via the EDS. In principle, even after 9 years, I am not sure that it was necessary - to intercept the ssl-packet outgoing from the terminal and pull out the pin-code from it is hardly much easier than accessing the machine and taking the EDS from there, and then merging the entire the balance of the agent’s balance on any Yandex money or web mani, but what's done is done.
And finally, the interface has been improved, automatic identification of the number belonging to one or another operator has been implemented, and the first version has been successfully launched. Of course, at first certain bugs and even bugs surfaced, but nothing serious, everything was fixed almost on the fly. Below are a couple of screenshots:
main screen, you can immediately dial the number to pay
after making money, you can shove some more money or pay
After several weeks of successful work without any failures, the logging module was added, which sent all information on the operation of the machine to our own web server: when it turned on or went to reboot, the status of the devices — the receipt printer and bill acceptor, the entered payments and the bills made. All this was stored in the firebird database, so the search for the necessary information was reduced to a simple sql query, be it some kind of statistics or the search for a lost bill.
I also wrote a small web muzzle in a minimalist style for displaying a mobile phone on the screen (no scripts, only a minimum of html) and a program for operators who answered calls and directed me to the right machine in case of any circumstances that required my presence there.
The program for operators. Print queue jobs mean the printer is out of paper.
A little later I made a call using my asterisk to my phone if I had problems with the bill acceptor, in order to quickly arrive and pull out the jammed bill or simply reload the device tortured by customers. It is very convenient - a certain number calls, I immediately go to look at the page with statistics where there are problems and I leave for the place, full automation.
After a year or two of successful work, it became necessary to accept payments for a local Internet provider, where a login was indicated as a personal account, and implementing it on a digital block is extremely problematic, at least for not very advanced grandmothers, who were sent by grandchildren a hundred rubles on the Internet and gave a piece of paper with a login, it would be an overwhelming task. I decided to redo the design and install the touch screen, which was done, not to say that everything turned out easily, but it did.
The software part was by that time processed, or rather divided into two independent modules: one worked with the interface, accepted bills and printed checks, and the second sent all data to the payment system server and logs to my server, and also served as a watchdog for the interface module. Looking ahead, I will say that in the future a check printing module was also selected as a separate executable file. I transferred not all automata to the sensor, but only the part where, in my opinion, this was justified, so the background module was left alone, but the interface was divided into two branches - for touch screens and normal ones. On the one hand, this somewhat complicated the support, because the programs became more, on the other - in two years the non-touch interface was licked to obscenity and I didn’t actually touch it anymore.
Although the interface for working with touch screens allowed me to add some providers that the machine could not physically accept, I decided to limit myself to accepting payments for cellular operators and a local Internet provider, later adding another one. First, observing the behavior of clients, it is possible to state unequivocally that the fewer choices there are, the fewer then there are problems with the fact that this very choice was made wrong. Secondly, my colleagues using OSMP software periodically made attempts to illegally withdraw money to various electronic wallets, and I decided not to bother. Interface pictures below:
the main screen, already have to choose something
in the process of payment
success!
By the time my network worked reliably, bringing a normal income and a minimum of problems, QIWI successfully bought an e-port and began to systematically cover the gateways for running its own software like mine. From time to time the managers called, warning that the gateway had been working for the last month and I could no longer accept payments, and persuaded them to switch to software from OSMP. Perhaps I would have passed, and this story was over, but half of the machines had no touch screens, I did not want to invest in upgrades, and the list of accepted operators is regulated by the payment system, and in some cases my commission.
Therefore, the only acceptable option remained - to leave your software on the terminals and write your processing as. Actually, all the logs from all payment terminals were already being sent to my server by that moment, so I just added an EDS for security and made a small parsing of logs so that the payments were displayed in a separate table in the same database that was used before for logging only . There is only one question left: how to make payments from this table?
Since QIWI really didn’t like the idea of ​​letting me use payment gateways to receive my payments uncontrollably, I had to go for the trick. A QIWI cashier program was installed, which was the operator’s workplace for receiving payments. The operators I needed were hung up on the hotkeys, and my emulator program depicted the operator's intense activity: from the database where the logs from the terminals were merged, the necessary information on payments was selected and conducted via the QIWI cashier. The program emulated pressing the required hot key to select the operator, dialed the payment details and amount and sent the payment to QIWI. All this was spinning in a virtual machine on the same server where the logs were merged, so I did not incur any additional costs. In general, the idea justified itself, except that from time to time it was necessary to glance that the QIWI cashier did not “have performed an unacceptable operation and will be closed” and restart it just as periodically, sometimes even a couple of times a day. However, low fees for the opportunity to leave their software on the network of terminals and fully control their activities.
At that time (2010), the tax inspectorate began to look intently at payment machines, because in most cases cash from the terminals was sold, and in the framework of the fight against cashing through the payment terminals everyone was obliged to use fiscal registrars. Of course, it was possible to deliver them; technically, there were no particular difficulties - but even if you did not take a one-time payment in 3.5 monthly profits from automatic machines, the annual maintenance of the EKLZ would deprive another tenth of the profits.
As a result, it was decided to add to their processing communication with the only fiscal officer standing in the office, and automatic machines on the ground print duplicate checks. I admit at once that the second part of this epic task was not implemented: a duplicate check was printed, but instead of the EDS that the fiscal registrar had to generate in the office, the check had the usual random (65536). As it turned out, the fiscal registrar, while printing the check, displays the “signature” that certifies it, only on the check itself, I could not get this signature programmatically. There was a thought to pull out EKLZ (electronic control tape protected - a block that actually stores all checks and generates a signature) and work directly with him - but from a legal point of view, a sent out cash register with an “honest” EKLZ is hardly better than the same check from wrong signature: the tax authorities check the presence of fiscal in the terminal, if there is - then everything is OK, if not - fine, and whether there are correct checks or not - nobody cares.
I still bought one fiscal registrar, as a result, the receipt printing module was supported not only by printers, but also by fiscal registrars of a certain model, and the checks were printed absolutely identical (not counting the EKLZ code), because the fiscal was made just on the basis of the same printer, My case is the Citizen CBM1000.
Maybe someone will be interested in how I made the printing of identical checks: from the kassy check program, common on the Internet, a font was drawn in the form of a picture consisting of checkered symbols. For printing, a picture was generated consisting of cut characters, in general, a classic example of using a raster font.
In the spring of 2011, I sold this business. But as a bonus, I decided to make the buyer normal processing so that he would not have to constantly look at the radmin at how the robot clicks the virtual buttons in the QIWI cashier.
We started by deciding to look at the cashier’s communication with the server, since you could manually specify which ones were used in the server list. Accordingly, all servers working via https were removed, wireshark was launched and everything became extremely clear: an xml request containing payment data. There were two difficulties: a certain “magic” parameter in the request that was not related to payment, and the EDS of the request. My friend and I decided to solve the first problem rather quickly - ollydbg, an hour of time - and the algorithm for calculating some code that adds up from the date, amount, and terminal number was ready. I had to tinker with the EDS: the cashier used standard Windows CryptoAPI tools, the key was generated non-recoverable, find it in memory and extract, if this is possible in principle, we didn’t have enough skill. Here you need to make a small digression and tell how the process of generating this key. To do this, QIWI has another program - QIWI-protection. It generates this most non-recoverable key, after which the QIWI cashier uses it to sign the sent requests. For generation, the function CryptGenKey is used, in one of the parameters of which various key options are set. We patched the exe file so that we set the CRYPT_EXPORTABLE flag, which allows us to export private keys. After that, we generated the key and successfully extracted it, although not without incident - in the parameter of the CryptExportKey function responsible for the password, we put empty quotes instead of NULL and for two days could not convert the exported key to the desired format. Well, when the bug was defeated, a couple of hours of coding and a php script launched from the crown every thirty seconds on a separate Linux virtual machine sent my payments to the QIWI server.
After another couple of years, my machines were again resold, already a large network that used QIWI software and did not bother with my processing. Apparently, it turned out to be more profitable to double the commission and pay a percentage of the turnover to the bank, under whose sign they worked, than to optimize something. And I turned off the virtual machine with processing, stopped the web server for collecting logs and one more my development became unclaimed.
I was inspired to write this article by the creation of Almazist , although our approaches differ fundamentally, but the essence, in my opinion, is the same - to establish our own rules for our machines. I am not a professional programmer, I do not make a living by writing code, so my development has stopped at Delphi 6, which is relevant during the years of my studies at the institute, and I do not post my source code for everyone to see. But if someone needs to - is ready to share, take it - it is not a pity. I hope it was interesting.
Acquaintance
Perhaps for someone it will be a revelation that 9 years ago not all machines had touch screens. Those that I acquired were arranged roughly like screens at ATMs — a conventional vandal-resistant screen, a separate digital block under the screen, and two rows of four buttons to the left and right of the screen. As a software, the program worked momentalka.exe, to which was attached an extensive manual of 15 A4 sheets, made in the best traditions of student work - 80% water for volume, 20% useful information. Unfortunately, this program has been lost beyond the prescription of time, and I will not be able to demonstrate its interface, a wretched little less than completely. In short, this is a set of jpg-pictures, where possible operators were hard-coded, and they were hard-coded in the program, and if I wanted to change, add or remove something, I myself was in for a severe disappointment. To the credit of the seller, I will say that before shipment on the main screen were exactly those operators that I needed.
At that time, the payment systems market was significantly less developed, and QIWI (and at that time, OSMP) was not the leader, mostly people used the e-port, which was later purchased by QIWI. Compared to QIWI, there were much more possibilities in the e-port: three formats of interaction with the server, the possibility of authorization via a pin code or digital signature to choose from, work via https.
There was no Internet in my machines: there were no 3G modems and generally no third-generation networks at that time in district towns, and the toad strangled to buy 10% of the cost of a GPRS modem. I purchased cheap motorolla E350L phones, the advantage of which was the presence of a USB port for communication and a separate power connector. There were some difficulties with them, but on the whole, the undertaking paid off.
')
First problems
They began on the first day of work. As it turned out, the protocol of work with the bill acceptor was worked out extremely crookedly, and often there was a situation when the bill acceptor reported to the host that the bill was not valid, but at the same time it was successfully swallowed. Or not swallowed, but chewed, but, in general, it does not matter: the client firmly believes that his money is about to come to the phone; I, as the owner, also count on it, but in the end we have a lost payment and unrecorded money in the bill acceptor’s steper. I had to compare the contents of the box with the logs of the bills received in the program and find these discrepancies. It often happened that the furious depositors informed us about the problems before we found the “left banknotes”.
The second unpleasant moment was associated with a complete lack of monitoring. Those. It was not possible to find out that the machine still stands in its place, didn’t chew the bill, didn’t freeze, and the Internet didn’t fall on it only indirectly - on occasional payments. At the same time, there was no big pattern between the missing payments and the operability of the terminal, and I often went to the point to come and find out that everything is in order with the machine gun.
Another disappointment was the Internet from the white-green operator. It seems to be the cheapest, but the billing threshold of 100kb at a price for traffic of 6 p / mb poured into 1000 rubles per month for the Internet. As a result, the stationary Internet was held on half of the machines, and on those where there was no such possibility - the operator was replaced, the Internet formally became more expensive, but in reality the Internet costs fell to 100 rubles per month.
The first improvements
One of the terminals was geographically located in the same building where my office was located, so a twisted pair was laid to it, and the terminal itself became the main experimental rabbit. Naturally, the native program from the terminal became the first victim of processing. For a short time, my friend and I investigated through the portmon the bill acceptor protocol, let me remind you that it was 2006, and we could not find any information on the Internet. Nevertheless, everything turned out, we were able to successfully accept banknotes. The second major refinement was the change of work with the e-port servers, we switched to the new protocol of the 2nd version and implemented the authorization via the EDS. In principle, even after 9 years, I am not sure that it was necessary - to intercept the ssl-packet outgoing from the terminal and pull out the pin-code from it is hardly much easier than accessing the machine and taking the EDS from there, and then merging the entire the balance of the agent’s balance on any Yandex money or web mani, but what's done is done.
And finally, the interface has been improved, automatic identification of the number belonging to one or another operator has been implemented, and the first version has been successfully launched. Of course, at first certain bugs and even bugs surfaced, but nothing serious, everything was fixed almost on the fly. Below are a couple of screenshots:
main screen, you can immediately dial the number to pay
after making money, you can shove some more money or pay
After several weeks of successful work without any failures, the logging module was added, which sent all information on the operation of the machine to our own web server: when it turned on or went to reboot, the status of the devices — the receipt printer and bill acceptor, the entered payments and the bills made. All this was stored in the firebird database, so the search for the necessary information was reduced to a simple sql query, be it some kind of statistics or the search for a lost bill.
I also wrote a small web muzzle in a minimalist style for displaying a mobile phone on the screen (no scripts, only a minimum of html) and a program for operators who answered calls and directed me to the right machine in case of any circumstances that required my presence there.
The program for operators. Print queue jobs mean the printer is out of paper.
A little later I made a call using my asterisk to my phone if I had problems with the bill acceptor, in order to quickly arrive and pull out the jammed bill or simply reload the device tortured by customers. It is very convenient - a certain number calls, I immediately go to look at the page with statistics where there are problems and I leave for the place, full automation.
Switch to sensor
After a year or two of successful work, it became necessary to accept payments for a local Internet provider, where a login was indicated as a personal account, and implementing it on a digital block is extremely problematic, at least for not very advanced grandmothers, who were sent by grandchildren a hundred rubles on the Internet and gave a piece of paper with a login, it would be an overwhelming task. I decided to redo the design and install the touch screen, which was done, not to say that everything turned out easily, but it did.
The software part was by that time processed, or rather divided into two independent modules: one worked with the interface, accepted bills and printed checks, and the second sent all data to the payment system server and logs to my server, and also served as a watchdog for the interface module. Looking ahead, I will say that in the future a check printing module was also selected as a separate executable file. I transferred not all automata to the sensor, but only the part where, in my opinion, this was justified, so the background module was left alone, but the interface was divided into two branches - for touch screens and normal ones. On the one hand, this somewhat complicated the support, because the programs became more, on the other - in two years the non-touch interface was licked to obscenity and I didn’t actually touch it anymore.
Although the interface for working with touch screens allowed me to add some providers that the machine could not physically accept, I decided to limit myself to accepting payments for cellular operators and a local Internet provider, later adding another one. First, observing the behavior of clients, it is possible to state unequivocally that the fewer choices there are, the fewer then there are problems with the fact that this very choice was made wrong. Secondly, my colleagues using OSMP software periodically made attempts to illegally withdraw money to various electronic wallets, and I decided not to bother. Interface pictures below:
the main screen, already have to choose something
in the process of payment
success!
Payment system operator change
By the time my network worked reliably, bringing a normal income and a minimum of problems, QIWI successfully bought an e-port and began to systematically cover the gateways for running its own software like mine. From time to time the managers called, warning that the gateway had been working for the last month and I could no longer accept payments, and persuaded them to switch to software from OSMP. Perhaps I would have passed, and this story was over, but half of the machines had no touch screens, I did not want to invest in upgrades, and the list of accepted operators is regulated by the payment system, and in some cases my commission.
Therefore, the only acceptable option remained - to leave your software on the terminals and write your processing as. Actually, all the logs from all payment terminals were already being sent to my server by that moment, so I just added an EDS for security and made a small parsing of logs so that the payments were displayed in a separate table in the same database that was used before for logging only . There is only one question left: how to make payments from this table?
Own processing, attempt number one
Since QIWI really didn’t like the idea of ​​letting me use payment gateways to receive my payments uncontrollably, I had to go for the trick. A QIWI cashier program was installed, which was the operator’s workplace for receiving payments. The operators I needed were hung up on the hotkeys, and my emulator program depicted the operator's intense activity: from the database where the logs from the terminals were merged, the necessary information on payments was selected and conducted via the QIWI cashier. The program emulated pressing the required hot key to select the operator, dialed the payment details and amount and sent the payment to QIWI. All this was spinning in a virtual machine on the same server where the logs were merged, so I did not incur any additional costs. In general, the idea justified itself, except that from time to time it was necessary to glance that the QIWI cashier did not “have performed an unacceptable operation and will be closed” and restart it just as periodically, sometimes even a couple of times a day. However, low fees for the opportunity to leave their software on the network of terminals and fully control their activities.
Printer
At that time (2010), the tax inspectorate began to look intently at payment machines, because in most cases cash from the terminals was sold, and in the framework of the fight against cashing through the payment terminals everyone was obliged to use fiscal registrars. Of course, it was possible to deliver them; technically, there were no particular difficulties - but even if you did not take a one-time payment in 3.5 monthly profits from automatic machines, the annual maintenance of the EKLZ would deprive another tenth of the profits.
As a result, it was decided to add to their processing communication with the only fiscal officer standing in the office, and automatic machines on the ground print duplicate checks. I admit at once that the second part of this epic task was not implemented: a duplicate check was printed, but instead of the EDS that the fiscal registrar had to generate in the office, the check had the usual random (65536). As it turned out, the fiscal registrar, while printing the check, displays the “signature” that certifies it, only on the check itself, I could not get this signature programmatically. There was a thought to pull out EKLZ (electronic control tape protected - a block that actually stores all checks and generates a signature) and work directly with him - but from a legal point of view, a sent out cash register with an “honest” EKLZ is hardly better than the same check from wrong signature: the tax authorities check the presence of fiscal in the terminal, if there is - then everything is OK, if not - fine, and whether there are correct checks or not - nobody cares.
I still bought one fiscal registrar, as a result, the receipt printing module was supported not only by printers, but also by fiscal registrars of a certain model, and the checks were printed absolutely identical (not counting the EKLZ code), because the fiscal was made just on the basis of the same printer, My case is the Citizen CBM1000.
Maybe someone will be interested in how I made the printing of identical checks: from the kassy check program, common on the Internet, a font was drawn in the form of a picture consisting of checkered symbols. For printing, a picture was generated consisting of cut characters, in general, a classic example of using a raster font.
Processing, second run
In the spring of 2011, I sold this business. But as a bonus, I decided to make the buyer normal processing so that he would not have to constantly look at the radmin at how the robot clicks the virtual buttons in the QIWI cashier.
We started by deciding to look at the cashier’s communication with the server, since you could manually specify which ones were used in the server list. Accordingly, all servers working via https were removed, wireshark was launched and everything became extremely clear: an xml request containing payment data. There were two difficulties: a certain “magic” parameter in the request that was not related to payment, and the EDS of the request. My friend and I decided to solve the first problem rather quickly - ollydbg, an hour of time - and the algorithm for calculating some code that adds up from the date, amount, and terminal number was ready. I had to tinker with the EDS: the cashier used standard Windows CryptoAPI tools, the key was generated non-recoverable, find it in memory and extract, if this is possible in principle, we didn’t have enough skill. Here you need to make a small digression and tell how the process of generating this key. To do this, QIWI has another program - QIWI-protection. It generates this most non-recoverable key, after which the QIWI cashier uses it to sign the sent requests. For generation, the function CryptGenKey is used, in one of the parameters of which various key options are set. We patched the exe file so that we set the CRYPT_EXPORTABLE flag, which allows us to export private keys. After that, we generated the key and successfully extracted it, although not without incident - in the parameter of the CryptExportKey function responsible for the password, we put empty quotes instead of NULL and for two days could not convert the exported key to the desired format. Well, when the bug was defeated, a couple of hours of coding and a php script launched from the crown every thirty seconds on a separate Linux virtual machine sent my payments to the QIWI server.
Conclusion
After another couple of years, my machines were again resold, already a large network that used QIWI software and did not bother with my processing. Apparently, it turned out to be more profitable to double the commission and pay a percentage of the turnover to the bank, under whose sign they worked, than to optimize something. And I turned off the virtual machine with processing, stopped the web server for collecting logs and one more my development became unclaimed.
I was inspired to write this article by the creation of Almazist , although our approaches differ fundamentally, but the essence, in my opinion, is the same - to establish our own rules for our machines. I am not a professional programmer, I do not make a living by writing code, so my development has stopped at Delphi 6, which is relevant during the years of my studies at the institute, and I do not post my source code for everyone to see. But if someone needs to - is ready to share, take it - it is not a pity. I hope it was interesting.
Source: https://habr.com/ru/post/253199/
All Articles