Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Table of contents

Definition

Status

IN DESIGN

RBIberia Owner

Cunha, Ricardo (Deactivated) Raphael Ferreira Gomes

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 specific rules that restrict the use of physical payments under certain scenarios.

Acceptance criteria

The Physical Payment Methods (described above) 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.

Success metrics

TBD

  • Reduction of incidences of deliveries in orders with physical payment

  • Physical payment restrictions do not significantly impact total order conversion

🤔 Assumptions

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

Solution

The plan is to map 3 physical payments limitations rules, given a configurable value per rule . These rules can be turned on/off on demand through LaunchDarkly.

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:
(tick) Guest adds 63€ to his/her cart. The platform remove all Physical Payments from the dropdown

(error) 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 payment

Scenarios

Scenario 1: First Order Physical Payment Limit

Steps

Expected results

  • Make sure the flag is ON 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.

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

Development

Release

  • No labels