Detailed information about the latest releases of Cheetah Loyalty.

Loyalty Version 23.1.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 23.1.0 unless otherwise stated.

Features

Offer Supports Preferred Location Time Zone

Background: Programs that operate in multiple time zones would like offers to start and end at the same time in the time zone of each member’s preferred location.

Solution: A new indicator, “Preferred Location TimeZone”, has been added for Offers within the Edit Offer, Response Period, and Usage Period Effectivity configuration screens.

If the member has a preferred location specified with a time zone, then the system will apply the effectivity, response, and usage end, where applicable, in the time zone for the member’s preferred location.

Example: If Member A’s preferred location is in Eastern Time, and Member B’s preferred location is in Pacific Time, and the Offer is configured to end at 23:59:59, the actual time for each member would be relative to their preferred location.

If the member has no preferred location specified, or the preferred location has no time zone specified, then the offer effectivity, response, or usage time zone would be the program time zone.

Note: member.place_integration_id must be set up to ensure member’s preferred location. For use of a Custom Attribute as an alternative, see details about the new program setting below, Place Integration ID Override.

There will be an online help update to follow explaining how to add the new indicator to offers here.

Place Integration ID Override

Background: Currently the system uses a standard attribute for configured Places, the Place Integration ID. This attribute is able to be set for a Member within their profile and used to indicate a preferred location, store, or property. The system also uses the Place Integration ID for additional functionality related to Offer Effectivity. The functionality assumes programs are using the standard attribute vs. a custom attribute.

For customers who have enabled a custom attribute, such as Favorite Store, Favorite Location, or Preferred Property, the standard Place Integration ID requires an override in order for this new capability to apply the location time zone properly.

Solution: A new program setting called “Place Integration ID Override” has been added which will map to the custom attribute enabled for the program. Specifically, this new setting allows the program to use a custom member attribute as an alternative to Member Place Integration ID and link to the Place Integration ID to determine the time zone for a location, store, or property in the Member profile. This setting is required to be configured if the program is using Offer Effectivity based on a Member’s preferred location, and if the program has a custom attribute for locations.

There will be an online help update to follow explaining how to enable this new program setting here.

Offer Response Hierarchy Rule Order

Background: Currently when offers are fetched by the POS APIs, the offer responses are sorted in a standard hierarchy: 1. Coupon Type, 2. Discount Type, 3. Usage End, 4. Discount Value, and 5. Created at. Programs do not have the flexibility to change the sort order for their program should this be required for any reason, such as to align with Program Terms and Conditions.

Solution: A new Program Setting, “Offer Sorting Hierarchy”, has been created to allow customers who choose to apply a different offer rule ranking.

This new setting will allow the program administrator to select an offer response sort from a drop-down in the program setting. The order in which the offer attributes are selected will be the order with which the Rule will apply, For example, if the admin first selects Discount Value and then Usage End, the rule hierarchy will be the following for all offer responses:

Discount Value
Usage End

Notes:

The program administrator may omit any offer attribute from the hierarchy; all five do not need to be indicated in the program setting, but the admin must identify a minimum of one.
As a general default, customer programs will continue to use the standard order rule ranking outlined above, unless a different hierarchy is indicated within the Program Setting.

There will be an online help update to follow explaining how to enable this new program setting here.

Loyalty Connector for Aptos POS

Background: Aptos POS required a connector to integrate with Cheetah Loyalty.

Solution: A new connector has been created to allow Aptos POS and its Loyalty and Customer management capabilities to integrate with Cheetah Loyalty. The connector supports the following capabilities:

To configure default program settings to allow Cheetah to provide basic Loyalty Plan definition* details to Aptos. Note that the Program Settings for this connector can be found under the Aptos program setting group.
To specify one or more rewards** to be available to the Aptos integration. This is accomplished by configuring a reward category called ‘Aptos’ in Cheetah, and attaching it to one or more rewards that are intended to be used by the integration.
To see details of the Loyalty plan and rewards shared by Cheetah via Aptos.
To create or update Loyalty members and send them to Cheetah via Aptos.
To look up Cheetah Loyalty members by various attributes, view details of the profile, and attach the member to the Aptos transaction.
To view and apply available program rewards to the transaction based on the member’s available points.
To submit a transaction from Aptos to Cheetah via real-time API integration for the member to be awarded points and redeem any rewards.

Please contact your Cheetah representative or account manager to enable this connector.

* The “Loyalty Plan definition” is an Aptos concept. It includes an identifier, a plan name, a start date, and other Aptos dependencies.

** Rewards in Aptos that are in the Loyalty plan are expected to be returned by the Loyalty platform. In Loyalty itself, a reward can be a coupon reward (points used) or coupon offer (no points used).

There will be an online help update to follow explaining how to enable these new program settings here.

Platform Support for OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange (PKCE)

Background: Previously, Cheetah has supported a password grant approach where a Client ID and Client Secret were passed to authenticate a user and retrieve an access token to make subsequent requests to the Member API. However, this approach can be exploited if the mobile app or website exposes the API credentials.

Solution: Platform support has been added to implement more secure client application integrations with Cheetah by enabling OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange, or PKCE. PKCE is used to make OAuth 2.0 Authorization Code grant type more secure through additional code verification and challenges.

There will be an online help update to follow explaining how to obtain an access token via OAuth 2.0 Code Flow with PKCE here.

OLO Order Id Can Be Saved as Unique Order Identifier

Background: Where Loyalty programs use multiple channels or methods to submit transactions, and each channel uses different unique identifiers, there can be a risk of points being accrued to an account twice from duplicate orders. Specifically for OLO, the POS usually has a different order identifier than OLO, so duplicate OLO orders can theoretically be created.

Solution: A new capability has been added to save OLO order identifiers as globally unique identifiers for Cheetah order records, eCommerce, and POS Integrations. This allows brands that have OLO integrations to capture the OLO order id in Cheetah as a unique key which can prevent duplicates if the OLO orders are submitted to the point of sale (POS) system and then transmitted to Cheetah in a retro claim file feed.

In addition, using this new feature will prevent duplicate order records from being created as long as the retro claim file feed includes the OLO order id in the order global unique identifier (guid*) column, and ‘guid’ is used as a match by option in the import definition. With this configuration, the system will check the imported order.guid against all existing orders and prevent creating a new order if the same OLO order id was used by an existing order.

* A “guid” (global unique identifier) is a 128-bit number created to uniquely identify resources.

There will be an online help update to follow explaining how to enable this new program setting here.

System Evaluates Punch Card Criteria on Orders Submitted via Sparkfly and OLO Integrations

Background: Previously, brands needed to configure triggered actions to implement punch card evaluation via Sparkfly and OLO integrations.

Solution: The system can now evaluate criteria on member punch cards when processing orders submitted via Sparkfly and OLO integrations.

There will be an online help update to follow explaining how to enable this new program setting here.

System Evaluates Offer Location Eligibility on Orders Submitted via Sparkfly and OLO Integrations

