QIWI terminals. Alternative way
To tell you the truth, I have never dealt with payment terminals from QIWI or with software for them. Apparently, the stars were so formed that my almost five-year conversation with payment machines began with an unknown firm of the basement type, where in 2006 five pink iron friends were acquired. Nevertheless, seeing how many QIWI terminals are around, I think that their owners will be interested to read how I created my own network, with my terminal software, processing and monitoring, and, perhaps, take something into service.
Perhaps for someone it will become a revelation that 9 years ago, far from all machines had touch screens. Those that I purchased were arranged approximately like screens in ATMs - an ordinary vandal-resistant screen, a separate digital unit under the screen, and two rows of four buttons to the left and right of the screen. The momentalka.exe program worked as software, to which was attached an extensive manual of 15 A4 sheets, made in the best traditions of student work - 80% of the water for the volume, 20% of useful information. Unfortunately, this program was lost a long time ago, and I will not be able to demonstrate its interface, wretched a little less than completely. In short, this is a set of jpg images where they werehardcoatedpossible operators were drawn, in the program they were hard-coded, and if I wanted to change, add or remove something myself, I was severely disappointed. To the seller’s credit, I’ll say that before shipment on the main screen were exactly the operators that I needed.
At that time, the market for payment systems was much less developed, and QIWI (and OSMP in those days) was not a leader, mainly people used the e-port, subsequently purchased by QIWI. Compared to QIWI, the e-port had much more possibilities: three formats for interacting with the server, the possibility of authorization via a pin code or digital signature, to choose from, and work via https.
The Internet was absent in my vending machines: there were no 3G modems and indeed third-generation networks at that time in county towns like mine, and the toad strangled the toad for 10% of the cost of the vending machine. I bought 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 idea paid off.
They started on the first day of work. As it turned out, the protocol for working with the bill acceptor was worked out extremely crookedly, and often a situation arose when the bill acceptor reported to the host that the bill was unusable, but successfully swallowed it. Or he didn’t swallow, but chewed, but this, in general, doesn’t matter: the client firmly believes that his money is about to arrive on the phone; I, as the owner, also count on this, but in the end we have a lost payment and unaccounted for money in the stacker of the bill acceptor. I had to compare the contents of the box with the logs of the accepted bills in the program and find these discrepancies. It often happened that angry investors informed us of problems earlier than we found "left banknotes."
The second unpleasant moment was associated with a complete lack of monitoring. Those. to find out that the machine is still standing in its place, didn’t jam the bill, it didn’t hang and the Internet didn’t fall on it, it was possible only indirectly - on periodic payments. At the same time, there was no big pattern between the missing payments and the terminal’s performance, and often I went to the point to arrive to find out that everything was okay with the machine.
Another disappointment was the Internet from a white-green operator. It seems to be the cheapest, but the charging threshold of 100kb at a price for traffic of 6 r / mb poured into 1000 rubles per month for the Internet. As a result, stationary Internet was carried out on half of the machines, and on those where this was not possible, the operator was replaced, the Internet formally became more expensive, but in reality the Internet costs fell to 100 r / month.
One of the terminals was located in the same building where my office was located, so twisted pair cables were laid to it, and the terminal itself became the main experimental rabbit. Naturally, the first victim of the processing was the native program from the terminal. For a short time, my friend and I examined through the portmon the protocol of the bill acceptor, I recall that this was the year 2006, and we could not find information on the Internet. Nevertheless, everything worked out, we were able to successfully accept bills. The second major improvement was the change in working with e-port servers, we switched to a new protocol of the 2nd version and implemented authorization by digital signature. In principle, even after 9 years, I’m not sure if it was necessary to intercept the ssl packet coming from the terminal and remove the pin code from it, it is hardly much easier than accessing the machine and taking the digital signature from there,
Well, finally, the interface was finalized, automatic identification of the number belonging to one or another operator was implemented, and the first version successfully worked. Of course, at first certain bajochki and even bugs surfaced, but nothing serious, everything was eliminated almost on the fly. Below are a couple of screenshots: the
main screen, you can immediately dial the number for payment
after making the money, you can stick in some more money or pay
After several weeks of successful work, without any glitches, the logging module was added, which sent all information on the machine's operation to our own web server: when it turned on or went to reboot, the status of the devices - a receipt printer and bill acceptor, entered payments and banknotes 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 a search for a lost bill.
He also wrote a small web muzzle in a minimalistic style for displaying on a mobile phone’s 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 requiring my presence there.
Program for operators. Tasks in the print queue mean that the printer is out of paper
A little later I made an asterisk ringing my phone in case of problems with the bill acceptor in order to quickly arrive and pull out the jammed bill or simply restart the device tortured by customers. It’s very convenient - a certain number rings, I immediately go to look at the statistics page where there are problems and go to 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 to enter it on a digital block is extremely problematic, at least for not too advanced grandmothers whom the grandchildren sent to put a hundred rubles on the Internet and gave a piece of paper with a login, this would be an impossible task. I decided to redo the design and install the touch screen, which was done, not to say that everything turned out easily, but still it turned out.
By that time, the software part was redesigned, or rather divided into two independent modules: one worked with the interface, accepted banknotes and printed checks, and the second sent all the 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, the receipt printing module was also allocated into a separate executable file. I did not transfer all the machines to the sensor, but only the part where, in my opinion, it was justified, so the background module was left alone, but the interface modules were divided into two branches - for touch screens and ordinary ones. On the one hand, this somewhat complicated the support, because there were more programs, on the other hand, in two years the non-touch interface was licked to indecent and I never touched it anymore.
Although the interface for working with touchscreens made it possible to add some providers that the machine couldn’t accept physically before, I decided to limit myself to accepting payments for mobile operators and the local Internet provider, later adding another one. Firstly, observing the behavior of customers, it can be clearly stated - the fewer choices, the less then the problems that this choice was made incorrectly. Secondly, colleagues using OSMP software periodically had attempts to illegally withdraw money to various electronic wallets, and I decided not to bother. Pictures of the interface below: the
main screen, you already have to choose something
in the payment process
success!
By the time my network was working reliably, bringing a normal income and a minimum of problems, QIWI successfully bought an e-port and began to systematically close the gateways for my own software to work like mine. Managers called from time to time, warning that the gateway had been working for the last month and I could no longer accept payments, and persuaded me to switch to software from OSMP. Perhaps I would have gone over and this story ended, but half of the vending machines were without touch screens, I did not want to invest in modernization, moreover, the list of accepted operators is regulated by the payment system, and in some cases my commission.
Therefore, the only acceptable option was to leave your software on the terminals and write your processing in quality. Actually, all the logs from all payment terminals were already sent to my server by that time, so I just added an electronic digital signature for security and did a little parsing of the logs so that the payments would be displayed in a separate table in the same database that was previously used exclusively for logging . There is only one question left: how to make payments from this table?
Since QIWI really did not like the idea of letting me use payment gateways to uncheck my payments, I had to trick. The QIWI cashier program was installed, which was the operator’s workplace for receiving payments. The operators I needed were hung on the hot keys, and my emulator program depicted the operator’s ebullient activity: from the database where the logs from the terminals merged, the necessary payment information was selected and carried out through a QIWI cashier. The program emulated pressing the desired hot key to select an operator, typed in 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 additional costs. On the whole, the idea paid off, unless you periodically had to look, that the QIWI cashier didn’t “perform an unacceptable operation and will be closed”, and restart it equally periodically, sometimes even a couple of times a day. However, a low fee for the ability to leave your software on a network of terminals and fully control their activities.
At that time (2010), the tax inspectorate began to look closely at payment machines, because in most cases cash from terminals was sold, and as part of the fight against cashing through payment terminals, everyone was obliged to use fiscal registrars. Of course, it was possible to supply them, there weren’t any technical difficulties - but even if you didn’t take a one-time payment of 3.5 monthly profits from automatic machines, the annual maintenance of EKLZ alone would deprive another tenth of the profit.
As a result, it was decided to add communication with the only fiscal person who is in the office to his processing, and the machines in the field print duplicate checks. I must admit right away that the second part of this epic task was not realized: a duplicate check was printed, but instead of the digital signature that the fiscal registrar should generate in the office, the check had the usual random (65536). As it turned out, the fiscal registrar, printing a check, displays a “signature” that certifies it, only on the check itself, I could not get this signature programmatically. There was an idea to pull out an EKLZ (a secure electronic control tape - a unit that actually stores all receipts and generates a signature) and work directly with it - but from a legal point of view, a gutted cash register with an “honest” EKLZ is hardly better than the same check with wrong signature:
I still bought one fiscal registrar, as a result, the check print module began to support not only printers, but also fiscal registrars of a certain model, and the checks were printed absolutely identical (apart from the EKLZ code), since the fiscal card was made just on the basis of the same printer, in my case is the Citizen CBM1000.
Maybe someone will be interested in how I printed identical checks: from a kassy check printing program common on the Internet, a font was extracted in the form of an image consisting of symbol cells. A print consisting of cut out characters was generated for printing, in general, a classic example of using a bitmap font.
In the spring of 2011, I sold this business. But as a bonus, he decided to make the buyer normal processing so that he did not have to constantly look in 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 the ones used in the list of servers. Accordingly, all servers working via https were removed, wireshark was launched and everything became very clear: an xml-request containing payment data. There were two difficulties: a certain “magic” parameter in the request, which had nothing to do with payment, and an electronic digital signature of the request. My friend and I resolved the first problem quite quickly - ollydbg, an hour of time - and the algorithm for calculating a certain code, consisting of the date, amount and terminal number, was ready. I had to tinker with the digital signature: the cashier used standard Windows CryptoAPI tools, the key was generated unrecoverable, find it in memory and extract, if this is possible in principle, we did not have the skill. Here you need to make a small digression and tell how the process of generating this key occurs. To do this, QIWI has one more program - QIWI protection. It generates this same non-recoverable key, after which the QIWI cashier uses it to sign the requests sent. For generation, the CryptGenKey function is used, in one of the parameters of which various key options are set. We patched the exe file in such a way as to set the CRYPT_EXPORTABLE flag, which allows exporting private keys. After that, the key was generated and it was successfully extracted, although not without incident - in the parameter parameter of the CryptExportKey function responsible for the password, empty quotation marks were set instead of NULL and for two days they could not convert the exported key to the format we needed. Well, when the bug was defeated - a couple more hours of coding and a php script launched from the crown every thirty seconds on a separate Linux virtual machine,
After a couple of years, my machines were resold again, 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 the guise of which they worked, than to optimize something. And I turned off the virtual machine with processing, stopped the web server for collecting logs, and another development of mine became unclaimed.
I was inspired to write this article by Almazist, although our approaches differ radically, but the essence, in my opinion, is the same - to establish their own rules for their machines. I’m not a professional programmer, I don’t make a living by writing code, so my development stopped at Delphi 6, which was relevant during the years of my studies at the institute, and I don’t put my source code on public display. But if someone needs it - he’s ready to share it, take it - it’s not a pity. I hope it was interesting.
Acquaintance
Perhaps for someone it will become a revelation that 9 years ago, far from all machines had touch screens. Those that I purchased were arranged approximately like screens in ATMs - an ordinary vandal-resistant screen, a separate digital unit under the screen, and two rows of four buttons to the left and right of the screen. The momentalka.exe program worked as software, to which was attached an extensive manual of 15 A4 sheets, made in the best traditions of student work - 80% of the water for the volume, 20% of useful information. Unfortunately, this program was lost a long time ago, and I will not be able to demonstrate its interface, wretched a little less than completely. In short, this is a set of jpg images where they were
At that time, the market for payment systems was much less developed, and QIWI (and OSMP in those days) was not a leader, mainly people used the e-port, subsequently purchased by QIWI. Compared to QIWI, the e-port had much more possibilities: three formats for interacting with the server, the possibility of authorization via a pin code or digital signature, to choose from, and work via https.
The Internet was absent in my vending machines: there were no 3G modems and indeed third-generation networks at that time in county towns like mine, and the toad strangled the toad for 10% of the cost of the vending machine. I bought 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 idea paid off.
First problems
They started on the first day of work. As it turned out, the protocol for working with the bill acceptor was worked out extremely crookedly, and often a situation arose when the bill acceptor reported to the host that the bill was unusable, but successfully swallowed it. Or he didn’t swallow, but chewed, but this, in general, doesn’t matter: the client firmly believes that his money is about to arrive on the phone; I, as the owner, also count on this, but in the end we have a lost payment and unaccounted for money in the stacker of the bill acceptor. I had to compare the contents of the box with the logs of the accepted bills in the program and find these discrepancies. It often happened that angry investors informed us of problems earlier than we found "left banknotes."
The second unpleasant moment was associated with a complete lack of monitoring. Those. to find out that the machine is still standing in its place, didn’t jam the bill, it didn’t hang and the Internet didn’t fall on it, it was possible only indirectly - on periodic payments. At the same time, there was no big pattern between the missing payments and the terminal’s performance, and often I went to the point to arrive to find out that everything was okay with the machine.
Another disappointment was the Internet from a white-green operator. It seems to be the cheapest, but the charging threshold of 100kb at a price for traffic of 6 r / mb poured into 1000 rubles per month for the Internet. As a result, stationary Internet was carried out on half of the machines, and on those where this was not possible, the operator was replaced, the Internet formally became more expensive, but in reality the Internet costs fell to 100 r / month.
First improvements
One of the terminals was located in the same building where my office was located, so twisted pair cables were laid to it, and the terminal itself became the main experimental rabbit. Naturally, the first victim of the processing was the native program from the terminal. For a short time, my friend and I examined through the portmon the protocol of the bill acceptor, I recall that this was the year 2006, and we could not find information on the Internet. Nevertheless, everything worked out, we were able to successfully accept bills. The second major improvement was the change in working with e-port servers, we switched to a new protocol of the 2nd version and implemented authorization by digital signature. In principle, even after 9 years, I’m not sure if it was necessary to intercept the ssl packet coming from the terminal and remove the pin code from it, it is hardly much easier than accessing the machine and taking the digital signature from there,
Well, finally, the interface was finalized, automatic identification of the number belonging to one or another operator was implemented, and the first version successfully worked. Of course, at first certain bajochki and even bugs surfaced, but nothing serious, everything was eliminated almost on the fly. Below are a couple of screenshots: the
main screen, you can immediately dial the number for payment
after making the money, you can stick in some more money or pay
After several weeks of successful work, without any glitches, the logging module was added, which sent all information on the machine's operation to our own web server: when it turned on or went to reboot, the status of the devices - a receipt printer and bill acceptor, entered payments and banknotes 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 a search for a lost bill.
He also wrote a small web muzzle in a minimalistic style for displaying on a mobile phone’s 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 requiring my presence there.
Program for operators. Tasks in the print queue mean that the printer is out of paper
A little later I made an asterisk ringing my phone in case of problems with the bill acceptor in order to quickly arrive and pull out the jammed bill or simply restart the device tortured by customers. It’s very convenient - a certain number rings, I immediately go to look at the statistics page where there are problems and go to 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 to enter it on a digital block is extremely problematic, at least for not too advanced grandmothers whom the grandchildren sent to put a hundred rubles on the Internet and gave a piece of paper with a login, this would be an impossible task. I decided to redo the design and install the touch screen, which was done, not to say that everything turned out easily, but still it turned out.
By that time, the software part was redesigned, or rather divided into two independent modules: one worked with the interface, accepted banknotes and printed checks, and the second sent all the 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, the receipt printing module was also allocated into a separate executable file. I did not transfer all the machines to the sensor, but only the part where, in my opinion, it was justified, so the background module was left alone, but the interface modules were divided into two branches - for touch screens and ordinary ones. On the one hand, this somewhat complicated the support, because there were more programs, on the other hand, in two years the non-touch interface was licked to indecent and I never touched it anymore.
Although the interface for working with touchscreens made it possible to add some providers that the machine couldn’t accept physically before, I decided to limit myself to accepting payments for mobile operators and the local Internet provider, later adding another one. Firstly, observing the behavior of customers, it can be clearly stated - the fewer choices, the less then the problems that this choice was made incorrectly. Secondly, colleagues using OSMP software periodically had attempts to illegally withdraw money to various electronic wallets, and I decided not to bother. Pictures of the interface below: the
main screen, you already have to choose something
in the payment process
success!
Change of payment system operator
By the time my network was working reliably, bringing a normal income and a minimum of problems, QIWI successfully bought an e-port and began to systematically close the gateways for my own software to work like mine. Managers called from time to time, warning that the gateway had been working for the last month and I could no longer accept payments, and persuaded me to switch to software from OSMP. Perhaps I would have gone over and this story ended, but half of the vending machines were without touch screens, I did not want to invest in modernization, moreover, the list of accepted operators is regulated by the payment system, and in some cases my commission.
Therefore, the only acceptable option was to leave your software on the terminals and write your processing in quality. Actually, all the logs from all payment terminals were already sent to my server by that time, so I just added an electronic digital signature for security and did a little parsing of the logs so that the payments would be displayed in a separate table in the same database that was previously used exclusively for logging . There is only one question left: how to make payments from this table?
Custom processing, number one attempt
Since QIWI really did not like the idea of letting me use payment gateways to uncheck my payments, I had to trick. The QIWI cashier program was installed, which was the operator’s workplace for receiving payments. The operators I needed were hung on the hot keys, and my emulator program depicted the operator’s ebullient activity: from the database where the logs from the terminals merged, the necessary payment information was selected and carried out through a QIWI cashier. The program emulated pressing the desired hot key to select an operator, typed in 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 additional costs. On the whole, the idea paid off, unless you periodically had to look, that the QIWI cashier didn’t “perform an unacceptable operation and will be closed”, and restart it equally periodically, sometimes even a couple of times a day. However, a low fee for the ability to leave your software on a network of terminals and fully control their activities.
a printer
At that time (2010), the tax inspectorate began to look closely at payment machines, because in most cases cash from terminals was sold, and as part of the fight against cashing through payment terminals, everyone was obliged to use fiscal registrars. Of course, it was possible to supply them, there weren’t any technical difficulties - but even if you didn’t take a one-time payment of 3.5 monthly profits from automatic machines, the annual maintenance of EKLZ alone would deprive another tenth of the profit.
As a result, it was decided to add communication with the only fiscal person who is in the office to his processing, and the machines in the field print duplicate checks. I must admit right away that the second part of this epic task was not realized: a duplicate check was printed, but instead of the digital signature that the fiscal registrar should generate in the office, the check had the usual random (65536). As it turned out, the fiscal registrar, printing a check, displays a “signature” that certifies it, only on the check itself, I could not get this signature programmatically. There was an idea to pull out an EKLZ (a secure electronic control tape - a unit that actually stores all receipts and generates a signature) and work directly with it - but from a legal point of view, a gutted cash register with an “honest” EKLZ is hardly better than the same check with wrong signature:
I still bought one fiscal registrar, as a result, the check print module began to support not only printers, but also fiscal registrars of a certain model, and the checks were printed absolutely identical (apart from the EKLZ code), since the fiscal card was made just on the basis of the same printer, in my case is the Citizen CBM1000.
Maybe someone will be interested in how I printed identical checks: from a kassy check printing program common on the Internet, a font was extracted in the form of an image consisting of symbol cells. A print consisting of cut out characters was generated for printing, in general, a classic example of using a bitmap font.
Processing, second run
In the spring of 2011, I sold this business. But as a bonus, he decided to make the buyer normal processing so that he did not have to constantly look in 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 the ones used in the list of servers. Accordingly, all servers working via https were removed, wireshark was launched and everything became very clear: an xml-request containing payment data. There were two difficulties: a certain “magic” parameter in the request, which had nothing to do with payment, and an electronic digital signature of the request. My friend and I resolved the first problem quite quickly - ollydbg, an hour of time - and the algorithm for calculating a certain code, consisting of the date, amount and terminal number, was ready. I had to tinker with the digital signature: the cashier used standard Windows CryptoAPI tools, the key was generated unrecoverable, find it in memory and extract, if this is possible in principle, we did not have the skill. Here you need to make a small digression and tell how the process of generating this key occurs. To do this, QIWI has one more program - QIWI protection. It generates this same non-recoverable key, after which the QIWI cashier uses it to sign the requests sent. For generation, the CryptGenKey function is used, in one of the parameters of which various key options are set. We patched the exe file in such a way as to set the CRYPT_EXPORTABLE flag, which allows exporting private keys. After that, the key was generated and it was successfully extracted, although not without incident - in the parameter parameter of the CryptExportKey function responsible for the password, empty quotation marks were set instead of NULL and for two days they could not convert the exported key to the format we needed. Well, when the bug was defeated - a couple more hours of coding and a php script launched from the crown every thirty seconds on a separate Linux virtual machine,
Conclusion
After a couple of years, my machines were resold again, 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 the guise of which they worked, than to optimize something. And I turned off the virtual machine with processing, stopped the web server for collecting logs, and another development of mine became unclaimed.
I was inspired to write this article by Almazist, although our approaches differ radically, but the essence, in my opinion, is the same - to establish their own rules for their machines. I’m not a professional programmer, I don’t make a living by writing code, so my development stopped at Delphi 6, which was relevant during the years of my studies at the institute, and I don’t put my source code on public display. But if someone needs it - he’s ready to share it, take it - it’s not a pity. I hope it was interesting.