⏮️ Context

https://rbictg.atlassian.net/servicedesk/customer/portal/53/IREQ-2301

It has been found that between the Payment and the Purchase steps in the funnel, Popeyes ES has scope for improvement in comparison with other markets (e.g.: Germany).

Popeyes ES abandonment rate is about the 11.8%

After analyzing the current flow (between the Payment and Purchase steps) and sync the findings in the Checkout discovered by the Fulfillment Team, our initial hypothesis of which could cause this rate were:

· Users may find unexpected and unclear errors when they are in the payment process.

· Users may feel that the actual payment process is slow.

· Users may feel that the actual payment process is complex.

🎯 Problem Statement

One of the errors that we have identified that could happen on the Payments page is when the payment is being processed:

When the user places the order (presses the button), the button state changes to a loading state, blocking the user to press it again. However, the rest of the page do not change or blocked, having the possibility to return to the previous step in the middle of the process (press X to close).

Permitting the user to go back during the payment process is a risk, because the payment process is an important step in which Payment and RBI platforms are involved. Their interruption leads to several errors, depending on when the user closes the page. Once the user comes back to the Checkout, these errors may occur:

• If the user presses the Continue button to place the same order again, the page informs the user that they have already placed the order (duplication) when it has not.

• The payment process was completed and registered as paid in Paycomet and the order was charged to the user, but the Order was not registered in RBI systems (DMP).

Important: Every time the user continues the purchase from the Checkout to the Payment page, a unique Transaction ID is created to track the order. So, if the user cancels the payment (eg.: selects Bizum but presses the “cancel” button), they return to the Checkout Page to create a new Transaction ID.

❔ Expected Outcome

Our goal is to avoid errors that may lead to high levels of frustration and a high volume of Customer Support incidences.

We think that blocking the user from closing the page while the transaction is being processed will reduce the volume of errors that might occur regarding orders.

📈 Success Metrics

❓ Open questions

• About Card User cases:

  • Card Data Verification:

    • When the user adds a new card, how does the Card Data Verification work? I mean, the happy path shows the users that they get both card and purchase confirmation done pressing the “Place Secure Order Button”, but I guess we’re doing two processes in the back. What’s going on behind? Does this process take long?

    • Can the Card Data Verification be interrupted (Go back) with no risks of generating future errors in the purchase?

• If a user tries to pay with a previously saved card but now it is not valid (has expired, is blocked by the bank, etc.), do we show a modal informing about the problem. After that, does the user must return to the Checkout to create a new Transaction ID or can they stay on the Order Payment Page (conserves the same Transaction ID)?

• If a card payment was not successfully processed, does the user have to return to the Checkout to create a new Transaction ID instead of staying in the Order Payment to select another Payment method?

• Paycomet Payment Verification Modal:

  • How does the Payment Verification modal layout work? Where does the user find the code they must enter to proceed?

  • Is any chance to adjust the Payment Verification modal layout?

• About Online/Mobile Payments Apps:

  • In the PayPal, Waylet, Apple and Bizum user cases in which an i-Frame (App) or a new window is opened (Desktop), if the user closes or cancels, where do they go? Do they must go to the Checkout page or can they stay on the Order Payment page?

• If a PayPal, Waylet, Apple or Bizum payment was not successfully processed, does the user have to return to the Checkout to create a new Transaction ID instead of staying in the Order Payment to select another Payment method?

• Is there any other platform to consider besides the Whitelabel-apps for this task?

Insights

1️⃣ Stakeholder Interviews

[Document here the main insights from interview if applicable]

2️⃣ Analytics

[Document here the main insights from analytics if applicable]

3️⃣ User Research

[Document here the main insights from research if applicable]

4️⃣ Competitor Landscape

We look into the competitors to find how they resolve the same problem and which solution they have implemented.

We identified 2 common patterns to block the user from going back during the payment process:

• Pattern 1: the loading state of the payment processing is displayed in a different page (loading page)

• Pattern 2: the loading state of the payment processing is displayed on the same page but blocking the whole screen (disabled state). We found two ways:

  • Loading icon and a black transparency mask covering all screen to indicate the user the screen is blocked (disabled) and they are not able to do any action:

• Loading icon and disabled state in all actionable elements: checkbox, buttons, etc., including the “Go Back” action:

5️⃣ Market analysis

We mapped the current behavior of the Close/Go Back action regarding the different payment methods in all markets. This previous analysis is important to ensure that the final solution covers all the markets needs and its singularities.

These are the markets current behavior (check it better on Figma): https://www.figma.com/design/wEeYkRHLwLdMJHKvQJOdd0/%5BIBFEC-1795%5D-Remove-Pre-filled-Name-On-Card-field?node-id=8800-22023&t=5jsIyQ5hjfO3p8nJ-4