Background: Brands that submit orders to Cheetah via Sparkfly or OLO integrations wanted to allow or restrict offers from being returned, depending on whether the order location is permitted to access and redeem the offer.

Solution: Brands that submit orders to Cheetah via Sparkfly or OLO integrations can now configure the Offer Location Eligibility parameter.

Similar to Segment Eligibility which allows marketers to target Offers to certain groups of members, Location Eligibility controls which locations can access and redeem an offer:

When an offer has neither Included nor Excluded Locations specified, then the offer is available in all locations.
When an offer is configured with Included Locations, then only those locations can access the offer.
When an offer is configured with Excluded Locations, then only non-excluded locations can access the offer.

There will be an online help update to follow explaining how to enable this new program setting here.

Wallet Pass Prohibits Sharing Capability

Background: For customers who wish to enable a Pass that prohibits sharing within iOS or Android.

Solution: The Wallet Pass has been updated to allow for configuring the Pass to allow or prohibit sharing. Specifically, this new configuration setting prevents members from sharing their Loyalty card with non-members.

Note: This setting is a preventative measure only from within the Wallet App and does not prevent a user from sharing the pass in other ways, such as a screen print.

There will be an online help update to follow explaining how to configure your wallet pass from sharing in iOS and Android here.

Enhanced Performance of the Content Reward Pick Winner Process

Background: Previously, when trying to pick a large number of winners, the Content Reward Pick Winner process would intermittently fail.

Solution: The Contest Reward Pick Winner process has now been enhanced so even large numbers of winners can be successfully determined.

Enhanced the Certificate Inventory Threshold Email to Include Offer Name in Plain Text

Background: The email previously included the offer name as part of a hyperlink.

Solution: The Certificate Inventory Threshold email was enhanced to include a plain text offer name element to simplify programmatic parsing of the email message.

Program API | Campaigns Pagination

Background: Customers could not specify number of campaigns returned by the API.

Solution: Support has been added to the Program API Campaigns endpoint for page and per_page parameters to allow customers to now specify the maximum number of campaigns returned by the API.

Program API | Offer Response Fulfill Error Code Update

Background: Previously, the Program API Offer Response Fulfill endpoint returned an error code of “Code 500: Internal Server Error” when the Offer’s usage period was beyond the current date. This error was vague and did not describe why the process failed.

Solution: The endpoint error handling has been updated to return a more descriptive error code when this scenario is encountered. The new error code is “5004: Invalid, Offer Certificate no longer effective”.

Endpoint for reference: PUT <base_url>/program/api/offers/responses/<id or certificate_code>/fulfill

Member API | Badges Description and Categories

Background: Previously, Member API Badge endpoints did not include Badge descriptions and categories.

Solution: The Member API Badges endpoints have been updated to now include Badge descriptions and categories as follows:.

GET <base_url>/api/badges/me added description and categories
GET <base_url>/api/badges/:id/me added description and categories
GET <base_url>/api/badges added categories

Note: All Badge endpoints have been updated with Categories as a query parameter.

Fixes

Wallet Pass | Added Google Wallet callback eventType

For every delete performed by the user in Wallet, Google makes callbacks (event triggered data request/ response) to the merchant with details about the add or delete event. Support has been added for eventType: Delete to track uninstall of Wallet Passes on Android to fix Passes which seem to have disappeared from the Wallet.

Punch Cards | Fixed Intermittent Recurring Reminder Moment Failures

A fix was delivered for intermittent failures of recurring reminder moments on External, Choice, and Multiplier punch cards.

Punch Cards | Added Retry Logic to Handle Intermittent Timeouts When Sending to Cheetah Messaging

A fix was delivered to improve reliability of queued message sending and how that process handles intermittent timeouts when sending requests to Cheetah Messaging. Retry logic was added to the process to resend a request when non-permanent errors are encountered.

Punch Cards | Fixed an Issue where Queued Messages Were Retried in a Loop

A fix was delivered to prevent queued messages from being retried endlessly.

Punch Cards | Fixed Intermittent Issue Where Reminder Moment Statistics Were not Captured by the System

A fix was delivered to improve the reliability of the system to capture and record the audience and delivery statistics of Punch Card reminder moments.

Offers | Fixed Error when Attempting to Fulfill Certificate Offer after Removing Excess Certificate Codes

A fix was delivered so that offer fulfillment continues to work after removing unused certificates on an offer.

Offers | Fixed an Issue where Duplicate Certificate Codes were Issued

A fix was delivered to address an intermittent scenario where certificate offers, issued via triggered actions, would reassign the same offer certificate code value to different members.

Offers | Fixed a Memory Leak in Grant Anniversary Scheduled Job When Issuing Large Volumes of Offers

A memory leak in scheduled job processing of large volumes of offer issuance was fixed in this release.

Badges | Fixed an Issue where the System Displayed an Incorrect Badge Image when the Badge Includes Multiple Levels

A fix was delivered to ensure the system displays the correct member badge image for badges with multiple levels, where there are different images for each level.

Orders | Fixed Order Display Details for OLO Orders

Fixes were delivered to present the OLO order business date on the Orders detail page in local time versus UTC, which was causing some business dates to be displayed with incorrect values. Coupons applied are now shown in the order details page.

Order Rules | Fixed Case Where Order Rules Became Unusable if Associated Business Unit was Deleted

A fix was delivered to allow order rules to be available after the associated business unit was deleted from the system. Order Rules can now be reconfigured to point to a different business unit.

Members | Fixed a Batch Member Merge Failure When Multiple Members Share the Same Merged From Value

A fix was delivered to correctly merge member records even if they share the same “merged from” id value.

Challenges | Fixed an Issue where Updates to the Challenge Response Could not be Retrieved in Later Requests

A fix was delivered to allow updates to the challenge response via the Program API to be available to retrieve via later requests.

Offers | Fixed an Issue where Duplicate Certificate Codes were Issued

A fix was delivered to address an intermittent scenario where certificate offers, issued via triggered actions, would reassign the same offer certificate code value to different members.

Loyalty Version 23.0.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 23.0.0 unless otherwise stated

Features

Multi-Factor Authentication Support for Member API

This feature allows programs that use the Member API to support member authentication and prefer to implement a higher level of authentication security to enable the system to send a one-time passcode (OTP) that members must include when authenticating to successfully complete the process.

The feature is enabled via a set of new Program Settings under a grouping called “Member API MFA” and can support sending the OTP via Email, SMS, or optionally both channels. Mobile and Web applications that implement member authentication using the Member API that intend to use the feature need the following steps:

Change the implementation to accommodate prompting the member to confirm the preferred channel to send the OTP.
Add an additional API call to initiate the sending of the OTP on the preferred channel.
Allow the member to input the OTP and submit it to the system to successfully complete the authentication process.

POST <base_url>/oauth/token is the Member API Authentication endpoint that now supports multi-factor authentication.

Note: this feature is only for customers sending via Cheetah Messaging implemented with EDP Sends / Smart Sending enabled.

Online help update can be found here.

Member API Registration Endpoint Allows Signup Without Email

The Member API to register a new member previously required email to successfully complete the signup process.

