Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents
stylenone

Considerations

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

  2. This should 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:

...

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

Note

Alternative check sanity payment method sort feature, having this map in LD or Sanity we can retrieve in the backend to add extra layer

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

...

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

Code Block
{
  "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

Code Block
{
  "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
      }
    }
  }
}

Rules Implementation

Rule 1 - First Order Physical Payment Limit

...