...
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).
Figma files with more details:
Popeyes ES abandonment rate is about the 11.8%
...
When the user places the order (presses the button), the button state changes to a loading state, blocking the user to press it again and. 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 the appearance of several errors, depending on when the user closes the page. Once the user come 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.
...
Important: Everytime 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.
...
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
| Info |
|---|
List here which are the metrics to look at to define success for the solution implemented. Use those KPIs to define the current status |
Importance | What do we want to measure? | Description | How are we measuring it? |
|---|---|---|---|
Primary metric | Number of errors produced while processing payment | We would like to decrease this number. Amplitude We expect to see a higher number of conversions. | Amplitude |
Primary Metric | Number of incidences in Customer Support related to Payments issues | We would like to decrease this number. | ?? |
❓ 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
...
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:
...
These are the markets current behavior (check it better on Figma): https://www.figma.com/design/wEeYkRHLwLdMJHKvQJOdd0Rh089bU2JWfFGo410sBngk/%5BIBFEC-1795%5D1796%5D-RemoveBlock-Preuser-filledfrom-Nameclosing-Onpayment-Card-fieldprocess?node-id=8800-22023&t=5jsIyQ5hjfO3p8nJ-48951-30454