| Table of Contents | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
⏮️ Context
| Info |
|---|
What is the context and status quo of the opportunity |
With a 45% market share of e-commerce transactions (SIBS), MB WAY is the leading mobile wallet in Portugal. It allows users to make purchases, transfer money, and manage their finances using a smartphone app. To pay online, customers select the MB WAY logo and enter their mobile phone number. They then validate the purchase on their device by entering their MB WAY PIN or TouchID.
Developed by SIBS Multibanco, its consumer base consists of over 3.5 million individuals who make 9 million purchases each month. MB WAY wallet is supported by 28 banks, providing 95% market coverage — all their customers can use it, and consumers can store up to eight bank cards in their MB WAY wallets.
According to SIBS:
94% of MB WAY users always pay with MB Way.
MB WAY is especially appealing to the younger market, 57% of young adults use it for e-commerce purchases.
MB WAY offers the same level of payment security as credit cards and 47% of the Portuguese population use merchants that accept the payment method.
Source of information: https://support.monei.com/hc/en-us/articles/17507434930705-What-is-MB-WAY
Paycomet documentation: https://docs.paycomet.com/en/recursos/espec/mbway
🎯 Problem Statement
| Info |
|---|
Summary on the opportunity main findings and what is going to be addressed |
As this is the leading mobile wallet in Portugal, it’s crucial for BK PT to allow to use this payment method, improving the customer experience and ultimately, it can help increasing conversion.
❔ Expected Outcome
| Info |
|---|
What are the goals the opportunity is going to address |
Design solution: https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=40558-3573&t=dsReC3EQqW10hRCT-0
Happy path
Enable this new payment method for BK PT.
Customer flow:
On WL web/ app:
The customer chooses MB WAY at checkout and enters their mobile number ( the customer will always have to introduce the mobile phone; this won’t be saved from previous transactions)
On MB Way app:
The customer receives a payment request notification on their mobile device.
The customer selects their payment card and accepts the payment.
The customer enters their PIN to authorize the payment.
A "Payment authorized" message appears on their mobile device.
On WL web/app:
The payment is confirmed on the website.
Map the payment events to include this payment method
This payment method should be the second one dropdown list of available payment methods for this market. MB WAY should show up right after the credit card option.
Edge Cases
SituationWrong shared phone number cases
Use case | Expected outcome | Flows |
|---|---|---|
The |
number isn’t registered on MBWAY, so the customer doesn’t receive the payment request on MBWAY app. | The customer gets an error message that the payment didn’t go through |
If the customer goes to order history details, the order will be there and the status is canceled.
The customer shared a wrong phone number
and theand this will be a generic error. Notes:
|
| |
The number is registered on MBWAY, and the owner of this number refuses or do not accept the payment on MB WAY. | The customer gets an error message that the payment didn’t go through and this will be a generic error. |
|
The number is registered on MBWAY, and the owner of this number accepts the payment on MB WAY. Notes: in this case the phone number may belong to someone that will pay the order on behalf of the customer and it works. | The order will be placed. In this case, this is considered a “happy path”, because the order is completed. |
The customer shared a wrong phone number
and the number is registered on MBWAY, and the owner of this number refuses or do not accept the payment on MB WAY.
The customer gets an error message that the payment didn’t go through due to wrong phone number.
If the customer goes to order history details, the order will be there and the status is canceled.
|
App minimized use cases (app in background without closing)
Use case | Expected outcome | Flows |
|---|---|---|
The customer refuses the payment on MBWAY app. | When the customer goes back to WL app, they’ll receive an error message informing that the order was canceled. |
| |
The customer forgets / do not accept the payment on MBWAY app | When the customer goes back to WL app, they’ll receive an error message informing that the payment was refused and the order was canceled. |
If the customer goes to order history details, the order will be there and the status is canceled.
The customer closes the WL app while the payment is being processed, and:
the customerApp closed during payment being process and goes back to the WL App cases
Use case | Expected outcome | Flows |
|---|---|---|
The customer completed the payment and goes back to WL app. | The customer goes back to the main page. |
The customer can follow the status of the order using order tracking. If the customer goes to order history details, the order will be there and the status is completed. The cart will be empty. |
The customer closes the WL app while the payment is being processed, and:
the(TBC if it’s possible to do this) Note: this is the same behavior as any other orders nowadays. Don’t require additional developments. |
|
The customer refuses the payment or the payment timeframe expired and the customer goes back to WL app. | The customer goes back to the main page. There is no details about this order. |
If the customer goes to order history details, the order will be there and the status is canceled.
The cart will keep the same items as the previous order, if the customer wants to try again. |
The customer closes the WL app while the payment is being processed, and:
theThe items will be kept in the cart during 20 min (same behavior as nowadays). Notes: We won’t change the order history details to show this order. This is a current limitation and we won’t change the behavior of order history to show more details about this order that wasn’t placed. If, in the future, we understand that this is a relevant issue, this can be evaluated as an additional milestone. If this is added, we shouldn’t call these as “cancelled orders”, but a different naming. The best naming TBD. |
|
The customer didn’t accept the payment yet, but it’s still within the timeframe, so the payment is being processed, and the customer goes back to WL app. |
|
If the customer goes to order history details, the order will be there and the status is pending payment.
The cart will keep the same items as the previous order, if the customer wants to try again.
The customer will get an error message informing that the order is being duplicated (existing feature)
When the customer opens the app, will be redirected automatically to the waiting payment page. This way, the customer knows that the order is still pending and they have to either pay it or cancel it on the MBWAY app.
The customer won’t be able to place a new order without taking an action on the current one. This way, we avoid the duplicated orders scenario.
|
|
Sources of information:
https://support.monei.com/hc/en-us/articles/17507605624465-How-do-MB-WAY-payments-work-for-consumers
📈 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 |
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
[Document here the main insights from what the competition is doing if applicable]
Examples from other apps:
Too Good to Go (food delivery service)
Woo (telcom company)
Wells ( pharmacy website)
