🛠️ Potential Solutions

Option 1: Use Sanity for payment methods configurations

Pros

• This is the standard tool for Fz’s (market) configuration persona

• Sanity is deployed for every Fz (market) in RBI

Cons

• Operations team doesn’t have access to Sanity.

  • Possibilities:

    • New sanity access roles for the operations team

    • Operations team would require Fz’s configurators to update it if necessary

• For Restaurant configuration level, it should be done one by one (despite that it can be added a new configuration to do for all restaurants at once).

• It’s not possible to do these configurations for the offline payment methods.

Option 2: Use DOP for payment methods configurations

Pros

• This is the tool used by the Operations team. If we use this one, they don’t need to learn and to get access to use another tool.

• This tool supports the configurations for offline payment methods (mainly for terminal machine at home and cash).

• Possibility to do these configurations at restaurant level. But it can also be extended to edit for multiple restaurants, just as "Cash Limitation feature".

• It’s possible to do the configurations on DOP and create a “view only” version on Sanity. Then WL can query this information.

Cons

• DOP is used only by Iberia and Germany. This solution will only impact these markets.

✅ Proposed Solution

Go with Option 2, as it enables better flexibility.

Add Payment Methods List on DOP

We need to implement offline payment methods (such as vouchers, cash, etc.) in the DOP, allowing users to choose which ones they want to temporarily disable for a specific restaurant.

Currently, the only place that manages which payment methods are available by market and brand is in the Front-end (Whitelabel). However, we cannot retrieve this information from the Whitelabel. Therefore, we need to prioritize solving this issue. The solution options we have are:

Option 1 - Payment Methods List in Sanity

We Recommend this Solution

After receiving feedback from the Menu team (Rafael Souza, Eduardo Yosida, and Lucas Palencia) and the Transactions team (Felipe Rooke), we have concluded that this solution is the best option at this time.

In this solution, we will create a new document for the list of payment methods. The DOP already has synchronization with Sanity, allowing it to access this information and determine which methods will be active or inactive. This way, the restaurant will have its payment methods organized by market and brand.

Note: This new screen will provide only the payment methods, the state of each payment method is managed in the DOP, and afterwards, the storage is done in the Sanity Restaurant Document.

Pros:

• Sanity is divided by market, brand, and region, allowing control over payment types by market;

• No coding is required when adding a new payment method, just include the information on Sanity;

• Only DOP manage the status of payment

Cons:

• Access will not be limited to the technical audience, allowing other users to add methods without difficulty;

• When adding a new payment method in the WLapp, we also need to register it in Sanity.

• The Transactions team is currently working on an improvement to get the payment method for a service, so this screen may be deprecated in the future.

Solution Option 1

In this solution, we need to implement new screens in Sanity to manage payment methods.

In the restaurant menu, we will create a new screen called “Payment Method,” where we can add, remove, or edit the payment methods that will be displayed in the DOP. It is important to note that on this Sanity page, we can only add the payment list, we don't save the state of these payment methods on this page.

Note: The design team has not created these screens yet, this is just a sketch

Field and Details	Screen on Sanity
The new screen in the Restaurant Menu. In this screen we can add, remove and edit the payment method
Screen where we can add new payment
Title of Payment (name) - Payment title, we will use this title to save the status within documents restaurant for identification
Payment method brand (paymentMethodBrand) - a string key that must match the one in WL_app. We will use this value to ensure consistent validation in the front-end. Example: “CASH“, “SODEXO_VOUCHER“, “PAYMENT_ON_DELIVERY_CARD”

Process to Retrieve Payment Methods in DOP.

In the GQL back-end, we will create a utility to retrieve this information for Sanity. In the future, when we are able to access the payment method list from the back-end service, we will need to develop a new utility to fetch this information. We can use the same structure, which will lead to fewer changes and less refactoring.

Data example that will return of Sanity - PaymentMethod

