Wallets
- Former user (Deleted)
- Persia Xenopoulou (Deactivated)
- Frini Pouyiouka
- Former user (Deleted)
On this page
Overview
A wallet is an account used by customers within CRM.COM to fund prepaid subscriptions and rewards.
Major features
- Wallets can be created, updated, or canceled manually or automatically, through various processes
- Wallets can be topped up automatically when a predetermined threshold is reached, through credit cards registered with CRM.COM.
- Wallet transactions are used to credit, debit and refund wallets. Transactions can be created manually or triggered by other processes.
- Funds can be transferred between wallets
- Each wallet is associated with an accounts receivable and funds can be transferred between the two.
Setting Up Wallets
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. Use Set as Default from the Data Entry page or Change Default from the Summary page Actions menu, to set the default type.
Once transaction types are created, define what type of transactions will result from the execution of specific events in the wallet definition.
Definition
Wallets definition is a set of business rules that are used to control the behavior of wallets throughout their life cycle.
Definition fields
The table describes the sections of the Wallet Definition Data Entry page and explains how the fields on the page are used.
Mandatory
Configurable
Wallet Causes Events that cause automatic wallet actions | |
|---|---|
| Create Wallets | Wallets are created when a prepaid subscription, rewards participant or (optionally) an accounts receivable is created. |
| Cancel Wallets | Wallets are canceled when an accounts receivable is terminated. Optionally, define whether a wallet should be canceled when it is no longer associated with a prepaid subscription and/or rewards participant. This can happen when:
|
| Debit Wallets | Wallets are debited when:
The credit note type that will be used to credit the account of the wallet can be defined. It is also possible to define whether a wallet should be debited when funds are used to settle an invoice or bill associated with the accounts receivable (using only the unconditional wallet balance).
|
| Credit Wallets | Wallets are credited when:
The invoice type that will be used to debit the account of the wallet can be defined.
|
Reimburse Wallets
| When a wallet is canceled its balance is returned to the wallet's associated accounts receivable (the funds are preserved). The accounts receivable is reimbursed:
|
| Void Wallet Transactions | Wallet transactions are voided when:
Specific payment cancellation types can be defined to void wallet transactions.
|
Wallet Rules | |
Balance Threshold Rules | Define the minimum acceptable wallet balance. The threshold 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 | Defines rules that are used to set the maximum total of debit and credit wallet transaction within a day or year. E.g., Credit = 50 and Debit = 50 total = 100 and which can differentiate based on KYC profile or accounts classification. Limits can be set to consider all wallet transaction types or specific types. |
| Crediting Rules | Define rules for crediting a wallet. If Debit the Related Accounts Receivable is enabled, select a debit financial transaction type and product to be used for debiting the account. A credit wallet transaction type can be defined as the trigger. |
| Reimbursing Rules | Define the rules for reimbursing an accounts receivable when a wallet is terminated to preserve the funds. If Credit the Related Accounts Receivable is enabled, select a credit financial transaction type and product and a limit on the maximum amount that the account can be reimbursed. A reimburse wallet transaction type can be defined as the trigger. |
| Voiding Rules | Define the rules for voiding wallet transactions.
|
Wallet balance 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 Calculate Wallet Balance Per Period available through the Actions menu. To view a list of errors identified while calculating the period, click on View Wallet Balance Per Period Errors available through the Actions menu.
Wallet Balance Period fields
The table describes the sections of the Wallet Balance Period Data Entry page and explains how the fields on the page are used.
Mandatory
Configurable
| Main Information | |
|---|---|
Number is a concatenation of integers representing the period's month and year. E.g., 201701 (January 2017). Name is made up of the period's month and year, e.g. January 2017. Life Cycle State can be 'Open' or 'Closed'. There can be multiple closed periods in the system, but only one can be in 'Open' at a time. From and To Date are the first and last day of the period, respectively. Available for 'Closed' periods only: Closed Date: The date on which the period was closed is available once the period closing process is completed. Closed by Wallet Balance Period: The name of the following period. Period Closing Performed by User: The user who initiated the Period Closing process. | |
| Wallet Balance Period Totals | The following totals are calculated during the period closing process:
|
| Period Wallet Transactions | |
| All wallet transactions that were submitted against the period. | |
Electronic Money Policies Definition
Used to define rules and policies for operating CRM.COM as an electronic money platform.
Electronic Money Policies Definition fields
The table describes the sections of the Electronic Money Policies Definition Data Entry page and explains how the fields on the page are used.
Mandatory
Configurable
Transaction Fee Rules (Determine the transaction fees for customers and merchants that use the platform to exchange electronic money) |
|---|
Transaction fees can be triggered by events. Fee Percentage: percentage of the total transaction amount, set by the user, and used to calculate the fee. Fee Ceiling: a maximum amount can be defined to avoid high transaction fees. Transaction Amount Range: the values that trigger the application of the rule. Financial Transaction Type used to charge the fee, which must be an FT type of 'invoice' classification Product used to represent the fee that is charged. Apply on Events: Enable the events that trigger the fee.
|
Maintenance Fee Rules (Determines the maintenance fees for customers owning a wallet in the platform) |
Maintenance fees are charged periodically (depending on the fee billing frequency) after a certain period of inactivity. Wallet Inactivity Period that triggers the maintenance fee. Fee Amount charged to the wallet owner for maintenance. Fee Billing Frequency (weekly, monthly, quarterly, or yearly), calculated and charged to the wallet owners for maintenance. Maintenance Fee Transaction Type |
Related configuration areas
The following modules are related to Wallets and may be configured for the Wallets module to operate at its full capacity.
| Module Link | Area | Description |
|---|---|---|
| Financial Transactions | Financial Transaction Types | Used in wallet definitions to define the types of transactions that result from specific wallet events and as a condition to trigger events.
|
| Payment Gateways | Payment Run Definitions | Used to automatically top up wallets (funded by a credit card) that fall below a certain threshold. |
Using Wallets and Wallet Transactions
Finance > Wallets > Manage Wallets
Wallet fields
The table describes the sections of the Wallets Data Entry page and explains how the fields on the page are used.
Mandatory
Configurable
| Main Information | |
|---|---|
Life Cycle State: Indicates whether a wallet is operational (Effective) or not (Cancelled). | |
| Balance information | Indicates the currently available Balance, the amount that expires in the next 30 days and the amounts subject to conditions. Amount on Hold is the amount that is not yet available for consumption due to a future validity date. Check the Allotments drill-down in the Wallet Transactions tab to view funds that are not yet available or subject to conditions. Wallet balances and transaction amounts can be represented in their default and alternative currency. The Alternative Currency set on wallets must be different than the default system currency and cannot be modified. |
| Latest Activity | Latest Auto Top Up Date: a read-only field which is set if the wallet is automatically topped up by automatic payment run definitions. Latest Debit (date) Latest Credit (date) Last 12-months Awarded Amount (for reward program participants only) Last 12-months Spent Amount (for reward program participants only) Last 12-months Subscription Spent Amount |
Wallet Period Transactions | The wallet transactions of the current period along with their allotments. Balance Period: the current running period for which the balance is calculated. Opening Balance Calculation Date: The date on which the current period started. Opening Balance: The balance carried over from the previous period. Total Debits: The sum of all debit wallet transactions created in the current period. Total Credits: The sum of all credit wallet transactions created in the current period. |
| Amount in alternative currency | Applies to all wallet transactions, provided an alternative currency was configured in General Settings. |
| Extra added amount in alternative currency | Applied on the wallet transaction. |
| Initiated by currency | Indicates whether a process that manages amounts in alternative currencies initiated the wallet transaction. E.g., a credit wallet transactions resulting from a customer award transaction in an alternative currency. |
Log Information (How the wallet was created or canceled) | |
| |
Finance > Wallets > Access Wallet Transactions
Wallet transaction fields
Each type of wallet transaction (debit, credit, void, reimburse) has different sections, depending on its classification.
Transactions can be created through the Transaction or Wallet data entry page.
The table describes the sections of the Wallet Transactions Data Entry page and explains how the fields on the page are used.
Mandatory
Configurable
| Main Information | |
|---|---|
Life Cycle State: Transactions in an 'Effective' state are taken into consideration when calculating the balance of the wallet.
Transaction Date Wallet Balance Period & Wallet Balance Period Date Funded by: The customer event, or reward offer or other entity that caused the creation of the credit wallet transaction Consumed by: the event or entity that has consumed the amount from the debit wallet transaction
Extra Added Amount: A credit bonus reflected in the balance but not taken into account by processes reimbursing the wallet or invoicing the accounts receivable. The value can be set automatically, when a credit transaction results from a voucher payment, offering bonus value as part of a promotion. (Available for Wallet Credit) Expiration Date: The day on which wallet funds expire, used by the 'Wallet Balance Expiration Run' to debit unspent amounts. (Available for Wallet Credit and Transfer) Voided by: The number of the transaction that voided a debit, credit or reimburse transaction. Voiding a transaction cancels it without affecting wallet balance. (Available for voided transactions) | |
Allotments | Allotments restrict how funds resulting from credit transactions can be spent.
|
Products | The products associated with the wallet debit or credit. Multiple products can be specified on each wallet transaction. (Available for Wallet Credit and Debit) |
Creating and processing wallets
Actions are subject to validations that take place before an action is initiated (prerequisite) or after it is submitted (post-condition).
Selecting and creating a wallet
Wallets are created manually and automatically (according to the configurations of the wallet definition).
To create a wallet manually:
Under Manage Wallets specify the criteria that match the wallets you are interested in or use NEW from the Actions menu on the Summary page. Define the accounts receivable that the wallet is created for and click SAVE to create the wallet.
Wallets are created automatically when:
- A new accounts receivable is created
- An accounts receivable that is not already associated with a wallet is added on a prepaid subscription or rewards participant.
| Postconditions | Only one wallet with an 'Effective' life cycle state can be associated with an accounts receivable at a time. |
|---|
Modifying a wallet
With the exception of the accounts receivable field which is selected when the wallet is created, values of the wallets Data Entry page are read-only and automatically updated by system events. Balance information, transaction information, and balance breakdown are updated when a prepaid billing run is executed; wallet information is updated when rewards are awarded or spent.
Canceling a wallet
Wallets are canceled (instead of deleted) so that their information is retained. Wallets are canceled manually or automatically.
To manually cancel a wallet from the Data Entry page use Cancel Wallet action available in the Actions Panel.
A wallet is canceled automatically when:
- The associated accounts receivable is terminated
- The accounts receivable on a prepaid subscription is replaced by another
- A prepaid subscription related to the accounts receivable is terminated
- A rewards participant related to the accounts receivable is terminated
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 Panel 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 the wallet definition and associated payment gateway run.
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 Panel 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 definition.
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 definitions, resulting in crediting or debiting the wallet.
To manually void a wallet transaction use VOID from the Actions menu 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 by:
- 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 in the Action Panel.
When transferring funds three transactions are created:
- Wallet transfer transaction
- Debit wallet transaction (debits the source wallet)
- Credit wallet transaction (credits destination wallet)
| Preconditions | Source and destination wallets must be 'Effective'. Source wallet must have sufficient funds. |
|---|
Transferring money from wallet to account
Funds can be transferred from the wallet to the associated accounts receivable by using 'Transfer to Account' from the Action Panel of 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 in the respective section of credit and debit wallet transactions, available in the wallet and wallet transaction Data Entry pages and 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
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.
Purchasing electronic payment vouchers (eVouchers) using wallet funds
- There should be sufficient funds in the wallet to cover the purchase
- Buying eVouchers results in debiting the wallet (value of voucher type * number of vouchers). The requested vouchers are generated automatically.
- If the wallet amount is allotted to a specific set of products or product types, then the customer must have sufficient funds allotted for at least one of the products supported by the voucher.
Applying business flows on wallets
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.
Viewing future wallet balance
The 'Validity Date' of funds in a wallet affects the available balance. Setting the 'Validity date' in the future restricts when the money can be spent. This is ideal for allotments and awards.
To view the balance that will be available once the funds are valid, use 'View Future Balance' from the Action panel of the wallet Data Entry page and enter the date.
Viewing product consumption
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.
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.
Viewing the balance breakdown
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).
Funds valid in the future are not taken into consideration in the balance calculation.
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 in the Action panel.
Communicating wallet information
Information on wallets can be communicated by using the Communicate Wallets action available through the Actions menu.
You can use tags (text that is automatically replaced by values specific to selected records) related to wallets when creating communications. Tags are available for selection by typing '#'.
Refer to the Communications manual for a complete list of wallets tags.
Notifying wallet amount
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.
Funds can be transferred between customers and between companies (partners and merchants) and customers. Companies (partners and merchants) are identified by their accounts receivable and customers are identified by their wallets.
Electronic money policies use two types of fees, one for transactions and one for maintenance (a fee charged on wallets).
Refer to Electronic Money Policies Definition for system configuration information.
Wallet Transaction Fees
Variable system fees charged on the customer wallet or account. The fees are calculated as a percentage of the transaction depending on the transfer type, and expressed in the currency of the account, as defined by the transaction rule (or the fee ceiling, in case the percentage exceeds the cap amount). If the account currency is different than the system default, the fee is converted accordingly.
Wallet transaction fees are applied in the following cases:
- Wallet to account transactions (customer to partner)
- The account of the partner is charged
- Account to wallet transactions (partner to customer)
- The account of the partner is charged
Wallet to wallet transactions (customer to customer)
- The wallet of the customer initiating the transactions is charged
- If a wallet cannot cover the transaction fee it is rejected.
Wallet Maintenance Fees
A recurring background process that is executed once a day calculates the fees.
Wallets that have been inactive for the period defined in the electronic money policy and have a positive balance are charged the maintenance fee, as defined in the maintenance rule. The date of the last (non-maintenance) transaction is used to calculate wallet activity.
When the wallet balance is not sufficient to cover the maintenance fee, the wallet is charged its remaining balance.
Like transaction fees, maintenance fees are applied in the currency of the wallet. If that is different from the system default currency, the amount is converted.
- 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.
Wallets Analytics
Segmenting wallets
Wallets with common business characteristics can be grouped together. Use the lists in system business processes for identification of customers or for simple statistical calculations.
For more information on segmentation and how you can create wallets lists, refer to Segmentation.
Printouts
A printout displays all wallet transactions that have taken place in the current year, the balance of the wallet to date and the balance carried over from the previous year. It is available through the wallets Data Entry page in one of the following formats: HTML, XLS, CSV, RTF, and PDF.
Refer to Printouts for information on how they can be created, printed and sent.
Wallets Business Examples
Scenario 1.
Company ZX offers prepaid subscriptions, where customers pay upfront for selected services.
- The credited amount can be allotted to specific subscription products
- Services are deactivated when the balance is insufficient to cover all selected services
- The wallet's balance and the date until which services are funded can be requested by phone.
Case
A customer is subscribed to two channels, Sports HD (Rate: €30/month) and Kids HD (Rate: €20/month). The customer has already paid €300 towards the normal price plan.
Solution
Customers with prepaid subscriptions have an accounts receivable and a wallet. The funds paid upfront for subscription services reside in the wallet. Once a prepaid billing run is executed the following information is available:
Day 1: 01.06
Wallet
- Estimated Consumption Days:183 days
- Estimated Consumption Date: 01.12
- Estimated Consumption as of Date: 01.06
- Balance: €300
Per Product
- Sports HD
- Estimated Consumption Days: 183 days
- Estimated Consumption Date: 01.12
- Estimated Consumption as of Date: 01.06
- Kids HD
- Estimated Consumption Days: 183 days
- Estimated Consumption Date: 01.12
- Estimated Consumption as of Date: 01.06
Day 2: 02.06
Wallet
- Estimated Consumption Days:182 days
- Estimated Consumption Date: 01.12
- Estimated Consumption as of Date: 02.06
- Balance: €298.33
Per Product
- Sports HD
- Estimated Consumption Days: 182 days
- Estimated Consumption Date: 01.12
- Estimated Consumption as of Date: 02.06
- Kids HD
- Estimated Consumption Days: 182 days
- Estimated Consumption Date: 01.12
- Estimated Consumption as of Date: 02.06
The following process demonstrates how debit transactions are allocated against credit transactions based on the aforementioned allocation logic.
- Green and pink cells indicate credit and debit transactions respectively
- Credit transactions can have an expiration and/or consumption validity date
- There are two allotment condition groups.
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/2017 | WT0001 | Credit | €10 | Group 1 | N/A | N/A |
| 2 | 01/10/2017 | WT0002 | Credit | €10 | Group 1 | N/A | 01/11/2017 |
| 3 | 02/10/2017 | WT0003 | Credit | €10 | Group 1 | N/A | 15/10/2017 |
| 4 | 02/10/2017 | WT0004 | Credit | €10 | Group 1 | 05/10/2017 | 10/10/2017 |
| 5 | 02/10/2017 | WT0005 | Credit | €10 | Group 2 | N/A | 09/10/2017 |
| 6 | 03/10/2017 | WT0006 | Debit | €-8 | Group 1 | N/A | N/A |
| 7 | 05/10/2017 | WT0007 | Debit | €-15 | Group 1 | N/A | N/A |
| 8 | 05/10/2017 | WT0008 | Debit | €-10 | Group 2 | N/A | N/A |
| 9 | 06/10/2017 | WT0009 | Credit | €10 | Group 1 | N/A | 20/10/2017 |
| 10 | 07/10/2017 | WT0010 | Debit | €-15 | Group 1 | N/A | N/A |
| 11 | 08/10/2017 | WT0011 | Credit | €10 | Group 1 | N/A | N/A |
| 12 | 09/10/2017 | WT0012 | Debit | €-12 | Group 1 | N/A | N/A |
| 13 | 10/10/2017 | 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 Allocation | Credit Allotment | Debit Allotment | Allocated Amount | Allocation Date | Unallocated Amount |
|---|---|---|---|---|---|
| 1 | WT0003 | WT0006 | €8 | 03/10/2017 | €2 |
| 2 | WT0004 | WT0007 | €10 | 05/10/2017 | €0 |
| 3 | WT0003 | WT0007 | €2 | 05/10/2017 | €0 |
| 4 | WT0002 | WT0007 | €3 | 05/10/2017 | €7 |
| 5 | WT0005 | WT0008 | €10 | 05/10/2017 | €0 |
| 6 | WT0009 | WT0010 | €10 | 07/10/2017 | €0 |
| 7 | WT0002 | WT0010 | €5 | 07/10/2017 | €2 |
| 8 | WT0002 | WT0012 | €2 | 09/10/2017 | €0 |
| 9 | WT0001 | WT0012 | €10 | 09/10/2017 | €0 |
| 10 | WT0011 | WT0013 | €10 | 10/10/2017 | €0 |
Notes
- If you are using a previous release, view CRM.COM Release Changes.
- Use the Wallets WEB API to create and manage Wallets from an external system, such as a customer portal. View the Wallets WEB API and Wallet Transactions WEB API for a complete list of actions available through the WEB API.
Glossary
| CRM.COM Term | Definition |
|---|---|
| Prepaid Subscription | A selection of customer services that are renewed automatically, billed on a recurring, usage or one-time basis and paid in advance. Prepaid subscriptions are funded directly from a subscriber's wallet. |
| Accounts Receivable | A ledger of the financial transactions carried out between a company and its customers, such as invoices and payments. The accounts receivable keeps a running balance of debits and credits and displays the amount a company is owed in exchange for goods supplied and services rendered. |
| Customer Events | Financial and marketing events involving customers, registered by CRM.COM for rewarding and additional processing. |
| Award Transactions | Transactions that credit the wallet of a rewards participant with a specific amount issued by a reward offer. |
| Spend Transactions | Transactions that debit funds awarded by a reward offer from the wallet of a rewards participant. |
| Expiration Transactions | Transactions that debit the wallet of a rewards participant by the sum corresponding to an award that is no longer valid. |
| Rewards Participant | A customer who is participating in a rewards program and can be awarded offers provided through the program. |
| Rewards Participating Merchants | Merchants that collaborate with a rewards platform and can participate in reward schemes. |