Overview

A wallet is an account used by customers within CRM.COM to fund prepaid subscriptions and rewards as well as used as a mean of money transfer in EMI (Electronic Money Institution ) business model .

Setting Up Wallets and Core Processes

Configuration / Finance Application / Finance Settings / Set up Wallet Settings

Before you start using Wallets set up the system to reflect your own business needs.

Wallet Transaction Types

User definable types are used to distinguish between wallet transactions of the same classification. Classifications define the operational characteristics of each transaction.
For example, create two separate transaction types of classification wallet credit, in order to differentiate between transactions that fund the wallet by credit card or with a voucher.
There are five predefined transaction classifications:

Wallet Credit funds the wallet.
Wallet Debit deducts funds from the wallet.
Wallet Reimburse takes funds from the wallet and credits the accounts receivable of the owner.
Wallet Void transactions reverse and cancel Credit, Debit and Reimburse transactions.
Wallet Transfer moves money from one wallet to another.

If multiple types are created for each classification, then a default type must be selected for each one. Enable through Used as Default Type .

Once transaction types are created, define what type of transactions will result from the execution of specific events in the wallet causes and rules.

Back to top

Wallet Causes

Wallet Causes are events that cause automatic wallet actions such as creating,canceling, debiting, crediting, reimbursing wallets and voiding wallet transactions. In some events you have the option to define specific parameters which will trigger the event, thus offering you greater flexibility on how the system will behave. For example, you can set that only when a specific financial transaction payment type (i.e. card payment) is created that the wallet should be credited.

Wallet Rules

Wallet Rules set the guidelines to how the system should behave with regard to wallet associated events, such as crediting or reimbursing the wallet. Additionally, define the balance threshold which is the minimum acceptable wallet balance; the value can be positive or negative. It is user-definable, inclusive and '0' by default.

If the balance drops below the threshold, the system blocks debit transactions (including reimburse, transfers or voiding of credit).

Wallet Transaction limits are also defined in the rules which are used to set the maximum total of debit and credit wallet transaction within a day or year and which is primarily used by the EMI business model

E.g., Credit = 50 and Debit = 50 total = 100 and which can differentiate based on KYC profile or accounts classification.

Setting up and Using Wallet Periods

A wallet balance period is the monthly time frame during which the balance of the wallet is calculated. The opening balance of a wallet is the sum of the balance brought forward from the previous (closed) period and balance resulting from transactions in the current (open) period.

The first period is automatically created by the system. The next period is created once the current one is closed (using the Closing Period process). Closed periods cannot be opened again or register new wallet transactions. Wallet transactions can only be posted against the one open period.

To close an open period from the Data Entry page, click on Close Wallet Balance Period available through the Actions menu. To view a list of errors identified while calculating the period, click on View Calculation Error Logs.

Recommended additional setup

In addition to the Wallets specific settings the following may be configured for the Wallets to operate at its full capacity.

Set up Financial Transaction Types used in wallet causes and rules to define the types of transactions that result from specific wallet events and as a condition to trigger events
Set up Automatic Recurring Payments (Accounts Receivable Settings) to define whether automatic top up of the wallet that fall below a certain threshold is supported through automatic recurring payments .

Back to top

Using Wallets

Finance / Wallets / Manage Wallets

Finance / Wallets / Access Wallet Transactions

Use Wallets to fund prepaid subscriptions and rewards as well as to handle EMI business model. In this section you can find out how your business can use Wallets to cover its own needs.

Specify the criteria that match the wallet you are interested in or use NEW from the Actions Menu to create a new Wallet by providing the accounts receivable to which the wallet will be associated. If a Wallet has been mistakenly opened you can CANCEL through Actions > Cancel action. The Wallet can be cancelled as long as there is no associated subscription account or rewards participant linked to the wallet. Cancelling a wallet can also be done automatically triggered by one of the events defined in the Wallet Causes.

Credit, debit,reimburse or void wallet transactions associated to the wallet either directly from the Wallet page (Actions) or through the dedicated Wallet Transaction page

Funding a wallet

The following processes result in a wallet being funded:

Manually creating a credit wallet transaction

