To receive payments from private clients, we have always used the services of aggregators. At first, we wanted to diversify between payment acceptance services, then there appeared requirements for issuing electronic checks ... In a word, there were many hotel wishes and requirements both on our part and on the part of the state. In this article we will share our experience and talk about a rake in tall grass that we had to step on and that we managed to avoid. I think that the described experience can be useful to all those who are still at the beginning of the path of integrating payments into their system.
Image from giphy.com
There were two merry cashiers at the granny ...
Our private clients check documents 3 times more corporate. From the very beginning of our business and until now, we have carefully preserved the possibility of a free search for loans on the Internet. Paid services have the following advantages:
- higher priority when checking
- lack of restrictions on the number of documents being checked per unit of time;
- the availability of a wide selection of search modules for connection.
The cost of a paid service consists of deductions from content providers and the costs of maintaining the audit infrastructure (including free ones) for private customers.
Now one check on the Joint Collection (OK), which includes all possible search modules, costs 270 rubles. Single checks are enough for ordinary users, and for ordinary users, checking is not very expensive. Those who check massively, we conditionally divide for ourselves into two classes: honest and dishonest. If this is an organization engaged in education or in need of a loan checker service to control the quality of scientific or other textual work, we offer to become our corporate clients, which reduces the clientâs costs in terms of one check. For âtunersâ and custom writers (guess what category they belong to), the path to the corporate segment is closed. That is our principle, we do not conclude contracts with companies that are doubtful, in our opinion. We also control the activities of our clients to prevent the use of corporate accounts in "business" purposes (heuristics, machine learning, that's all). In our history, there were several terminations of contracts after we found out that the client was not the one he claimed to be. Unfortunately, we cannot conclude an agreement with each private user, therefore, an offer is used for them. This is convenient for private users, but at the same time we cannot control who uses paid access, as a store cannot forbid to buy goods displayed on a window from him. The cost of mass inspections for private customers will increase steadily. Thus, we make writing work to order an expensive pleasure and adhere to our mission to improve education in Russia and the world.
How it all began
Our service transferred some of the previously free services for private clients to the category of paid services on May 4, 2010. Up to this point, all the functionality was fully available, only checks on external collections were paid, for which we, in turn, paid the content providers themselves. We have made a paid service the formation of a full report. Obviously, users were unhappy and easily calculated our fabulous incomes.
Screenshots of the statements of April-May 2010 from our forum.
Alas, I still do not have real estate in Cyprus, despite the fact that I wrote the first version of billing.
First Robot Touch
To launch mass payments, we used an already proven solution - integration with Robokassa (RK). Until May 4, 2010, we accepted payments for examinations on dissertations and legal documents. The RK service suited us. Integration was as simple as felt boots, on our side we had to do a minimum: just redirect to the cashier's website and cashier's callback handler about the payment status. The standard user action scenario was as follows:
- The user selects a product on the site, clicks the pay button.
- The site (with the participation of the billing service, but this is not so important in the current context) redirects to the Robokassa service, indicating the store identifier, product and payment amount.
- The user on the site pays for the goods.
- The cash desk service accepts the money and notifies us of the payment by a call back (callback, in Russian).
- ... magic is happening here ...
- Profit !!! Money is transferred to the account of the company minus the commission.
Everything was set up and worked for years. And as you know: it works - do not touch! It could not last forever, I had to change something.
Y (et) a (nother)
We live in a turbulent time of change and opportunity. At the end of December 2015, the process of revoking licenses from banks was in full swing, and since any payment system is tied to a bank, we decided that we needed a backup option. Plan B will not allow us at some point to remain without the ability to accept payment. From more or less large aggregators of payments, the choice fell on Yandex.Kassa (Yak). The task was done in record time, for the last 3 days of December, and we went on vacation with covered rear. By the way, the risks in relation to Kazakhstan were not realized, but we got an alternative payment system. Do not throw it away! Since then they have been working together. Two happy geese!
Experience not yet applied
As I already wrote, we want to develop Anti-Plagiarism and be less distracted by side things. Paid services for private clients is an opportunity to continue to provide free services.
It so happened that we implemented the integration in the simplest possible ways that each of the payment aggregators offered. Therefore, we have a very clear payment page with two different mechanisms for two different cash desks.
For the Republic of Kazakhstan, the choice of payment method occurs after going to the aggregator page, for UC - on our page, before the transition. To understand the correlation of the payment profile with the load below, blue is the share of money received through Kazakhstan, and orange is the number of paid checks.
So, without really worrying about the implementation, we tested the usability of two options for payment interfaces. It seems that users prefer the option of UC. Bursts above 50% are characteristic for the very beginning of the use of UC and lightly loaded periods of the year when the number of payments is less. Apparently, at this moment, the fact that the RC is higher and selected by default is more influenced.
Babusya Atol FF Dekhovna
Let us make a reservation right away: we do not violate the laws of physics and the Russian Federation. Therefore, together with everyone, they began to look for a solution to write checks from July 1, 2017 in accordance with Federal Law No. 290 . Searched in advance, just during the next spring session. It immediately became obvious that we would not be putting up the cashier and knocking out checks manually.
By the deadline set by the state, we, like many companies in the country, did not meet the deadline. This happened for the prosaic reason for the lack of an online booking office as a service. At that time, many offered various other options. For example, in Robokassa there was an option with the sale of their goods in their store. It looked somehow not very. Most of all, we were impressed by the KaaS approach - checkout as a service. One of the first (if not the very first) such a service was offered by Atol.
Despite the hype, we quickly concluded a contract, bought and registered a fiscal drive - a special flash drive for storing all transactions that were knocked out through the cash register.
It was indicative that both of our geese almost immediately began to support integration with Babusey-Atol. As the fairy tale says: we began to live, live, and make good.
Transition to FFD 1.05
Everyone knows that it is necessary to start a new life on January 1 (as soon as you wake up, yeah). True, this is clearly not the best time for the introduction of any legislative changes. However, from January 1, 2019, we all had to switch to the new version of the fiscal document format (FFD) 1.05. The changes are cheap, but I still shudder from the memories of the events of this update.
The study of the issue showed that it is necessary to add only two parameters to the transferred values: the calculation object (payment_object, payment_subject) and the calculation method (payment_method, payment_mode). For our only product, the Anti-Plagiarism score, indicating this pair of parameters cost nothing. Here is a simple plan diagram for achieving the Go to FFD Support v1.05 goal:
- Refine the site so that it passes a couple of new constants in the requests;
- Check with aggregators that they understand and accept all this;
- Switch in Atole FFD format to version 1.05;
- ... magic is happening here ...
- Profit !!!
The parameters do not change in time and do not depend on anything, set once - and thatâs all, a freebie. So they thought, in fact, everything turned out to be not so easy at all ... What could have gone wrong?
- The development department finalized the site of the Anti-Plagiarism, we rolled it out into the prod. We checked with our technical support and specialists of both aggregators that everything works and the new data is transmitted correctly.
- In the process of change, one of the aggregators saw new information for itself: the value of the âsiteâ field should coincide symbolically with the value specified in Atola (WTF 1 - why the requirement for this coincidence, because there is an INN and all sorts of other things?) As it turned out later, this very important.
- Ok, let's change. In Atola, on one page in your account there is a field with the website address and a daw about the transition to the FFD version 1.05. Fine! Iâm changing the site to www.antiplagiat.ru (I removed the http that stood there before, added www) and put a daw on the transition to the FFD version 1.05. Three working days to change (WTF 2 - is it really that the engineer personally goes there and changes the cash desk firmware?)! Nuuuuu approx. For now, Iâll expose the same site values ââon aggregators. Changed. That's it, we are waiting for the change on 1.05.
- The next morning I receive information that the checks are not beaten out. The atol managed faster than three working days and changed the version of the FFD, but did not change the site address: antiplagiat.ru (WTF 3 - well, how so ?! The site is changed by hands somewhere too?). When changing the address of the site, RK itself quietly added âhttp: //â: www.antiplagiat.ru (WTF 4 - I wanted the check to be smaller and without a protocol, but it wonât work because of one aggregator). Yak like well done, everything worked as it should www.antiplagiat.ru . Total - checks are not written out to any of the aggregators, because everywhere the different name of the site. But I specifically made them the same the day before!
- I swear with everyone on the phone, Atol is handsome, they have one fee for any request: 3 working days. I turn off the RK, because they canât change the site to the one that is currently registered in Atola, because the site must be with http or https. Iâm changing the site in the UC to the one now at Atola (the benefit is quickly changing there and there is no http requirement). Hooray, checks begin to be written out! The atoll turned out to be motivated by my speech on the phone and in half an hour changes the site to www.antiplagiat.ru (this format suits the Republic of Kazakhstan). At this moment, knocking out checks on the UC ceases to work, because there the old site is registered. I change through my personal account, it does not change, I call in TP, they change. Turn on the RK.
- Fuh, it seems to work everywhere. It remains to deal with unwritten checks. There are several hundred of them. RK - at the request of the phone runs all of their own with the new value of the site, they pass. YAK:
Cat of our employee
Explanation: we sent the check to Atoll, he returned to us, they say, the check is incorrect. We have kept this information with us and now nothing can be done with it (WTF 5 - it still kills me, as if their system is not their own). December 29 - a working Saturday (WTF 6 - but here itâs just out of habit, December turned out to be successful for pain, remember the previous article , the action with clouds takes place in parallel), is not the best day for proceedings. What to do with non-stamped checks, we will think in January. - Everything works fine, with a calm soul, we are going to celebrate the New Year. December 29, at 20 hours, treacherously, without declaring war, the UC changes the address of the site to another. Checks through them cease to be written out.
Why they did so, they could not explain. They said something about a letter from Atola. Apparently, this couple wanted to do the best. Atol took care of those who were not aware of this requirement, since the site address in the aggregator of payments and cash desk did not match. Only the data, you see, were old, at least from the morning of December 29th.
On the morning of January 10, we have a bunch of letters in a box with messages from the UC about errors knocking out checks. Great start to the year! The cant recognize and themselves (!) Forward these checks to the Atol (well, they can, when they want). In addition to this case, it was not possible to re-send UC checks more than once. On the contrary, they convinced me that this was impossible! What needs to be done to still write a check? Right, drive it in with your hands! In Atola we get to a page with a dozen fields that need to be filled. Filled, well, well, one check knocked out. In the next check, you need to fill everything in the same way (except for a couple of fields) again!
We have a bunch of letters with errors, we need to knock out checks. We wrote a script that takes letters from the UC and knocks checks in Atoll using them. Put on the machine. A trifle, but if the check is not beaten out, then this is a violation of the law. I had to figure out how it all works in Athol. Why the UC can not do the re-sending of checks on its side is not clear. The script is in our newly created public repository on Github.
Conflicting Yandex.Documentation
There are a lot of documentation in the UC, it is with beautiful pictures and screenshots. It would seem, use and rejoice. Let's see what is written about the interaction with the box office:
Screenshot taken 10/30/2019.
At step 5, Atol sometimes reports that not everything is OK with the check, and in our account the payment with the status âAcceptedâ appears, but without the check. This is because the recommended way to send â3 days in advanceâ checks is selected.
Online checkout settings , option âWith our helpâ. Screenshot taken 10/30/2019.
And again the 5th point, the description of the process of which does not work exactly as described. Pressing a button in your personal account does not change anything in the status of the check (consulted with technical support, she confirmed). The check is still not broken. It can be knocked out manually. Maybe choose "5 minutes"? Let's see what is written in the help in your account.
Screenshot from your personal account.
It turns out that for us the âFor 3 daysâ method is not just recommended, it is mandatory!
conclusions
Atol. Not everything is automated, much is done by hand. One can see how slowly but surely the interface of the personal account is getting rich. The standard rate for any change is 3 business days. Sometimes they offer to drive checks for us, but for some reason they never drove them. In order to speed up the solution of the request in response to the message about the creation of the ticket, you need to send the TIN to the organization (even if it is already in the body of the appeal), they have an automated priority increase, apparently in this way.
Yandex.Cash. They cannot resend the check in case of problems on the side of Atol. Others may, they do not, but in reality they can, but they probably do not want to. I had to write a script for them. There is a lot of documentation, and, probably, therefore it is inconsistent.
Robokassa. For some reason, they improve the storeâs web address, while doing this completely unnoticed. The rest are lovely guys.
FTS. Original time for implementation of changes. Not well thought out laws and requirements. Now electronic cash registers are identical to ordinary physical. If in an offline store payment and knocking out a check is done by one device and these two procedures go almost like a single transaction, then in the online world everything is different. Payment is accepted by one service, but the check is knocked out by another. By analogy with offline cash registers for knocking out a check is given no more than 5 minutes. You can read more, for example, here .
Lessons learned
It seems like trifles, but because of these trifles I had to spend about 60 hours on the above and the development / debugging of the script. Even two large national payment aggregators together with a large provider KaaS cannot make a service in which an ordinary user will receive the service, minimally understanding the subject area. It is very sad that with any, even trifling change, you have to be on the alert in the format and, in the end, propping up everything with your own crutches.
By the way, in the usual routine, both companies provide quite high-quality technical support and the service itself. It is easy to sag on the phone with a technician for an hour, debugging something or finding out the causes of certain failures due to the fault of payment systems. All is well with the documentation, with reliability. Yandex.Kassa carefully warns about all failures in payment systems and its own scheduled work. The cash desk was not seen in such mailings, but there are fewer complaints from our customers about problematic payments through it, which means that there are not particularly downtimes.
What to do next? On the horizon loomed a payback project to optimize the choice of aggregator depending on the payment method chosen by the user. Perhaps, against this background, it will be possible to connect to several more providers (I expect new âOMG! Why is this done so ?!â and reasons for articles about the pain). Due to the strong unevenness of the volume of payments over the course of the year, an interesting task may arise to optimize the collection of several backpacks: which user should be sent where to pay in order to minimize losses on commissions and discounts for monthly payments. If someone has had such an experience and whether the game is worth the candle, please share in the comments!