Tech Discovery - Cash Limitation

Considerations:

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

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:

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:

^{New user without any order.}

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

Rule 2 - Physical Payment Amount 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 extend this flag to all Physical Payments and verify before we show the payment methods dropdown to our customer, removing all physical payment. To achieve that we should not change the current implementation but implement our own.

1. Create feature flag for this limit

2. Evaluate when creating iPaymetMethods

Rule 3 - Repeated Delivery Failure

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

• Need to check with Helio if we have this information from DMP/Partners.