Page Comparison

...

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.

Image Removed

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	Image Removed
Screen where we can add new payment	Image Removed
Title of Payment (name) - Payment title, we will use this title to save the status within documents restaurant for identification	Image Removed
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”	Image Removed

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.

...

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.

Image Added

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	Image Added
Screen where we can add new payment	Image Added
Title of Payment (name) - Payment title, we will use this title to save the status within documents restaurant for identification	Image Added
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”	Image Added

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"
  }
];

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.

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.

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

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.

Option 3 - Payment Methods Hard Code on DOP

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.

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:

...

...

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": "CashSodexo Voucher",
    "keyLokalise": "paymentMethods.cashsodexoVoucher",
    "paymentMethodBrand": "CASHSODEXO_VOUCHER",
    "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.

...

...

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

...

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.

...

  }
}

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

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.

Store Payment Methods with Their States in Sanity

...

...