...
| Table of Contents | ||
|---|---|---|
|
Considerations
...
...
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.
This should only affect delivery orders.
Frontend Preparation
Status colour Blue title Ready for dev
Rules Implementation
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.
Status colour Blue title Ready for dev 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.
Create feature flag for this limit
Evaluate when creating iPaymetMethods
Status colour Blue title Ready for dev
...
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
...
Status colour Red title BLOCKED