[This post is slightly outdated, but the details are still informative to learn more about Rehive. Refer to our Help Center for more up to date content. Or start by creating a project here.]

This blogpost explains how Rehive works. In future blog posts we’ll share more details about specific features and a guide to get started.

You can think of Rehive as the technology lego blocks for building a fintech product. We have looked at over 20 fintech use cases and whether you’re creating a bill splitting app, savings bot, employee budgeting tool, invoicing solution, cryptocurrency bank, API billing service, a crowdfunding platform, or similar product, we found that roughly 80% of the backend features are always the same.

In the same way, it is relatively easy to create a website using Wordpress, or an e-commerce store using Shopify — Rehive makes it easy to create and manage a fintech product on the internet. Read more about our vision, mission and strategy here.

Rehive is a powerful tool for developers and managers to rapidly build, launch and scale user-facing fintech applications. For developers, our team has created beautiful documentation, a browsable API and we maintain SDKs and a range of open-source projects to help you get started quickly and effortlessly.

What makes Rehive special is that we have gone beyond crafting just a “tool for developers, by developers”. We have extended the platform to offer an interface for managers which allows them to configure every piece of business logic that is programmatically executed in the backend. This bridges the gap between developers and business analysts for working together in building and configuring fintech products collaboratively.

Rehive systems

At a high-level Rehive consist of two key systems:

• Rehive Platform — a flexible, lightweight fintech-specific business logic layer on top of a store of value, for quickly building fintech applications without the need for building the core backend features from scratch. The Rehive Platform is live and already supports production level products.

• Rehive Services — an open marketplace for Services that are created by third-party participants and integrated on top of the Rehive Platform. Anyone, anywhere in the world can create and publish a Service on Rehive’s marketplace. Services can be hosted by third parties, or by Rehive. Rehive Services is currently in beta and only selected projects are available to the public. Services cover the remaining 20% of the features that make a fintech product unique.

Rehive Platform — how it works

Imagine, imagine

Imagine you want to build an app that pays users for answering questions for completing a survey. You have already created the survey system, but now you want to add payments to track the users’ earnings and payouts. In the end, you probably need to build something that can do the following:

1. Currency account creation: When a new user signs up to your service you need to create a currency account for the new user in USD and maybe EUR too.
2. Email and account verification: In order to make sure this user is not a bot you need to ask the user to verify their email. However, you don’t want to force the user to verify their email before they can start earning money. So, you allow the user to start completing surveys that create a “Pending” transaction in the meantime.
3. Country restrictions by mobile number: Perhaps you need to enforce country restrictions on your product, which can be enforced to a reasonable extent by verifying the user’s mobile number.
4. Outstanding credits: On email verification, you need to check if the user has any “Pending” payouts associated to their email address. And if there are any outstanding payouts, you’ll credit the user’s balance once they have verified their email.
5. User balance: Obviously, you want the user to be able to view their total earnings.
6. User payouts: You’ve partnered with your local payment provider to do the actual payouts of user earnings directly to their bank accounts. On the one hand, you need to collect all user bank account details for making payouts. On the other hand, you need to keep track of payouts to ensure that the user’s balance is debited when a bank transfer is executed successfully. You probably also want to keep a record of the bank payout transaction ID that is associated with the debit transaction in the core system.
7. Transaction limits: You’ve managed to successfully integrate your payout service provider using the Rehive Services architecture, but want to implement daily payout limits per currency. For some users, you want to increase their daily payout limits.
8. Transaction filtering: You want the user to get a report of transaction history and filter on important parameters.
9. User controls: In some cases, you may want to freeze a user’s account from being able to earn any further money or requesting any payouts.
10. Notifications: You start getting complaints from users not knowing if payouts to their bank accounts have cleared, so you implement an optional SMS and email notification feature to quickly inform users of any account activity.
11. Race conditions: On top of all the feature requirements you need to make sure there is no risk of transactions being credited twice or going missing.
12. Error handling: If you’ve built these kinds of applications before, you’re probably feeling a restless sensation and breaking into a cold sweat thinking of API error handling, standardizing responses, etc.

If you’re new to using fintech solutions, you’re probably thinking: “I can just use Stripe, bitcoin or even a bank to do all of this for me, right?” The short answer is “No, you can’t”. Stripe is an API for merchant payment processing. Bitcoin is a low-level protocol for making payments on the internet. Bank systems weren’t designed with this flexibility and openness in mind. None of these existing options offer you the kind of flexibility you require to meet your needs. Stripe and bitcoin are part of the puzzle for possibly doing the final payout event, but without Rehive, you still need to build most of these features from scratch and securely host it yourself — we believe that doing this is a barrier to fintech innovation…

So, now you’re probably asking, “How does Rehive solve the edge cases for adding payments to my survey app?”

How does Rehive help?

Rehive has identified and created 4 core resources needed for building a fintech product:

1. Groups — Create groups to categorize and configure fintech business rules for sets of users.
2. Currencies — Rehive supports all known fiat currencies and several cryptocurrencies, but you can also create your own currency code, e.g. if you’re creating a rewards and points system.
3. Accounts — ability to create virtual pockets for currencies. Traditionally this would be savings, cheque and credit accounts. But Rehive let’s the admin or user create as many accounts as they need. Accounts are powerful for building applications where you need to manage transacting permissions and more on multiple layers.
4. Transactions — there are two main types of transactions: debit and credit, but Rehive makes it possible for the administrator to create transaction subtypes. Transaction subtypes are integral to Rehive’s flexibility and you’ll shortly realize why this is such a powerful little feature.

