...
Besides that we have a possible problem: these masses of data are prod-voucherify
This is the example for of the request/response when applying a promotional code:
...
Code Block | ||
---|---|---|
| ||
{ "data": { "validatePromoCode": { "code": "8B9IKPQK", "reason": "misconfiguredCode", "message": "missing offerId", "isValid": false, "isRedeemed": false, "offerId": "", "__typename": "CBACouponResponse" } } } |
Attention
...
point
We are always sending
cognitoId
attribute (cognitoId
is like user id);The promo code is
CBACoupon
type;We sent a send an available offer
"7bf2c11c-ec68-4d44-abd3-597b3967fcef"
;
...
There is a method validateCoupon
that receive receives the frontend call
path:
intl-promotion-service/src/providers/vendors/voucherify.ts
This flow will create customers datas customer data on Voucherity with metadata:
...
if
userIdType: "cognitoId"
so, the promo code is CBA type.if
userIdType: "loyaltyId"
so, the promo code is loyalty type.As frontend always send sends the attribute
cognitoId
on backend, in other words, the promo code at checkout will be always CBA type.
After validated validating the voucher with Voucherify API (client.validations.validateVoucher()
) the return will be:
Code Block | ||
---|---|---|
| ||
{ valid: true, applicable_to: { data: [], total: 0, data_ref: 'data', object: 'list' }, inapplicable_to: { data: [], total: 0, data_ref: 'data', object: 'list' }, tracking_id: 'track_ECpOaiQwipBVhSIEWGSfgmnjgtme+FQfW97lzOopYE6W1FvVYiEk7A==', code: 'INBIIT5F', discount: { type: 'AMOUNT', effect: 'APPLY_TO_ORDER', amount_off: 5000 }, start_date: '2023-08-28T07:00:00.000Z', metadata: { configId: '7bf2c11c-ec68-4d44-abd3-597b3967fcef' }, campaign: 'TEST VOUCHERIFY', campaign_id: 'camp_bHKpj7ruZxRPLoq2BqfCx0H2' } |
The problem start starts here: because the attribute metadata
contains { configId: ‘7bf2c11c-ec68-4d44-abd3-597b3967fcef' }
, this value is for loyalty code types, in other words, this return is wrong and should be returned an offerId
attribute.
...
There is a mutation
redeemMutation
that send the loyaltyId, so we will add this mutation with some condition to send loyaltyId (to markets that wants want to use promo code at checkout, or to market that don’t doesn’t use it and impact other markets).This condition can be a flag on sanity maybe.
...
Attention point
Is possible on Voucherify, configure a promo code with expiryDate
undefined, but on backend validate it and can receive a an error, so if it will need to use a an “infinity“ expiryDate
, that don’t doesn’t have an end date finish, so we will change a validate date loyalty flow.
...
We will change this condition to validate the expiry date just there is a valide date.
After
...
these changes on frontend and backend
...
OBS:. This test was done, mocking de the codes and apis APIs responses, using apollo studio
...
Code Block |
---|
{ "data": { "loyaltyValidatePromoCode": { "code": "8B9IKPQK", "configId": "7bf2c11c-ec68-4d44-abd3-597b3967fcef", "isRedeemed": true, "isValid": true, "message": "", "personalizedOfferId": null, "reason": null, "shouldRedeem": null } } } |
How to calculate the discount value
Send the offer sanityId to Winrest
They will register these
sanityId
on their system, and after that, we’ll use some offers with thesesanityId
registered, and Winrest will return the calculated offers correctlyWe already sent the
sanityId
offer to the backend (intl-partners-service
)
When the
intl-partners-service
calls the Winrest API, the integration will know how much will be the discountThe discount is always on the total value of the cart
...
How to configure a promotional code
For To show the feature on checkout:
Enable feature flag:
ENABLE_PROMO_CODE_AT_CHECKOUT = 'enablePromoCodeAtCheckout'
After configure configuring sanity:
To create the promotional codes, we need to access from Voucherify, this vendor is used current by PLK ES in production to create another other promo codes on offers page;
...