Skip to main content

Loyalty Programs

docs image

Loyalty Programs

Offering benefits to loyal customers

Loyalty programs enable you to offer special pricing and exclusive payment methods to frequent customers. Additionally, these programs allow for the accumulation of points under specific conditions. Customers can use these points as a form of payment or to trigger special promotions. This guide explains how to set up a loyalty program and describes the available options.

Loyalty programs are managed in Admin Suite, under Promotions -> Loyalty Programs.

Authorization

In order to be able to access this chapter, you need the LoyaltyPrograms permission. Check the loyalty related functionalities for more details.

The initial overview

The chapter's initial UI consists of two tabs displays an overview of all existing Loyalty programs or Loyalty program groups (if any). It offers options to create new ones using the '+' icon, or edit existing ones by clicking one. Make use of the filter to fine-tune your overview.


Create loyalty program

To begin a creation flow, click the '+' icon in the initial overview page.


The Create modal will consist of the following fields:

Expand to view field descriptions
  • Name: Enter a name of your choice.
  • Description: Provide a description of your choice.
  • Options: Choose from three options:

View Options
  • Enable Payment Methods: This allows the loyalty program to also be used as a payment method. Selecting this option will enable the Payment types tab where additional configuration is required.
  • Enable Loyalty Points: This allows the loyalty program to be used for example, accumulating points and withdrawing points. Selecting this option will enable the Point saving rules tab where additional configuration is required.
  • Enable Discounts: This allows the loyalty program to also be linked to a discount.
  • Point usage types: Choose from three types:

View Point usage types
  • Allow Awarding: Specifies whether the program permits awarding points. This works in conjunction with the Points saving rules tab. Enabling this option allows points to be awarded, so specifying how those points would be saved and managed is necessary.
  • Usable as Payment Method: Specifies whether points can be used as a payment method. For example, 1000 points can be used as a discount of €1.00.
  • Usable for Withdrawal: Specifies whether withdrawing points is permitted. For example, 1000 points can be withdrawn to obtain a free product.
  • Handler: We currently have two loyalty program handlers:

Expand to see options

LOYALTYAPI

This handler gives you the most flexibility, but is also the hardest to set up, as it requires you to have a third party to store loyalty points, and a custom integration. Read more here.


EVALOYALTY

This handler stores your points in EVA. We support withdrawals, payments (using points), and points awarding in EVA LOYALTY, we also support this on production environment. We don't want to be a bank, so we can't store actual monetary value. This is why EVA LOYALTY does not support payments on production environments.

  • User identifier: Using this field you can determine how the user identifier would look like. There are 2 options:

Expand to see options
  • Request from frontend: Implies that a user identifier will be fully provided by the frontend user during application. The user will need to manually input/scan an identifier; otherwise, an error will occur.
  • Custom: Implies that the user identifier will be based on the inputs of the following 3 fields:
    • Prefix: A fixed user identifier prefix (Example: PRE-)
    • Start: A starting user identifier number (Example: 1000)
    • Suffix: A fixed user identifier suffix (Example: -SUF - Combining the inputs, your user identifier would look like this PRE-1000-SUF, and the next subscriber as PRE-1000-SUF and so forth).
Settings for 'Request from Frontend' User Identifier for POS

If you choose Request from Frontend, you must adjust the following setting to enforce the identifier request: Subscriptions:ForceSubscriptionUserIdentifiers.


Setting value is true:

  • The POS displays a User Subscription Identifier form.
  • Customers cannot subscribe without a User Subscription Identifier.
  • Customers are subscribed only after a User Subscription Identifier is provided.

Setting value is false:

  • The POS displays a User Subscription Identifier form.
  • Customers can subscribe without a User Subscription Identifier.
  • Customers can subscribe even if a User Subscription Identifier is provided.
  • Start Date: Choose your preferred start date.
  • End Date: Choose your preferred end date.
  • Status: Select from these options:

