B2BinPay is a cryptocurrency payment system with many associated application backends, analytics, nodes, queues, but only one UI page that the end user sees. High demands are placed on it regarding ease of use. Despite the apparent simplicity of the page, it would be interesting for the development team to share how it works from the inside.
To understand business processes, you will need to immerse yourself in the subject area. For readers who do not yet know what cryptocurrency, blockchain and address are, we have compiled short and understandable definitions below the cut.
To understand the terms, here are analogies with the fiat world of payments:
Blockchain is a decentralized (ideally) database that stores information about addresses, transactions, and balances. It consists of blocks, each of which contains a limited amount of information. Blocks are generated by miners through power-based settlement (PoW) or proof-of-stake (PoS). Each subsequent block contains a list of new transactions and a link to the previous one. Each cryptocurrency has its own blockchain.
A merchant is the same as a store owner who rents a payment system to accept payments from end users.
A wallet is the same as an account in the traditional financial world.
A transaction is a record in the blockchain that funds have been sent from one wallet to another. The wallet balance is formed from the amount of transactions.
Address - the same as account details. The difference is that most blockchains allow you to generate an infinite number of addresses for a single wallet.
A confirmed transaction is one after which a safe number of blocks have been generated. One block is equal to one confirmation. If a transaction has not received 4-8 confirmations, then it is not considered completed.
Payment system is software that provides acceptance and processing of payments in cryptocurrency. Links and aggregates orders, payments, transactions, returns, replenishments, withdrawals and other information. It also informs the merchant system about changes in the context of orders and payments, rather than blockchains and transactions.
Explorer is a service or website that explores data entering the blockchain. Using such a service, you can obtain information about addresses, transactions and blocks in a convenient form.
A node is a computer on which a copy of the entire database (blockchain) is stored.
The payment process is divided into several stages. Each of them does not require user action other than the direct transfer of money. Standard successful scenario:
Accordingly, the payment page can be in two states: viewing details and waiting for confirmation. When viewing details, you can enter the address in two ways: scan the QR code or copy the address in text form. In addition to the basic information, we will add a mini-instruction in text form that will tell you how to pay, where to download the wallet application and how to buy currency. In addition to these fields, there is one more, the presence of which depends on the selected currency. Sometimes, to correctly match a transaction, payment order and buyer, you need to know not only the address, but also additional information. For example, for the Ripple currency, when sending, you must specify a destination tag (comment on the transaction).
For those who copy the address in text form rather than scan the QR code, a copy button has been added. The coin logo should also be present on the page, since many people identify currency visually, by the shape and color scheme of the logo, and not by the letter designation.
The state change occurs when an incoming transaction to the payment address is detected. At this point, the details disappear as they are no longer required; the user goes into standby mode, and the page needs a constant flow of information about the status of the transaction. Now on the page you can find: the waiting time until the transaction is completed, the current number of confirmations, a short comment explaining further actions.
The page should be easy to understand, intuitive and at the same time quite informative. For experienced buyers, it is necessary to focus on the address and amount.
From the listed requirements, the layout of the future page was created.
Pros: No load on our capacity, easy to implement, no potential security risks.
Cons: unreliable sources and untimely receipt of new information, difficulties in delivering code base updates to end clients (uncontrolled caching). The decisive disadvantage is that many currencies do not have stable explorers with a developed API.
The second option (working) is its own microservice, which receives information directly from a pool of nodes, filters it and distributes it across payment pages. Using Server Side Events on the client will reduce redundancy and save traffic. SSEs fit into the use case because the page is passive in its behavior - it only accepts new information.
Cons: a lot of implementation costs, additional load on the equipment.
Pros: high level of reliability and independence from third-party services; order context, not transaction context.
When the payment page is opened in the buyer's browser, a request is sent to the asynchronous backend of the microservice to create an SSE connection. The request specifies the address to be tracked, payment amount, lifetime and other minor parameters. On the backend this is stored in in-memory noSQL storage. Every time a new block appears on any of the blockchain nodes, the application receives and extracts useful information from it regarding addresses and transactions stored in the database. If the next block is useful, then updates are sent to clients. Connections are closed by the server when enough acknowledgments have been received or the TTL has expired.
Thus, the backend performs resource-intensive operations and drives traffic only when new information arrives at the node, and there is no periodic “poll” for new information. Thanks to asynchrony, we get high speed work with thousands of simultaneous connections.
Knowing that for PoW coins the delay in receiving new information within a second is negligible, minimal horizontal scaling of such a system will give a large increase in throughput. On particularly busy days, such as Black Friday, the workload increases. In case the system cannot cope or is technically faulty, the client has a fallback state in which the page remains in the details viewing mode forever. For PoS coins, the step of monitoring the number of confirmations can be skipped, since the transaction speed is often from 2 to 5 seconds.
The third option for implementing the backend is a hybrid one, when, depending on the speed of the blockchain transaction and information about the current availability of third-party services, either SSE or HTTP interaction with explorers is used. It is the most effective and labor-intensive at the same time.
The front-end technology suitable for the task is vue.js with declarative rendering and the ability to create multiple component states. It is a lightweight library with an elegant structure and reactive DOM modification. The data source is an SSE connection that opens when the component is initialized.
We are developing the product and making it high-quality and reliable in order to make blockchain payments convenient, widespread and accessible. We love not only money, but also the most advanced technologies, complex problems and elegant solutions.
In developing the B2BinPay payment system , we regularly solve problems that, despite their apparent simplicity, require a non-standard approach or a fresh look. We will be grateful for your feedback, comments and suggestions. If you want to bring new and bold ideas to the payment service that is used all over the world, look at the current vacancies.
To understand business processes, you will need to immerse yourself in the subject area. For readers who do not yet know what cryptocurrency, blockchain and address are, we have compiled short and understandable definitions below the cut.
To understand the terms, here are analogies with the fiat world of payments:
Blockchain is a decentralized (ideally) database that stores information about addresses, transactions, and balances. It consists of blocks, each of which contains a limited amount of information. Blocks are generated by miners through power-based settlement (PoW) or proof-of-stake (PoS). Each subsequent block contains a list of new transactions and a link to the previous one. Each cryptocurrency has its own blockchain.
A merchant is the same as a store owner who rents a payment system to accept payments from end users.
A wallet is the same as an account in the traditional financial world.
A transaction is a record in the blockchain that funds have been sent from one wallet to another. The wallet balance is formed from the amount of transactions.
Address - the same as account details. The difference is that most blockchains allow you to generate an infinite number of addresses for a single wallet.
A confirmed transaction is one after which a safe number of blocks have been generated. One block is equal to one confirmation. If a transaction has not received 4-8 confirmations, then it is not considered completed.
Payment system is software that provides acceptance and processing of payments in cryptocurrency. Links and aggregates orders, payments, transactions, returns, replenishments, withdrawals and other information. It also informs the merchant system about changes in the context of orders and payments, rather than blockchains and transactions.
Explorer is a service or website that explores data entering the blockchain. Using such a service, you can obtain information about addresses, transactions and blocks in a convenient form.
A node is a computer on which a copy of the entire database (blockchain) is stored.
General scheme of work and requirements for the content of the payment page
The payment cycle occurs as follows: on the store’s website, the buyer selects the product and payment currency. The system redirects the user to the payment page. It contains the following information: currency, address, information comments. The user sends the required amount to the specified address and waits for a sufficient number of network confirmations to recognize the payment as successful. While waiting, the buyer can monitor the status of the payment without leaving the page to the explorer site. Once the payment is accepted, the user is redirected to a successful payment page on the merchant's website.The payment process is divided into several stages. Each of them does not require user action other than the direct transfer of money. Standard successful scenario:
- On the seller’s website, the user selects the B2BinPay payment method and currency
- The seller's IS sends a request to create a new payment order, receiving in response a link to the payment page
- The user is redirected to the payment page, which contains information: currency, amount, address and additional fields if necessary
- The user pays for the purchase
- The system detects that a new transaction has arrived at the address and the page goes into the tracking state
- The transaction status is monitored and the information on the page is updated until a safe number of confirmations is reached
- The user is redirected to a successful payment page on the seller's website
Accordingly, the payment page can be in two states: viewing details and waiting for confirmation. When viewing details, you can enter the address in two ways: scan the QR code or copy the address in text form. In addition to the basic information, we will add a mini-instruction in text form that will tell you how to pay, where to download the wallet application and how to buy currency. In addition to these fields, there is one more, the presence of which depends on the selected currency. Sometimes, to correctly match a transaction, payment order and buyer, you need to know not only the address, but also additional information. For example, for the Ripple currency, when sending, you must specify a destination tag (comment on the transaction).
For those who copy the address in text form rather than scan the QR code, a copy button has been added. The coin logo should also be present on the page, since many people identify currency visually, by the shape and color scheme of the logo, and not by the letter designation.
The state change occurs when an incoming transaction to the payment address is detected. At this point, the details disappear as they are no longer required; the user goes into standby mode, and the page needs a constant flow of information about the status of the transaction. Now on the page you can find: the waiting time until the transaction is completed, the current number of confirmations, a short comment explaining further actions.
The page should be easy to understand, intuitive and at the same time quite informative. For experienced buyers, it is necessary to focus on the address and amount.
From the listed requirements, the layout of the future page was created.
Backend
The first option for implementing a backend is to do without it entirely! When generating a payment page, you know in advance which address the money will be sent to. You can receive new transactions at this address from the explorer using JS. Thus, the task comes down to writing connectors to explorers and periodically polling the required one. A static class diagram could look like this:
Pros: No load on our capacity, easy to implement, no potential security risks.
Cons: unreliable sources and untimely receipt of new information, difficulties in delivering code base updates to end clients (uncontrolled caching). The decisive disadvantage is that many currencies do not have stable explorers with a developed API.
The second option (working) is its own microservice, which receives information directly from a pool of nodes, filters it and distributes it across payment pages. Using Server Side Events on the client will reduce redundancy and save traffic. SSEs fit into the use case because the page is passive in its behavior - it only accepts new information.
Cons: a lot of implementation costs, additional load on the equipment.
Pros: high level of reliability and independence from third-party services; order context, not transaction context.
When the payment page is opened in the buyer's browser, a request is sent to the asynchronous backend of the microservice to create an SSE connection. The request specifies the address to be tracked, payment amount, lifetime and other minor parameters. On the backend this is stored in in-memory noSQL storage. Every time a new block appears on any of the blockchain nodes, the application receives and extracts useful information from it regarding addresses and transactions stored in the database. If the next block is useful, then updates are sent to clients. Connections are closed by the server when enough acknowledgments have been received or the TTL has expired.
Thus, the backend performs resource-intensive operations and drives traffic only when new information arrives at the node, and there is no periodic “poll” for new information. Thanks to asynchrony, we get high speed work with thousands of simultaneous connections.
Knowing that for PoW coins the delay in receiving new information within a second is negligible, minimal horizontal scaling of such a system will give a large increase in throughput. On particularly busy days, such as Black Friday, the workload increases. In case the system cannot cope or is technically faulty, the client has a fallback state in which the page remains in the details viewing mode forever. For PoS coins, the step of monitoring the number of confirmations can be skipped, since the transaction speed is often from 2 to 5 seconds.
The third option for implementing the backend is a hybrid one, when, depending on the speed of the blockchain transaction and information about the current availability of third-party services, either SSE or HTTP interaction with explorers is used. It is the most effective and labor-intensive at the same time.
The front-end technology suitable for the task is vue.js with declarative rendering and the ability to create multiple component states. It is a lightweight library with an elegant structure and reactive DOM modification. The data source is an SSE connection that opens when the component is initialized.
Design
We are developing the product and making it high-quality and reliable in order to make blockchain payments convenient, widespread and accessible. We love not only money, but also the most advanced technologies, complex problems and elegant solutions.
In developing the B2BinPay payment system , we regularly solve problems that, despite their apparent simplicity, require a non-standard approach or a fresh look. We will be grateful for your feedback, comments and suggestions. If you want to bring new and bold ideas to the payment service that is used all over the world, look at the current vacancies.
