Tech Discovery - Delivery Fees improvements

Front-end

Say we have the following order:

Open

With this improvements, we want to split the amount of the delivery fee into two fields:

• delivery fee and management fee.

Similar to what we have in the current app (airtouch):

Open

• gastos de envio → delivery fee

• otros gastos → management fee

FE tech discovery can be found here

Figma: https://www.figma.com/file/RtD0UFtwuwXx14lbLCAPlr/branch/4JKHiBl13JOyOqh88dSPkV/Burger-King?type=design&node-id=20699-1728&mode=design&t=AEfdHRE0DnQ6879D-0

Mapping of how delivery fee is set (BE):

• PriceOrder

  • Calls partner to get price related info including fees.

  • Persists fees into the database

• GetOrder

  • Retrieves order related info from the database, including fees

Backend discovery

• priceOrder

  • intl-whitelabel-app → priceOrder

  • intl-whitelabel-graphql → priceOrder

  • intl-fullfilment-service → priceOrder

    • updateDeliveryEntry

      • intl-delivery-service

      • getFeeAndDiscountByBrand ( using intl-packages delivery lib or intl-delivery-service?)

• Delivery fees are managed by the fee service ( intl-delivery-service):

  • getFeeAndDiscountByBrand

    • getFeeChargeByTier

      • It get the values from launchdarkly based on the service mode.

        • If catering , it uses tiered-catering-delivery-fees

        • Otherwise, it uses tiered-delivery-fees

      • Searches the tier list from highest to lowest key, stopping when requestedAmountCents exceeds that tier.

      • Said that, we can to analyze the following "return” to propose the management fee. Apart from that, looks like Launchdarkly existing configuration (variations) were thought to enable "free delivery” and we can leverage this approach.

         

        return { baseDeliveryFee: fee, --> LD fee deliverySurchargeFee, --> LD expandedFees (based on delivery quotation value) discount, --> LD discount fee: fee + geographicalFee + serviceFee + smallCartFee + deliverySurchargeFee, geographicalFee, --> LD geographicalFee serviceFee, --> Calculated with LD serviceFeePercent of the requested amount smallCartFee, --> LD smallCartFee };

         

• Going further in priceOrder (fulfillment), it reaches the applyQuote service

  • await this.quotesApi.applyQuote(applyQuoteParameters);

    • /api/v1/quotes/apply

  • intl-delivery-service

    • return this.service.enqueueApplyQuoteNotification(request); → SQS_APPLY_QUOTE_QUEUE_URL / SNS_QUOTE_TOPIC_ARN

• Here, the services are decoupled. Therefore, there is a lambda function that listens to the apply quote queue and handles it.

  • intl-delivery-service

    • on-apply-quote Lambda

    • return quoteService.applyQuote(message);

    • async applyQuote(request: ApplyQuoteRequestDto): Promise<ApplyQuoteResponseDto> {

    • getFees

As result, zeroed fees are being set. See cloud watch logs from lambda function.

*The quotedFee comes from partners. In Iberia, it comes from DMP, aka: intl-partners-delivery. But it depends on the market. DMP also uses launchdarkly to calculate the fee. It doesn’t get the other fees.

Once we get these fees (including the zeroed one), intl-delivery-service sends the result to

• SNS: dev-plk-delivery-quote-outcome

  • SQS: aws-rbi-dev-plk-apply-delivery-service-quote

    • Lambda: sls-rbi-dev-plk-orders-delivery-service-apply-quote ( intl-orders-service)

      • Which get the message and updates the current order in the database (dynamodb)

BE Proposal

• Enhance this lambda function (dev-plk-delivery-on-apply-quote) to not overwrite discount and service fees with zeroes. It should keep the value from launchdarkly.

• Configure launchdarkly to fit business needs enabling FE to show fees and discounts properly.

  • discount <> 0

  • serviceFee <> 0

  • fee <> 0

Proposal validation with transactions team:

https://rbidigital.slack.com/archives/C04D0V74P0D/p1702672116251489

FE impacts

When discount, fee and service fee come to FE, intl-whitelabel-app can be changed to display FREE fees as according to UX (figma). The design screens should be adapted to consider them accordingly. In such case, depending on the launchdarkly config ( fee tier), we may have a different value for fee, service and discount. In principle, to minimize BE impacts, we may continue using a single field for discount. It’s up to the FE display "FREE” for the related use-cases. E.g:

• discount == fee + servicefee

  • FREE fee

  • FREE service fee

• discount == fee, but discount < fee+servicefee

  • FREE fee

  • X.XX service fee

• discount < fee

  • X.XX fee

  • X.XX service fee

• Other configurations may not be supported

Feature control

As usual the activation of this feature should be done using LD feature flag in both FE and BE. Later it can leverage a new sanity config (toogle) under guest checkout.

Enhancements

• Since, in the future, we may have partners who calculates delivery fees not only based on LD, we can have an additional config for FREE delivery fee / FREE delivery service fee, where BE (intl-delivery-service) would override LD values - meaning that discount can be set with the same amount of the fee or fee + service fee.

Architecture

In partners service, create quote flow calls both in delivery : quote_create and quote_apply

Configured webhooks*:

Possible existing bugs

During this discovery, strange behaviors were detected. They are detailed here

Hints:

How to run local lambdas:

• Example:

  • yarn start:function on-apply-quote

A suggestion from trx team is to use partners-service repo as reference, where it shows also how to mock local events simulating (local queues). It ensures that you will be able that your lambda “consumer” will really read the event (and not the lambda that is AWS).