Multi-Merchant Reward Platform - R15


Overview

The multi partners reward platform enables multiple merchants to utilize the rewards features provided by the system, through a single organisation, by allowing them to:

  • Create and run their own reward offers.
  • Create and manage their own products
  • Create and run their own segments
  • Create and run their own notifications

Multi-Merchant Platform at a Glance


Merchants can be managed through a multi-merchants reward platform if they are created as partners within the business network and have a rewards' participation agreement in place. Such agreements define reward schemes that the partners participate to, the actions that can be performed directly by them and their default contribution which is applied on all reward offers that don't have an explicit definition of the contribution for that partner.

Rewards participating merchants are the merchants that have a partnership with the organisation that owns the reward platform and can participate in the provided reward schemes following specific award, spend and sign up rules. Further more reward participating merchants are contributing on the amount that is awarded to reward participants, based on rules which are agreed and defined between the merchant and the company that owns the reward platform. By default, the merchant contribution is set to 100%

Rewards participating merchants can be grouped together and form a reward participating merchants group. Each rewards participating merchants group also has a partnership with the company that owns the rewards platform so business rules which represent the agreement between these two parties, such as the contribution rules, can be set up. All those rules will be applied for all rewards participating merchants within the group.

Set up the merchants

Create Partner Units and Partner Groups which will be used in the agreements.

Set up the agreements

For each partner unit or group set up an agreement. If the same rules apply to all merchants then you can just create a group agreement and the settings provided there will be applicable to all partner units.

Rewards participation agreements are defined at the level partner group, but they can also be overridden by agreements that are done at the level of partner units. 

Set up the scheme and offers

Set up the schemes in which merchants will participate and create the reward offers

Perform actions

Every time an award-eligible event takes place, the system will check for the merchant that logged the event in order to find the applicable offers as well as calculate the contributions. The way to identify the merchant (or group) through which an event is logged is through the 'Performed by Unit' of the event.


 Back to top


Setting Up Multi Merchant Reward Platform and Core Processes



Configuration > Rewards Application > Access Rewards Admin / Partner Agreements

Partner Agreements

Partner agreements establish the cooperation between the business with the rewards platform and its partners that participate in the schemes.  A set of rules are agreed between the parties that determine the contribution of reward partners to the amount awarded to participants.  Rewards participation agreements are defined at the level partner group but they can also be overridden by agreements that are done at the level of partner units. 

  • Partner unit agreement is defined for each individual partner and can override agreements made at the group level.
  • Partner group agreement can be defined once and applied to all partners in the same group.

In terms of setting up the agreement, both hold the same information. If a unit has its own settings for a specific area then those will be taken into consideration instead of the group setup

Partners can only participate in reward offer classifications that require that a customer event that meets the criteria of the offer is created. These are:

  • Increase Revenue, Product based Conditions
  • Increase Revenue, Transaction based Conditions
  • Reward Loyalty, Transaction Amount Based Conditions
  • Reward Loyalty, Transaction Number based Conditions
  • Reward Loyalty, Transaction Item Quantity based Conditions
  • Reward Achievement Conditions
  • Just Money Conditions
  • Lottery
  • Reward Subscription Maturity Conditions



Owning an accounts receivable


Each partner must be associated to an accounts receivable. The account will either belong to the partner group or the partner unit depending on the setup of the business network. A merchant (unit) will need to have its own account in case that debiting and crediting of the account from reward actions must be handled by each merchant, whereas the account should be associated to the partner group if merchants do not handle their own accounts. For example, in a setup where multiple shops of the same brand (company) operate as units and share a rewards plan, may have a single account at the group level. However, in a setup where you have multi - operation merchants that only operate within a common rewards plan, you would need to have an account defined per unit.

As soon as you select a unit or group in the agreement the accounts receivable will be set automatically as defined at the business network.

The account defined at the agreement will be the one used during the settlement process to either debit or credit accordingly.

Participating in specific schemes


The power of the multi-merchant platform comes from the ability to have reward schemes shared among multiple merchants as well as schemes which will be specific to the merchant. For each scheme you can allow or deny the sign up of new participants on the scheme. If sign up is not allowed, then if the logged in user belongs to the group or unit of the agreement then he will not be allowed to register new participants.


Setting up partner permissions


Partner permissions allow you to safeguard against changes on the reward platform setup such as offers, products, segment and notifications from users within the group or the unit

Additionally you can define if participants can be awarded for customer events which are performed by the specific partner as well as redeem their awards on that partner. If awards can be redeemed you can define the range within the spent amount can be allowed.

 

Allowing automatic wallet fund spend