In this release, it is now possible to enable the system to allow signup without needing to provide email. Mobile Phone, Card Id, and Username attributes are all now supported alternative identifiers and can be submitted for signup without including email.

Note: this feature is only enabled on request, so please contact your Cheetah account manager to request that the “ALLOW_SIGNUP_WITHOUT_EMAIL” option be enabled in your environment.

Combined Gift Card Balance For POS, Sparkfly, and OLO Integrations

Gift Cards, which serve the purpose of a Stored Value Reward or a multi-use discount item that holds a balance, have been enhanced in this release to support returning a combined balance across all member gift card instances.

This capability can be important for brands that prefer to implement gift card expiration and that want to return a single reward balance to point of sale (POS) or ecommerce systems.

This feature can be enabled on Gift Card Classes that aren’t already configured to add value to a single card instance, and can be used in commerce integrations using the Cheetah POS API, Sparkfly, or OLO integrations.

When an amount is redeemed against the combined balance, the system will debit the amount against the member gift card instance that is expiring first, and then against other gift card instances expiring later until the entire redeemed amount is debited.

Optimized Sparkfly API Response Time Performance

The Sparkfly API was enhanced in this release to reduce API response time when members are attached to large orders via the Sparkfly integration, and when the system returns custom messages in the response.

Gift Card Program API Credit and Debit Endpoints Can Now Ignore Changes to Expired Cards

The Program API for Gift Cards has been enhanced to include an ‘ignore_expired’ parameter that when passed will suppress any attempted credits or debits if the card is expired. This can be useful when the program prefers not to allow changes to expired Gift Cards.

Challenges, Offers, Rewards, and Punch Card Resource Attribute Token Values Displayed in Content Editor

In this release the content editor has been enhanced to allow the display of resource attribute values that reference the same object type (such as Offer, Reward, Challenge, or Punch Card) that the content editor is defining content for.

For instance, if configuring the content for an Offer, it is now possible to include resource attribute content tokens that reference Offer elements such as the label or the date it was published. Then these attributes or elements can be included in the Offer content.

This feature is now enabled for Challenges, Offers, Rewards, and Punch Cards.

Punch Card Type Reminder Moment Enhancements

Reminder Moments are contextually relevant messages sent automatically to Members based on their Punch Card activity. Reminder Moment audience definitions have been updated in this release to handle the case where a Punch Card Type is configured with an Automatic Start Type. This allows audiences to not have to check whether a member accepted the punch card.

Reminder Moments also have been enhanced to support recurring schedules with a reference to when a punch card became usable. This allows reminders to be sent on a specified day since the member punch card can start earning credit automatically.

Order Rule Fixed Amount Bonus No Longer Requires Qualified Item List

Order Rules configured with Fixed Amount bonuses no longer require the bonus to have qualified items configured.

Source Scheduled Job and Source Segment Information now available for Activity Reporting

Granting Object Details is a set of details the system writes to the activity to establish the activity context. For instance, when you have a reward that generates an offer for a member, the offer activity will include one or more attributes that indicate the granting object detail.

When generating activities from scheduled jobs, the system will now include the scheduled job and related segments used in the granting object details on the related activity. This allows reporting to be configured to highlight which job generates the activity and which segment was targeted.

Fixes

Fixed Mobile Wallet Passes Installed as Inactive

A fix was added to correct an issue that caused Mobile Wallet passes to occasionally be installed in inactive status.

Fixed Duplicate Image Appearing in Mobile Wallet

A fix was delivered to correct an issue where Mobile Wallet would incorrectly display two images when only one was added to the wallet pass configuration.

Fixed Extra Label Appearing Under Barcode in Mobile Wallet on Google

A fix was delivered to correct an issue where the Mobile Wallet pass would incorrectly display extra text below the barcode on the front of the wallet pass in Google Wallet.

Fixed Metric Transfer Reward Support for Metrics With Decimals

A fix was added to correct an issue where Metric Transfer Rewards were not correctly handling metrics with decimals.

Fixed Intermittent Offer Certificate Code Reuse Issue

A fix was added to correct an issue where the same Offer Certificate Code intermittently would be issued to multiple members. The fix covers issuance through triggered actions, API, and the admin console.

Fixed Incorrect Handling in getExpiringMetric() Groovy Function

A fix was added to correct the handling of negative earn activities by the getExpiringMetric() function. Previously the function incorrectly calculated expiring points when earn activities that had negative values were encountered.

Fixed POS API Performance When Enabling Punch Card Evaluation When Using Segments

The performance of the POS API was optimized in this release to fix an issue where response times increased if Punch Card evaluation was enabled and the whitelisted Punch Card used Segments.

Fixed High Memory Usage in Punch Card Push Message Queue Service

A fix was delivered for memory usage by the queuing service used to send push messages triggered from Punch Card Reminder Moments.

Fixed Cross-Site Scripting Vulnerability

A fix was added to correct a cross-site scripting vulnerability found when using the <base_url>/is endpoint.

Fixed Lookup Content Token Update Issue

A fix was made to address a scenario where lookup content tokens lost their configuration when making an update.

Fixed Smart Quote Handling in Content Templates

A fix was added to correct the handling of smart quotes in content templates.

Fixed GET Campaign Program API Response Details

A fix was delivered to correct an issue where the GET Campaign Program API didn’t return expected created_at and updated_at data.

Fixed Incorrect Receipt UI Handling of PDF

A fix to the Receipt UI was made to correct handling of PDF receipt images.

Deprecated the Certificate Inventory Notifier Action from Triggered Actions

The ‘Certificate Inventory Notifier’ action was found to cause performance and scalability issues and has been deprecated. There is a Scheduled Job action of the same name that can be used instead.

Loyalty Version 22.4.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 22.4.0

Fixes

Fixed Offer Certificate Import to Generate Offer Response and Set Usage Period Details

A fix has been made to allow the import of Offer Certificates, where the status is set to redeemed, to create an Offer Response and the usage_start and usage_end dates are specified in the import, so that these values are on the Offer Response record.

Fixed Offer Certificate Import to Lookup Member Based on Integration_Id Attributes

A fix has been made when importing Offer Certificates with an integration_id or integrationXX_id attribute value, the system will correctly lookup the member based on that value and return the member.id value to the import. This will enable linking the member to the Offer Certificate, and also the related Offer Response record, if created.

Fixed an Issue where Content Sources Did Not Return Offer Responses when Ordering Strategy Used First Expiring

A fix was made for Content Sources that use Offer Responses, to return data correctly, when the Ordering Strategy uses the option First Expiring.

Fixed an Issue with “Set Nearest Place” Inbound SMS Handler Action

Inbound SMS can include a handler definition that will create a new member record if the mobile phone used to send the SMS isn’t already in the system. The handler can also include a Set Nearest Place action to link the member to the closest active place in the system based on a ZIP code provided in the Inbound SMS flow.

A fix was made to the Set Nearest Place action to correct an issue, so that members are correctly linked to the place record closest to the member’s zip code.

Optimized Performance of GET /punchcards/json_blocks Endpoint

