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 fisical).

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, so we need to create a way for the user to change these to one or many restaurants.
These rules are:

• Rule 1 - In first buy of user, the value to user can pay with physical payments will have a limitation, e.g. $30.00

• Rule 2 - In second or more buy of user, the value to user can pay with physical payments will have a limitation, e.g. $50.00;

• Rule 3 - 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 motives:

    • Wrong address

    • Customer was not there

    • Fake order

    • Problems with payment

UX Proposal

Tech Discovery

Flow Home Delivery

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

Notice that package makes a query to DynamoDB, we can use the same logic to get the limitation rules of restaurant.

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

To do this, we simply need to add the data control logic in intl-packages/package/sanity and import this package into DOP. This allows us to centralize restaurant information in just one place (Sanity), making the implementation simpler.

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

• Create a store-service SDK in DOP repository, and the DOP uses these function to persist on DynamoDB

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.