Manage Loyalty Rewards
A loyalty program can have one or more reward tiers that define how buyers can redeem points for discounts. While building an order, you can offer discount options to the buyer for qualifying purchases based on the point balance of their loyalty account and reward tier requirements. For information about retrieving reward tier information, see Get discount details for a reward tier.
The Loyalty API supports the following operations for working with loyalty rewards:
Redeem a loyalty reward (applications that integrate with the Orders API do not need to call
RedeemLoyaltyReward
)
The following is an example LoyaltyReward
object:
This example loyalty reward requires 15 points and has a REDEEMED
status. The following fields represent key attributes of a loyalty reward:
Field | Description |
---|---|
status | The reward status: ISSUED , REDEEMED , or DELETED . Rewards with a REDEEMED status also include a redeemed_at field. Both REDEEMED and DELETED are terminal states. |
loyalty_account_id | The ID of the loyalty account to which the reward belongs. |
reward_tier_id | The ID of the reward tier that defines the reward details. |
points | The number of points required to claim the reward discount. |
Call CreateLoyaltyReward to issue a loyalty reward when a buyer chooses to redeem points for a discount. You provide the following information in the request:
The ID of the loyalty account associated with the buyer. To get the loyalty account ID, call
SearchLoyaltyAccounts
and search by phone number or search by customer ID.The ID of the corresponding reward tier.
If the order was created with the Orders API, the ID of the order. Integrating with the Orders API can simplify loyalty workflows.
After receiving the request, Square does the following:
Removes the required points from the loyalty account balance and holds them in reserve until the reward is redeemed or deleted.
Generates a searchable loyalty event.
Did you know?
You can show buyers a preview of the discount before creating the reward. For more information, see Deferred reward creation.
The following is an example response, which includes the points required to redeem the reward:
The following considerations apply when creating loyalty rewards:
Your integration with the Orders API determines whether Square updates the order or whether it is your responsibility to do so:
If an order ID was specified in the
CreateLoyaltyReward
request, Square attaches the reward to the order, applies the corresponding discounts to qualifying line items, and adjusts the discount and total amounts accordingly.If no order ID was specified, you must apply all appropriate discounts to the order.
The Orders API allows you to add items and rewards to an order in any sequence. If adding a reward first, you should verify that the discounted item is part of the order. For example, if the reward gives the buyer a free coffee, make sure the order includes a coffee.
If an order ID was specified when creating the reward but the item is not included in the order, Square deletes the reward after the order is paid and returns the points to the buyer's loyalty account.
The steps required to redeem the reward and manage the order also depend on whether you specified the order ID in your
CreateLoyaltyReward
request. If you use the Orders API to manage orders, Square handles most of the remaining workflow. For more information, see Managing the reward state.
If your application does not integrate with the Orders API, call RedeemLoyaltyReward to redeem the reward. The location_id
provided in the request must reference a participating location in the loyalty program.
Note
If your application integrates with the Orders API, Square calls this endpoint automatically after the order is paid. For more information, see Managing the reward state.
After receiving the request, Square does the following:
Permanently removes the points from the loyalty account balance.
Sets the reward to the
REDEEMED
terminal state.Generates a searchable loyalty event.
The following is an example response, which contains the generated loyalty event:
Call RetrieveLoyaltyReward to retrieve a loyalty reward by the reward ID.
The following is an example response:
If the reward cannot be found, Square returns a 404 NOT_FOUND
error.
Call SearchLoyaltyRewards to list loyalty rewards, optionally filtered for a loyalty account or reward status.
The following is an example response:
Results are sorted by the updated_at
timestamp in descending order. If no results are found, the response contains an empty object:
Call DeleteLoyaltyReward to delete a reward that was issued but not redeemed.
After receiving the request, Square does the following:
If an order ID was specified when the reward was created, updates the order by removing the reward and related discounts.
Returns the reserved points to the loyalty account.
Sets the reward to the
DELETED
terminal state.Generates a searchable loyalty event.
If successful, the response contains an empty object:
A deleted reward can still be retrieved.
A loyalty reward can be in one of the following states:
ISSUED
. The initial state of a reward. When a reward is created, the points required to redeem the reward are removed from the loyalty account and held in reserve until the reward is redeemed or deleted.REDEEMED
. The reward was redeemed. When a reward is redeemed, the reserved points are permanently removed from the loyalty account.DELETED
. The reward was deleted. When a reward is deleted, the reserved points are returned to the loyalty account.
Note
REDEEMED
and DELETED
are terminal states. You cannot delete a redeemed reward in order to return points to a loyalty account. If you need to manually adjust the point balance of a loyalty account, call AdjustLoyaltyPoints.
The following common workflows can cause rewards to move from ISSUED
to the REDEEMED
or DELETED
state. Your responsibility depends on whether a Square order ID was specified when creating the reward.
Order ID specified: Square sets the status to
REDEEMED
.No order ID specified: You must call RedeemLoyaltyReward, which sets the status to
REDEEMED
.
Order ID specified: Square sets the status to
DELETED
.No order ID specified: You must call DeleteLoyaltyReward, which sets the status to
DELETED
.
An example scenario for this workflow is when a buyer removes a discounted item from the order before paying for the order.
You must call DeleteLoyaltyReward, which sets the status to DELETED
.
Order ID specified: Square removes the discount from the order and updates the order amount.
No order ID specified: You must also update the order appropriately.
For abandoned orders, you can determine the appropriate amount of time to wait before deleting dangling rewards, but it is your responsibility to clean them up. Otherwise, they remain in the ISSUED
state and the reserved points cannot be used for other purchases.
Showing buyers a preview of the discount before creating the reward might help avoid creating dangling rewards. For more information, see Deferred reward creation.
Note
The operations involved in changing the reward state run asynchronously, so changes might not be immediately visible if you call RetrieveLoyaltyReward to retrieve the reward.
The following high-level steps describe how to get discount details and product information that correspond to the reward tiers in a loyalty program:
Step 1: Get the reward tiers for the loyalty program.
Call RetrieveLoyaltyProgram
in the Loyalty API. Then, check whether the loyalty account balance has enough points to qualify for a reward tier.
Step 2: Get the discount details for the reward tier. Call RetrieveCatalogObject
in the Catalog API to get the PRICING_RULE
, DISCOUNT
, and PRODUCT_SET
catalog objects that define the discount for each qualifying reward tier. You must retrieve these objects at a specific catalog version.
Step 3: Get current product information. Call BatchRetrieveCatalogObjects
in the Catalog API to get the CATEGORY
and ITEM_VARIATION
catalog objects that the discount applies to. This step applies to CATEGORY
and ITEM_VARIATION
scopes only and ensures that you show the most recent category or item information to the buyer.
To get the reward tiers for a loyalty program, call the RetrieveLoyaltyProgram endpoint.
The following is an excerpt of a RetrieveLoyaltyProgram
response. The reward_tiers
field contains a list of LoyaltyProgramRewardTier objects that represent the reward tiers in the loyalty program.
Each reward tier in the response contains the following key fields:
id
. The reward tier ID that you use to create a loyalty reward for a buyer.points
. The number of points that must be redeemed to claim the reward.name
. The seller-defined name for the reward tier.pricing_rule_reference
. The specific version of aPRICING_RULE
catalog object that defines the discount details for the reward tier.
Note
The RetrieveLoyaltyProgram
response currently includes the deprecated definition
field, which is replaced by the pricing_rule_reference
field. You should use pricing_rule_reference
.
To get the discount details for a reward tier, call the RetrieveCatalogObject endpoint in the Catalog API. You must retrieve these objects at a specific catalog version. The request must:
Include the
object_id
andcatalog_version
from the correspondingpricing_rule_reference
field.Set
include_related_objects
totrue
to return all catalog objects that are part of the discount definition.
The following table describes where you can find discount details in the PRICING_RULE
, DISCOUNT
, and PRODUCT_SET
catalog objects from the response:
Discount property | Catalog API mapping |
---|---|
Type of discount offered by the reward tier | The discount_data.discount_type field of the DISCOUNT catalog object.Valid values are FIXED_AMOUNT or FIXED_PERCENTAGE . |
Fixed percentage of a FIXED_PERCENTAGE discount | The discount_data.percentage field of the DISCOUNT catalog object.This value is a string representation of a decimal number. For example, a 7.25% discount is represented as "7.25". |
Maximum money amount of a FIXED_PERCENTAGE discount | The discount_data.maximum_amount_money field of the DISCOUNT catalog object.Optional. This field is a Money object, which specifies amount using the smallest denomination. |
Fixed money amount of a FIXED_AMOUNT discount | The discount_data.amount_money field of the DISCOUNT catalog object.This field is a Money object, which specifies amount using the smallest denomination. |
Scope of the reward | The discount_target_scope field of the PRICING_RULE catalog object and the product_set_data field of the PRODUCT_SET catalog object. You can determine which items the discount applies to, as follows:If the discount applies to the entire order: • discount_target_scope is WHOLE_PURCHASE .• product_set_data contains "all_products": true .If the discount applies to specific categories of items: • discount_target_scope is LINE_ITEM .• product_set_data contains a product_ids_any field that references one or more CATEGORY catalog objects.If the discount applies to specific items: • discount_target_scope is LINE_ITEM .• product_set_data contains a product_ids_any field that references one or more ITEM_VARIATION catalog objects. |
Note
The related CATEGORY
and ITEM_VARIATION
catalog objects are also returned in the response, but they might not be the latest versions of the objects. You should also make a call to get current product information.
The following are example RetrieveCatalogObject
responses for the different scopes.
Example response for the order scope (whole purchase)
The following example represents a "$10.00 Off Entire Order" reward. It specifies a FIXED_AMOUNT
discount of $10.00.
Example response for the category scope
The following example represents a "50% Off One Hot Drink" reward. It specifies a FIXED_PERCENTAGE
discount of 50.0 with a maximum discount amount of $2.75. It also specifies the category (hot drinks) to which the discount applies. Although this example applies to a single category, a CATEGORY
reward tier can apply to multiple categories.
Example response for the item variation scope
The following example represents a "Free Latte or Cappuccino" reward. It specifies a FIXED_PERCENTAGE
discount of 100.0, which represents a free item. It also specifies two item variations (latte and cappuccino) to which the discount applies.
The following considerations apply to reward tier discount integrations:
Developers cannot use Square APIs to manage loyalty programs or reward tiers. To ensure that the discount details for a reward tier cannot be changed using the Catalog API, Square pins the corresponding pricing rule to a
PRICING_RULE
catalog object at a specific catalog version.When a seller updates the reward tier in the Seller Dashboard or Point of Sale application, a new pricing rule is created.
The Loyalty API does not use all fields in the
PRICING_RULE
,DISCOUNT
, andPRODUCT_SET
catalog objects. You can ignore fields that are not listed in the Catalog API mapping table, such asapplication_mode
,max_applications_per_attachment
, andapplication_method
.You should use the
RetrieveCatalogObject
endpoint to get discount details for a reward tier. Although theBatchRetrieveCatalogObject
endpoint can also return catalog objects at a specific version, a single call might not return all pricing rules for a loyalty program because the correspondingPRICING_RULE
catalog objects might belong to different versions.
To get the current product information for the catalog objects that are eligible for the discount, call the BatchRetrieveCatalogObjects or RetrieveCatalogObject endpoint in the Catalog API. This step ensures that you retrieve all updates made since the catalog version specified in the previous request, such as changes to an item's price.
Note
This step applies to CATEGORY
and ITEM_VARIATION
scopes; it does not apply to ORDER
scopes. Depending on your application flow, you might have already retrieved the most current category or item information and can skip this step.
For this call, the request should:
Include the IDs from the
product_set_data.product_ids_any
field of thePRODUCT_SET
catalog object from the previous request.Not include the
catalog_version
field.
In your application flow, you can show buyers a preview of how a loyalty reward would affect a purchase before you create the reward. Buyers can use this preview to decide whether they want to redeem the points.
By deferring reward creation until the buyer completes the order, you can avoid locking reward points prematurely. When a reward is created, the required points are removed from the loyalty account. The points are held in reserve and cannot be used for discounts on other purchases. For more information, see Managing the reward state.
For example, consider the following eCommerce checkout scenarios.
Window shopping. Buyers can add items to the cart and apply available discounts to see the effect on purchase price. They might keep the cart open for a long time without paying for it.
Abandoned carts. Buyers might never pay for items they added to the cart.
Both scenarios illustrate the benefit of deferring reward creation until the buyer completes the order. In such scenarios, you can call CalculateOrder in the Orders API to create a copy of an order with the specific rewards applied. Then, you can show the buyer the effect of applying the discounts. Later, when the buyer is ready to make a purchase, you can call CreateLoyaltyReward
to create a reward.
The following example CalculateOrder
request calculates the amounts for a non-catalog item order.
For the order
object in the request body, you can provide an existing order or a preview order that is not yet created:
Existing order. If you know the order ID, you can call RetrieveOrder to retrieve the order and pass the entire
Order
object.Preview order. While you are building an order, you can pass an
Order
object that does not contain an order ID, as shown in the preceding example. Use the same object that you would send to the CreateOrder endpoint.
For the proposed_rewards
field, provide the following:
reward_tier_id
. The ID of the reward tier from the loyalty program.id
. A random string that serves as the ID for the simulated reward.
The following is an example response that provides a preview of the order with the applied discount.
Note the following fields in the response:
The
total_discount_money
,total_money
, anddiscount_money
amounts for the order and line item are updated with the applied discount.The
discounts
field is added to the order. The discount contains information about the applied discount.The
applied_discounts
field is added to the line item. The discount maps to the order-level discount.The
rewards
field is added to the order. This simulated reward contains the reward and reward tier IDs you provided in theproposed_rewards
field of the request.
In a simple scenario, applications might allow a buyer to redeem only one reward per order. The application flow is simple: show the rewards the buyer qualifies for (for example, a free coffee for 10 points and a free sandwich for 15 points) and let the buyer make the choice. After the buyer chooses a reward, the point balance is adjusted accordingly.
Alternatively, applications (such as Square Point of Sale) can allow buyers to redeem multiple rewards per order. To provide a consistent experience, your application can also allow multiple redemptions. In this scenario, your application must track changes to the loyalty point balance when buyers add or remove rewards, as follows:
If your application immediately calls
CreateLoyaltyReward
each time the buyer adds a reward orDeleteLoyaltyReward
each time the buyer removes a reward, the loyalty account reflects the latest point balance. You can call RetrieveLoyaltyAccount to fetch the updated balance.If your application uses the deferred reward creation approach as buyers add and remove rewards, the buyer's loyalty account does not accurately reflect the available point balance. In this case, your application must keep track of the available point balance on the client side. You can use the following logic to track the available point balance on the client side:
When you apply multiple rewards to an order, the Square pricing engine applies discounts so that they maximize the reward value in the buyer's favor. Therefore, discounts might be rearranged as more rewards are added to the order. For example, consider the following scenario:
Your cart contains one tea for $4 and one coffee for $2.
You offer two rewards: a Free Drink and a Free Tea.
If you first add the Free Drink reward to the order, Square discounts the tea because it is more expensive. If you then add the Free Tea reward, the Free Drink discount is moved from the tea to the coffee, so the Free Tea reward can be applied to the tea.
Note
For other considerations related to multiple redemptions, see Requirements and limitations.
If you need more assistance, contact Developer Support or ask for help in the Developer Forums.