A query optimization made in this release reduces the number of SQL calls to retrieve punch card data, slightly improving API response time.

Optimized Performance of POST /punchcards/accept Endpoint

A query optimization made in this release consolidates SQL queries and slightly improves API response time of this endpoint.

Loyalty Version 22.3.0 Release Notes

Features

New Order Return Program API Allows Offer Clawback on Product Returns

Background

Retail brands with longer return policies can run into the scenario where a customer returns a product they purchased, but in the meantime the points earned from the purchase have been used to redeem a reward. This incurs extra cost for the loyalty program due to the system not fully offsetting point accrual when products are returned, and because the issued reward offer is not rescinded.

Solution

To mitigate the additional program cost this scenario can incur, Cheetah has introduced a new Order Return Program API to evaluate and execute returns that can:

Evaluate the returned items to assess the points to be removed from the member’s balance based on the value accrued from the original purchase.
Provide the current point balance of the customer, in response to the Evaluate request and if the point balance is insufficient to fully absorb the return, the API will return a list of available offers that were generated from rewards that are available to be canceled.

With this additional insight, if the member’s point balance is sufficient to absorb the return, eCommerce or Point of Sale systems can proceed with the return as-is by submitting an Execute request. However if the point balance is insufficient to fully absorb the return, then the eCommerce or POS system can specify one or more available reward offers to be canceled in the request, causing points to be returned to the member’s account. Thereby appropriate points can be offset corresponding to value of the return, reducing the cost and liability of any extraneously issued rewards.

POS API Enforces Offer Location Eligibility

Background

Provide capability for brands that want to limit Offer access and redemption to certain locations, and the ability to execute the appropriate business rules.

Solution

Brands that submit orders to Cheetah via the POS API can now configure Offer Location Eligibility parameter and accordingly the POS API will allow or restrict offers from being returned in the Assign Member request, depending on whether the order location is permitted to access and redeem the offer.

Like Segment Eligibility allows marketers to target Offers to certain groups of members, Location Eligibility controls which locations can access and redeem an offer. When an offer has no Location Eligibility configured (neither Included nor Excluded Locations are specified) then the offer is available in all locations. When an offer is configured with Included Locations, only those locations can access the offer, and when an offer is configured with Excluded Locations, then only non-excluded locations can access the offer.

Search Members Program API Supports Configurable Set of Returned Member Attributes

Background

Enhance search members functionality to retrieve additional member attributes.

Solution

The Search Members Program API has been enhanced to allow the API request to specify additional member attributes to be included in the response. The attributes can be standard or custom attributes.

The new input parameter to specify additional member attributes to include in the response is member_attributes[] and examples of correct usage include:

URL Parameters

curl --location -g --request GET '{{base_url}}/program/api/members?term={{search_term}}&member_attributes[]=mailing_country&member_attributes[]=mailing_street&member_attributes[]=mailing_state_custom' \

--header 'Accept: application/vnd.stellar-v1+json' \

--header 'Content-Type: application/json' \

--header 'Authorization: Bearer {{token}}'

Form Parameters

curl --location --request GET '{{base_url}}/program/api/members' \

--header 'Accept: application/vnd.stellar-v1+json' \

--header 'Content-Type: application/json' \

--header 'Authorization: Bearer {{token}}' \

--form 'term="{{search_term}}"' \

--form 'member_attributes[]="mailing_country_custom"' \

--form 'member_attributes[]="mailing_street_custom"' \

--form 'member_attributes[]="mailing_state_custom"'

When specified, the API will return the default set of attribute values and any additional attributes specified in the member_attributes[] input parameter.

New Permission Settings for CSR Screen Independent from Other Member Screens

Background

Before this release, programs that wanted to provision access to the CSR > People screen couldn’t do that without also providing access to other screens under the Member tab including the legacy People screen (Member list and detail pages).

Solution

This release separates the CSR > People screen from other Member screens through the updated Members resource available in Admin > Role >Permissions tab, so that it now controls access to the CSR > People screen. A new Members (Legacy) resource has been introduced that allows access to the legacy People screen (Member list and detail pages).

To provision access to only the CSR > People screen, program administrators can create a new role or update an existing role by including only the Members resource.

Consolidation of Tier Expiration Settings

Background

Prior to this release, the Tier Expiration Settings were managed from multiple places in the admin console.

Solution

This release consolidates tier settings under the Tier Scheme level, so for brands that have one tier scheme, this will be managed under the default or single active scheme. When multiple Tier Schemes are defined in the program, each can support its own expiration settings.

Tier-related program settings that were removed in this release and consolidated under the Tier Scheme Settings include:

Default Tier Period
Tier expiration description
Expiration Metric
Expiration Value

Tier Rule Settings under Rules > Settings > Tier Rule Settings have been similarly removed and consolidated into the Tier Settings.

Refer to Tier Scheme Settings section in the Online Help for more information.

Fixes

Fixed Local Store Marketing (LSM) to Allow Local Store Admins to Manage Segments

A fix has been made to allow LSM to expose the Segment screen to local store admins allowing them to view and manage Segments when the program has Business Units defined. This corrects a previous issue where the system didn’t properly reconcile LSM and Business Unit access control handling, causing the functionality on the Segment screen to behave incorrectly for local store admin users.

With this fix, local store admin users will have access to segment records tagged with the same store, the local store admin has access to. Additionally, segment results will be filtered to only include members with the same Place Integration Id member attribute value, matching the store the local store admin user has access to.

Note that if a program doesn’t track a member’s Place Integration Id value (typically used when having members select a favorite store at signup), then the system will not filter the segment results to only return members with the same store as the local store admin user.

Fixed Integration with Sabre to Pull Customer Web Services Description Language (WSDL) file from New Hosting Location

Updated the Cheetah-Sabre integration to pull the Sabre Customer WSDL definition from a new hosting location. This corrects an issue that was causing member sync between Cheetah and Sabre to fail.

Fixed Inconsistent Return Codes When Submitting Retro Claim Requests

Retro Claim return codes were not consistent when the program was using Receipt and Credit Card based retro claim schemes. The system will now return the same code in both cases.

Fixed a Content Token Rendering Issue When Using Content Source Token Type

This fix corrects a bug that caused the system to incorrectly return the default token value instead of the value from the content source.

Fixed a Campaign Offer Targeting Issue Related to Incorrect Default Rule Score Values

Previously, campaign targeting rules would default the score to integer values (1) which caused the rules to be evaluated incorrectly, requiring manual intervention to correct. The system now defaults the score to a decimal value (1.0) that allows the score to be correctly evaluated without changes.

Fixed a Point Expiration Issue that Incorrectly Handled Canceled Redemptions

The system did not compute points to expire correctly when the member activity history included a canceled redemption. This fix allows the system to recognize and handle this case correctly and offset any expirable points from canceled redemptions.

Fixed a Get Place Program API Issue That Didn’t Retrieve Place Records by Integration Id

The Get Place Program API didn’t correctly find matching place records when the request specified an integration id input parameter. This fix corrected the issue and now places can be retrieved by integration id.

