...

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:

...

{
    "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 attributecognitoId 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:

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

...

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 (POC)

• OBS:. This test was done, mocking de the codes and apis APIs responses, using apollo studio

...

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:

  • https://rbictg.atlassian.net/wiki/spaces/COG/pages/3445949068/Offers#Rulesets

  • Systemwide Offers

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;

...