Business Problem

The RBIberia relates that recent analyses have highlighted a significant risk of fraud in home delivery orders that are paid for using physical payment methods (Cash, terminal at home, voucher physical).

To safeguard our operations and protect both our business and customers from fraudulent activities, it is essential to implement additional rules that restrict the use of physical payments under certain scenarios. In these scenarios, there are some rules that can be controlled by the user can control, so we need to create a way for the user to change these rules to one or many restaurants.
These rules are:

• First buy order on Home Delivery - : In first buy of the user order, the value to the user can pay with physical payments will have a limitation, e.g. $30.00

• Buy on Home Delivery - : In the second or more buy of user order, the value to the user can pay with physical payments will have a limitation, e.g. $50.00;

• Prevent Repeat Failures - : In cases where the last order involved a physical payment method and was marked as a delivery failure, the next order from the same user will be restricted to only online payment methods.

  • Delivery failure motivesreasons:

    • Wrong address

    • Customer was not there

    • Fake order

    • Problems with payment

In case some of these rules are active, the WL-app must hide the physical payments (Cash, voucher, etc)to the user.

UX Proposal - Payment Method Section

Tech Discovery

Flow Home Delivery

Current flow the system gets the information of restaurant on Sanity and DynamoDB.

...

Solution Proposal

Why we use DOP and not use only the Sanity?

The Sanity is a good solution option, but it doesn't fully meet our needs, as RBI wants the restaurant to have more independence to adjust rules with desired limits. Additionally, only a few users have access to the Sanity tool, as it is more geared towards management level. In DOP, on the other hand, we have users within several restaurants, making configuration more practical and agile.

DOP (FZ-Portal) With Sanity - Better Solution

After a conversation with Pawel, we discovered that we can control this through Sanity, where we can add these rules to the restaurant document within Sanity and retrieve/modify this file in other services such as DOP.

Detailed solutions

1.ctg-fz-portal

#We Prefer this Solution

After a conversation with Pawel and Francisco, we resolved to create the Sanity-client Lib into the DOP service, this way is simpler and resolve our problem. Only DOP there are access to change this information, so we don’t have problems in this are into only DOP.

...

• Create a query to add new data of cash limitation in the sanity through DOP

• Add new data of rules of Cash Limitation in restaurant interface;

• Add this rules of cash limitation in the DOP service;

• Import the sanity-client in DOP

Another Solutions

These another solutions we didn’t choose, because it is not so good, there are many integrations and the development is more complex.

2.Intl-packages

...

Decision

We will create a new screen on DOP and the user can choose and manipulate the “rules” to one or many restaurants. This information will be saved on Sanity and the WL-app will get these values when the restaurant is chosen, so the WL-app can verify if it allows or doesn’t the payment by physical method.

Store this information in restaurant on Sanity

• 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
    

    Image Added

Manipulate this information on DOP (FZ-Portal)

To enhance the functionality of managing rules and purchase limits for home deliveries, a new page will be created containing all the relevant information. This page allows users to perform several important actions.

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.

This functionality is not limited to end users. Franchisees will also be able to access and modify this information, ensuring that all organizational levels can effectively manage their own settings.

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.

WL-app controls the exhibition of physical payments

On Home Delivery, the WL-App gets the information about the restaurant, and in this data, there are the values about cash limitation:

• Create all the logic for adding, updating, and removing cash limitation rules in the packages on Sanity Package;

• Add new data of rules of Cash Limitation in restaurant interface;

• Add this rules of cash limitation in the restaurant.tsx file on intl-whitelabel-cms repository;

• Import the intl-packages/sanity in DOP repository, and the DOP uses these function to persist on Sanity

Flow Delivery with physical payment limitation with SANITY

With this solution, the flow is the same.

...

DOP (FZ-Portal) With DynamoDB

Creation of a new page on DOP (FZ-Portal), where DOP user can edit these rules for each or many restaurants.

DOP inserts this information in DynamoDB and after the flow of delivery gets this information in the same flow above.

Example table structure:

Pk: restaurant#idstore 
Sk: idstore
Rules: {
  ruleOne: {
    enabled: true, // Flag to active or desactive the rule
    value: 500 // rule value
  },
  ruleTwo: {
    enabled: false,
    value: 100
  }
  ruleThree: {
    enabled: false,
  }
}
Date: datetime
User: userX

Detailed solutions

Our biggest question is what is the best way to achieve this integration.
It doesn't make sense for DOP to store this directly in DynamoDB, we believe that the best way is to use a service that will be in charge of manipulating this information.
For this, we have two options:

1. Place all this control in intl-package/package/restaurant and import this package into DOP

2. Add this control to intl-store-service and create an SDK for this service in DOP

1. Intl-packages

#We prefer this solution
We prefer this option because it is faster and simple in the development, and the query of list of restaurants is in this repository.

• Create all the logic for adding, updating, and removing cash limitation rules in the packages and inserting this into DynamoDB (creating a new table);

• Create a new table in DynamoDB - example {stage}-{brand}-cash-limitation;

• In the listByShearchParams function in the intl-packages, get this limitation and return with the restaurants.

• Import the intl-packages/restaurant in DOP repository, and the DOP uses these function to persist on DynamoDB

...

2. intl-store-service

...

Create all the logic for adding, updating, and removing cash limitation rules in the store-service and inserting this into DynamoDB (creating a new table);

...

Create a new table in DynamoDB - example {stage}-{brand}-cash-limitation;

...

In the listByShearchParams function in the intl-packages, get this limitation and return with the restaurants.

...

...

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

Flow Delivery with physical payment limitation with DYNAMODB

This is the Delivery flow with the query to get the physical payment limitation.

The example of return listBySearchParams query:

IRbiRestaurant {
  storeId: string
  available: boolean
  curbsideHours?: IHoursOfOperation
  …
  rules?: {
		flagRuleOne?: true // Flag to active or desactive the rule
		ruleOne?: 50.00 // rule value
		flagRuleTwo?: false // Flag to active or desactive the rule
		ruleTwo?: 00 // rule value
		flagRuleThree?: // Flag to active or desactive the rule, it doesn’t have other value
  }
  …
}

...

Conclusion

With any of these solutions, the user will have control over changing the rules to impose physical payment limitations on the delivery flow.
For both cases in the delivery flow, we intend to retrieve this information about the limit on intl-package in the listByShearchParams function, as this way we are sure that all restaurants close to the location will have this information.The system will validate all active rules. If any rule is violated, the payment methods will be limited to online payments only, such as credit card, PayPal, etc.

It is controlled through a hook called useCashLimitation in the following: filesrc/pages/cart/payment/order-payment/use-cash-limitation.ts.

This hook is invoked in the Paycomet Payment screen located at:: src/pages/cart/payment/order-payment/paycomet-hosted-page-payment/paycomet-hosted-page-payment.tsx

Image Added

Consequences

• Create new fields in Restaurant Document on Sanity to store Cash Limitation rules data;

• Create a new screen on DOP (FZ-Portal) so that user can manipulate Cash Limitation rules and store them on Sanity;

  • Use the Sanity Client Lib to get and save information on Sanity, this library is already available on DOP

• Create a new logic on WL-App in the payment page to control the exhibition according to the information and limitations that are got from Restaurant;