MB WAY

MB WAY is the Portuguese mobile payment app run by SIBS. The customer is identified by the mobile phone number linked to their MB WAY account. When you create a payment, the customer receives a push notification in the MB WAY app and approves the payment there. There is no hosted page and no browser redirection.

MB WAY supports:

• one-off payments (POST /rest/payment),
• authorisations that you capture or reverse later (POST /rest/authorize),
• full and partial refunds,
• MB WAY mandates: the customer approves a mandate once in the app, and you then charge it with recurring payments that need no further approval.

Available in	Networks	Currencies	Features	Integrations	payment_type
Portugal	MB WAY / SIBS	EUR	Payment Authorize Capture Refund Partial refund Recurring Reverse Register	Server-to-Server Checkout Page Pay by Link Payment Page Redirect	mbway

Payment workflow

The following diagram explains the MB WAY payment workflow for the Server-to-Server integration.

MB WAY — Server-to-Server

Scroll horizontally if the diagram is wider than your screen.

1. 1
   Payer (MB WAY app)→Merchant (Acceptor)

   1. Enters the phone number linked to MB WAY at checkout

2. 2
   Merchant (Acceptor)→OneAPI

   2. Create payment (Payment API, payment_type mbway + phone)

3. 3
   OneAPI→SIBS (MB WAY)

   3. Create the purchase and send the push to the customer's phone

4. 4
   OneAPI→Merchant (Acceptor)

   4. Response with status started (1)

5. 5
   SIBS (MB WAY)→Payer (MB WAY app)

   5. Push notification: approve the payment in the MB WAY app

6. 6
   Payer (MB WAY app)→SIBS (MB WAY)

   6. Approves (or rejects) in the app

7. 7
   SIBS (MB WAY)→OneAPI

   7. Payment result (notification)

8. i
   OneAPI

   Status changes to completed (3), or authorized (8) for an authorisation. A rejected or unanswered request ends as declined (6)

9. 8
   OneAPI→Merchant (Acceptor)

   8. Postback with the final status

10. 9
    Merchant (Acceptor)→Payer (MB WAY app)

    9. Shows final order confirmation

A payment moves through the following statuses. The Status Code column is the transaction's status code:

Status	Status Code	When
started	1	Payment created and the push sent to the customer's phone. Waiting for the customer to approve it in the app
completed	3	The customer approved the payment (POST /rest/payment), or an authorisation was captured
authorized	8	The customer approved an authorisation (POST /rest/authorize). Capture or reverse it later
reversed	12	An authorisation was reversed
declined	6	The customer rejected the request, did not answer it in time (about 4 minutes), or SIBS declined it (for example, the phone number has no MB WAY account). message carries SIBS's reason
canceled	5	SIBS reported the request as timed out
error	4	SIBS reported an error
refunded	7	There are partial or full refunds for this payment

note

The started status in the synchronous response is not the final result. The customer approves the payment in the MB WAY app, usually within a few minutes, and the final status is delivered by postback. Use the postback as the source of truth. If the customer does not answer within about 4 minutes, SIBS declines the request and the payment ends as declined.

A mandate created with the Mandate Reference API has its own lifecycle: pending (2) until the customer approves it in the app, then registered (9). See MB WAY mandates.

Integration options

Choose how you want to accept MB WAY:

Server-to-Server

Collect the customer's MB WAY phone number in your checkout and create the payment via the Payment API. The customer approves it in the MB WAY app; no redirect is needed.

Start integrating