April 10, 2019 at 09:00We process bitcoin. How is the B2BinPay payment page arranged?
B2BinPay is a cryptocurrency payment system with many related backends for applications, analytics, nodes, queues, but only one UI page that the end user sees. It has high requirements regarding ease of use. Despite the apparent simplicity of the page, the development team would be interested to share how it is arranged from the inside.
To understand business processes, you will need to dive into the subject area. For readers who do not yet know what cryptocurrency, blockchain and address are, we made short and understandable definitions under the cut.
The payment cycle takes place 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, informational comments. The user sends the required amount to the specified address and expects 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 on the explorer website. Once the payment is accepted, the user is redirected 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 direct money transfer. Standard successful script:
Accordingly, the payment page can be in two states: viewing details and waiting 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 correlate a transaction, a payment order and a buyer, it is necessary to know not only the address, but also additional information. For example, for the Ripple currency, when sending, you must specify the destination tag (comment on the transaction).
For those who copy the address in text form, and do not scan the QR code, a copy button has been added. Also, the logo of the coin should be present on the page, since many people identify the currency visually, by the shape and color scheme of the logo, and not by the letter designation.
The change of state occurs at the moment when an incoming transaction to the billing address is detected. At this moment, 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 timeout 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 sufficiently informative. For experienced buyers, emphasis must be placed on the address and amount.
From the above requirements, a layout for the future page was obtained.
The first option for implementing the backend is to do without it! When generating the payment page, it is known in advance to which address the money will be sent. You can receive new transactions at this address from the explorer using JS tools. Thus, the task is to write connectors to the explorer and periodically interrogate the necessary one. A static class diagram could look like this:
Pros: there is no load on our capacities, it is easy to implement, there are no potential security threats.
Cons: unreliable sources and untimely receipt of new information, difficulties in delivering code base updates to end customers (uncontrolled caching). Decisive minus - many currencies do not have stable explorer with a developed API.
The second option (working) is its own microservice, which receives information directly from the pool of nodes, filters 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, since 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; The context of the order, not the transaction.
Circuit diagram:
When the payment page opens in the customer’s browser, a request to create an SSE connection is sent to the asynchronous backend of the microservice. The request indicates the address to be tracked, the amount of payment, lifetime and other minor parameters. On the backend, this is stored in in-memory noSQL storage. Each time a new block appears on any blockchain node, the application receives and extracts useful information from it at 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 server’s initiative when enough confirmations are received or 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 “interrogation” for new information. Thanks to asynchrony, we get high speed with thousands of simultaneous connections.
Knowing that for coins with PoW, the delay in receiving new information within a second is negligible, the minimum horizontal scaling of such a system will give a large increase in throughput. On especially active days, such as Black Friday, the load increases. In case the system fails or is technically malfunctioning, then 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.
Third optionthe backend implementation is hybrid, when, depending on the speed of the blockchain transaction and information on the current availability of third-party services, either SSE or HTTP interaction with explorers is used. It is the most effective and time-consuming at the same time.
The front-end technology suitable for the task is vue.js with declarative rendering and the ability to create several component states. It is a lightweight library with a sleek structure and reactive DOM modification. The data source is the SSE connection that opens when the component is initialized.
We develop the product and make it high-quality and reliable in order to make blockchain payments convenient, massive and affordable. We love not only money, but also the most advanced technologies, complex tasks 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 would be grateful for feedback, comments and suggestions. If you want to bring new and bold ideas to the payment service that is used all over the world, see current vacancies .
To understand business processes, you will need to dive into the subject area. For readers who do not yet know what cryptocurrency, blockchain and address are, we made short and understandable definitions under the cut.
To understand the terms, here are some analogies with the fiat world of payments:
Blockchain is a decentralized (in the ideal case) 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 thanks to miners through energy-intensive calculations (PoW) or proof of stake (PoS). Each next block contains a list of new transactions and a link to the previous one. Each cryptocurrency has its own blockchain.
Merchant - the same as the owner of the store, renting a payment system for receiving payments from end users.
A wallet is the same as an account in the traditional financial world.
Transaction- a record in the blockchain that funds were sent from one wallet 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 a transaction after which a safe number of blocks has been generated. One block is equal to one confirmation. If the transaction has not received 4-8 confirmations, then it is not considered completed.
Payment system- Software that provides the acceptance and processing of payments in cryptocurrency. Links and aggregates orders, payments, transactions, returns, replenishment, withdrawals and other information. It also informs the merchant system about changes in the context of orders and payments, and not blockchains and transactions.
Explorer - a service or a browser site for data entering the blockchain. Using this service, you can conveniently get information about addresses, transactions and blocks.
A node is a computer on which a copy of the entire database (blockchain) is stored.
Merchant - the same as the owner of the store, renting a payment system for receiving payments from end users.
A wallet is the same as an account in the traditional financial world.
Transaction- a record in the blockchain that funds were sent from one wallet 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 a transaction after which a safe number of blocks has been generated. One block is equal to one confirmation. If the transaction has not received 4-8 confirmations, then it is not considered completed.
Payment system- Software that provides the acceptance and processing of payments in cryptocurrency. Links and aggregates orders, payments, transactions, returns, replenishment, withdrawals and other information. It also informs the merchant system about changes in the context of orders and payments, and not blockchains and transactions.
Explorer - a service or a browser site for data entering the blockchain. Using this service, you can conveniently get information about addresses, transactions and blocks.
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 takes place 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, informational comments. The user sends the required amount to the specified address and expects 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 on the explorer website. Once the payment is accepted, the user is redirected 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 direct money transfer. Standard successful script:
- On the seller’s website, the user selects the B2BinPay payment method and currency
- The seller’s IP sends a request to create a new payment order, receiving a link to the payment page in response
- The user redirects to the payment page, which contains information: currency, amount, address and additional fields, if necessary
- User pays for purchase
- The system detects that a new transaction has arrived at the address and the page goes into tracking state
- Transaction status is monitored and information is updated on the page until a secure number 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: viewing details and waiting 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 correlate a transaction, a payment order and a buyer, it is necessary to know not only the address, but also additional information. For example, for the Ripple currency, when sending, you must specify the destination tag (comment on the transaction).
For those who copy the address in text form, and do not scan the QR code, a copy button has been added. Also, the logo of the coin should be present on the page, since many people identify the currency visually, by the shape and color scheme of the logo, and not by the letter designation.
The change of state occurs at the moment when an incoming transaction to the billing address is detected. At this moment, 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 timeout 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 sufficiently informative. For experienced buyers, emphasis must be placed on the address and amount.
From the above requirements, a layout for the future page was obtained.
Backend
The first option for implementing the backend is to do without it! When generating the payment page, it is known in advance to which address the money will be sent. You can receive new transactions at this address from the explorer using JS tools. Thus, the task is to write connectors to the explorer and periodically interrogate the necessary one. A static class diagram could look like this:
Pros: there is no load on our capacities, it is easy to implement, there are no potential security threats.
Cons: unreliable sources and untimely receipt of new information, difficulties in delivering code base updates to end customers (uncontrolled caching). Decisive minus - many currencies do not have stable explorer with a developed API.
The second option (working) is its own microservice, which receives information directly from the pool of nodes, filters 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, since 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; The context of the order, not the transaction.
Circuit diagram:
When the payment page opens in the customer’s browser, a request to create an SSE connection is sent to the asynchronous backend of the microservice. The request indicates the address to be tracked, the amount of payment, lifetime and other minor parameters. On the backend, this is stored in in-memory noSQL storage. Each time a new block appears on any blockchain node, the application receives and extracts useful information from it at 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 server’s initiative when enough confirmations are received or 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 “interrogation” for new information. Thanks to asynchrony, we get high speed with thousands of simultaneous connections.
Knowing that for coins with PoW, the delay in receiving new information within a second is negligible, the minimum horizontal scaling of such a system will give a large increase in throughput. On especially active days, such as Black Friday, the load increases. In case the system fails or is technically malfunctioning, then 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.
Third optionthe backend implementation is hybrid, when, depending on the speed of the blockchain transaction and information on the current availability of third-party services, either SSE or HTTP interaction with explorers is used. It is the most effective and time-consuming at the same time.
The front-end technology suitable for the task is vue.js with declarative rendering and the ability to create several component states. It is a lightweight library with a sleek structure and reactive DOM modification. The data source is the SSE connection that opens when the component is initialized.
Design
We develop the product and make it high-quality and reliable in order to make blockchain payments convenient, massive and affordable. We love not only money, but also the most advanced technologies, complex tasks 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 would be grateful for feedback, comments and suggestions. If you want to bring new and bold ideas to the payment service that is used all over the world, see current vacancies .