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.

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.

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

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: {
  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
}
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:

Place all this control in intl-package/package/restaurant and import this package into DOP
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

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.

ADR Solution - Cash Limitation