⏮️ Context

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

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

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

Edge Cases

Wrong 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 and this will be a generic error.

Notes:

no ability to differentiate errors.
the “waiting payment page” works as a loading page as well, to wait for the confirmation of success and errors from MBWAY.

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.

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.

App 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. (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.

The cart will keep the same items as the previous order, if the customer wants to try again. The 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.

~~The customer goes back to the main page.~~

~~There will be a new tracking banner, showing that the order is being processed and the payment is pending. For processing orders that link with the order details.~~

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.

~~If the customer completes a new purchase, it will go through and a duplicated order will be placed. The customer must complain to get refunded.~~

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.

Note: for this scenario, we will develop the re-use the tracking banner to consider the “order processing, payment pending” scenario. This will be created for MB WAY scenario, but can be re-used for other payment methods / markets.