Table of contents

Definition

Glossary

Physical Payments

Every payment that’s not done on through our platform. Some examples of Physical payments are
Examples: Cash, Ticket (paper) and Credit/Debit card machines. All other payments done by our platform is not considered physical payment.

Online Payments

All payment types done through our platform.
Examples: Credit Card, Apple Pay, Paypal, Bizum,

❓ Open questions

Requirements

Problem statement

Recent analyses have highlighted a significant risk of fraud in home delivery orders that are paid for using physical payment methods.

To safeguard our operations and protect both our business and customers from fraudulent activities, it is essential to implement additional rules that restrict the use of physical payments under certain scenarios.

Existent Cash Limitation Rules

Cash Payments Price Limit

This rule establishes a cap on cash transactions. Activation and deactivation are managed in a tool, which also adjusts the transaction limit, represented in cents.

Order Flood Limit

This rule set a limit on multiple orders for the same user, given a time. For example - how many orders the same guest can place in 1 hour.

Acceptance criteria

Physical payment methods should be hidden from the Payment Method dropdown on the Payment Method Screen. This adjustment occurs automatically and does not prompt any additional messages to the user.

The physical payment methods should not appear on the Payment Method dropdown, at Payment Method Screen, without any further message. In case of any of the rules are met we should show the Online payments only

If any pre-set conditions are triggered, only online payments options will be displayed to the user.

Success metrics

TBD

Objective 1: Reduce Incidences of Delivery Issues for Orders with Physical Payment

• Measurement: Percentage decrease in delivery-related issues for orders utilizing physical payment methods.

• Target: Establish a benchmark based on historical data and aim for a significant reduction.

Objective 2: Maintain Overall Order Conversion Rates Post-Implementation of Physical Payment Restrictions

• Measurement: Comparison of total order conversion rates before and after the implementation of physical payment restrictions.

• Target: Ensure that the imposition of restrictions on physical payments does not result in a significant adverse impact on total order conversions.

🤔 Assumptions

All error messages and texts related to this feature will be provided Iberia, . Dev team will only implement in English and the translation will be done later.

Solution

The plan is to map 3 To mitigate risks associated with physical payments limitations rules, given a configurable value per rule , we propose the introduction of three configurable limitation rules. These rules can be turned on/off on demand without app deployment.

Existent Cash Limitation Rules

Checkout Cash Payments Price Limit

This rule set a limit on cash payments. Based on a Launch Darkly flag, this flag controls if this rule is ON and OFF and also serves a variation of the amount, in cents.

Order Flood Limit

This rule set a limit on multiple orders for the same user, given a time. Based on a Launch Darkly flag, it controls if this rule is ON and OFF and also serves a variation of how many orders the same guest can place in 1 hour.

Proposed Physical Payments Limitation Rules

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

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€. This value is not cumulative, only the total amount of the current order should be considered. Example:
Guest adds 63€ to his/her cart. The platform remove all Physical Payments from the dropdown

Guest place one order of 30€ in the lunch, and another 35€ in the dinner. The platform removes all Physical Payment as the total ordered was greater than 50€.
Why this is invalid? We should consider only the total amount of the current order to this rule.

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 paymentare designed to be dynamically controlled, allowing for real-time adjustments based on operational needs.

Additionally, we plan to implement detailed logging and event tracking through DataDog and Amplitude. This integration will facilitate in-depth analysis of the rules' effectiveness, user behavior, and the overall impact on transaction security and user experience. Furthermore, we will empower individual restaurants to set specific, higher thresholds for physical payment limitations if they choose.

This added flexibility ensures that the system can accommodate the unique circumstances and risk profiles of different restaurants.

Rule 1: First Order Physical Payment Limit

• Description: New customers placing their first order with a value equal to or greater than a specified amount must use online payment methods.

• Configurable Value: The threshold value, initially set to 20€, can be adjusted as needed.

• Rationale: This rule aims to reduce the risk of non-payment for first-time orders.

Rule 2: Physical Payment Amount Limit for Subsequent Orders

• Description: For all orders following the first, physical payment methods will be disabled if the order value reaches or exceeds a certain threshold.

• Configurable Value: The limit is initially set to 50€, subject to modification. The evaluation is based solely on the current order's total amount, not cumulative purchases.

• Clarification: It's crucial to note that the limitation applies to individual orders, not the cumulative total of multiple orders within a certain timeframe. For instance, a single order of 63€ would disable physical payments, whereas separate orders of 30€ and 35€ would not, provided each is considered independently.

Rule 3: Repeated Delivery Failure

• Description: Following an order that utilized a physical payment method and resulted in a delivery failure, only online payment options will be available for the customer's next order.

• Rationale: This rule is intended to prevent recurring issues with physical paymentsafter a delivery failure, such as non-payment or fraudulent orders.

Follows the possible use-cases to be considered in the failure of rule 3.

Homeria Error use cases:

Image Added

DMP error use cases:

Image Added

Scenarios

Scenario 1: First Order Physical Payment Limit

Steps	Expected results
Make sure the flag configuration is ON done and 20€ is the limit Create a new user Add to cart >= 20 € items Select Delivery and click on Place Secure Order Try to select Cash, Paper ticket or Pay on delivery and click on Place Secure Order	Physical Payments should not be shown in the payment methods dropdown.

Scenario 2: Physical Payment Amount Limit

Steps	Expected results
Make sure the flag is ON and 50€ is the limit Login with a pre-existent user who has already placed orders Add to cart > 50 € items Select Delivery and click on Place Secure Order Try to select Cash, Paper ticket or Pay on delivery and click on Place Secure Order	Physical Payments should not be shown in the payment methods dropdown.

Scenario 3: Repeated Delivery Failure

Steps	Expected results
Make sure the flag is ON Login with a pre-existent user who has already placed orders Place a delivery order Fail the delivery order in partner Place a new order and try to select Cash, Paper ticket or Pay on delivery and click on Place Secure Order	Physical Payments should not be shown in the payment methods dropdown.

NoteStill need to define which “delivery failure” should be considered. Before that should be validated if the reason behind order cancelled is sent to WL

.

Design

N/A

Development

Release