Bitcoin process. How is the payment page in B2BinPay
B2BinPay is a cryptocurrency payment system with many related backends of applications, analytics, nodes, queues, but only one UI page that the end user sees. It has high requirements for ease of use. Despite the seeming simplicity of the page, the development team would be interested to share how it works from the inside.
To understand business processes will need to dive into the subject area. For readers who do not yet know what cryptocurrency, blockchain and address are, we have made short and clear definitions under the cut.
The cycle of the payment is as follows: on the store site, the buyer selects the product and payment currency. The system redirects the user to the payment page. It contains the following information: currency, address, informational comments. The user sends the required amount to the specified address and waits for a sufficient number of confirmations of the network to recognize the payment successful. While waiting, the buyer can monitor the status of payment, without leaving the page on the site-explorer. As soon as the payment is accepted, the user is forwarded to the successful payment page on the seller’s website.
The payment process is divided into several stages. Each of them does not require user action, except for the direct transfer of money. Standard successful script:
Accordingly, the payment page can be in two states: view details and wait for confirmation. When viewing the 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, which 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 chosen currency. Sometimes, in order to correctly match a transaction, a payment order and a buyer, it is required to know not only the address, but also additional information. For example, when sending a Ripple currency, you must specify the destination tag (comment to the transaction).
For those who copy the address in text form, rather than scanning the QR code, a copy button has been added. Also on the page should be the logo of the coin, as many people identify the currency visually, according to the shape and color of the logo, and not by letter designation.
The change of state occurs at the moment when an incoming transaction is detected at the billing address. At this point, the details disappear, since 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 completion of the transaction, the current number of confirmations, a short comment explaining further actions.
The page should be easy to read, intuitive and at the same time quite informative. For experienced buyers, you need to focus on the address and amount.
From the listed requirements the layout of the future page turned out.
The first implementation of the backend is to do completely without it! When generating a payment page, you know in advance what address the money will be sent to. You can receive new transactions at this address from the explorer using JS. Thus, the task is reduced to writing connectors to the explorer and periodically poll the necessary one. A static class diagram might look like this:
Pros: there is no load on our power, it is easy to implement, there are no potential security threats.
Disadvantages: unreliable sources and untimely receipt of new information, difficulties in delivering updates to the code base to end customers (uncontrolled caching). The decisive disadvantage is that many currencies do not have stable explorators with a developed API.
The second option (working) is your own microservice, which receives information directly from the pull node, filters and distributes to payment pages. Using Server Side Events on the client will reduce the level of redundancy and save traffic. SSE fit into the use case, as the page is passive in its behavior - it only accepts new information.
Cons: a lot of the cost of implementation, the additional load on the equipment.
Pros: a high level of reliability and independence from third-party services; order context, not transaction.
Schematic diagram:
When a payment page is opened in the customer’s browser, a request to create an SSE connection is sent to the asynchronous backend of microservice. The request indicates the address to be monitored, the amount of payment, the lifetime and other minor parameters. On the backend, it is stored in the in-memory noSQL repository. Each time a new block appears on any of the blockchain nodes, the application receives and extracts useful information from it on the addresses and transactions stored in the database. If the next block is useful, then updates are sent to clients. Connections are closed at the initiative of the server when enough confirmations are received or when 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 “polling” for new information. Thanks to asynchronous, we get high speed with thousands of simultaneous connections.
Knowing that for coins with PoW, the delay in obtaining new information within a second is insignificant, the minimum horizontal scaling of such a system will give a large increase in throughput. On particularly active days, such as Black Friday, the load increases. In case the system fails or is technically faulty, then the client has a fallback state in which the page remains in the details view mode forever. For PoS-coins, the stage with monitoring the number of confirmations can be skipped, since the transaction speed often ranges from 2 to 5 seconds.
The third implementation of 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 the explorer is used. It is the most efficient and time-consuming.
The frontend technology suitable for the task is vue.js with declarative rendering and the ability to create several component states. This is a lightweight library with an elegant structure and a reactive change to the DOM. The data source is an SSE connection that opens when the component is initialized.
We develop the product and make it high-quality and reliable to make blockchain payments convenient, massive and affordable. We love not only money, but also the most advanced technologies, challenges and elegant solutions.
In the development of the B2BinPay payment system , we regularly solve problems that, despite their apparent simplicity, require an unconventional approach or a fresh look. We would be grateful for feedback, comments and suggestions. If you want to bring new and bold ideas to the payment service that is used throughout the world, see current vacancies .
To understand business processes will need to dive into the subject area. For readers who do not yet know what cryptocurrency, blockchain and address are, we have made short and clear definitions under the cut.
To understand the terms, we give an analogy 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 them contains a limited amount of information. Blocks are generated by miners using energy-intensive calculations (PoW) or proof of proportion (PoS). Each next block contains a list of new transactions and a link to the previous one. Each cryptocurrency has its own blockchain.
')
The merchant is the same as the store owner, who rents the payment system to receive payments from end users.
Wallet - the same as the account in the traditional financial world.
Transaction - an entry in the blockchain stating that funds were sent from one purse to another. Wallet balance is formed from the amount of transactions.
The address is the same as the account details. The difference is that most blockchains allow you to generate an infinite number of addresses for one wallet.
A confirmed transaction is such a transaction, after which a safe number of blocks was generated. One block equals one acknowledgment. If the transaction has not received 4-8 confirmations, then it is not considered complete.
Payment system - software that accepts and processes payments in a cryptocurrency. It links and aggregates orders, payments, transactions, returns, deposits, 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 - a service or site-browser of data entering the blockchain. Using this service, you can conveniently get information about addresses, transactions and blocks.
A node is a computer that stores a copy of the entire database (blockchain).
')
The merchant is the same as the store owner, who rents the payment system to receive payments from end users.
Wallet - the same as the account in the traditional financial world.
Transaction - an entry in the blockchain stating that funds were sent from one purse to another. Wallet balance is formed from the amount of transactions.
The address is the same as the account details. The difference is that most blockchains allow you to generate an infinite number of addresses for one wallet.
A confirmed transaction is such a transaction, after which a safe number of blocks was generated. One block equals one acknowledgment. If the transaction has not received 4-8 confirmations, then it is not considered complete.
Payment system - software that accepts and processes payments in a cryptocurrency. It links and aggregates orders, payments, transactions, returns, deposits, 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 - a service or site-browser of data entering the blockchain. Using this service, you can conveniently get information about addresses, transactions and blocks.
A node is a computer that stores a copy of the entire database (blockchain).
The general scheme of work and the requirements for the content of the payment page
The cycle of the payment is as follows: on the store site, the buyer selects the product and payment currency. The system redirects the user to the payment page. It contains the following information: currency, address, informational comments. The user sends the required amount to the specified address and waits for a sufficient number of confirmations of the network to recognize the payment successful. While waiting, the buyer can monitor the status of payment, without leaving the page on the site-explorer. As soon as the payment is accepted, the user is forwarded to the successful payment page on the seller’s website.
The payment process is divided into several stages. Each of them does not require user action, except for the direct transfer of money. Standard successful script:
- On the merchant site, the user selects a payment method B2BinPay and currency
- The seller's IP 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
- User pays for the purchase
- The system detects that a new transaction has arrived at the address and the page enters the tracking state.
- The status of the transaction is monitored and the information on the page is updated until a secure amount of confirmations is reached.
- The user is redirected to the successful payment page on the seller’s website.
Accordingly, the payment page can be in two states: view details and wait for confirmation. When viewing the 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, which 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 chosen currency. Sometimes, in order to correctly match a transaction, a payment order and a buyer, it is required to know not only the address, but also additional information. For example, when sending a Ripple currency, you must specify the destination tag (comment to the transaction).
For those who copy the address in text form, rather than scanning the QR code, a copy button has been added. Also on the page should be the logo of the coin, as many people identify the currency visually, according to the shape and color of the logo, and not by letter designation.
The change of state occurs at the moment when an incoming transaction is detected at the billing address. At this point, the details disappear, since 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 completion of the transaction, the current number of confirmations, a short comment explaining further actions.
The page should be easy to read, intuitive and at the same time quite informative. For experienced buyers, you need to focus on the address and amount.
From the listed requirements the layout of the future page turned out.
Backend
The first implementation of the backend is to do completely without it! When generating a payment page, you know in advance what address the money will be sent to. You can receive new transactions at this address from the explorer using JS. Thus, the task is reduced to writing connectors to the explorer and periodically poll the necessary one. A static class diagram might look like this:
Pros: there is no load on our power, it is easy to implement, there are no potential security threats.
Disadvantages: unreliable sources and untimely receipt of new information, difficulties in delivering updates to the code base to end customers (uncontrolled caching). The decisive disadvantage is that many currencies do not have stable explorators with a developed API.
The second option (working) is your own microservice, which receives information directly from the pull node, filters and distributes to payment pages. Using Server Side Events on the client will reduce the level of redundancy and save traffic. SSE fit into the use case, as the page is passive in its behavior - it only accepts new information.
Cons: a lot of the cost of implementation, the additional load on the equipment.
Pros: a high level of reliability and independence from third-party services; order context, not transaction.
Schematic diagram:
When a payment page is opened in the customer’s browser, a request to create an SSE connection is sent to the asynchronous backend of microservice. The request indicates the address to be monitored, the amount of payment, the lifetime and other minor parameters. On the backend, it is stored in the in-memory noSQL repository. Each time a new block appears on any of the blockchain nodes, the application receives and extracts useful information from it on the addresses and transactions stored in the database. If the next block is useful, then updates are sent to clients. Connections are closed at the initiative of the server when enough confirmations are received or when 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 “polling” for new information. Thanks to asynchronous, we get high speed with thousands of simultaneous connections.
Knowing that for coins with PoW, the delay in obtaining new information within a second is insignificant, the minimum horizontal scaling of such a system will give a large increase in throughput. On particularly active days, such as Black Friday, the load increases. In case the system fails or is technically faulty, then the client has a fallback state in which the page remains in the details view mode forever. For PoS-coins, the stage with monitoring the number of confirmations can be skipped, since the transaction speed often ranges from 2 to 5 seconds.
The third implementation of 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 the explorer is used. It is the most efficient and time-consuming.
The frontend technology suitable for the task is vue.js with declarative rendering and the ability to create several component states. This is a lightweight library with an elegant structure and a reactive change to the DOM. The data source is an SSE connection that opens when the component is initialized.
Design
We develop the product and make it high-quality and reliable to make blockchain payments convenient, massive and affordable. We love not only money, but also the most advanced technologies, challenges and elegant solutions.
In the development of the B2BinPay payment system , we regularly solve problems that, despite their apparent simplicity, require an unconventional approach or a fresh look. We would be grateful for feedback, comments and suggestions. If you want to bring new and bold ideas to the payment service that is used throughout the world, see current vacancies .
Source: https://habr.com/ru/post/447418/
All Articles