Fixed Push Message Validation that Incorrectly Required a Member to have an Email Specified

Previously, the system would require members targeted with Push Messages to have an email address specified, and the fix removed this incorrect validation so email is no longer mandatorily required for members who are targeted with push messages.

Fixed Handling of Gift Card Debits when Offer Lock is Disabled

Previously, when submitting a POS API request where the lock parameter was set to false, meaning no locking of Offers and other discounting objects like Gift Cards are used, the system would incorrectly reserve value on the Gift Card as it does when lock is enabled. The fix prevents a Gift Card debit from reserving a value if Offer lock is disabled.

Fixed the OLO API to Return HTTP 400 When Responding with an Error

The OLO API did not previously differentiate between successful and failed processing, returning HTTP 200 for all responses. With this fix, when a request results in an error, Cheetah will return the HTTP 4xx response code together with the body of the response.

Loyalty Version 22.2.0 Release Notes

Features

Mobile Wallet Enhancement

Background

Members can view their earned offers (e.g. a $25 subtotal discount) via our Mobile Wallet solution. To redeem the offers both online and in store whilst reducing fraud, some brands require the use of a Certificate Code and a security PIN. Therefore we need to store both of these details and the Mobile Wallet needs to be able to display them.

Solution

Certificate codes and PIN data attributes can now be imported through batch feeds, into Offer Responses* and exposed as a Content Source so they can be displayed in a Mobile Wallet and other channels.

There will be an online help update to follow.

Daily process to Update Offer Responses

Background

Offer responses are generated in two scenarios:

Members claim an offer that they are eligible for, at which point certificates will be allocated if applicable
Offers are automatically assigned to members using a scheduled job, triggered action, or via a reward

Offer responses are most often updated through the API. However, there are some scenarios where brands have a requirement to update the offer responses from external systems, such as if the offer expiry is managed, or if offers are redeemed via an external system. These updates would need to be done on a regular schedule to keep offer responses synchronized across the external system and Cheetah Loyalty.

Solution

To enable offer responses to be updated via an external system, a new Response Identifier has been added, called "Id (Integer)", to the mappable fields in the offer response records. This new feature enables offer responses to be updated via a batch process from an external system, ensuring correct updates to the records without needing to use the API. This can be set to a daily schedule.

Updating the offer responses' status allows them to remain in sync with systems external to Cheetah such as POS or Ecommerce systems.

Refer to Offer Responses update and Response Identifier feature in the Online Help for more information on how to do this.

Enable Manual Approval of Receipts

Background

When a paper receipt is scanned to provide a proof of purchase in order to, for example, award points to a Loyalty member, the system will use automated scanning to read the receipt, or OCR (Optical Character Recognition).

However, where there is no system in place for OCR the brand needs an option for the CSR (Customer Service Representative) to create the receipt manually in the system.

Solution

A new program setting is provided so the brand can choose to Skip OCR and manually create a receipt.

Refer to Skip OCR Scanning program setting in the Online Help for more information.

Multi language Translations Tab

The multi language feature is currently in preview mode and can be activated in customer staging environments upon request.

Background

A key requirement for multi language support is to enable the marketer to add, review and amend member facing text.

A Translations Tab within Challenges, Offers and Rewards has been added. This tab displays all the configured languages for the program, including all member facing text that has been added or spaces where member facing text can be added if required.

All member facing text needs to be exported including the necessary spaces so that translations can be added offline and then imported.

This includes multi question challenges where the number of questions to be displayed, reviewed and amended, exported and imported, dependent on user input.

Solution

A Translations Tab within multi question Challenges now renders according to the question configured by the marketer, and the export file structure is driven by the questions configured by the marketer.

There will be an online help update to follow.

Multi Language Default Locale

The multi language feature is currently in preview mode and can be activated in customer staging environments upon request.

Background

Where a brand starts using the multi language features for Offers, Rewards and Challenges, the default locale will be automatically set to US English (en-US), however, if the required default locale or language is different, then the admin user needs to be able to retain existing text that is not US English as the default language or local.

Solution

When the admin user changes the default locale from en-US to for example “da” for Danish, then all existing member facing text will be labeled as Danish and will be present in the default locale space.

Refer to the Available Member Content Locales in the Online help for more information.

Improved Testing for Different Punch Card Types

Background

When testing different types of punch card, good test data is required to perform effective tests before launch. Currently a single set of test data for all punch card types is locally stored by an admin user which means that the user has to manually enter the correct values for the punch card type in question each time they conduct a test.

Solution

The admin user can now create and update a standard set of punch card data for each punch card type using the Categories feature in Loyalty, which is already used to define punch card types.

The system will automatically access the correct test data based on the category selected during the punch card configuration.

The user can then view and edit the standard test data and the changes will be stored locally. This test data is then automatically available to future configurations of the same punch card type and again the user can view and edit it as required.

The user will also have the facility to restore the standard test data, overwriting the locally stored data.

There will be an online help update to follow.

Improved Data for Punch Card Reporting

Background

More data can give better insights on campaign effectiveness and assist with troubleshooting.

Solution

Additional data points for punch cards have been added for reporting purposes:

List of offers / promotions, number of transactions, number of punches, first and last transaction in 24 hour window (helpful for troubleshooting).

Reserving Gift Card Debit for Orders

Background

Gift Cards can store reward metrics such as points or monetary value which can be used against orders and purchases. Often an order is placed ahead of the purchase being completed. A common scenario would be where an online order is made on a restaurant website for food to be collected later. Another scenario might be where goods are pre-ordered due to a release date of new stock in the future.

In some markets, rewards stored on gift cards as a monetary value can be used “pre-tax” to help pay for purchases and reduce the overall total.

The challenge here is that money or points required for orders to be completed later should not be available for use on other orders or purchases as this could lead to a negative balance and potential abuse from consumers “gaming” the system.

Consumers may wish to use the entire monetary value or number of points available, or they may prefer to specify the exact amount to use towards an order and purchase.

Solution

In the same way that credit cards operate where the credit amount is reserved to cover the purchase amount that will be banked later, the monetary amount or points required for orders can now be reserved on Gift cards which will be debited later when the purchase is completed. These reserved amounts can also be voided where an order is canceled.

To achieve this, integration is required with e-commerce / online ordering systems and Point of Sale systems (POS). A number of enhancements to the Loyalty APIs have been made to facilitate these integrations with robust and supportable solutions.

The API documentation will be updated under Technical Documentation here (password required for access).

POS Enhancements to Enable choice to Lock Offers to a Member

Background

POS APIs support multiple different functions, such as fetching member offers or rewards, so that the sales assistant or server can advise the member what is available and so that they can be used at the POS.

Currently when offers and rewards are fetched by the POS they are locked to the member until the order is complete.. However, sometimes the requirement is simply to advise the member of the offers and rewards available at the POS but not to lock them into using them for that order.

Solution

It’s now possible to specify that the offers or rewards fetched to the POS will not be locked to the member, if they are only required for information purposes.

The API documentation will be updated under Technical Documentation here (password required for access).

