Page Comparison

Considerations

1. Platform wide change, this should work on every market;

2. This should only affect delivery orders only.

Identify Payment Methods as Online or Physical Payment

We should identify on both Frontend (WhitelabelApp) and in the backend (Payment Service). The main implementation and first barrier should be the frontend (hidding the Physical Payments from the payment methods dropdown). In other hand, the backend should grant that, even somehow the Frontend allow the Physical Payment, it will be blocked.

Frontend: Add onlinePayment at Payment Method Interface

1. Add a new property called onlinePayment at this interface

2. Update the constants that implement this interface adding the onlinePayment method here, the configuration should be:

3. Create a new method to verify if a payment type is online or not. This method should grant that cash will always be considered false regardless the configuration. (as you can see, there’s no configuration for cash in the table above, that represents the state/payment/constats.ts file)

Creating Editable Configurations

Sanity Option

We can create a new field on Sanity that will map the available payment methods with the flag TRUE or FALSE for isOnlinePayment question.

Prós: Sanity fits better to hold a remote configuration, possible to retrieve this config in the backend

Cons: Strange memory cache and/or CDN cache, not reliable to replicate configs in real time

Feature Flag Option

We should create a new Feature Flag on Launch Darkly with the following definitions:

Pros: Good place to serve realtime configuration/variations

Cons: Not the correct place to hold configurations, this is more like a remote config then a Feature Flag.

Feature Flag creation (suggestion):

Name: physical-payments-limitation

Description:
This flag enable the Physical Payment Limitation, to avoid joke/fake orders on delivery. It intends to allow online-only payments on certain conditions, the implemented rules are below (please update this description when creating new rules):

• First Order Limit (limit_first_order) → Limit every first order of our guests in our platform, equal or greater then a given amount, to be online paid only.

• Total Amount Limit (limit_total_amount) → Limit every order greater or equal then a given {amount} to be online paid only.

• Last Delivery Failed (limit_last_delivery_failed) → When the previous delivery order failed, the subsequent one should be paid online only

Variation Value:

{
  "limit_first_order": {
    "active": true,
    "amount": 20,
    "amount_in_cents": 2000
  },
  "limit_total_amount": {
    "active": true,
    "amount": 50,
    "amount_in_cents": 5000
  },
  "limit_last_delivery_failed": {
    "active": false,
    "reasons_to_limit": {
      "customer_absence": true,
      "reason2": false,
      "reason3": true
    }
  }
}

Variation option to consider payment methods

In case we need to map the physical payment methods in a configurable way

{
  "payment_methods": {
    "cash": false,
    "cc": true,
    "debit_online": true
  },
  "rules": {
    "limit_first_order": {
      "active": true,
      "amount": 20,
      "amount_in_cents": 2000
    },
    "limit_total_amount": {
      "active": true,
      "amount": 50,
      "amount_in_cents": 5000
    },
    "limit_last_delivery_failed": {
      "active": false,
      "reasons_to_limit": {
        "customer_absence": true,
        "reason2": false,
        "reason3": true
      }
    }
  }
}

Frontend Preparation

1. Frontend Preparation Changes

   Status
   colour Blue title Ready for dev

Rules Implementation

1. Rule 1 - First Order Physical Payment Limit

   For the first order with a value >= X €, only online payment will be allowed, where X is configurable. The initial intention is to set it to 20 €.

   Questions:

   • How can we identify the first order of a user? Is there any mechanism in place?

   Solution

   We can get advantage of gateway query getUserOrders, this query returns all orders from the logged user with a count. We query this when the browser loads the payment method screen. This is the response:

   Image Removed

   ^{New user without any order.}

   When this count is 0, we don’t show Physical Payments.

   Status
   colour Blue title Ready for dev

2. Rule 2 - Physical Payment Amount Limit

3. Create feature flag for this limit

4. Evaluate when creating PaymetMethods

   For subsequent orders with a value >= X €, only online payment will be allowed, where X is configurable. The initial intention is to set it to 50 euros.

   Solution:

   We already have a cash payment limit, but it’s only for cash. We should create a new flag to all Physical Payments and verify before we show the payment methods dropdown to our customer, removing all physical payment.

   Status
   colour Blue title Ready for dev

5. Rule 3 - Repeated Delivery Failure Limitation

If the last order was paid in Physical Payments and there was a delivery failure (e.g. a joke order), the next order will only allow online payment

• The tablet expeditor app has some order cancellations actions, these actions are sent through Delivery Events API but they are not stored in any of our databases.

• We believe this ticket can potentially unblock us, to get the correct reason a delivery have failed:

  Jira Legacy
  server System Jira serverId 255417eb-03fa-3e2f-a6ba-05d325fec50d key IREQ-1123

  , it’s currently at “To Do” status

Once we have the correct reason of order or delivery cancelations stored in the backend we’ll be able to identify, in the cash limitations methods, if the last delivery failed for some of the reasons we want and remove Physical Payments.

To dos:

1. Get together the cancelation reasons we want to consider for this rule

2. Create the feature flag for this rule

3. Implement on Cash Limitations check this rule

   Status
   colour Red title

...

1. BLOCKED

Backend Restrictions

1. Possible Future Improvements