Users — Rehive includes everything about users, from on-boarding through to day-to-day management. Users can sign up, login, reset the password, change password, verify email and enable 2-factor authentication. The same authentication features apply to administrators and managers, however, administrators can also create permanent API keys used for custom and/or third-party integrations via Services.

Rehive went one step further: in addition to these 4 core resources, the Rehive Platform covers a range of specific built-in features needed for a fintech application, such as:

• Tiers, Fees, Limits — in many cases you want to tie limits and fees to users that are qualified at different tier levels. A tier level is determined based on user information provided and a scoring algorithm. For example, the administrator can configure Tier 1 users to transact only $10.00 per day and $100.00 per month.
• KYC — fintech businesses need to collect specific information and documents for regulatory compliance.
• Webhooks — a highly configurable webhook system that triggers webhooks on any user, transaction event or process.
• Controls — ability to enable and disable API keys, transactions, users, accounts, currencies
• In future blog posts we’ll unveil the full set of features and demos.

In conclusion, Rehive’s magic is that administrators and developers can create and configure every feature on a Currency, Account, Transaction and User level. This kind of granular customizability allows for creating innovative payment recipes, without having to hard code it into the source code. We’ve carefully designed the flexibility and ease of management with the goal to make it easy and help you save time, cost and many headaches.

Key Concepts

The following section should help clarify some key concepts that you might be wondering about.

Store of value

A store of value refers to the custodian of user funds — the place where user funds are officially stored such as banks, blockchains, payment processors, etc. Rehive never holds user funds nor handles any real payment processing.

Admin and User API

Rehive Platform is built as a Restful API that consists of two distinct API types: User and Admin APIs. The User API refers to all the API endpoints that can be accessed by user-facing applications and can only trigger actions that impact the user directly. The Admin API is designed to be accessed by custom or third-party services that can execute actions on behalf of one or many users. The Admin API can do everything the User API can do, and more. The User API uses temporary token authentication, whereas the Admin API uses a permanent permission-based token.

User App and Admin Dashboard

Newcomers often get confused by the difference between Rehive’s User App and Admin Dashboard.

User App refers to the client-side application that is used by the end-user, whether it is a corporate client or retail consumer. Rehive has created an open-source User App in React Native, Ionic and in AngularJS for web browsers. User App is mostly built on top of the User API.

Admin Dashboard is the client-side application used by the back office management team and developers. Rehive has open-sourced the project built in AngularJS, making it easy for you to make changes and further integrations as needed for better managing your product. The Admin Dashboard is integrated on top of the Admin API, where all API calls are capable of executing actions on behalf of users in the ecosystem.

Account mapping

1-to-1 account mapping refers to cases where every account on Rehive Platform is mirrored on the existing system of the underlying store of value. 1-to-many accounts mapping refers to cases where all user funds are stored in a single custodian account, where the Rehive Platform is the only record of user account balances and transaction history. The Rehive Platform can be configured to map accounts 1-to-1 or 1-to-many on top of a store of value.

Banks often want to know if Rehive can integrate with legacy infrastructure to support 1-to-1 account mapping. The short answer is “Yes”, but Rehive is more valuable if you are using 1-to-many mapping logic.

Transaction ledger

At the core of the Rehive Platform is the transaction ledger system. There are two types of transactions: debits and credits. Debit transactions reduce an account balance whereas a credit transaction increases an account balance. Each transaction has a set of attributes that you can read more about here. One of the more powerful attributes is the metadata field that can be used in creative ways to store any special data associated with a transaction. Each transaction also includes a status field that is directly tied to a set of internal business logic when the status is updated, e.g. changing a transaction status from “Pending” to “Complete” will run internal processes and ultimately adjust the account balance accordingly.

Webhooks

The Rehive Platform boasts a highly configurable webhook system that can trigger webhooks on any user or transaction event. Webhooks are useful for integrating custom or third-party systems. The Rehive Platform currently supports several user and transaction webhooks to accommodate the most common requirements such as password reset or transaction execution. Read more on our webhooks here.

Transaction subtypes

Administrators and developers can configure transaction subtypes for which a whole string of specific business logic and rules can be configured and executed when a specific subtype is executed. Transaction subtypes, in combination with webhooks, allows for unlimited creative transaction recipes. E.g. you can create a custom ‘rebate’ transaction subtype, e.g. rebate_credit, which is triggered on a debit transaction. This subtype can be configured to allocate 1% of every user debit to a ‘savings’ account which incentivizes users to spend more or spend at specific merchants or spend according to some gamification logic, etc.

Browsable API

Developers can use Rehive’s browsable API to test functionality from their favorite browser. It is a convenient feature that developers enjoy using to play around with to better understand how the system responds. It is best to use the browsable API and Rehive documentation together as the documentation provides more detail.

Blockchain

In future blog posts, we’ll explain how Rehive leverages the advantages of existing blockchain networks and how we’ve created a set of tools and features for making it easy, secure and scalable to launch a Crypto Bank or Crypto Fund using the Rehive Platform and Rehive Services. Rehive is currently testing Bitcoin, Ethereum and Stellar blockchains in beta.