Modern life can in many ways be broken down into a series of transactions. We give something, like information, money or services, and we get a corresponding value in return. In that regard, time really is money. And so are stored values like virtual assets, loyalty points, kilometers driven and hours of usage.
Effective stored value management has become an important factor for online and offline businesses – all the more as customers interact with stored value systems on a daily basis too.
For startups and small companies, the fast-paced nature of value exchange is not necessarily good news. It requires reliable software to handle monetary, stored value management and similar use cases – something not easy to provide if the company’s USPs lie apart from digital finance.
Stored Value Management with CoreWallet
This is where CoreWallet comes in. Integrated into a company’s own backend, the CoreWallet API can be used to build up a scalable and efficient system for any kind of digital money and virtual account management. As a software foundation, it is applicable to a broad range of use cases.
Among the possible applications are transfers of stored value assets. Such assets have monetary relevance for your non-fintech businesses but are not emoney per se. Think of such non-money currencies like loyalty points, bookable kilometers or VIP credit points, for example. In the following paragraphs, we will detail how CoreWallet handles such assets and present a handful of use cases, where this comes in handy. As a first step, we have to talk about the functions at the heart of all stored value systems in CoreWallet: Wallets and Balance Transactions.
Storing Value: Wallets and Other Entities in CoreWallet
When you want to set up your own stored value transaction system on the CoreWallet foundation, you have to think about the purpose of the stored value and how you want it to interact with emoney and payment processes.
For example, when you plan to run a loyalty point system, you must determine which actions shall be allowed for loyalty points:
- Can you buy directly from your online shop using them as a currency?
- Should it be possible to exchange them for emoney or cryptocurrencies or other stored values?
- How are they issued – bought or given freely?
- Which rights are provided to users, to interact with the stored value assets (peer-to-peer transactions, i. e.)?
When answering these questions, it boils down to the systemic entities specified in CoreWallet and how they interact with each other. These entities, which you build your own stored value app on, basically are:
- Subsidiaries: The overriding layer of the app, representing the app’s “bank”, which fills the User wallets. It’s a closed container of Accounting Accounts, out of which the currencies (loyalty point or otherwise) are issued and distributed among the User wallets. It’s possible to have several Subsidiaries, which can interact with each other.
- Wallets: A wallet is a container of wallet accounts. A wallet can either be owned by a user (User Wallets) or the system of the app in question itself (System Wallets). User Wallets contain the payment instruments, the system allows usage of, as well as one or several Wallet Accounts. Wallets interact with subsidiaries and with each other, for example during a shop purchase – in this case, a User Wallet would interact with a System Wallet.
- Wallet Account: A single account in a Wallet, which has a single, defined purpose and processes one single currency (i.e. emoney or stored value assets). How a Wallet Account can be used exactly is determined by the configuration of the app built on top of CoreWallet. There must be one Main Wallet Account in any Wallet. Wallet Accounts hold one or more Accounting Accounts.
- Accounting Accounts: Each one is assigned to a Wallet Account or directly to a subsidiary. It has an Account Balance, indicating the financial status of that Account in a single currency. Also, it’s Accounting Accounts between which transfers such as debiting and crediting occur.
You can find more detailed information about this topic in the CoreWallet Documentation. Configuring these entities allows you to simply implement the exact functionalities you will see in the use cases below. One feature we have to address first, however, is Balance Transactions.
Money on the Move: Balance Transactions
The Balance Transaction is the central feature in CoreWallet to establish a specific flow of accounting and transaction processing for your product.
In essence, the feature runs all sorts of balance alteration in wallets and accounts. This means it furnishes a number of default operations, which allow you to build exactly the product you intend. It is mandatory to fine-tune those operations and fit them into your backend using the Balance Transactions API. Important parameters going along with or preceding transactions like access control configurations, authorization, and KYC regulations lie on the part of your own backend. Of course, CoreWallet is all set to fully comply.
Within an app managing and transferring stored values, those stored values would have balances spread across different User Wallets and System Wallets – the later are especially important as the stored value is fed into the system via the Accounting Accounts of Subsidiaries (see above). There are a number of basic operations, you would likely want your product to perform with stored values. And all of them are part of the CoreWallet feature set, among others. A selection:
- Authorize: An amount of stored values is transferred from one User Wallet Account to another User Wallet Account or System Account.
- Debit: Transfers an amount of stored value from another account (User Wallet Account or System Account) and creates a WalletAccountItem if needed (see below).
- Cancel: An existing or ongoing Balance Transaction is canceled. The stored value is reverted to the original Wallet Account.
- Refund: Refunds an amount of stored value based on existing authorized balance transaction, which transfers it back to the original Wallet Account. Each Refund is a new Balance Transaction.
There are several more operations, CoreWallet ranks among its features. If you want to learn more, the CoreWallet Documentation elaborates on this in greater detail. In any case, most Balance Transactions create so-called Wallet Account Items attached to the Wallet Accounts performing the operation in question. Wallet Account Items are wallet activity entries, visible to the user (and system operators as may be necessary – the data protection regulations of your country apply of course.)
There are a number of options to fine-tune these operations. For instance, you might want to set a minimum balance for certain stored-values which is always met and restrict the types of currencies certain wallets can interact with.
Now that’s the theory. Now let’s dive into some actual examples of usage.
We will use special text to indicate, what a specific functionality might look like in CoreWallet.
1. The Chat App: Managing Credits for In-App Purchases
Let’s imagine you want to create a chat software accessible via a client on desktop and mobile devices. It allows users to share messages, pictures, and videos, as seen in other software like Facebook or Whatsapp. However, all users have their own animated avatars. Express yourself – with Expresto, the new chat app!
Upon registration, you plan that every user generates an avatar, which is displayed in the chat environment. Messages, pictures, etc. presented by the avatar, in speech bubbles. Emojis, however, follow a different approach. They are expressed through animated facial reactions of the avatar.
Later on, avatars can be customized with new hair, facial features, and accessories. To do that, the user spends actual money to get so-called Expresto Smiles, an in-app currency. In a special online shop, she can unlock new optical assets via these. Different offers cost different amounts of Expresto Smiles.
Expresto Smiles are stored-value assets. They must be generated in your app’s backend, issued through a System Wallet with an Accounting Account tied to the Subsidiary (the Expresto App Main System). The Users use the payment instruments tied to their User Wallets to send money to a Shop Wallet Account via their Wallet Account. Then, a System Wallet assigned to handling Expresto Smiles transfers the corresponding amount to the User Wallet Account handling Smiles. Taken together, all involved Wallet Accounts come out at a balance of 0.
Conversely, once the user pays with Smiles for digital content in the Expresto Shop, the shop’s backend would issue a balance transaction to debit the user’s wallet and move the Smiles to the defined target System Wallet.
It is also possible for a user, to send contacts and chat friends a small number of Smiles from as a present. All she has to do is use the “Wrap up present” feature in the chat app’s UI.
On the backend, this is also a simple Credit operation (see above). A User’s Expresto Smiles Wallet Account sends the Smiles to another User’s Wallet Account.
Aside from buying them, the user can also slowly collect Expresto Smiles without paying: Upon first login on a given day, she is granted 1 Smile. If she clicks on an ad banner and watches the video of a sponsor, she is granted 5 Smiles.
This is where the Minimum Balance feature might come in handy. In any case, the System Wallet in charge must be automated to undertake a daily Balance Transaction to credit the Users’ Wallet Accounts.
Of course, the system can be expanded with additional currencies like Premium Smiles, too: First off, you would have to create this currency as you did with regular Smiles (see above). Then wallet accounts in the System Wallet must be established for that currency – and for each user who owns units of the new currency. Then balance transactions of Premium Smiles to and fro User Accounts are possible.
2. The Forklift Rental: Managing Kilometers and Rental Credits
Let’s say you run the mid-tier business Elstar Logistics GmbH, a forklift rental service. Customers can lend out your forklifts to use in their own warehouses. They rent them based on a Kilometer-per-Euro ratio. This requires a customer buys such a user package and gains a specified budget of Kilometers.
The customer can use the forklift in her company locations as she sees fit. Software installed on the forklift tracks the Kilometers driven with it. If the forklift drives more Kilometers than the user package allows for, the customer has to pay an additional fee when turning the forklift back in.
In this example, purchasing the non-money value might be a little more complex, when compared to the previous use case. Let’s say you want to ask users to top up their accounts with money (e. g. Euro), and then they use this money to gain a specific budget of Kilometers, determined by a preset exchange rate.
On the level of the CoreWallet API, you would need several system wallets, adding Euro (EUR) and Kilometers (KM) as currencies. The system wallets under the Subsidiary will be the source and target for issued EUR and KM and will manage their flow during purchase and spending. Two basic procedures are required to make the forklift rental process work: Purchasing Kilometers with Euros and tracking Kilometers.
Feeding In Euros
First off, for each User Wallet of the Elstar Logistics forklift service, two User Wallet Accounts need to be created, one for KM and one for EUR. To purchase Kilometers, the user must have access to the Elstar Logistics online rental portal backend, where he can credit his EUR Wallet using his preferred payment instruments. For each successful payment, the System Wallet responsible for issuing EUR would order its Accounting Accounts to make a transaction to the EUR Wallet Account of the user, who paid the sum.
(Keep in mind, that according to the financial transactions and KYC regulations applying to your country, you will have to purchase licenses and enact authorization procedures in this step. It should be noted, that CoreWallet can also handle the payment and top-up process, too. For more information, contact us.)
Purchasing Kilometers
With her wallet account, now containing EUR, the user can bulk up her Kilometer stock. This follows the exchange rate, you have set up beforehand. Let’s say it equals to 1 EUR per 2 Kilometer. If the user pays 10 EUR, her user wallet Euro balance would be increased to the same sum.
This would require two transfers. To purchase kilometers worth of 10 EUR, the EUR value would be transferred from the proper User Wallet Account to the proper System Wallet Account. The second transaction goes the other way round: Kilometers are transferred from a System Wallet to the User’s second Wallet Account, managing her Kilometer stock.
Tracking Kilometers
To manage spent Kilometers from the user’s account, each forklift has to have a device installed that tracks the Kilometers per trip, which then answers to your backend. Once the forklift comes to a stop, it sends the kilometers driven and the forklift’s ID number to the forklift rentals system. Both, the tracking software and the backend rentals system are software developed by your team or a third party itself, in that case. The CoreWallet software, however, does the math in the background.
Once your backend has tracked, how many Kilometers were driven with a given forklift, a Balance Transaction is issued. It moves the KM amount from the prepaid user’s KM Wallet Account to a special System Wallet Account.
To identify the transaction and trace it back in CoreWallet later, the forklift ID can be used as the “custom type/tag” for the transfer. If you want to see, which trips were taken with a specific forklift, you can just query the Wallet Account Items (see above) and look for its ID. The KM budget as a whole is represented by the System Wallet Account used to issue KM, without time constraint. If a detailed history is needed, you can query the Wallet Account Items for the given Wallet Account.
Multiple Forklifts
Instead of using one target System Wallet for all forklifts, one could also think of giving each forklift its own System Wallet. In this case, using the forklift ID as the “external id” for a system wallet. That means: Spending KM from the user’s KM Wallet Account will be split to multiple System Wallet Accounts, depending on which forklift the user will use.
3. The Public Library: Managing Borrowed Media via User Wallets
Let’s say you run the Public Library of the city of Ogdenville and have issued a shared library system with the libraries of North Haverbrook and Capital City. Now you want to replace your old, cash-based rental service, hoping to reduce the workload for the staff and to provide incentives for frequent customers. You decide on an eWallet based solution.
Every customer of the Public Library networks, who an account at one of the libraries receives a membership card. This card is connected to an online platform. By paying a fixed sum of 10 Euros, which can be done online on the library’s website or directly within the library, the customers receive 100 so-called Bookmarks, a custom currency used to pay for borrowing media from the libraries.
Customers pick up the books, magazines or DVDs they want to take with them and scan them before leaving the library. Each medium costs a specific amount of Bookmarks to rent it. Books and Magazines are 1 Bookmark, DVDs are 2 Bookmarks per day.
As long as the media is borrowed, the customer’s wallet is charged every day. When it reaches a negative balance, the customer has to pay a fine when returning the media, related to how many negative Bookmarks were gathered.
You know the drill: The library system needs to track which books are rented via the membership card, and perform a daily charge on the card by creating a Balance Transaction from the User Wallet Account to a dedicated System Wallet Account (either the total sum, or one transaction for each book, which in the end provides a more granular overview later, when checking the data).
Alternatively, one can think of creating a Wallet Account for each book, which allows an even more exact way to manage the library’s stock.
Purchasing Bookmarks is also done using a transfer from the System Wallet Account. Once the customer pays the sum at the counter or online on the library’s homepage, Bookmarks are issued to the User Wallet Account.
But Wait, There Is More…
We can think of many more examples for use with CoreWallet. And conceivably, your own projects and business frameworks might function completely different than we might imagine – and will show more business acumen than to our sketchy examples.
But this it is precisely why CoreWallet was designed with maximum flexibility in mind: Your unique core features and selling propositions are what matters. We enable you to fully focus on them and not be forced to bind resources and know-how to create a stored value management software all on your own.
There is a lot more to discover about CoreWallet. Just look at the Product Page for an overview or visit the CoreWallet Documentation portal for technical details and access to a Demo Wallet environment.
