Page Comparison

...

• Main local to store information about restaurant;

  • Added in restaurant the new type physicalPaymentMethodsLimitations

    • schemas/menu/documents/restaurant.tsx

    • schemas/menu/objects/physical-payment-limitations.tsx

• The information in Sanity is only read-only. Only DOP can change it.

...

• The interface to receive this information is IDeliverOrderAmountLimit

• This interface exists in many repositories:

  • intl-fulfillment-service

  • intl-whitelabel-graphql

  • intl-store-service

  • intl-packages

  • intl-whitelabel-app

  • intl-delivery-service
    

    

...

Firstly, it will be possible to establish specific access rules for this page, ensuring that only authorized users can view and modify the information. The access rules will be detailed in this reference.

Users will have the ability to decide which rules they want to apply to their transactions. Additionally, they will be able to adjust the limit values for purchases in home deliveries, providing greater flexibility and control over financial operations.

...

To assist users in using this new page and its functionalities, a detailed guide will be made available through in this link.

Finally, all information configured by users will be saved in Sanity, using the Sanity Client Library to connect DOP with Sanity. This will ensure that the data is stored securely and is accessible for future consultations and modifications.

...

Image Added

• The mutation that controls updates in Sanity is located at workspaces/graphql/src/schema/mutations/updateRestaurantCashLimitation.ts.

• The pages are controlled in workspaces/frontend/src/pages/payment-methods/index.ts.

...

...

...

• With cash limitation data, the WL-App can validate if some rule is active and if it needs to hide physical payments, following the order:

  • First order on Home Delivery: Verify if it is the user's first purchase in “home delivery” mode. To do this, perform a query using useGetUserOrdersQuery, which will return a counter indicating the number of orders in this service mode. If the counter is zero, validate if the purchase amount exceeds the maximum allowed value.

  • Prevent Repeat Failures: In the next rule, you should check if the user's last “home delivery” order was canceled. If it was canceled for any of the reasons mentioned above and the payment was made physically, this will constitute a violation of this rule, resulting in a change to the available payment methods.

  • Buy on Home Delivery: In this rule, we must first check if it is not the first “home delivery” order. To do this, we use the same query from the first rule (first delivery), but here we validate if the counter is greater than zero. Then, we check if the purchase amount exceeds the defined limit.

• More details about these rules, this control is by each user;

  • At the moment of payment, the WL-app retrieves information about the user's most recent delivery order using the getUserOrders function. This includes restaurant details and any applicable limitation rules. Based on this information, we need to implement logic that hides the physical payment option if any limitation is met.

    For example, if it is the user's first home delivery purchase, which we can determine if the getUserOrders query returns zero orders of this type, and the selected restaurant has a rule that the first purchase must not exceed $30.00 (as specified by the restaurant's information from Sanity), then the WL-app can check the current order value on this screen. If the order total cents exceeds the limit, the WL-app will hide the physical payment options.

    With all these details, the WL-app can effectively decide whether to display or hide the physical payment option.

...