...

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

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

...

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 save on Sanity and the WL-app get these values when choose the restaurant, so the WL-app can verify if allow or not the payment by physical method.

Summary the decision:

• Store this information in restaurant on Sanity;

  • Main local to store information about restaurant;

• Manipulate this information on DOP (FZ-portal);

  • The users can choose which rules they want to use;

  • The users can adjust the limit values to purchases in home delivery;

  • The users can make this to your restaurants;

  • The franchisees can change this information as well;

• WL-app control the exhibition of physical payments;

  • With rules, the WL-App can validate if some rule is active and if need to hide physical payments

Image Added

Consequences

• Create a new field in Restaurant Document on Sanity to receive this information;

• Create a new screen on DOP (FZ-Portal) to user can manipulate this information and to send to Sanity;

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

• Create a new logic on WL-App in payment page to control the exhibition of according the information and limitation that get of Restaurant;