Skip to content
Menu

PAYMENT GATEWAY

D.2.1 Recurring Payments – MBWAY Authorized Payments

MB WAY Authorized Payments allow merchants to charge a customer multiple times after the customer grants prior authorization within the MB WAY application.

In a recurring payment scenario, the customer explicitly authorizes the merchant to perform future charges. Once the authorization is granted, subsequent payments can be initiated by the merchant without requiring customer interaction for each transaction.

This model is commonly used in subscription services, memberships, installment plans, and recurring billing arrangements within the MB WAY ecosystem.

How It Works

In a typical MB WAY Authorized Payments flow:

  1. The merchant initiates an authorization request through the SIBS Payment Gateway.
  2. The customer provides their mobile phone number associated with MB WAY.
  3. An authorization request is sent to the customer’s MB WAY app.
  4. The customer approves the recurring authorization within the app.
  5. Upon approval, an authorization reference (mandate) is created.
  6. The merchant stores the authorization reference securely.
  7. Future recurring charges are initiated by the merchant using the stored authorization reference.
  8. Each recurring transaction is processed through the MB WAY network.
  9. The final transaction result is returned to the merchant system.

The customer interaction is required only during the authorization setup phase. Subsequent recurring charges are merchant-initiated.

Workflow Characteristics

The MB WAY Authorized Payments flow has the following characteristics:

  • Explicit customer consent during setup
  • Mobile-based authorization process
  • Authorization reference generation (mandate-based model)
  • Merchant-initiated recurring transactions
  • Immediate transaction response with subsequent status follow-up support
  • No repeated customer confirmation per transaction (after authorization)

Recurring authorizations may be subject to limits, expiration, or customer revocation.

Subsequent recurring collections are processed as Merchant Initiated Transactions (MITs), using the previously established authorization reference (mandate).

Transaction Lifecycle

The lifecycle of an MB WAY Authorized Payment typically includes:

  • Authorization request
  • Customer approval in MB WAY app
  • Authorization reference creation
  • Merchant-initiated recurring charge
  • Authorized and captured (successful)
  • Declined or revoked (if authorization is canceled or invalid)

If the customer revokes authorization or the mandate expires, further recurring charges will not succeed.

Use Cases

MB WAY Authorized Payments are commonly used in:

  • Subscription-based digital services
  • Membership platforms
  • Installment plans
  • Educational or institutional recurring fees
  • Donation and contribution programs

This payment method is particularly suited for environments where:

  • Customers prefer mobile-first payment experiences
  • Strong customer authentication is required during setup
  • Frictionless recurring payments are desired after initial consent
  • Recurring billing is limited to the Portuguese market

For webhook delivery behavior and asynchronous transaction notifications, refer to E.1 – Webhooks (Notifications).

For complete Status Inquiry endpoint specifications and response interpretation, refer to E.2 – Status Inquiry / Get Status.

Practical MB WAY Authorized Payment examples, recurring collection workflows, Postman collections, and operational testing scenarios are documented in F. Technical Examples and Best Practices.

The Sandbox Payment Simulator may also be used to validate MB WAY Authorized Payment mandate creation flows, customer authorization behavior, mandate lifecycle progression, recurring collection scenarios, and operational request/response payloads in the sandbox environment.

Example sandbox simulator entry point

Particularities in the SIBS Context

When working with MB WAY Authorized Payments in SIBS SPG, merchants should consider:

  • Customer approval is mandatory during authorization setup.
  • Recurring collections depend on a valid authorization reference (mandate).
  • Mandates may expire, be revoked by the customer, or become unavailable for operational reasons.
  • Each recurring collection is processed as an independent transaction and generates its own transaction lifecycle and status.
  • Operational reconciliation should correlate recurring collections with the originating authorization reference.
  • Proper monitoring and handling of failed recurring collections is essential to maintain service continuity.

Integration Context

Within the SIBS Payment Gateway, MB WAY Authorized Payments are implemented through:

  • An initial authorization request (customer approval required)
  • Authorization reference generation
  • Server-to-server merchant-initiated recurring transactions

Each recurring charge is processed independently and returns its own transaction status.

Merchants should implement proper handling for:

  • Authorization revocation
  • Authorization suspension
  • Authorization expiration
  • Failed recurring charges
  • Customer mandate cancellation scenarios

Merchants should implement operational monitoring capable of detecting authorization revocation, expiration, and collection failures before subsequent recurring billing attempts.

The following sections describe the technical integration flow, required parameters, authorization handling, and recurring charge execution for MB WAY Authorized Payments.

The SPG transactionID should be treated as the primary and authoritative identifier for transaction monitoring, recurring charge validation, webhook correlation, reconciliation, and status inquiry operations throughout the lifecycle of MB WAY Authorized Payments.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.