Page Comparison

...

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.

...

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

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

Detailed solutions

#We Prefer this Solution

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

...

Pk: restaurant#idstore 
Sk: idstore
Rules: {
  ruleOne: {
    flagRuleOneenabled: true, // Flag to active or desactive the rule
   ruleOne value: 50.00500 // rule value
  flagRuleTwo},
  ruleTwo: false{
// Flag to active orenabled: desactivefalse,
the rule   ruleTwovalue: 00100
// rule value}
  flagRuleThreeruleThree: //{
Flag to active or desactive the ruleenabled: false,
it doesn’t have}
other value
}
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.

...