How and why we implemented our own crypto cashier?
Architecture overview and reasoning behind implementation of deriv.com crypto cashier.
Here at binary.com we decided to add support for cryptocurrencies such as Bitcoin and Ethereum, alongside our existing major fiat currencies - the crypto world is a natural choice for our business and forms the basis of our ongoing ICO
Our main requirement initially was to make crypto currencies readily available to our clients.
Based on above reasoning we decided to go ahead with already existing crypto cashiers, so that we can quickly and easily plug them in our system.
This gave us an early leverage, as we were able to accept crypto currencies on our website within a week after deciding on this.
Problems with existing cashiers
But as we started accepting and processing crypto currency payments, we found numerous issues common to multiple crypto cashiers we tried:
- No proper reconciliation support, so our payments team was doing it manually, hence decrease in productivity.
- Delay in response to support tickets/issues, leading to less customer satisfaction, hence more burden on customer support and marketing team.
- Mismatch in actual and reported end of month balance leading to manual reconciliation for payments team.
- Slow response in adding new crypto currencies.
- Security was also not upto standard expected at Binary.com.
Requirements for our cashier
So based on above issues, we decided to implement our own in-house crypto cashier.
We decided on following requirements as baseline for our crypto cashier:
- Simplicity: Our cashier need to be as simple as possible and easy to use for our clients, and as well as our payments, customer support and marketing team respectively.
- Security: Our cashier was designed from the ground up to be secure and reliable service, as security should never be an after thought.
- Reconciliation: Our cashier need to have proper reconciliation support for our payments team so that our payment team has to deal with very little or no manual work at all.
- Configurable: Our cashier need to be easily configurable so that we can add new cryptocurrencies as and when needed.
Architectural overview
For better understanding lets breakdown the architecture in terms of how participant interacts with each other, participants here being Client
, Cashier Page
, Crypto Webservice
, Crypto Node
- our own crypto currency node, Database
- store records for crypto transaction performed/requested by client, Daemon
- handles processing of blockchain transactions and Blockchain
.
Initial interaction
- Client visit cashier page on binary.com website to perform deposit or withdrawal to his/her account.
- On intial request (deposit/withdrawal) cashier page performs handshake request with our crypto webservice to validate client request.
- On handshake success client is shown cashier page based on action they have selected i.e deposit or withdrawal page.
We will explain remaining architecture flow by taking example of deposit
only, as both deposit and withdrawal, are quite similar in terms of architecture.
Backend processing
- Cashier page makes call to our crypto webservice, when client select
deposit
on our cashier page. - Crypto webservice calls our crypto node (crypto node is our full blockchain node) to generate new address for client deposit only if, no new address exists for that client in our database.
- Generated new address is then stored in our database for that client.
- Crypto webservice return address to cashier page, which is then displayed to client to perform deposit transaction.
Daemon workflow
- Client performs deposit to the specified address on blockchain.
- Our daemon selects addresses from database and keeps checking our crypto node for transaction performed for those addresses using JSON RPC (for example, for BTC: Bitcoin developer reference and for ETH: JSON-RPC).
- Once daemon finds the transaction it waits for confirmation (for example 3 confirmations for BTC/LTC/BCH and checks if latest block has transaction associated with our address for ETH).
- On receiving confirmations, daemon credit the client account and update database to mark state as confirmed.
Withdrawal
Withdrawal process is similar in terms of overview, major difference being:
- client provides us an address and amount to withdraw to
- and then daemon debit client account and performs transaction on blockchain for client specified address and amount. On receiving confirmations daemon mark the transaction as confirmed.
That's all for our first post on our crypto cashier, we will cover additional topics like reconciliation and bookkeeping in upcoming posts.
Note: This post has been ported from https://tech.binary.com/ (our old tech blog)