Expand to see options
  • Disabled: This status deactivates the loyalty program and prevents point withdrawals to any remaining outstanding points (if applicable).
  • Enabled: This status keeps the loyalty program fully operational within the specified start and end dates.
  • Loyalty program group: Is used to organize loyalty programs under a broader collection of programs. More on loyalty program grouping can be found here.
  • Requires subscription validation (checkbox): Specifies whether validation of the user identifier for the linked subscription is required or optional from the frontend. A tile labeled "User subscription identifier" will appear during the checkout flow for input of the user identifier when this checkbox is checked.

Edit loyalty program

To start the edit flow, click an existing loyalty program from the initial chapter overview. The UI will consist of five tabs:

General information

First tab: Here you can modify all fields initially set up during the creation of the loyalty program.

Price lists


In addition, you will be presented with another card namely, price lists. The dropdown will include all currently available price lists. The chosen price list will apply to orders when the loyalty program is active.

Multiple pricelists

It is not possible to have multiple pricelists consuming the same currency.

Required order custom fields


The Required order custom fields card enables you to associate a custom field with a loyalty program. This dropdown menu displays only custom fields of type Order. For guidance on creating these custom fields, refer to Custom fields documentation.

During the checkout process, this custom field will be triggered as an order requirement.

Organization unit sets


This card is used to link your loyalty program to a single or multiple organization unit(s).

Click the '+' icon at the bottom and select the desired OU or OU set.

The modal consists of the following fields:

  • Is active: Determines if the subscription is or is not active for the specified organization unit(s). Based on the choice this will impact where the subscription will be displayed/prompted on front ends or not.
  • Hide from Frontend: Determines if the subscription will be visible on the front end or not.
  • Default selected: Makes the user automatically subscribed instead of needing to do a manual tick to subscribe.
  • Preferred notification: Gives the subscription a preferred note on the front end rather than optional.
  • Subscription validation: Specifies the mode of opt-in validation. This consists of three options:
    • None: No validation needed.
    • Email: Validation via email. This requires setting up a stencil template called NewsLetterSubscription stencil, which will hold the token used in the ConfirmSubscription service. More information on creating a Stencil Template can be found here.
    • Webhook: Validation via a webhook, which triggers a webhook event. The event type is called subscription_confirmation. You can configure this in the Event Export Configurations chapter.
Webhook Compatibility

Webhooks (if configured) will only trigger for subscriptions that have handlers specified as either Default or Newsletter.

  • Priority: Sets the order of the subscription on the front end.

Point saving rules

Enabled or Disabled

This tab will be disabled if the option Enable Loyalty Points from the General information card was not initially selected.

Second tab: In addition to self-explanatory fields, the following require further explanation:


Expand to view field descriptions

Points to award


Check Awarding loyalty points docs for more on creating or editing rules.


Expiration span


The expiration span dictates how long loyalty points will be usable before expiring. There are 5 options;

OptionDescription
DefaultNo expiration date.
CustomExpire along a custom interval. Selecting week and entering 10 will result in expiration after 10 weeks.
Expire end of yearPoints will expire at the end of the year.
Expire end of monthPoints will expire at the end of the month.
Expire set datePoints will expire on the given month and day in the year when the points were issued. If the given date falls BEFORE the issued date, they will expire the following year.

Expire set date comes with an additional field; Leniency days. This dictates the minimum amount of days required between when the points are issued to when they expire.

Note

Expiration span only kicks in after the pending period has concluded.


Pending points


Some retailers want to have a certain pending period before points are issued.

OptionDescription
DefaultNo pending period.
CustomCustom pending period. Selecting week and entering 10 will result a pending period of 10 weeks.
Pending Return PeriodPoints will remain pending until after the return period expires. Same value as setting Returnable:InvoicedDays which is one of the settings available that influence returns for more.

Conditions


This card allows you to specify the necessary conditions that should apply in order to activate the specified Point saving rules. Defining conditions here is optional. The following are the available options:

  • Order amount: Specify the order amount threshold whereas if the order amount is greater than the point saving rules would trigger.
  • Product set: Specify the product set and quantity that if applicable would trigger the point saving rules. The dropdown will list existing configured Product sets.
  • Consumer: Select the desired user custom fields from a dropdown menu that lists all available ones.