Order Rules Enhancements

Background

Earn rules are used to define how various activities such as purchases or visits are processed and how they will earn points or other metrics. These can be complicated to configure and require technical knowledge or Groovy scripting language.

Order rules are different to earn rules in that they determine the number of points that would be accrued or earned from orders submitted through a POS API, based on the configured order rules. From that determination an “SL” value is created and included on the purchase activity for the order, and that SL value is applied to calculate the accrual or points earned.

The challenge is to provide self service capabilities for non technical marketers to manage their accrual rules including more complex rules and to understand the breakdown of how a member earned their points so that campaign effectiveness can be better understood and for where adjustments are required to specific elements of a total number of points accrued for a transaction.

Solution

Order Rules can now be configured through a simple user interface without the need for any scripting language.

The configuration includes more eligibility criteria for bonus rules such as location, minimum qualifying quantities or amounts, minimum order amounts, plus look up tables can be used to determine included and excluded items, plus additional multiplying factors.

Order rules will now specify the breakdown of points that are calculated against an order i.e. base points plus points from all the different bonuses. This allows marketers to track effectiveness of rules and promotions; they can also charge back or reconcile as required, or determine points attributed to partner promotions etc.

This development provides a powerful self service tool for marketers to configure their earn rules, track effectiveness of those rules and accurately calculate any manual adjustments required.

Refer to Order Rules updates in the Online Help for more information.

Offer Placements available via API

Background

A Placement is a reusable, named location where Offers (or other content objects such as Rewards and Challenges) can be displayed, such as a web carousel or a particular section of an email message.

These features are currently available via the Loyalty application, however, external applications also need to use the placement functionality.

Solution

Offer placements have now been added to the Program API, so external systems can now get the necessary access to configure placements.

The Program API documentation has been updated here (password required for access).

Notable Fixes

Fixed an issue where images were not displaying correctly in the Content Editor
Fixed an issue where Punchcards were showing as completed where there were insufficient punches
Fixed an issue where discounts for free items were not applied correctly
Fixed an issue where changes to Offers were not saving correctly
Fixed an issue with error notifications in Mobile Wallet
Fixed an issue with merged accounts where a deleted metric was showing an error
Fixed an issue where the time value in the Program Setting “Metric expiration program date” was not saving
Fixed an issue to enable a forced import for airline member profiles

Loyalty Version 22.1.1 Release Notes

All features and fixes are automatically available to all customers upon upgrade to version 22.1.1

Features

Configure Response Data to Preserve When Member is Deleted

Background

Currently the system will delete the member record and all related responses in MySQL when the Delete Member API is invoked.

Solution

A new Program setting has been created so that the program administrator can specify whether to delete child responses or remove the member ID from the response instead of deleting it.

The program setting is called “Delete Member API Nullifies Member ID on Response Objects”.

For response records specified in the program setting, the system will delete the member ID but not the response record. For response records not specified in the program setting, the system will delete the member ID and the response record.

This enhancement enables the program to choose to retain anonymized data while complying with a member deletion request.

Refer to Response Data to Preserve When Member is Deleted program setting in the Online Help for more information.

Notable Fixes

Fixed an issue where the system was ignoring the number of decimal places configured for a Member Metric.
Fixed an issue where gift card qualification using lookups was not processed by the system correctly.

Loyalty Version 22.1 Release Notes

All features and fixes are automatically available to all customers upon upgrade to version 22.1.1

Features

All new features will be available to customers upgrading to version 22.1. Contact your Cheetah representative for more details where configuration assistance is required.

Add Funds to Existing Gift Card Reward

Background

Many loyalty programs issue cash equivalent rewards to their members, often at specified earn thresholds, either as single-use coupons or loaded onto a single “Stored Value Reward” digital gift card that can be redeemed across multiple purchases.

For the Stored Value Reward use case, Cheetah has supported issuing Gift Card rewards where each redemption would generate separate Gift Cards, however this has the challenge of maintaining separate reward balances across each Gift Card.

Solution

In this release, Cheetah has enhanced Gift Card rewards so when a member is issued a reward, the system will create a new Gift Card instance if one doesn’t already exist, or if a Gift Card reward of a certain type has already been issued, the system will add value to the balance of the existing Gift Card reward.

This has the benefit of allowing brands to surface a single reward balance so members can access a unified view of their “Reward Cash”, and because there is only one balance to manage.

In addition, the Gift Card object has been enhanced to support qualification rules similar to Coupon Offers, for instance:

The Gift Card class can be configured with a set of eligible or ineligible Product Categories or PLUs (Price Look Up codes). When defined, Gift Card value can only be redeemed for eligible products.
The Gift Card class can be configured with a minimum purchase subtotal. When a value above 0 is defined, the system will check whether an order submitted has a subtotal equal to or greater than the value configured on the Gift Card class to determine whether the order is eligible to redeem Gift Card value.

Introduced “Delete Member” Member API

Apple App Store Review Guidelines now mandate that apps requiring consumers to create an account, allow consumers to delete the account from within the app. This new rule is set to take effect by the end of June 2022.

To support this use case, Cheetah has added a Delete Member endpoint to the Member API. It allows members to initiate a request to delete their member profile in Cheetah Loyalty, and to confirm their request by either specifying their password or to have the system trigger a one-time code and to use that value to confirm the request.

Once confirmed, the system will delete the consumer’s member record in Cheetah Loyalty, and remove all related data in the system.

More information on the Delete Member API is available in the Member API documentation.

Introduced ValueLink Gift Card Integration

For brands that use ValueLink gift cards, it is now possible to integrate Cheetah Loyalty gift cards with ValueLink to support purchasing, linking, and viewing ValueLink gift card details in the context of a loyalty program.

Contact your Cheetah representative to request enablement of the integration in your program environment.

Introduced New Integration Id Member Attributes

To help brands needing to manage additional external system identifiers on a member record, we’ve introduced a set of new integration NN_id attributes in this release e.g. integration7_id, integration8_id, integration9_id, integration10_id, and integration11_id.

Members can be searched by these attributes in the Member screen in the Cheetah admin console, and the POS API has also been enhanced to support member lookup by these new integration id attributes.

Introduced Retro Claim Barcode for Sparkfly Integration

For brands using the Cheetah-Sparkfly POS Integration, it is now possible to configure Cheetah to return order details when no member is assigned to a check so a scannable barcode can be generated by the POS system on a receipt.

The barcode is meant to provide an easy way for consumers who weren’t added to a check to initiate a retroactive claim to earn credit for the purchase.

The feature is enabled and configured by new program settings - Print Retro Claim Barcode (false by default - this setting enables the feature), Retro Claim Barcode Format (QR or Barcode), and Retro Claim Barcode Content (configurable with references to retro claim elements like location, transaction id, business date, and subtotal).

Configuration instructions will be added to Online help here as a new section in this Program Settings Page.

Enhancement to Purchase Gift Card Member API

To support the ValueLink gift card integration, an enhancement has been made to the Purchase Digital Gift Card Member API to support a card_uid input.