"paymentMethods": [
  {
    "name": "Cash",
    "paymentMethodBrand": "CASH"
  },
  {
    "name": "Sodexo Voucher",
    "paymentMethodBrand": "SODEXO_VOUCHER"
  },
  {
    "name": "Ticket Restaurant Voucher",
    "paymentMethodBrand": "TICKET_RESTAURANT_VOUCHER"
  }
];

Option 2 - Centralize Payment Methods in the Back-end

Change the source from which the application retrieves payment methods. Currently, this information is fetched from the front-end (Whitelabel). By moving this responsibility to a back-end service, we will be able to access this information from anywhere, ensuring the maintenance of more consolidated payment methods.
Pros:

• All services that need to access payment methods can query the back-end service to obtain this information;

• A single source for payment methods;

• More consolidated application.

• Get Payment Method by brand and market

Cons:

• Significant change in the payment architecture;

• Much effort required;

• High complexity;

• The Transactions team is already working in this improvement.

Solution Option 2

In this solution, we will add all payment methods to a separate back-end repository, maybe in intl-payment-service or intl-packages. Additionally, we can create a new API to retrieve this information in any other service, such as the DOP.

Once the state of each payment method is selected, this information will be saved in the "Restaurant" document within Sanity.

Basically, we will retrieve the payment file in the front-end (WL-app) and transfer it to the back-end:
workspaces/frontend/src/state/payment/constants.ts

We will need to move all feature flags related to payment methods from the front-end to the back-end.

The Transaction Team is currently working on this, but they will need more time to complete it (approximately 3 to 4 months).

Option 3 - Payment Methods Hard Code on DOP

Pros:

• Fast development;

• Simple solution;

Cons:

• we don't have separation by market;

• All payment method are presented to all markets;

• When added new market in WL-app, need to add in DOP as well;

Solution Option 3

In this solution, we will add all offline payment methods directly to the DOP source code. The display of these payment methods will be implemented for all markets, even if a specific market does not have any available payment method.

Once the status of each payment method is selected, this information will be saved in the "Restaurant" document within Sanity.

Note: If the user marks a nonexistent payment method for a market as true, it will not be displayed on the whitelabel screen.

Example of data to show payment method:

"paymentsMethod": [
  {
    "name": "Cash",
    "keyLokalise": "paymentMethods.cash",
    "paymentMethodBrand": "CASH",
    "onlinePayment": false
  },
  {
    "name": "Sodexo Voucher",
    "keyLokalise": "paymentMethods.sodexoVoucher",
    "paymentMethodBrand": "SODEXO_VOUCHER",
    "onlinePayment": false
  },
  {
    "name": "Ticket Restaurant Voucher",
    "keyLokalise": "paymentMethods.ticketRestaurantVoucher",
    "paymentMethodBrand": "TICKET_RESTAURANT_VOUCHER",
    "onlinePayment": false
  }
];

• paymentsMethod List:

  • name: a string used for easy identification of the payment method, and we can use this name to show on Sanity.

  • keyLokalise: a string that may contain a key from Lokalise.

  • paymentMethodBrand: a string key that must match the one in WL_app. We will use this value to ensure consistent validation in the front-end.

  • onlinePayment: A boolean value to choose if the payment method is online or offline. In the first momento we’ll use just offline payment.

Solution 4 - Payment Methods List in Secrets

In this solution, we would create a Secrets for each market, where each secret would include only the payment methods available for that market. The DOP would use these payment methods as a basis to identify which ones are available and determine which are active or inactive. When saving this information, it would be sent to Sanity, where each payment method would be recorded.

Pros:

• Access restricted to the technical team;

• With secrets, we can control payment methods by market and brand;

• No new coding would be required each time a new payment method is added, just include the key in Lokalaise for DOP.

Cons:

• When adding a new payment method in the WLapp, we also need to include it in the Secrets;

• Need add the secrets for each stage (dev, stg, qa, prod);

• Need to add this secrets in intl-packages/secrets

• The Transactions team is currently working on an improvement to get the payment method for a service, so this secrets may be deprecated in the future.