Payment types

Enabled or Disabled

This tab will be disabled if the option Enable Payment Methods from the General information card was not initially selected.

Third tab: Loyalty programs allow you to expose additional payment types by configuring one here. When adding a payment type, you'll need to provide the following details (note how some are labelled optional on the frontend):

Expand to view field descriptions
  • Payment type: The dropdown menu will only display configured payment types that utilize the LoyaltyProgram system payment method.
  • Sequence: Accepts only integer values. It determines the order of calculation among payment types, which is crucial for accurate tax computation and budgeting.
  • Tax Handling: Offers two options:
    • In Tax: The budget includes tax (e.g., a budget of $100 means you can spend $100 including tax).
    • Up to Tax: The budget excludes tax (e.g., a budget of $100 allows spending up to $120 with a 20% tax rate).
  • User Budget Deduction: Provides three options:
    • Program: Deducts the paid amount from the program's budget.
    • Payment Method: Deducts from the specific payment method's budget.
    • None: No deduction from any budget.
  • Budget: This field accepts numerical values with decimals. Represents the total amount available for transactions using this payment type.
  • User budget: This field accepts numerical values with decimals. Indicates the total amount a user can spend using this payment type for the specified program.
  • User maximum usage: This field accepts integer values only. Limits the number of times a user can utilize this payment type.
  • Maximum amount per order: This field accepts numerical values with decimals. Sets the ceiling on spending per order using this payment type.
  • Maximum percentage of user budget per order: Only integer values are accepted. Restricts the spending per order to a percentage of the user's total budget (example, a 10% limit means spending cannot exceed 100 on a 1000 budget per order).
  • Overall quantity limit per order: Sets a cap on the total number of products per order from the defined set that can be paid for using this payemnt type.
  • Overall quantity limit per user: Establishes a total quantity limit per user across all products within the defined set that can be paid for using this payemnt type.
  • Excluded from program budget (Checkbox): Indicates whether usage of this payment type affects the program's budget. When checked, usage does not impact the program's specified budget.
  • Required (Checkbox): Mandates the use of this payment type in an order if it is still applicable to the user.
  • Allow partial payment (Checkbox): If checked, partial payments are permitted up to the full calculated amount. For example, if the User Budget for this Program is $50 and the order amount is $70, checking this box allows a payment of $20, considered partial for this order.


For POS, a tile named Select Payment will be displayed at checkout under Order options. This tile corresponds to the payment type specified in the Payment Type field. If multiple payment types are available, the user will be prompted to choose one.

Conditions

Fourth Tab: Loyalty programs allow you to establish specific conditions that dictate when the benefits apply. For example, benefits will only apply if the value of user custom field who is tagged to an order contains a specific value.

Available conditions with descriptions:

Customer

Customer


This condition restricts the program to specific customers, identified by their customer ID, email address, or those subscribed to a certain subscription or another loyalty program.

  • Exclude: Check this box to prevent the specified customers from availing the loyalty programs benefits, enabling participation for others only.


User custom fields

User Custom Fields


This condition limits the program benefits to certain users based on the value of certain user custom fields. When adding a user custom field condition, you need to provide the following details:

  • All or at least one: Specify whether the program applies if all or at least one of the user custom fields meet the requirements.
  • Custom Field: Select the desired user custom fields from a dropdown menu that lists all available ones.
  • Operator: The criteria in which the specified Value will be checked. For instance, Equals requires the user's input to exactly match the specified value of the following field "Value".
  • Value: Specify the custom field value that would be checked against the Operator criteria.


Order custom fields

Order custom fields