Credit wallet transactions (which increase the funds available in the wallet) can be created by selecting NEW from the wallet transaction Data Entry page or by selecting Credit Wallet from the Actions of the wallet Data Entry page.

Topping up a wallet

Funds are deducted from a wallet when a prepaid subscription is charged or when awards are redeemed. When the balance falls below a predetermined threshold the system can use the subscriber's online payment system (e.g., credit card or PayPal) to top the wallet up and avoid the interruption of services.

Top up rules must be set up in Automatic Recurring Payments available under Accounts Receivable Settings.

Posting a payment or credit note

The system can be configured to automatically credit the wallet when a payment or credit note is posted in an accounts receivable.

Transferring money from one wallet to another with an action

Transferring money from the account to the wallet (as long as the account balance is less than zero)

Executing a prepaid billing run (to bill Prepaid subscription services) If a prepaid service is removed before being fully consumed, the billing run credits the wallet with the unused amount.

Creating an award transaction

Awards are funds that credit the wallet of reward participants and can be redeemed for goods and services. Although awarded funds appear available in the wallet, spending them can be subject to conditions or restrictions. For example, a €20 award that must be spent on a Monday.
Most award transactions are triggered by the creation of customer events.

Canceling a spend transaction - Voiding

The wallets of reward participants are credited with awards and administer how the awards are redeemed. When an award is redeemed funds are debited from the participant's wallet. Funds can be returned to the wallet by voiding the debit wallet transaction (e.g., in case the participant returns a product bought with awarded cash).

Canceling an expiration transaction - Voiding

Funds earned through awards that are available in the wallet can be subject to an expiration date (e.g., end of the month or year). Expiration transactions debit expired amounts from the wallet. Funds can be returned to the wallet by voiding the debit wallet transaction (e.g., in case the award was expired by error).

Back to top

Spending or deducting money from the wallet

Wallets in CRM.COM are mostly used to pay for prepaid subscriptions and to redeem awards.

Funds can be deducted from the wallet by creating debit wallet transactions.

Select NEW from the wallet transaction Data Entry page or by selecting Debit Wallet from the Actions of the wallet Data Entry page.

Executing a prepaid billing run

Prepaid subscription services are billed through a prepaid billing run. When a prepaid billing run is executed, services are billed and funds are directly deducted from the subscriber's wallet.

The wallet is debited by using debit wallet transactions.

Canceling a payment - Voiding

If a payment made to the account (resulting in a credit wallet transaction) is canceled, the respective wallet funds are deducted from the wallet by voiding the transaction.

Canceling an award transaction - Voiding

If an award is canceled (e.g., in case the participant returns the products that gained him the award) funds can be removed from the wallet by voiding the credit wallet transaction.

Creating a spend transaction

Awards credit the wallet of reward participants. Awards can be redeemed through spend transactions which debit the wallet. A debit wallet transaction is created to reflect the spend reward transaction.

Spend transactions are triggered by 'spend request' customer events.

Executing a wallet expiration run

Awarded funds available in the wallet can be subject to period validity constraints (e.g., until the end of the month or year). Expiration transactions trigger debit wallet transactions that remove the expired amounts from the wallet.

Transferring to account

Funds can be moved from the wallet to the associated account, debiting the wallet.

Paying off a bill or an invoice using wallet funds

An outstanding bill or invoice can be settled using the unconditional balance in the wallet (through the WEB API only).

Back to top

Reimbursing an account through a wallet

Funds from a defunct wallet can be preserved and reimbursed into an accounts receivable. The maximum amount that can be reimbursed is specified in the wallet rules.

Canceling a wallet

When a wallet is canceled, its balance is transferred to the associated accounts receivable through a reimburse transaction.

Replacing a prepaid subscription accounts receivable

Funds are reimbursed from wallets whose accounts receivable is no longer associated with a prepaid subscription.

Manually reimbursing an account

Automatic reimbursement can be disabled for more control.

To manually reimburse an amount create a NEW reimbursement transaction in the wallet transaction Summary page or use the Reimburse Wallet action from the Action Panel on the Data Entry page of the destination wallet.