Solution Option 4

In this solution, we intend to implement a secrets, which will include variations tailored for each market.

These Secrets will have the following format:
Need to create this definition on packages/secrets/src/definitions

{
  "pk": {
    "S": "rbi/dev/plk/es/payment-method"
  },
  "sk": {
    "S": "current"
  },
  "createdAt": {
    "S": "2024-10-23T12:23:35.389Z"
  },
  "description": {
    "S": "Secrets for the payment method in DOP FZ-Portal."
  },
  "updatedAt": {
    "S": "2024-10-23T12:23:35.389Z"
  },
  "value": {
    "S": "paymentMethods": [
      {
        "name": "Cash",
        "paymentMethodBrand": "CASH",
        "onlinePayment": false
      },
      {
        "name": "Sodexo Voucher",
        "paymentMethodBrand": "SODEXO_VOUCHER",
        "onlinePayment": false
      }
    ]
  }
}

• Payments Methods List:

  • name: a string used for easy identification of the payment method, and we can use this name to show on Sanity.

  • paymentMethodBrand: a string key that must match the one in WL_app. We will use this value to ensure consistent validation in the front-end.

  • onlinePayment: A boolean value to determine whether the payment method is online or offline. Initially, we will only use offline payment.

Store Payment Methods with Their States in Sanity

In this section, we will explain how we will display this information in the DOP and how we will save the state of each payment method. All the solutions outlined above will use this approach to save the payment methods along with their states in Sanity.

This information will be stored in the Restaurant Document in Sanity, as each restaurant can have its own payment methods with their respective states. Therefore, the best location to save this information is within this Sanity Document.

How will we display the payment methods along with their states?
When we access the DOP on the Payment Methods screen, two queries will be executed:

1. Retrieve the payment methods from Sanity in Payment Method;

2. Retrieve the payment methods and their states from Sanity in the Restaurant Document.

If the restaurant has not yet configured the payment methods, we will display the screen as follows:

Since the values have not been configured yet, they do not exist in Sanity on Restaurant Document. Therefore, only the values from the Payment Method of Sanity will be displayed, with the states set to undefined.

When the user makes any changes and selects the active and inactive payment methods, the system will save this information in Sanity, into the Restaurant Document like Cash Limitation.

DOP	SANITY

The data we will save in Sanity in the Restaurant Document will be in this format:

{
  "paymentMethods": [
    {
      "name": "Cash",
      "state": true,
      "paymentMethodBrand": "CASH",
      "onlinePayment": false
    },
    {
      "name": "Sodexo Voucher",
      "state": true,
      "paymentMethodBrand": "SODEXO_VOUCHER",
      "onlinePayment": false
    }
  ]
}

Once the configuration is set for the restaurant, every time the DOP opens the payment methods screen, it will perform the two queries again:

1. Retrieve the payment methods from Sanity in Payment Method;

2. Retrieve the payment methods and their states from Sanity in the Restaurant Document.

Now, the Sanity query will provide the status of each payment method, allowing the user to know which are active or inactive and make new modifications.

Note: On Sanity the Restaurant Document will only display this information for viewing purposes, it will not be possible to change these values or statuses through Sanity, only via the DOP.

Create the fields in Sanity alongside Cash Limitation and present the payment methods and their respective statuses. The file is schemas/menu/documents/restaurant.tsx.

How the Whitelabel-app get this Information

intl-packages

We will create a new attribute in IBaseRestaurant in the file packages/sanity/src/restaurant/restaurant.ts.

The name of this attribute can be paymentMethod and it is an object:

export interface IPaymentMethod {
  name?: string
  state?: boolean
  paymentMethodBrand?: string
  onlinePayment: boolean
}

export interface IBaseRestaurant {
  ...
  paymentMethod?: IPaymentMethod[];
  ...
}

After this, we need to run the Sanity generate into the Sanity package.

And now the function listBySearchParams get this information on Sanity.

Create the paymentMethod on GraphQL Flow

