How we made a cryptocurrency payment system: five main problems

    Hello, Habr! In touch is B2Broker, a provider of liquidity and technology solutions for the brokerage and exchange industry. One of our products is the B2BX.exchange trading platform. When we launched the platform in the summer of 2017, we thought about how to accept cryptocurrencies and what processing to use. Alas, no one at that time was ready to give at least any guarantees on the vulnerability of the contract, and the story of the attack on the DAO platform was still at the hearing. We did not want to follow in the footsteps of the DAO. In addition, we had some experience in accepting payments through the blockchain. So we decided to independently work out the entire cycle of blockchain payments. In this post we will talk about what we did, and, most interestingly, about what problems we had to solve in the process.


    Source: ripplecoinnews.com

    In the process of working on the payment system, we realized that we can make a service not only for our B2BX.exchange platform, but also a completely independent product. We called it B2BinPay.

    What B2BinPay consists of


    The payment system is divided into several basic parts. All of them are written in PHP.

    The first part of the system is responsible for interacting with blockchains, that is, for receiving, sending and tracking payments.

    The second part is the API. He is engaged in interaction with consumers of services and exchanges: notifies the receipt of funds, carries out the exchange of cryptocurrencies. The API is written using the Laravel framework.

    The third part is the acquiring office for consumers. It reflects the state of the system as a whole, connected wallets and their balances, active transactions and accounts. Perhaps soon we will connect classic fiat acquiring. To create an office, we used Yii2.

    A separate block is a system for working with ICO projects. It allows you to distribute tokens at all stages of the sale. In addition to it is the possibility of developing a contract (ERC-20) and a personal account. Using these tools, we provide a turnkey ICO service.



    For security reasons, all data about wallets is stored in the database in encrypted form, so even if an attacker gains access to them, he will not be able to withdraw funds from wallets. Two-factor user authentication is connected. Finally, the merchant can create a whitelist of IP addresses that can work with the API.

    We provide system fault tolerance with a large number of servers, including backup ones. Each blockchain node is located on a separate server with limited access from the outside.

    What problems have we encountered?


    Blockchains are different. Some are poorly documented and do not have an active community. This was mainly the reason for our main problems.

    1. The Ethereum API does not have the ability to return lists of incoming transactions of the account.

    When creating an account, our payment system generates a unique address to which the user must transfer a certain amount in the selected currency. With a given frequency, we get a list of incoming transactions and verify their wallet addresses. Then we verify the addresses of the wallets with the addresses of unpaid bills. As it turned out, the broadcast does not allow receiving information about incoming transactions.

    What to do? We decided to receive transactions using a third-party service - etherscan.io. But he revealed some problems, so we switch to explorer, a service written by our programmers.

    2. Some blockchains have extremely poor documentation.

    Here is a typical case: somehow we deployed a node to one of the little-known cryptocurrencies, and after a few days it stopped accepting transactions without reporting any errors. We restarted it, but a few days later the situation repeated.

    What to do? When they started to figure it out, they found out that the problem is in one of the parameters in the configuration file. There was not a word in the documentation about this parameter, so I had to configure everything by trial and error.



    3. Private blockchain for testing functionality is difficult or simply impossible to deploy

    Once we needed to deploy a blockchain for the NEO cryptocurrency. We found a ready docker image, did everything according to the instructions and got an error. A quick analysis of the scripts did not lead to anything, Google also did not prompt anything.

    What to do? We created an issue on github, spent about a month discussing it, and finally decided to deploy testnet. But not every cryptocurrency has testnet. And if it does, then most often you need to send an application for test coins and wait a while. The development of a private blockchain on official sites in most cases is not even considered, so you have to use third-party solutions.

    In fairness, it is worth saying that in most cases, you can get answers to questions related to the infrastructure of a particular cryptocurrency. The most useful resource in this sense is Github, then you should go to the official forums and Reddit.

    4. Irrational code reuse

    Bitcoin has over the years created many copies with individual blockchains and blocks - do not confuse them with forks. In most cases, such cryptocurrencies have an absolutely identical Bitcoin API. In order not to multiply the same code, for working with such copies we use the same class as for working with Satoshi Nakamoto's currency.

    But it may not be so simple. When we needed to integrate Dogecoin, we followed the described scenario, configured and deployed testnet. As a result, some tests fell and there were problems with creating transactions.

    What to do? First, we ran the test through the debugger. It turned out that Dogecoin in the request to create a transaction does not allow transferring the amount in the form of a string, as Bitcoin does. Because of this, we had to redefine the method in the child class. By the way, this is the only identified difference in the Dogecoin and Bitcoin APIs. What is its meaning is incomprehensible.

    5. Not all cryptocurrencies allow generating an unlimited number of unique addresses.

    Everything is simple here: without this generation, we cannot use payment identification by address.

    What to do?In such situations, we use a unique message that is attached to the transaction when sending the payment. Unfortunately, some customers forget to indicate these messages and then wonder why the payment was not credited automatically.

    How to integrate into CMS?


    We made B2BinPay plugins for WordPress, Woocommerce, Magento, PrestaShop. Here the appetite came with eating - initially we did not plan to promote the system through plugins for CMS. For each plugin we did a review in the system. The most serious thing happened for the Magento plugin, we’ll tell you more about this review.

    The review is divided into two parts - Technical and Marketing. Technical inspection consists of four stages:

    • Code sniffer
    • Installation & Varnish Test
    • Copy paste paste detector
    • Manual QA

    The first three stages are fully automated, so it’s better to take into account some things at the development stage. To simplify your life during the test, first of all, you need to remember the rules for Code Sniffer.

    Magento rules for Code Sniffer comply with PSR-1 and PSR-2 standards, this is one of the few CMS whose developers adhere to modern approaches to development in PHP. In addition, the guys from Magento published a separate set of rules that helps to find errors in the xml-configurations of the extension structure and complements the generally accepted checks. A script for checking the contents of the finished package is also published on their github account, which should also be used before sending your development for automated verification.

    The basic Magento installation contains a bootstrap class for phpunit: you can use it to write tests for your plugin. Honestly, we still haven’t figured out if the availability of tests contributes to the rapid completion of the Technical Review.



    The first three stages of the technical inspection are automatic. For the fourth stage and for Marketing Review, you will have to be patient: both processes are performed by people and because of this, queues are formed.

    We waited for the results of Manual QA for about 5 days, which is basically normal. But each of our applications for Marketing Review has been processed for more than a week. Here, it was important for the testers that in the first paragraphs we write down the integration with which service we provide and what its pricing model is, and only then indicate the advantages of our plugin.

    Future plans


    We believe that B2BinPay turned out to be quite simple in terms of interaction with users and therefore it will be convenient for both new companies in the crypto market and advanced business - for example, in the field of online sales - where a stable and secure product is needed.

    At the start of the initial circulation of coins, we accepted Bitcoin, Bitcoin CASH, Litecoin, DASH, Ethereum, Monero and others. Now we offer services for merchants and wallets for enterprise clients under our Estonian company, for which we received two licenses - for exchanging cryptocurrencies and for wallets.

    When onboarding clients, we make a full-fledged KYC for each merchant, after which the merchant can start accepting cryptocurrencies, which are automatically converted into dollars, euros or pounds and paid to the merchant bank account.

    We will be happy to answer your questions on the creation of B2BinPay and on the product itself in principle. In addition, we are now actively looking for like-minded people who have Python programming skills and are ready to join our team. Now in St. Petersburg we have opened vacancies for team lead and senior developer . We look forward to your resume!

    Also popular now: