When comparing payment providers in Portugal, start with what happens to the order while the customer is paying. A MULTIBANCO payment reference can remain unpaid after checkout. An MB WAY purchase asks the customer to approve a request in the app. These different journeys affect stock reservations, customer messages and the evidence your team needs before fulfilment.
The useful comparison connects each method to a complete business process: collect the payment, confirm the order, return money when necessary and reconcile what reaches the business account. EUR business payouts need their own qualification alongside that process.
A MULTIBANCO reference creates a payment opportunity
In the SIBS Payment Gateway one-off reference flow, the customer receives an entity, reference and amount, then pays through an ATM, home banking or mobile banking. Generating those details does not complete the payment. The order must remain distinguishable from one whose payment has been confirmed.
Ask a shortlisted PSP to show what the customer receives after checkout and what your operations team sees. Can staff identify an unpaid reference, retrieve its expiry and match a later confirmed payment to the original order? Which event permits shipping or service activation? Those questions matter more than having a familiar method name on a coverage list.
Make expiry and stock reservations agree
MULTIBANCO's official FAQ says reference duration varies and directs customers to the date supplied by the merchant. An attempt to pay an expired reference is declined. There is no single expiry period to copy into every Portuguese checkout.
Agree the validity period with the provider and make your stock policy visible to the customer. If you reserve an item only until a stated deadline, establish how payment validity and order cancellation will follow that deadline. Also confirm what happens if a paid reference is presented again. The SIBS documentation describes a one-off flow; it is not evidence for a universal reuse rule across all reference products. Do not promise reusable references or automatic duplicate-payment rejection without checking the actual setup.
Consider a hypothetical EUR 45 order for the last item in stock. The merchant has agreed a reference valid until 18:00 and reserves the item until then. The customer pays at 17:59, but the confirmation reaches the shop at 18:02. A rule that releases stock solely because the local clock passed 18:00 could conflict with that payment.
The acceptance test should cover this timing boundary. SIBS's reference-payment example calls for status validation around expiry, including when delayed processing could have produced a successful payment. Ask the PSP how unresolved orders are checked and escalated before stock is released or a customer is asked to pay again. The example illustrates a merchant policy decision, not a measured delay or recommended universal reservation period.
MB WAY approval still needs a final result
For the ordinary online purchase described by MB WAY, the customer selects the method, enters their mobile number and accepts the request in the app. This supports a checkout conversation centred on approving the current purchase, rather than retaining a reference for later payment.
The merchant still needs confirmed payment evidence. SIBS's one-off MB WAY integration describes an asynchronous result: the initial purchase response is not final, and an unconfirmed request expires after its allowed window. Confirm the final outcome through the provider's notification or status service.
During evaluation, test acceptance, rejection and an unanswered request. Check that the customer sees the appropriate next step and that staff can distinguish a failed attempt from an unresolved result. Confirm the actual timeout and retry rules for the selected integration. This comparison concerns one-off purchases; subscriptions and other MB WAY arrangements require their own scope.
Compare refunds, settlement and EUR payouts separately
A refund returns money against a purchase; a supplier payment or other business payout serves a different purpose. SIBS documents a digital MULTIBANCO reference refund capability without a separate bank transfer. Confirm whether the proposed PSP setup provides it, and request equivalent detail for MB WAY refunds: eligible transactions, full or partial amounts, deadlines, funding and completion evidence.
Then compare collection settlement: receiving account, currency, schedule, fees and how refunds appear in reconciliation. A confirmed customer payment should not be treated as proof that funds have already reached your business account.
For EUR business payouts, provide a separate brief covering recipient types and countries, payment purposes, funding source, amounts and expected volume. Ask which destinations and operations the PSP can approve, how it validates beneficiary details, and what happens to rejected or unresolved transfers. Acceptance of a Portuguese checkout method does not establish those payout capabilities or your company's eligibility.
Start with a focused Portugal brief
PayStar's 14 September 2026 snapshot contains 13 unique recorded payment offers associated only with Portugal. All 13 are classified as collections (Deposit), and all 13 have an EUR association. This is a count of offer records, not independent PSPs, live integrations or approved routes. Separately linked countries, currencies and methods do not establish every combination.
This narrowly defined sample contains no payout-classified offers. That does not mean Portugal or the wider database lacks payout options. Current availability and merchant eligibility require separate confirmation.
Want information about these payment options for free? Just write to us. Contact Anastasia through PayStar Discovery with your business activity, registration country, transaction profile and collection/payout requirements. Free information concerns the options; it does not include integration, processing or all subsequent Discovery services. The merchant selects and contracts directly with the PSP, which handles commercial approval, processing and settlement.
PayStar’s role
PayStar provides information and technical services. PayStar is not a bank or PSP, does not arrange payment acceptance or settlement in its own name, does not receive or hold customer or merchant funds, and does not settle those funds. Payment services are provided by the selected provider under a direct agreement with the merchant. PayStar’s API, routing and monitoring operate within the agreed technical role.