Check the complete list of parameters and responses of the
PUT redeem/preview endpoint to preview
or validate rewards redemptions.Overview
When you want to emit a purchase event that contains rewards redemptions, you may want 2 things before emitting the event:- Preview the rewards redemptions: This allows your customers to be sure what they are going to redeem before they actually redeem it.
- Validate the rewards redemptions: This allows you to check if the rewards redemptions are valid and can be redeemed.
Why do we need to check if a redemption is valid?
Every type of reward have different rules to follow in order to be redeemed. POINTS: Can be redeemed at any level, this is the reward type that is most flexible. DISCOUNT: Discounts when created are configured to work on a specific entity, like a product, the shipping cost, or the order value. When redeeming a discount, you need to set the discount at the same entity that was configured. PRODUCT: Either ADD or REPLACE product rewards must only be redeemed at the order level. This is because adding a product that doesn’t exist or replacing a product for another one, you wouldn’t have a place to set the rewards to be redeemed. GIFT CARD: Gift cards are redeemed using only the redeem gift card endpoints. Redeeming a gift card in a purchase event will not work. Additionally, each reward may have some conditions configured to be met in order to be redeemed. For example, a discount may have a minimum order value to be redeemed.Preview rewards redemptions
To preview rewards redemptions, you need to send aPUT request to the redeem/preview endpoint.
The endpoint will send back the exact order you originally sent, but with an additional keyword redemptions_result at each level where a redeem array was found.
The endpoint doesn’t want to force you how to present the data to the customer, it just provide the data you need to build whatever experience you want to show.
Example Order sent
Let’s pretend we want to preview the rewards redemptions for the following order:Example Order received
The response will be the same order you sent, but with the rewards redemptions previewed:- The
redemptions_resultobject was to the product that redeemed 6 points. - This new object contains the discounted value of the product
value, how much was discounteddiscount_value, the percentage of the discountdiscount_percent. This values can be used to show the customer how much they are saving. - It also contains an
actionfield that tells you what to do with the affected entity:UPDATE: The entity was updated, display these values instead.READ: The entity has been updated before, but the last redeem didn’t change anything.DELETE: Then entity was removed, don’t display this item in the order.CREATE: The entity is new and must be display along the other products in the order.
- The
redeemedarray contains the rewards that were redeemed and the action that was taken. - Even though we redeemed a reward at the product level, a redemption_result was created at the order level as well. This is because the order level was affected by the redemption.
redemption_stepsrecords every redemption in application order.beforeandaftershow how the order changed. Product and shipping steps also includetarget_beforeandtarget_afterfor the affected item.
How value, discount_value and discount_percent are calculated
Rewards are applied one by one, in the same order as the redeem array. Each redemption builds on top of the previous redemptions_result of the entity, so the fields always accumulate across all redeemed rewards:
- POINTS: discounts
amount × conversion_factorfrom the entityvalue. The accumulated discount is capped at the entity value, sovaluenever goes negative. - DISCOUNT (fixed): discounts
discount_value × amountfrom the entityvalue. - DISCOUNT (percentage): the percentage is applied over the remaining
value(after previous redemptions). This means the order of theredeemarray matters for percentage discounts: a 50% discount applied after a $2 discount is smaller than one applied before it. - PRODUCT (ADD_PRODUCT / REPLACE_PRODUCT): adds
estimated_value × replace_amount(ornew_amountfor additions) todiscount_value, but does not reduce the entityvalue. The saving is an estimate: the customer pays the same for the rest of the order and receives the added/replaced product for free.
value: what the entity costs after applying the value-reducing rewards (POINTS and DISCOUNT). This is the field to use when validating the amount to charge.discount_value: the total accumulated saving from all redeemed rewards, including the estimated value of PRODUCT rewards. Because PRODUCT rewards don’t reducevalue,value + discount_valuecan be greater than the original entity value.discount_percent: the percentage that the value-reducing rewards represent over the original entity value, capped at1. PRODUCT rewards don’t change it (it keeps the previous percentage, ornullif there is none), so when PRODUCT rewards are redeemeddiscount_percentwill not equaldiscount_valuedivided by the original value.redemption_steps[].discount_value: the saving contributed by that individual redemption to the order total. Failed or fully capped redemptions contribute0.redemption_steps[].before.discount_percentandredemption_steps[].after.discount_percent: the cumulative saving divided by the original order value, capped at1. These step percentages include the estimated value of PRODUCT rewards.
redemption_steps is chronological across the whole preview: product redemptions are applied first in product order, then shipping redemptions, and finally order redemptions. Within each target, entries follow the original redeem array order. Use target to map the contribution to an external code—for example, shipping to a delivery discount code and order or product to the corresponding merchandise discount code. before and after always show the cumulative order state. target_before and target_after are only present for product and shipping steps, where the affected target differs from the order.
For example, on a 2.34, the existing order-level result remains value: 53.125, discount_value: 55.465 and discount_percent: 0.5. In redemption_steps, the first reward leaves after.discount_percent at 0.5 and the product reward raises it to 0.5220235294117647 (55.465 / 106.25).
Example Order with an error
Some rewards may have conditions that need to be met in order to be redeemed. If the conditions are not met, the rewards will not be redeemed. Take into consideration that the response will end with a status of 200. You will need to display the error to the customer.error was added to the redeemed object. This error can either be shown to the customer or used to debug your implementation.
Re-validating an order
Many things may happen that will force you to update an order. For example: adding/removing products, applying/removing a reward, updating an item amount, changing the delivery address, etc. After each of these situations, you will need to re-validate the order. When revalidating the order you must keep a copy of your original products and values. Do not replace them with the ‘redemptions_result’ object. This data should only be used to help your customers preview the rewards redemptions. Use the action field to know what to do with the entity. If you are re-validating an order, it is super important to also bring with you the ‘redemptions_result’ object of each entity. Masivo will use these objects to know what rewards to redeem next, which rewards were already redeemed, and which rewards were removed.Validate rewards redemptions
The same endpoint can be repurpose to validate an order. Call this endpoint in your backend and use the fieldorder.redemptions_result.value to compare if what you are going to charge the customer matches.
If the order values don’t match, the order may have been tampered with. You should not emit the event.