When we want to receive payments from customers we face a problem how to provide a secure and simple payment gateway? In this article I will analyze popular approaches to solving the problem.
There are two main approaches: to set up your own service or to use an external one.
Using an external payment service
Such services are easy to integrate because they have a good documentation, they are usually affordable, but you don’t know anything about what is inside. Most of crypto payment gateways have a closed proprietary code. So using these services is at your own risk.
Deploying your own payment service
The major benefit of this approach is that you know how it works. Usually, you own a source code of your service and could audit it as many times as you want.
There are two types of services: with a full node and without one. When you are using a full node (Bitcoin Core, Go Ethereum, Parity, etc) you can use their API for tasks like new customer’s address generation, checking transaction status, checking balance, forwarding funds to a cold wallet. Also full nodes have a good API documentation that simplifies development. But this option has at least 2 problems.
First, full nodes requires a lot of resources. For example, on March 18, 2018, Bitcoin Core was about 200 GB, Go Ethereum (geth) was about 700 GB. Also Ethereum full node requires about 32 GB of RAM.
Second, you need to keep your private keys on these nodes. Because when a full node generates a new address, it saves a private key to wallet file. Any person who has an access to the server can steal the keys. We will not talk about wallet passphrases, because anyway this type of service is not secure enough.
To sum it up, the full node service is easy to develop but resource-intensive and not very secure.
Second type is a service without a full node. To check transactions or forward funds to a cold wallet (broadcast transactions) you can use already failovered block explorers and you do not need huge resources for making nodes available 24/7/365. To generate a new customer’s address it’s better to use Hierarchical Deterministic (HD) keys.
Hierarchical Deterministic (HD) keys in a simple words
What is HD keys? This is an algorithm which allows you to split public and private keys storage.
Classically, when you generate a new address, first you generate a private key, store it, then you generate a public key and address from the public key, and store it, too. So, to create a new address you need to store its private key.
Let’s go back to HD keys. Imagine that we have an algorithm which allows us to generate separately some private seeds and some public seeds. Then we can generate a new private key from a private seed in one place and a new one public key from a public seed in another place. And this algorithm works such a way, that if we generate 5th private key from private seed, it will be the private key of 5th public key from public seed.
You can read a detailed article about how HD keys work here. But the main conclusion is that we can separate public and private keys generation. So we can generate only public keys on your server and generate private keys for them in a safe place.
Let’s return to an own service without a full node. Now we know that HD keys is a secure way to collect funds, but we need an implementation to use it in our service. There are not so many libraries for different languages, but all of them have many dependencies. To make it clear, you need to audit a huge amount of code before using these libraries.
We at HashEx solved this problem by self-implementation of HD library in Java. The main features of our library are:
- HD keys support (BIP32);
- Mnemonic seed support (BIP39). You can use our keys in any HD-compatible wallet if you want;
- REST API interface;
- Java application without untrusted dependencies. You can audit the code;
- New addresses generation in any currency (BIP44);
- Balance and transaction checking with block explorer;
- Funds collection mechanism to send collected funds to a cold wallet with fees optimisation. Sending funds with our library is cheap as never before.
Let’s summarize, an own service without a full node with HD keys is resource-effective and secure. But it is more complex in implementation than the first one.
If you want to use our library, drop me a message.
HashEx website: https://hashex.org
Connect with me via LinkedIn https://www.linkedin.com/in/dmitrymishunin/