Voiding a wallet transaction

Voiding reverts a wallet transaction, removing funds that were added to the wallet or adding funds that were deducted from it. Credit, debit, reimburse and transfer wallet transactions can be voided. Voiding is in most cases undertaken by the system, as configured in the wallet causes, resulting in crediting or debiting the wallet.

To manually void a wallet transaction use VOID from the Actions in the transaction's Data Entry page and then click on SAVE in the modal window.
Voided transactions remain visible.

Transferring money between wallets

Funds can be transferred from one wallet to another as long as the wallets are effective and the source wallet has enough funds.

Creating a NEW transfer wallet transaction from the wallet transactions Summary page.
Using the transfer wallet transaction action from the Data Entry page of the source wallet.
Using the respective transfer to wallet action through Actions.

When transferring funds three transactions are created:

Wallet transfer transaction
Debit wallet transaction (debits the source wallet)
Credit wallet transaction (credits destination wallet)

Back to top

Transferring money from wallet to account

Funds can be transferred from the wallet to the associated accounts receivable by using 'Transfer to Account' faction through Actions in the wallet Data Entry page. Only the unconditional balance of the account can be transferred (debiting the wallet).

It is also possible to transfer funds to other accounts not associated with the wallet.

Wallet money allotments

Wallets are used to finance prepaid subscriptions and administer award transactions.

CRM.COM uses wallet transaction allotments to impose restrictions on the consumption of wallet funds. Allotted funds must be spent either on specific products or on certain dates or at designated merchants.

Allotments are displayed through the wallet balance breakdown section available in the wallet Data Entry page.

In credit wallet transactions, allotments designate how funds 'can be' spent, while in debit wallet transactions, they designate how funds 'were' spent.

The system makes automatic allotments:

When vouchers are used to fund prepaid subscription products.
For transactions that debit the wallet during prepaid billing runs.
For award transactions (spend conditions defined in reward offers are added in the wallet allotment conditions).

Allotments can also be made manually when creating wallet transactions

Creating and maintaining reward transactions in the default currency and the alternative currency of the wallet

Reward processes that create award, spend and award expiration transactions display the amount in the default and alternative currency, and the applicable exchange rate.

Award transactions: the amount is converted into either currency, depending on the award of the reward offer.
Spend transactions: wallet owners can spend their wallet balance in either currency.
Award expiration transactions: wallet balance in either currency is debited when an amount expires.

Back to top

Viewing beneficiaries

Wallets are used to fund prepaid subscriptions and to handle awards and spends. While a wallet can fund more than one subscription, it can only be used on one reward participant.

To view prepaid subscriptions and reward participants funded through the wallet, click on View Beneficiaries through the Actions button.

Viewing period transactions, product consumption & balance breakdown

Period transaction information provide transactions that took place in the current period. Search criteria can be used to limit the results to specific transaction types.

Product consumption information is relevant to wallets used to fund prepaid subscriptions. The utility provides an estimation of the days left until the wallet funds run out, based on current service consumption. For example, if you have €20 in your wallet and you are subscribed to a service with a flat rate of €1/day, then the Estimated Date of Full Amount Consumption will be 20 days. Prepaid billing run and bill subscription actions automatically calculate estimations. The estimations can be accessed through the View Product Consumption action available in the Action panel.

The balance breakdown displays a list of credit records that make up the total available wallet balance. The records are grouped on common conditions, that designate how (on which reward partners and products) and when the funds can be spent. Search criteria can be used to limit the displayed balance, based on conditions applied to wallet funds. The conditional and unconditional balance is displayed, as well as the total balance (in the absence of search criteria).

Enforcing wallet consumption

In order to fund a prepaid subscription and avoid deactivation, a wallet must have a sufficient balance to cover all subscription services. In case the wallet balance is not sufficient to activate a prepaid service for its pre-rated duration, the services will be deactivated and the balanced will not be affected. To avoid deactivation, the customer may select to use the existing balance to fund his subscription services for a shorter period, by using the Enforce Wallet Consumption action.

The action can only be performed on prepaid pre-rated services.

For more information, refer to Billing of Prepaid Subscriptions.

