Technology

The blockchain integration topic is not new to us, we got most of our knowledge and pains through the ICO platform development. One of our main challenges was to decide which blockchains we should integrate directly, interfacing with our own full node, or use a third party provider for this first cycle of the product.

When researching, we did integrations directly to the Bitcoin and Ethereum blockchains. However, on the latter we felt that we should go through a more mature and tested implementation and, side by side, start implementing our own with what we learn through the development cycle.

At this stage, we are using Infura for integration with Ethereum. This gives us insurance that all needed functionality is implemented and tested, so we can consume from their APIs and deploy the product. On a separate stage we will start doing tests with our own Blockchain API integration for Ethereum, so we can get a more direct control over the communication with the network. When choosing a partner we look for fast integration and maturity, this allow us to move quicker and increase the throughput of our development roadmap.

Tech Stack

We chose to build infrastructure primarily with Elixir, a functional language with a Virtual Machine (BEAM) that uses the Actor Model. Even though Elixir is a pretty recent addition to the space, it is fundamentally the same and even shares the same Virtual Machine as Erlang, which has been around for a long time and still powers most of the world’s telecommunications.

Therefore, we are confident that we will be able to scale the way we intend and go where we want to go on top of this environment. As a bonus, it is a very interesting and enjoyable language to work with, which is also an important criteria for us, since we care deeply about developer happiness as a performance metric.

As far as architecture goes, we were heavily influenced by Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES), which are being used in some form by most of the major technology corporations in the world (regardless of them calling it that or not). We are also using Elixir Umbrella Applications, which allow us to have a microservices architecture, without ever leaving the comfort of the BEAM.

In our web and API layers we are using the Phoenix framework, the main web framework for Elixir. Note that since most of our business logic lies within our core application, this web layer ends up not being very complex, allowing us to focus more on the quality of each piece.

As far as our front-end clients go, we are using React with Redux, which communicate with the web layer via AJAX and Websockets. We are opinionated in regards to the way we organize the front-end, and specifically for CSS, we use CSS modules with CSSnext for component-based UI development.

Our mobile apps (still in testing) are built using React Native, which allows us to more quickly develop applications for different platforms. Ethereum and Bitcoin integration are already in place and we are now looking to integrate other blockchains and ERC20 tokens.

Integration Tools

As challenges occurred throughout the development cycle, we started to incorporate some integration tools into our stack to improve team communication, code reviews and the overall development heartbeat.

Semaphore is one of those tools. With the introduction of Continuous Integration, we now use it to offload most of the work when running tests, especially when we have multiple feature branches and each developer needs to run tests before merging the code. The frustration of managing logs for readability and logging lead us to Timber, that although is a relatively new SaaS, has been a big help.

As we aim to be a remote team in the future, most of our communication needs to be static rather than dynamic. We used Slack in the past, but most of the knowledge and discussions were lost in the pit, when the first development cycle began we started using Twist from ToDoist. It is particularly strong when it comes to retaining knowledge.

API Showcase

To give a first impression of what the Merchant API looks like, we are showcasing two examples here. This primarily serves developers show what they can expect. All API methods are built RESTfully.

Store Order creation

POST /stores/order

Store Order Payment Listing

GET /stores/payments

Know Your Customer (KYC)

A hot-button topic within most blockchain projects right now is making the KYC process as seamless as possible, avoiding an awful experience and headaches. We have learned a lot about this during our ICO last year, in which we gained experience in what are the pain-points, and how to solve them.

First and foremost, we see UTRUST a financial product. We deal with cryptocurrencies as well as fiat currencies, and therefore comply with all necessary regulation. In the financial world, KYC is a requirement, so we needed to fully understand the flows and how users experience it. One of the first information sources we learned from, was the on-boarding process on several mobile-first banking apps.

Next, we we studied the legal implications and documents requirements within Switzerland and SEPA regions (Europe & et al). This is crucial, as we are on track to get our own license. Our flow needs to be well understood by all members, from development to marketing.