Card_uid is the internal identifier that ValueLink returns in their Add to Wallet flow, which when passed in the Purchase Gift Card Member API, provides a unique id the Cheetah Loyalty system can pass back to ValueLink to get the gift card details like card number, pin, and current balance.

Introduced Update Punch Card Type Program API

It is now possible to programmatically update Punch Card Type objects via the Cheetah Program API, meaning that Punch Card metadata can now be updated from external systems in addition to the existing support for creation of metadata.

SKU Criteria on Punch Card Overrides Global Exclusion List

System behavior has been enhanced to give credit to order line items that match the specified SKU criteria on a personalized punch card even if the SKU appears on the Global Exclusion List.

Introduced New Punch Card Punch Criteria “Qualifying Line Amount Subtotal”

When configuring punch cards with sku or category criteria, it is now possible to specify a qualifying line amount subtotal so the system can determine whether the order meets the configured threshold or range for the amount spent on qualifying line items.

The line items included in the qualifying line amount subtotal are only those with skus or categories matching the sku and category criteria on the punch rules.

Introduced New "Between" Comparison Operator on Punch Rule Criteria

Previously, Punch Card credits could be awarded for purchase values above a specific amount, for example, all purchases of $5 or more would be awarded a punch.

It is now possible to configure punch rule criteria in personalized punch cards that can evaluate a criteria between two values. For example, a brand could now give a punch card credit for a purchase value between $5-$10.

An example payload for an issued punch card illustrating the between operator for the total criterion is shown in Appendix I.

Introduced the Ability to Configure Punch Card Limit Week Start Day and Time

When Punch Card Limits are used to control how many punches can be awarded in a given time period, and the period specified is a Week, the system now allows marketers to specify the day and time the weekly period starts.

This configuration is managed as a Program Setting. See Appendix II for details.

Reminder Moments are Now Supported with Multiplier Offers

Multiplier Punch Cards are used for time limited campaigns where the usual punches are multiplied by the configurable multiplying factor, such as x 2 for a “Double rewards day”.

These Multiplier Punch Card types are now integrated with reminder moments, which means that scheduled email or push messages can be configured for these campaigns.

Notable Fixes

Fix for Translation Export CSV File

As part of the enhanced support for Multiple language content, marketers can export a .CSV file with the existing translations in the content object (offer / reward / challenge) including all the fields where member facing text can be entered for the configured languages. This then enables the import of translations into the same object to streamline the configuration process for multiple languages.

The .CSV file included content that was irrelevant to the translation process and has now been removed to improve the user experience.

Fix to Allow Cancel and Reissuance of External Punch Cards

Fixed an issue that prevented canceling and reissuing a member punch card.

Performance Fix for Punch Card Campaigns

Improved SQL query performance related to ‘Choice’ punch cards.

Performance Fix for Retro Claim

Improved query optimization for requests to retroactively claim orders.

Performance Fix for Places

Optimized performance of queries to retrieve Place data.

Fixed an Issue with the SFMC Connector

Introduced a fix to support long scope values for the SFMC Connector.

Appendices

Appendix I

An example payload for an issued punch card illustrating the between operator for the total criterion is shown below:

The matcher element for the between operator is "bet".
The lower end of the range to compare is specified as "min_value".
The upper end of the range to compare is specified as the "max_value".