This condition limits the program benefits to certain orders based on the value of certain order custom fields. When adding an order custom field condition, you need to provide the following details:

  • All or at least one: Specify whether the program applies if all or at least one of the order custom fields meet the requirements.
  • Custom Field: Select the desired order custom fields from a dropdown menu that lists all available ones.
  • Operator: The criteria in which the specified Value will be checked. For instance, Equals requires the order custom field value input to exactly match the specified value of the following field "Value".
  • Value: Specify the custom field value that would be checked against the Operator criteria.


Order type

Order type


This condition limits the program benefits to certain order types. The dropdown will by default list all available order types.


Order properties

Order properties


This condition limits the program benefits to certain order properties. The dropdown will by default list all available order properties as listed below.

  • Is excluding: Check this box to exclude certain order properties from loyalty program benefits. Only orders with different properties will be eligible.

See list of all available order properties

Product limitations

Fifth tab: A loyalty program may include a product limitation. Such limitation can restrict the number of products purchased at one time. Specifically, you can specify a set of products, apply a filter, or use the Apply to price list checkbox to indicate that the limitation applies to the products specified in the used pricelist for this loyalty program.

Only one product limitation can be added per program.

  • Quantity limit per user: Imposes a limit on the quantity each user can purchase of each product within the defined set.
  • Overall quantity limit per user: Establishes a total quantity limit per user across all products within the defined set.
  • Quantity limit per order: Limits the number of each product that can be purchased per order within the set.
  • Overall quantity limit per order: Sets a cap on the total number of products from the defined set that can be purchased per order.

Examples

Consider a product set that includes Boots, Belts, Hats, and Shirts.

Scenario 1: If the Overall quantity limit per order is set to 3, a customer can purchase no more than three items in total from the defined product set (all 3 the same or different makes no difference).

Scenario 2: With a Quantity limit per order of 1, a customer can purchase no more than one of each item from the defined product set per order. This means one pair of boots, one belt, one hat, and one shirt.

Scenario 3: Combining the limits from Scenarios 1 and 2, the Overall quantity limit per order and Quantity limit per order are both set to 3 and 1, respectively. This means a customer could purchase one pair of boots, one belt, and one hat, reaching the total limit of three items, thus excluding the possibility of buying a shirt.

Applied Price List

You can find the loyalty program's applied price list under the General Information tab.


Create Loyalty program group

Loyalty program grouping is used to link multiple loyalty programs together. This method simplifies the management of umbrella budgets across various programs.


Based on role permissions, each user may have different rights on what can be done within the loyalty module and frontend behavior. Permissions are managed from the Roles and rights chapter namely, from the functionalities card of a user's role.

The following table provides a list of those permissions and the impact each one has on the users rights:

Show loyalty related functionalites
Functionality nameScope when functionality is not ticked
LoyaltyProgramsThe scope on what a user can do using the loyalty programs tab.
BlockUserSubscriptionThe ability to block/unblock/reverse a blocked subscriber from accumulating or using loyalty points from a specified loyalty program.
DepositLoyaltyPointsThe ability to deposit loyalty points to any users balance.
WithdrawLoyaltyPointsThe ability to withdraw loyalty points from a users balance.
RebalanceLoyaltyPointsThe ability to use rebalance feature on a users balance.
ApplyLoyaltyDiscountThe ability to apply a discount that is grounded upon loyalty benefits.
LoyaltyProgramGroupsThe scope on what a user can do using the loyalty program groups tab.
LoyaltyProgramBudgetManagementThe ability to manage a loyalty program budget.
LoyaltyProgramGroupBudgetManagementThe ability to manage a loyalty program group budget.

Separate Loyalty Programs from Subscriptions

You can configure the system to separate Loyalty Programs from Subscriptions during user sign-up or enrollment. By default, both subscriptions and loyalty programs appear together in a single list on the user interface, without distinction.

To change this default behavior, use the setting described below:

SettingValueOrganization UnitDescription
Subscriptions:SplitUserSubscriptionstrue (default is false)Applicable organization unit(s)When set to true, the services GetAllSubscriptionsByUserID and GetUserSubscriptions exclude Loyalty Programs from the list during sign-up via the respective flows in the Apps or Admin Suite, thus separating them into different lists.