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:

Link to section

LoyaltyReward object

The following is an example LoyaltyReward object:

{ "id": "c7f57ff2-c3ad-38d7-bef8-31a345e883e0", "status": "REDEEMED", "loyalty_account_id": "716cefbc-3d71-4d7c-bdc8-9c7f84c2d793", "reward_tier_id": "7b897fee-572a-4516-a3d3-47676931e4f3", "points": 15, "created_at": "2022-03-03T21:32:12Z", "updated_at": "2022-03-03T21:38:52Z", "redeemed_at": "2022-03-03T21:38:53Z" }

This example loyalty reward requires 15 points and has a REDEEMED status. The following fields represent key attributes of a loyalty reward:

FieldDescription
statusThe 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_idThe ID of the loyalty account to which the reward belongs.
reward_tier_idThe ID of the reward tier that defines the reward details.
pointsThe number of points required to claim the reward discount.
Link to section

Create a loyalty reward

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.

Create loyalty reward

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:

{ "reward":{ "id": "6c1ac262-a066-3c0e-8386-5704eac36b86", "status": "ISSUED", "loyalty_account_id": "716cefbc-3d71-4d7c-bdc8-9c7f84c2d793", "reward_tier_id": "46c2716e-f559-4b75-c015-764897e3c4ae0", "points": 10, "order_id": "cb9LSpDgOH3rITBaZ6eIBb9ee4F", "created_at": "2022-03-13T00:00:51Z", "updated_at": "2022-03-13T00:00:51Z" } }

The following considerations apply when creating loyalty rewards:

  • Your integration with the Orders API determines whether Square updates the order or whether it's 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 isn't 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.

Link to section

Redeem a loyalty reward

If your application doesn't 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.

Redeem loyalty reward

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:

{ "event": { "id": "08fb6143-3716-3a78-8b6a-858230b4041b", "type": "REDEEM_REWARD", "created_at": "2022-03-03T21:38:53Z", "redeem_reward": { "loyalty_program_id": "8031c1b2-d729-4c76-9c40-ab5472ed2e04", "reward_id": "c7f57ff2-c3ad-38d7-bef8-31a345e883e0" }, "loyalty_account_id": "716cefbc-3d71-4d7c-bdc8-9c7f84c2d793", "location_id": "MK34ENDNWY03R", "source": "LOYALTY_API" } }
Link to section

Retrieve a loyalty reward

Call RetrieveLoyaltyReward to retrieve a loyalty reward by the reward ID.

Retrieve loyalty reward

The following is an example response:

{ "event": { "id": "08fb6143-3716-3a78-8b6a-858230b4041b", "type": "REDEEM_REWARD", "created_at": "2022-03-03T21:38:53Z", "redeem_reward": { "loyalty_program_id": "8031c1b2-d729-4c76-9c40-ab5472ed2e04", "reward_id": "c7f57ff2-c3ad-38d7-bef8-31a345e883e0" }, "loyalty_account_id": "716cefbc-3d71-4d7c-bdc8-9c7f84c2d793", "location_id": "MK34ENDNWY03R", "source": "LOYALTY_API" } }

If the reward cannot be found, Square returns a 404 NOT_FOUND error.

Link to section

List or search for loyalty rewards

Call SearchLoyaltyRewards to list loyalty rewards, optionally filtered for a loyalty account or reward status.

Search loyalty rewards

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:

{}
Link to section

Delete a loyalty reward

Call DeleteLoyaltyReward to delete a reward that was issued but not redeemed.

Delete loyalty reward

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.

Link to section

Managing the reward state

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.

Link to section

If the buyer pays for the order and receives the discount

  • Order ID specified - Square sets the status to REDEEMED.
  • No order ID specified - You must call RedeemLoyaltyReward, which sets the status to REDEEMED.
Link to section

If the buyer pays for the order but didn't receive the discount

  • 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.

Link to section

If the buyer chooses not to redeem a reward or abandons 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's 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.

Link to section

Getting discount details for a reward tier

Reward tier discounts are defined using catalog objects. The following high-level steps describe how to use the Loyalty API and Catalog API to get discount details and product information for the reward tiers in a loyalty program:

Step 1: Get the reward tiers for the loyalty program - Call RetrieveLoyaltyProgram in the Loyalty API to get the active reward tiers and current discount details. At this point, you might want to 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 only for catalog-based or item-based discounts so you can show the most recent product information to the buyer.

This process ensures that you don't use obsolete information for discounts (if reward tiers are updated or removed) or products (if the catalog changes after the reward tier is created).

Link to section

Step 1: Get the reward tiers for the loyalty program

To get the reward tiers for a loyalty program, call the RetrieveLoyaltyProgram endpoint.

Retrieve loyalty program

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 a PRICING_RULE catalog object that defines the discount details for the reward tier. The object_id and catalog_version fields are used to retrieve the discount details for the pricing rule.

