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
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.
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 of the 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 regards 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 .
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).
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).
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)
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.
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.
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 regards 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 awards 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:
- 'View Logs' to view already executed runs.
- 'Stop' to stop the execution of the run.
Using Wallets in EMI (Electronic Money Institution)
- 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)
- 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
- Maintenance Fee: A fee which is paid recurrently for wallet maintenance given that there is no transactional movement carried out for a period of time
- 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
- 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
Real Time Business Flows
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
Release news
Check out a full list of CRM.COM features available per release.
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.