Table of contents
Definition
Status | IN DESIGN |
RBIberia Owner | |
RBI Owner |
Glossary
Physical Payments
Every payment that’s not done through our platform.
Examples: Cash, Ticket (paper) and Credit/Debit card machines.
Online Payments
All payment types done through our platform.
Examples: Credit Card, Apple Pay, Paypal, Bizum,
❓ Open questions
We need to constantly make this section empty.
Questions
#1 What’s the expected behavior when our guest reach any of the rules? Example: Show a message, block the button COMPLETED
#2 Besides Datadog, should any metric be collected when any of the rules is triggered? Which ones? PENDING
#3 Can these 3 rules be implemented together or they can be turned on/off separately? COMPLETED
#4 We need confirmation that these rules are “global” in the platform or should be done by restaurant. PENDING
#5 What Delivery Failures Reasons should we consider to limit Physical Payments? PENDING
Answers
#1 - We don´t show the option to pay cash in the dropdown
#2 - Pending
#3 - Yes.
Number of first orders that exceeded the established maximum limit and average ticket orders in physical payment x online payments
Number of subsequent orders that exceeded the established maximum limit and average ticket orders in physical payment x online payments
Number of orders impacted by an incident in a previous order versus delivery success rate in orders with physical payment
Impact on order conversion due to physical payment restrictions
Cart abandonment rate due to physical payment restrictions
Add the rule applied to checkout in Amplitude
#4 - Implement a global rule, but allow you to configure exceptions to limits differentiated by restaurant. The objective is to allow franchises (non-RBI restaurants) to set higher cash order limits
#5 - Pending - I´ll try to solve this today (Paula)
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 through a Launch Darkly feature flag, 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. 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.
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.
If any pre-set conditions are triggered, only online payments options will be displayed to the user.
Success metrics
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, in English and the translation will be done later.
Solution
To mitigate risks associated with physical payments, we propose the introduction of three configurable limitation rules. These rules are designed to be dynamically controlled via LaunchDarkly, allowing for real-time adjustments based on operational needs.
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 payments after a delivery failure, such as non-payment or fraudulent orders.
Scenarios
Scenario 1: First Order Physical Payment Limit
Steps | Expected results |
|---|---|
|
|
Scenario 2: Physical Payment Amount Limit
Steps | Expected results |
|---|---|
|
|
Scenario 3: Repeated Delivery Failure
Steps | Expected results |
|---|---|
|
|
Still 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
0 Comments