Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
stylenone

...

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.

...

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

  1. Rule

...

  1. 1 - First Order Physical Payment

...

  1. Limit

...

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.

  1. Create feature flag for this limit

  2. Evaluate when creating PaymetMethods

...

  1. Status
    colourBlue
    titleReady for dev

  2. Rule 2 - Physical Payment Amount Limit

    Status
    colour

...

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
    serverSystem Jira
    serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
    keyIREQ-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

    Blue
    title

...

  1. Ready for dev

  2. Rule 3 - Repeated Delivery Failure Limitation

    Status
    colourRed
    titleBLOCKED