{

"member_integration_id": "MP022811",

"execution": "async",

"personalization": {

"recurrence_enabled": true,

"prizes": [

{

"punches": 1,

"punches_types": "Static",

"has_metric": true,

"metric_name": "point",

"metric_amount": 75

}

"punch_rules": [

{

"label": "Generic Named Punch1",

"name": "gen_np1",

"total": {

"matcher": "bet",

"min_value": "50.00",

"max_value": "74.99"

}

]

}

Appendix II

The configuration to specify the day and time the weekly period starts for punch card limits is managed as a Program Setting, and is available in the Cheetah Admin Console under Program > Settings > Program Settings.

A new section in Online Help under program settings entitled “Punch Card Weekly Limits” has been added here

Week Start Day - indicates the day of the week the weekly limit period begins. This value defaults to Monday but can be configured per the business requirements.
Week Start Time - indicates the time, in 24 hour notation, that the weekly limit day begins. This value defaults to 00:00 but can be configured per the business requirements.

While issued punch card personalization does not set the week limit start day or time, the following example is provided to share how issued punch cards can specify a limit of 4 punches in a week (one of the Rewards Together MVP use cases):

{

"member_integration_id": "TEST-DARW-001",

"execution": "async",

"personalization": {

"recurrence_enabled": true,

"prizes": [

{

"punches": 4,

"punches_types": "Static",

"has_metric": true,

"metric_name": "point",

"metric_amount": 25

}

"punch_rules": [

{

"name": "sr_transactions_only",

"label": "SR transaction",

"channel": {

"type": "fixed",

"value": "sr_reward"

}

"limits": {

"card_limit": {

"response_rate": 4,

"response_rate_unit": "week"

"continuity_period": {

"punch_period_num": 1,

"punch_period_unit": "week"

}

Loyalty Version 22.0 Release Notes

Major Feature: Multiple Language Campaigns

This enhancement has been enabled in preview mode for the current release, meaning that it can be deployed into customer staging environments for assessment.

Background

Marketers very often run campaigns across multiple markets meaning that content
must be provided in multiple languages or locales*.
Currently, content objects such as Offers, Rewards and Challenges can only be
configured in a single language.
This results in complexity for the marketer as they must configure one duplicate
object for each language with no easy mechanism to input translations. Categories are assigned to each object so that calling applications such as Mobile Apps and websites know which object to target for the required language.
It also results in complexity for the data analyst since responses to objects such as
multi question surveys are received in multiple languages and therefore need to be
translated to a single language in order to conduct data analysis.

Solution

A major content management enhancement to Offers, Challenges and Rewards so that:

marketers can more easily configure and manage multiple language campaigns
data analysts can easily report on multiple language campaigns

This initial release includes support for:

All Offer types
All Challenge types except Ratings, Multiple Choice and Text Surveys since they
are covered under Multi Question Surveys
All Reward types
The solution does not currently support Punch Cards, Badges and Wallet

Availability

This enhancement can be made available in staging environments upon request to all customers who upgrade to Release 22.0.0. Please contact your Cheetah Representative.
Where campaigns are already in operation across multiple languages / locales, please discuss with your Cheetah representative to assess any actions required to transition to the new approach.

Updated Member API documentation has been published to the CES Help Center here

Details on how to configure the required languages / locales in Program Settings is here under "Member Content Locales"

Other online help updates have been completed in the applicable sections.

Supported Use Cases by Persona, via the Loyalty UI

Admin:

Configure the program to support the required languages and/or locales
Set a default language to serve as the “stored” language used for data analysis
and to return when requested language is not configured

Marketer:

Create new content objects and easily configure member facing text or other translatable content** in the languages / locales configured for the program
Export configured member facing text from a single content object in the correct
file structure to enable addition of all translations applicable to the defined
object and configured languages
Import translations created offline for a single Content Object using the
previously exported file
Preview and amend content for each language from within the Content Object.

Data Analyst:

Analyze responses received in multiple languages without manual intervention
to translate and aggregate responses
Analyze data about the languages / locales from which the responses were
received

Member:

Calling application (website or mobile application) determines the required
language and requests it via the Member API

* locale means a language and its associated region, so that regional variations in languages can be
accounted for where required, e.g. French (France) French (Senegal) or English (US) English (UK) English (Canada). Where the term language is used alone in this document, the term locale applies equally.

** translatable content means content other than member facing text that needs to be different due to language / currency / clothing sizing differences by locale. If content varies for any other reason, it is treated as a different campaign.

Prevent “Double Dipping” with POS Integration

Background

Where Loyalty programs use multiple channels or methods to submit transactions, and each channel uses different unique identifiers, there can be a risk of points being accrued to an account twice from duplicate orders.

Solution

Introduction of a globally unique identifier for use on Cheetah orders and for
eCommerce and POS integrations, through both the POS API and Sparkfly API.
For online ordering flows the eCommerce system can submit an order both to Cheetah directly, and to the Point of Sale system for fulfilment that in turn relays it to Cheetah after fulfilment. This means that Cheetah receives the order twice.
The presence of a globally unique identifier allows Cheetah to recognize a single order coming through both channels and therefore is able to prevent creating a duplicate order.
Details on how to use this new functionality will be available in online help later this
month.

Availability

This enhancement is available to all customers upgrading to this release.

Notable Fixes

Added system retry support to SVS Gift Card integration.
Added support to get Vantiv Gift Card balance when getting a Gift Card by Id.
Added support for Gift Cards to be returned when using Sparkfly integration with staff-selected rewards.
Fixed an issue where points were incorrectly calculated when an OLO order included a non-Cheetah discount.
Fixed an issue where Cheetah coupon offer discounts were incorrectly calculated when an Aloha discount was applied to the order.
Fixed an issue where Triggered Actions caused an unexpected Tier change.
Fixed an issue where admin user roles were incorrectly assigned when authenticated via an external Auth Provider.

Loyalty Version 16.0 Release Notes

Configurable Point of Sale Message (via Sparkfly)

Background

When a loyalty program Member is making a purchase, such as paying a bill at a restaurant, the server can enhance the customer experience if they can view details of the Member’s account. For example:

Advising the Member of their current points balance enables the Member to make the decision whether to redeem their points.
Status and lifetime value information provide the server with context for interacting with the Member.
Displaying rewards available to the Member enables the server to provide personalized service by helping the Member use their rewards, increasing emotional loyalty.

Solution

This release introduces a new Program Setting called “Discount Display Message Content.” This feature is intended for Loyalty programs that use our Point of Sale (POS) integration via the Sparkfly POS system.

This new feature enables a marketer to configure a template for a pop-up message to display at the POS when the Member is added to the check or bill.

Optionally, you can configure the POS message to utilize a “relative” time zone when displaying Offer expiry times. Loyalty program Members register with the program in the specific time zone according to their residential address. However, for programs that operate across multiple time zones, redeeming an Offer could take place in a different time zone. If an Offer is being redeemed in a different time zone than the Member’s residence, the exact expiry date/time can be adjusted accordingly. For example, let’s say a Member has traveled to a different time zone, and they want to redeem an Offer that expires at midnight. The Offer will expire at midnight local time, as opposed to the time zone in which the Member resides.

For instructions on configuring the POS message template, please see Appendix I in the PDF file "Version 16.0" attached below. This enhancement is available to all Cheetah Loyalty customers upon upgrade to Release 16

OAuth Application Enhancement for JSON Web Tokens

Background

OAuth is a protocol that lets external apps request authorization to access Member data, such as Loyalty Member Profiles. OAuth enables that authorization to be monitored, throttled, or revoked at any time.

A registered OAuth application in the Loyalty platform is assigned a unique Client ID and Client Secret, which can be used by the client application. For example, mobile apps or websites can request authorization to Member data via Cheetah Member and Program APIs.

For Cheetah Loyalty, some applications use JSON Web Tokens (JWT) for authenticated API access to the Loyalty Member Profiles or other Member data. A JWT is a public key or standard way of encrypting and decrypting data. This method is used by some applications for data sent from an external application via API, to enable OAuth authenticated access to data in the receiving application, in this case Cheetah Loyalty.

The sending application “signs” the JWT string, and the consuming application, Cheetah Loyalty, verifies that signature using a public certificate provided by the sending application.

Upon verification, the platform will decode and accept the data; however, the data can be decoded without verifying the signature. Therefore, no sensitive or Personal Identifying Information (PII), such as email address, password, or credit card details, should be sent using JWT.

Within the Loyalty platform, you can manage your OAuth configurations on the Admin > Access > OAuth Applications screen. You can find additional information about this screen within the Loyalty Online here.

Solution

Additional support for OAuth using JWT has been added in this release of Cheetah Loyalty. The platform now supports the use of a shared secret key with a specific encryption algorithm namely “HS256.”

Cheetah Loyalty is now able to decrypt the HS256 algorithm for applications that use it for OAuth, using a shared secret key.

This enhancement is available to all Cheetah Loyalty customers using OAuth with JWT upon upgrade to Release 16.

Configurable Landing Page

Background

Currently, the Dashboard is displayed when a user signs into Cheetah Loyalty. However, some roles may prefer a different landing page. For example, it may be beneficial for Customer Service Representatives to automatically view the Member CSR screen when logging into the platform, as this is the screen where they do most of their work.

Solution

This release of Cheetah Loyalty now offers the following three choices for the landing page when users log into the platform. The landing page can be specified at a global level, and for a specific Role. For screen shots please see the PDF file "Version 16.0" attached below and for instructions on configuring the default landing page, please see Appendix II in the same document.

Notable Fixes

Incorrect and different numbers of decimal places were showing in different places, such as: Members > Members and Members > CSR > People. This discrepancy is now fixed so that a single decimal place displays throughout the application.
Sparkfly Point of Sale integration incorrectly processed orders that attempted to redeem multiple Reward Offers. This issue has been resolved, so that the platform correctly processes those orders and redeems multiple Offers when present.
Some Punch Cards were not displaying the configured Prizes within the platform user interface. Prizes now display correctly as configured.
When a user clicked an Order record in Cheetah Digital’s Engagement Data Platform (EDP), the user was incorrectly routed to a page in Loyalty. The platform now routes the user correctly to the Order record.
An issue where Order details were not displaying correctly in Members > Orders has been fixed.
The purchase or addition of credit to Vantiv Gift Cards was not processed correctly; this issue has been resolved.
An issue with the Member Merge feature not operating correctly is now fixed.
An issue with editing tab names in the application is now fixed.
An issue where Visitors were receiving a New Member Email Confirmation is now fixed.
Confirmation instructions were not being sent to imported visitors that converted to a full Member via an application using Single Sign On (SSO). This issue has been resolved.
An internal server error message displayed on the Content Page is now fixed.