We are very happy to return to you again to share how Payler lives and develops. In this post we want to summarize the interim results of our work from the first day of work (we have been working since May 1, 2014). We have already conducted more than 4,441,000 transactions and believe that the first baptism of fire has already been completed. We want to talk about all the nuances, including the difficulties and feils that we encountered. Read on.
')
Who do we need
At the moment, about 60 clients have already connected to our system and we already have a much better idea of ​​the portrait of our audience. In general, here everything is going according to plan, but we want to share our observations. So, who mainly uses the services of Internet acquiring:
1) Companies providing services at the intersection of online and offline technologies . This could be, for example, booking services, insurance services, travel agencies and electronics stores. All these companies are united by one thing: a fair share of communications with them was originally planned to be carried out on the network. That is, the company's office for the client is secondary to the site. Such customers especially note the convenience of setting up Payler for themselves, in particular, they usually ask for and receive significant improvements in their personal account and reporting formats.
2) Company aggregators, partner networks, game stores, tickets . For example, it can be bonus programs or loyalty programs, as an example - one of our favorite clients “Royal Beauty”. These companies differ in that they provide their services remotely and at the same time in many different points (for example, in the best beauty salons in Moscow). Accordingly, it is more convenient for the client to purchase services via the Internet, so he can immediately “contact” the entire affiliate network, and not individually to the program participants. Such customers especially note the speed of the receipt of funds on the account, since within the network delays are disastrous.
3) "Recurrent" - Content providers, CRM-systems, taxi parks, etc. The rate is not important for these customers, since the return on sales is more than 20-30%. The first question they ask is that we need a clear API / SDK and Support, as well as the transition to combat mode as quickly as possible. Since the average check of companies that are serviced at Payler is 900 rubles - the business began to care about the time of its customers and masters the recurrent at a good pace.
Downs and ups
Naturally, in such a complex mechanism as a payment gateway there are failures and abnormal situations. We prepared for them and developed a self-learning antifraud system, but the effective work of the payment service is in any case related not only to the lack of jambs, but more to the ability to quickly correct them. So, our top 5 files and ways to solve them:
1. Lack of feedback from the bank . Some clients are refused without explanation, which greatly delays the connection process. That is why we work with several banks and in case of refusal we immediately coordinate everything in another bank. As a rule, the reason lies in the rules of each particular bank, and not in the client, therefore, such that all the banks refused at once did not happen yet. But no, it was once - but the client had a negative credit history.
2. Frode . Some clients are rated by banks as risky, and we can get a certain level of chargeback - protest the transaction by the issuing bank and return it to the payer at the expense of our client, after which all the proceedings fall on our shoulders. Now we are trying to avoid such situations by limiting countries, the number of transactions, the amount and other security settings.
3. 161-FZ . It is also the Federal Law “On the National Payment System”. In some projects there is a need for additional control of financial flows in accordance with the law. In such cases, we cannot issue money through ourselves without being a bank or non-bank credit institution. We solve by partnership with banks and NGOs. By the way, we are already very closely studying this area, since the strategic goals of the company in 2015 - 2016 will develop into NGOs.
4. Absence or heavy workload of technical specialists on the client side . Many clients do not have the opportunity to independently make technical integration, or their specialists are heavily loaded and they don’t care. We provide our specialists in such cases, or we offer a package of ready-made solutions.
5. Restrictions on the part of banks . Incorrect fraud monitoring by the bank can cut a good percentage of transaction traffic. In such cases, we do everything to reach an agreement with the bank on changing the fraud monitoring settings on their part. In the future, we plan to open a gateway that does not depend on restrictions from the bank.
Mobile commerce
We have important news from our Billingrad - a mobile commerce service has passed alpha testing, and integration is currently being completed. The service allows you to make payments from a mobile phone account up to 15,000 rubles. The limitations of the standard for electronic wallets: you can not pay for drugs, weapons, pornography.
It is important to note that when connecting to mobile commerce, in the process of coordinating the service, the “category” of your business is linked. Depending on the category, the commission changes, and the more liquid the product or service, the lower the commission.
Some Billingrad clients could already see new features in the interfaces. Already, we are starting to accept applications for approval, and soon the service can be activated almost automatically. Please send your applications to hello@payler.com or rs@billingrad.com - in the application you need to specify a description of the project and products, a link to the project, the average bill, the estimated expected amount of payments.
We asked the technical director of Billingrad to describe the details of the service device:
When writing a mobile commerce module, basic requirements were fault tolerance and usability. Fault tolerance is provided by distributing the load across multiple servers. In case of failure of one of the machines (flood, fire, the fall of the Internet in the data center), the requests go to other workers.
The backend is written in node.js + cluster.
The first version of mobile commerce was written using the nosql couchdb database, but declined in favor of postgresql. Horizontally for storage of the general data between servers (session) stretch redis.
Clients can customize the address to which to send requests for past \ rejected transactions and its body at its discretion. You can make json, xml, yaml or any other data format using the capabilities of the built-in template engine. The setup screen looks like this:
In the comments I can answer any technical questions about the billingrad device.
Right now we are integrating with their solution, which will make its use transparent to our customers.
Besides the fact that we have a lot of favorite customers and the ability to quickly deal with not the most pleasant moments, we are developing in other directions. First, we moved to a new office: from the cult for all young companies of Red October, we moved to the street of matured businesses: New Arbat. Now, against the background of houses, books and the brightest lights of Moscow, we come up with new products.
In particular, we are actively developing a new direction of auto-collection together with our partners ITB Technologies (itb-t.ru). This scope of services includes a variety of software and technical solutions, such as smart safes, autocash terminals, co-branded cards. We will devote a separate post to this area, but this will be a bit later. For now a photo from our new office