Reward participants can pre-authorise the use of wallet funds for purchases.  In case a merchant does not allow this method, an explicit request is necessary (i.e., wallet funds are not automatically spent). To set up the system to support instant spending:   

  1. In the Partner Unit Agreements under Partner Permission Settings section enable 'Allow Automatic Spend'.

    OR

  2. In the Rewards Participants enable Automatic Spending.
The setting in the partner agreement overrides the one set on the rewards participant (I.e., if automatic spending is not allowed at merchant level, it cannot be enabled at participant level).




Rewards ParticipantPartner AgreementResult
1Allow Automatic Spend
2Allow Automatic Spend
3Allow Automatic Spend
4Allow Automatic Spend

Do not confuse Spend Method 'Spend Instantly' (available in a number of reward offer classifications) and 'Allow Automatic Spend'.

  • 'Spend Instantly' directly deducts the award earned from a specific purchase as an instant discount, regardless of the participant and merchant setting.
  • 'Allow Automatic Spend' deducts any awarded amount available in the participant's wallet (possibly in addition to 'Spend instantly').


 Back to top

Defining reduction method


The reduction method defines how the amount requested by a participant to be spent will be reduced. Each partner can define their own reduction settings depending on the way they operate.

The allowed reduction methods are the following:

  • Front-End Reduction: If selected then the reduction will be done by the front-end system (for example the POS). This is the default option
  • Back-End Reduction: If selected then the reduction will be done by a back-end system (for example PayPal). If this option is selected then it is mandatory to specify the back-end reduction settings. An example of a back end reduction is where a customer instead of getting an instant discount on his purchase (granted through an award) , the customer will pay a regular price  at the point of sale and the awarded money is returned to an online account , i.e. PayPal.
    The amount will be credited to the participant's account and then refunded through the online account.


Contributing to the awards


A contribution determines the percentage of the awarded amount that should be provided by the partner. By default, the partner contribution is 100% but it is possible to change this. The contribution percentage can be set per reward offer classification and a scheme. Unless a partner unit specifies rules, Partner Group Agreement contributions are considered.

Partner Agreement Contribution Setup

It is possible however to define contributions at the reward offer level which will override the setup in the partner agreement. In the reward offer you can set a different contribution per partner group or partner unit.

Partner Contributions at Reward Offer Level



Debiting and crediting partner accounts based on contributions


Reward settlement is the process responsible for balancing rewards participating merchant groups or rewards participating merchants by debiting them for a percentage of the amount of money that was awarded by them, as defined through the agreed contribution rules, and crediting them for the amount of money that was spent by customers on them.

For each agreement you can define the Period to look in the past for settlement which can be defined in months as well as how often the settlement run should be

To provide the debit and credit transaction types as well as the products used when settling the accounts go to Configuration / Rewards Application / Access Rewards Admin / Settlement Settings.

The settlement process is a background process which is done by the system and available at Foundation / Platform / Manage Admin Settings / Batch Processes Admin Board. If a settlement process is required you need to make sure that the process is working (Started)

 Back to top

Using Multi Merchant Platform

Viewing and managing agreements


Partner agreements are available and can be managed through the Reward Board (Rewards / Reward Board) in addition to the configuration pages.

Perform actions as a merchant user


When users that belong in one of the units or groups that have partner agreements defined in the system, the actions they will be allowed to perform are subject to the permissions defined on the agreement.


Business Flows


Back End Reduction Award Spending

Scenario

Aluxsat Co. would like to handle auto-spend customer returns through Zulu.

A rewards participant makes a discounted purchase by using an award. The customer pays the regular price at the point of sale and the awarded money is returned to their Zulu account (Back-end reduction).

 

Configuration

  • Configure the refund method that will be used for back-end reductions through Zulu.
  • Configure a refund transaction type and add the refund method as 'allowed'.
  • Configure the Zulu provider and select the allowed refund method that will be logged by back-end reduction.
  • Configure automatic payment run definitions that will refund the Zulu account of reward participants.
  • Enable the back-end reduction method on the reward participating partner and define the refund type and method that will be used to refund the Zulu account of reward participants.
  • Configure an accounts receivable payment preference and relate it to Zulu.

User Process

Accounts Receivable: When a user registers an accounts receivable using Zulu gateway details, select a Zulu payment preference and provide customer credit card number as an identifier

Technical staff is responsible for communicating to Zulu (on an hourly basis) the payments to be effected using CRM.COM WEB APIs to collect pending payment requests and to update CRM.COM with the respective responses from Zulu.

Use GET payment_gateway_requests/get_pending  to update Zulu. Once Zulu responds, CRM.COM should be updated accordingly, using the following WEB APIs:

 

On this page

For the developer

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

WEB API

Analytics

Check out reports and dashboards available for Multi Merchant Reward Platform

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


Refunding reward participant payment gateway accounts for back-end reductions