Note

Although the RetrieveLoyaltyProgram response also currently includes the deprecated definition field, you should use the pricing rule to get discount details.

Link to section

Step 2: Get the discount details for the reward tier

To get the discount details for a reward tier, call the RetrieveCatalogObject endpoint in the Catalog API. The request must include:

  • The object_id parameter set to the pricing_rule_reference.object_id field in the reward tier.
  • The catalog_version parameter set to the pricing_rule_reference.catalog_version field in the reward tier.
  • The include_related_objects query parameter set to true, which tells Square to return all catalog objects that are part of the discount definition.

Retrieve catalog object

The returned PRICING_RULE catalog object references a DISCOUNT catalog object and a PRODUCT_SET catalog object. These three catalog objects define the discount type and discount scope of the reward tier.

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.

Link to section

Discount type

The discount type and type-specific details are defined in the discount_data field of the DISCOUNT catalog object.

Discount detailDISCOUNT field mapping
Discount typediscount_data.discount_type
Amount of a FIXED_AMOUNT discountdiscount_data.amount_money
Percentage of a FIXED_PERCENTAGE discountdiscount_data.percentage
Maximum amount of a FIXED_PERCENTAGE discount (optional)discount_data.maximum_amount_money
Discount namediscount_data.name

A reward discount can be a fixed amount or a percentage:

  • For a fixed amount discount (such as $5 off):

    • discount_type is FIXED_AMOUNT.
    • amount_money is the discount amount. This amount is specified as a Money object, which uses the smallest denomination of the currency.
  • For a percentage discount (such as 20% off):

    • discount_type is FIXED_PERCENTAGE.
    • percentage is the discount percentage, specified as a string representation of a decimal number. For example, a 7.25% discount is represented as "7.25" and a free item is "100.0".
    • maximum_amount_money is the optional maximum discount amount. This amount is specified as a Money object, which uses the smallest denomination of the currency.
Link to section

Discount scope

Scope details are defined in the PRICING_RULE and PRODUCT_SET catalog objects:

  • The discount scope is defined in the discount_target_scope field of the PRICING_RULE object.
  • Discounted categories or items (if any) are specified in the product_set_data field of the PRODUCT_SET object.

A reward discount can be scoped to the entire order or to one or more categories or items.

ScopePRICING_RULE and PRODUCT_SET settings
Discount applies to the entire orderPRICING_RULE.discount_target_scope is WHOLE_PURCHASE
PRODUCT_SET.product_set_data contains "all_products": true
Discount applies to specific categories of itemsPRICING_RULE.discount_target_scope is LINE_ITEM
PRODUCT_SET.product_set_data contains a product_ids_any field that references one or more CATEGORY catalog objects
Discount applies to specific itemsPRICING_RULE.discount_target_scope is LINE_ITEM
PRODUCT_SET.product_set_data contains a product_ids_any field that references one or more ITEM_VARIATION catalog objects

The following RetrieveCatalogObject responses show examples of the different scopes:

  • WHOLE_PURCHASE scope for a discount on the entire order

    The following example represents a "$10.00 Off Entire Order" reward. It specifies a FIXED_AMOUNT discount of $10.00.

  • LINE_ITEM scope for a category-based discount

    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.

  • LINE_ITEM scope for an item-based discount

    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, new PRICING_RULE, DISCOUNT, and PRODUCT_SET catalog objects are created.

  • You should always retrieve the loyalty program to get the active reward tiers with references to the specific pricing rule and version that defines current discount information. This step ensures you don't use obsolete discount information defined for reward tiers that are updated or removed.

  • You should use the RetrieveCatalogObject endpoint to get discount details for a reward tier. Although the BatchRetrieveCatalogObject 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 corresponding PRICING_RULE catalog objects might belong to different versions.

  • The Loyalty API doesn't use all fields in the PRICING_RULE, DISCOUNT, and PRODUCT_SET catalog objects. You can ignore fields that aren't described for the discount type or discount scope, such as application_mode, max_applications_per_attachment, and application_method.

Link to section

Step 3: Get current product information

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 doesn't apply to ORDER scopes. If you already retrieved the most current category or item information in your application flow, you can skip this step.

For this call, the request should:

  • Include the IDs from the product_set_data.product_ids_any field of the PRODUCT_SET catalog object from the previous request.
  • Not include the catalog_version field.

Batch retrieve catalog objects

Link to section

Deferred reward creation

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.

Calculate order

For the order object in the request body, you can provide an existing order or a preview order that isn't 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're building an order, you can pass an Order object that doesn't 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, and discount_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 the proposed_rewards field of the request.
Link to section

Multiple reward redemption

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 or DeleteLoyaltyReward 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 doesn't 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's 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.

Link to section

See also