Funds valid in the future are not taken into consideration in the balance calculation.

Back to top

Additional Processes and Automations for Wallets

Notifying customers about their wallet balance

CRM.COM enables the user to group customers for communication purposes. Customers can benefit from wallet specific information (such as when their funds are running low or when awards are about to expire)

For more information, view Notifications.

Communicating Wallets

It is possible to automatically create communications on various events that take place with regard to a wallet such as debiting crediting and transferring of funds by setting up 'Event Based Communication Definition' accordingly. You can use tags related to wallets (text that is automatically replaced by values specific to selected records) when creating communication templates or communications. Tags are available for selection by typing '#'.

Refer to the Communications manual for a complete list of service request tags.

Expiring wallet balance

Wallet funds (especially awards earned through reward offers) are subject to expiration. Funds added through credit wallet transactions can also be created with validity parameters. The expiration process can identify unspent/expired wallet amounts and deduct them from the wallet balance. When awarded funds expire, an award expiration transaction is created which debits the wallet. This background process is executed every 1 hour.

Navigate to Foundation / Platform / Manage Admin Settings / Batch Processes Admin Board
Go to Recurring System Processes
In Execute Wallet Balance Expiration Runs click on:
1. 'View Logs' to view already executed runs.
2. 'Stop' to stop the execution of the run.

Back to top

Using Wallets in EMI (Electronic Money Institution)

'Electronic money' is a monetary value (digital cash) stored on an electronic carrier or remotely in a central accounting system. E-money is intended to be used to perform payment transactions, bypassing the need of using cash, debit or credit cards which may require further authorisation. An e-money institution is an undertaking that has been authorized to issue e-money in accordance to laws and regulations laid out by the country of operation. In CRM.COM the EMI is defined as the Platform Operator (CRM.COM’s customer) which will use CRM.COM to manage EMI customers, merchants and transactions.

In an EMI business model the key players would be the following:

Merchants: The companies which accept e-money as payments for services or product sold Merchants (Wallet owners)
Customers: The customer which wished to use e-money to make payments for services or products purchased (Wallet owners)
E-money Transactions: The transactions which are carried out between customers and merchants using e-money (Transactions in and out)

EMI is governed by the transfer of money between customers’ and merchants’ wallets however deposits and withdrawals from and to external funding sources (i.e. Bank Account) are required.

Transaction-In and Transaction-Out are the transactions used to move money between customers and merchants wallets

Transaction In: Transactions that credit wallets by moving an amount of money to another customer or merchant wallet
Transaction Out: Transactions that debit wallets by moving an amount of money to another customer or merchant wallet

Deposits and withdrawals are responsible to debit or credit merchant and customer wallets, whose funds are used to carry out e-money transactions

Deposit money to a customer’s or merchant’s wallet from their funding source (i.e. bank account)
Withdraw money from customer’s or merchant’s wallet and put back to their funding source

Electronic Money Policies

All customers and merchants are subject to additional charges/fees, imposed by the platform operator (account owner)

Maintenance Fee: A fee which is paid recurrently for wallet maintenance given that there is no transactional movement carried out for a period
Transaction Fee: A fee which is applicable on transaction-in and transaction-out and it’s usually a % on the transaction amount. It is possible to define various restrictions and conditions, such as:
- Maximum transaction fee
- Apply the transaction fee only if the transaction amount is too small

Set this up in Electronic Money Policies: Configuration / Finance Application / Finance Settings / Electronic Money Policies

Transactions carried out using e-money may be imposed to a daily or annual maximum transaction limit.

The maximum transaction limit is calculated as the Absolute Sum of wallet transactions
Depending on how the system is set, the wallet transactions taken into consideration can be of all or specific transaction types

Set this up in Wallet Rules: Configuration / Finance Application / Finance Settings / Wallet Rules

Back to top

Business Flows

Allocation of Wallet Transactions

Scenario

Aluxsat offers vouchers which can be bought from various stores in the city and can be used to top up wallets of prepaid subscribers. These vouchers can be used only for specific packages/channels. For example, there are different vouchers that can be used for product Gold and product Addon.