intl-whitelabel-graphql

Create a new attribute in RestaurantNode in the file src/functions/graphql/schemas/restaurant.gql

type PaymentMethod {
  name: string
  state: boolean
  paymentMethodBrand: string
  onlinePayment: boolean
}

type RestaurantNode implements Node {
...
  paymentMethod: [PaymentMethod]
...
}

Run graphql:types to create the file “generated”.

Create the paymentMethod on Gateway Flow

We need to insert the new atribute paymentMethod in RestaurantNode type on GraphQL.

type PaymentMethod {
  name: string
  state: boolean
  paymentMethodBrand: string
  onlinePayment: boolean
}

type RestaurantNode implements Node {
...
  paymentMethod: [PaymentMethod]
...
}

1. Create this new field on Types in intl-fulfillment-servive, intl-delivery-service, intl-store-service

2. We need to insert this field with @inaccessible directive documentation

3. Only after this new field with @inaccessible be deployed in PROD we can start the integration between GraphQL (gateway) and WL-app (Front)

4. remove @innaccessible directive and to make the integration of GraphQL

Note:
If we don’t insert the @inaccessible directive in PROD we can’t make the integration with front, and if we don’t use the @inaccessible, this will cause breaking changes on GraphQL and will block the pipelines.

intl-whitelabel-app

We can get this information on DeliveryRestaurant Query.

This query provides the information for the selected restaurant. Therefore, at the time of the order, we can access this information and validate the offline payments that are disabled for the restaurant.

Create a new hook to payments methods and call this hook on workspaces/frontend/src/pages/cart/payment/order-payment/paycomet-hosted-page-payment/paycomet-hosted-page-payment.tsx.

This file contains the list of payment methods, and we can use this list to compare it with the new payment list of restaurants.

To compare these payment methods, we will use the field paymentMethodBrand and onlinePayment in the first moment we’ll use only onlinePayment: false therefore only to offline payment.

Note:

The source of truth will always be the Whitelabel. If a payment method exists only in Sanity, the Whitelabel will not display it, as the payment method must be registered in the Whitelabel.

Change Checkbox Components

Before:

After:

We can use the EditorAvailability component
workspaces/frontend/src/pages/editor/editor-grid/EditorAvailability.tsx

An example:

And the setState we need to change as well, like this:

This way allow we can change to 3 status, true, false and neutral:

False	True	Neutral
Remove the value or change to 0 the value of cash limitation	Allow we can put a value for cash limitation	Ignore the field, nothing will be changed, this behavior only happens when we choose more than one restaurant

Payment Methods Schedule

In DOP, a possible solution would be to program how long the payment can be disabled.

This Date component already exist on DOP.

Component:

<DateFilter/>

workspaces/frontend/src/pages/delivery/history/filters/OrderHistoryFilters.styled.ts

Sugestion:

Change the location of this component to a more generic location.

Figma file

Potential Challenges

💰 Cost

🎛️ Configuration

• A new feature flag enable-payment-method in Whitelabel-app and DOP

📈 Metrics

🗓️ Delivery Plan

🧑‍🚒 QA Plan

⚠️ Call-outs

Which screen will the user be able to make these changes?

Users can make changes on the "Edit Payment Methods" screen located in the Restaurants tab. This screen is the same one used for Cash Limitation, so users with access to Cash Limitation will also be able to access the offline payment methods list.

If we add a new payment method only in the DOP, will it appear in the WL-app?

No, the new payment method will not appear. This request is solely for controlling the display of already existing offline payment methods.

If we configure the DOP to allow the SODEXO payment method, but we disable the flag for that payment in the WL-app, will it be displayed?

No, it will not be displayed, as the Whitelabel has greater control in this case.

Can I make changes directly in Sanity for the saved payment methods in the Restaurant Document?

No, editing must be done exclusively through the DOP.

Why will we save the payment status in Sanity?

Because Sanity is the true source of restaurant information. All details about the restaurant are stored in this document, so we will maintain this standard.