Learn how to preview & validate rewards redemptions
Check the complete list of parameters and responses of the PUT redeem/preview
endpoint to preview
or validate rewards redemptions.
When you want to emit a purchase event that contains rewards redemptions, you may want 2 things before emitting the event:
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.
To preview rewards redemptions, you need to send a PUT
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.
Let’s pretend we want to preview the rewards redemptions for the following order:
The response will be the same order you sent, but with the rewards redemptions previewed:
Several things happened in the response:
redemptions_result
object was to the product that redeemed 6 points.value
, how much was discounted discount_value
, the percentage of the discount discount_percent
. This values can be used to show the customer how much they are saving.action
field 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.redeemed
array contains the rewards that were redeemed. This array will contain the rewards that were redeemed and the action that was taken.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.
In this case, the discount was not redeemed because it was a shipping discount and it was redeemed at the product level.
A new field error
was added to the redeemed object. This error can either be shown to the customer or used to debug your implementation.
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.
The same endpoint can be repurpose to validate an order. Call this endpoint in your backend and use the field order.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.
Masivo also checks if all conditions match for a redemption when an event is emitted. If the conditions don’t match, or whether the customer has insufficient funds, the event will be rejected.
Learn how to preview & validate rewards redemptions
Check the complete list of parameters and responses of the PUT redeem/preview
endpoint to preview
or validate rewards redemptions.
When you want to emit a purchase event that contains rewards redemptions, you may want 2 things before emitting the event:
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.
To preview rewards redemptions, you need to send a PUT
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.
Let’s pretend we want to preview the rewards redemptions for the following order:
The response will be the same order you sent, but with the rewards redemptions previewed:
Several things happened in the response:
redemptions_result
object was to the product that redeemed 6 points.value
, how much was discounted discount_value
, the percentage of the discount discount_percent
. This values can be used to show the customer how much they are saving.action
field 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.redeemed
array contains the rewards that were redeemed. This array will contain the rewards that were redeemed and the action that was taken.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.
In this case, the discount was not redeemed because it was a shipping discount and it was redeemed at the product level.
A new field error
was added to the redeemed object. This error can either be shown to the customer or used to debug your implementation.
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.
The same endpoint can be repurpose to validate an order. Call this endpoint in your backend and use the field order.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.
Masivo also checks if all conditions match for a redemption when an event is emitted. If the conditions don’t match, or whether the customer has insufficient funds, the event will be rejected.