Maria has subscribed to a prepaid subscription package which includes both the Gold product and Add-on product. She has been buying vouchers to top up her wallet which will fund the subscription.

Maria is also participating in the rewards program therefore she has funds added to her wallet through awards, however those awards are only available for a specific period (Validity Date and Expiration Date)

The following process demonstrates how debit transactions are allocated against credit transactions based on the aforementioned allocation logic.

Green cells indicate credit transactions
Pink cells indicate debit transactions
Credit transactions can have an expiration and/or consumption validity date
There are two allotment condition groups; i.e. one allotment group has conditions on the products which can be paid

Table 1 - Wallet Transactions Table

Order of Creation	Created Date	Number	Wallet Transaction Type	Amount	Allotment Condition Group	Consumption Validity Date	Expiration Date
1	01/10/2018	WT0001	Credit	€10	Group 1	N/A	N/A
2	01/10/2018	WT0002	Credit	€10	Group 1	N/A	01/11/2018
3	02/10/2018	WT0003	Credit	€10	Group 1	N/A	15/10/2018
4	02/10/2018	WT0004	Credit	€10	Group 1	05/10/2018	10/10/2018
5	02/10/2018	WT0005	Credit	€10	Group 2	N/A	09/10/2018
6	03/10/2018	WT0006	Debit	€-8	Group 1	N/A	N/A
7	05/10/2018	WT0007	Debit	€-15	Group 1	N/A	N/A
8	05/10/2018	WT0008	Debit	€-10	Group 2	N/A	N/A
9	06/10/2018	WT0009	Credit	€10	Group 1	N/A	20/10/2018
10	07/10/2018	WT0010	Debit	€-15	Group 1	N/A	N/A
11	08/10/2018	WT0011	Credit	€10	Group 1	N/A	N/A
12	09/10/2018	WT0012	Debit	€-12	Group 1	N/A	N/A
13	10/10/2018	WT0013	Debit	€-10	Group 1	N/A	N/A

Table 2 displays the allocation and the allocation order in the system, taking into consideration the:

Allotment Condition Group: credit transactions that belong to the same allotment condition group as the debit transaction and are not fully allocated.
Expiration Date & Created Date: transactions are sorted from the earliest to the latest expiration date (if present) and then by created date.
Consumption Validity Date: credit transactions whose consumption validity is before the current date.

Table 2 - Allocations Table

Order of Creation	Created Date	Number	Wallet Transaction Type	Amount	Allotment Condition Group	Consumption Validity Date	Expiration Date
1	01/10/2018	WT0001	Credit	€10	Group 1	N/A	N/A
2	01/10/2018	WT0002	Credit	€10	Group 1	N/A	01/11/2018
3	02/10/2018	WT0003	Credit	€10	Group 1	N/A	15/10/2018
4	02/10/2018	WT0004	Credit	€10	Group 1	05/10/2018	10/10/2018
5	02/10/2018	WT0005	Credit	€10	Group 2	N/A	09/10/2018
6	03/10/2018	WT0006	Debit	€-8	Group 1	N/A	N/A
7	05/10/2018	WT0007	Debit	€-15	Group 1	N/A	N/A
8	05/10/2018	WT0008	Debit	€-10	Group 2	N/A	N/A
9	06/10/2018	WT0009	Credit	€10	Group 1	N/A	20/10/2018
10	07/10/2018	WT0010	Debit	€-15	Group 1	N/A	N/A
11	08/10/2018	WT0011	Credit	€10	Group 1	N/A	N/A
12	09/10/2018	WT0012	Debit	€-12	Group 1	N/A	N/A
13	10/10/2018	WT0013	Debit	€-10	Group 1	N/A	N/A

On this page

For the developer

Check out the Wallets WEB API for a complete list of actions available used to integrate CRM.COM to external systems

WALLETS WEB API

WALLET TRANSACTIONS WEB API

Analytics

Check out reports and dashboards available for Wallets

Analytics

Release news

Check out a full list of CRM.COM features available per release.

Features

Check out upgrade notes to find out what needs to be done to upgrade from your current release to the latest release of CRM.COM.

Upgrade Notes

Browser not supported