Understand which MULTIBANCO product you are adding
MULTIBANCO is a broader Portuguese payment network, while an ecommerce checkout may specifically offer MULTIBANCO reference payments. Keep that distinction clear in the provider proposal and customer instructions. This guide focuses on the reference-payment journey: an order generates payment details, the customer completes payment through a supported banking channel, and the merchant reconciles the confirmed result to that order.
SIBS presents MULTIBANCO references alongside MB WAY and cards in its online-payment offering. These are distinct choices within a possible gateway arrangement. Enabling one should not be treated as enabling the others. Establish the exact service, integration and commercial agreement being proposed before comparing features or using a familiar brand name as shorthand for several different payment flows.
Confirm eligibility before designing checkout
Ask the provider which merchant entities, settlement accounts, currencies and business activities its reference-payment product supports. Document the customer market and transaction pattern you intend to serve. An international merchant should not assume that a Portuguese customer base alone establishes onboarding eligibility, while a local entity should not assume every business category will be accepted.
Describe fulfilment timing, refunds, average order value and any regulated products accurately. If the business operates several brands, clarify which are covered by the agreement and how they appear to customers. Keep the written approval with the integration record. This prevents a later technical change from quietly extending the payment arrangement to a website or activity that was never reviewed.
Give references a clear relationship to orders
Create the order record before requesting its payment reference, and store the provider identifiers against that record. Display the entity, reference and amount exactly as returned through the approved integration. Customer-facing instructions should explain that generating payment details is a step toward payment, rather than evidence that the merchant has received funds.
MULTIBANCO's official FAQs explain that reference validity can vary, that customers should check the supplied date, and that expired references are rejected. Translate the provider's actual configuration into a clear deadline on the order page. Avoid inventing a standard expiry period. If support issues replacement details, preserve the relationship to the previous reference and explain which instructions the customer should now use.
Handle the gap between checkout and payment
Reference generation and customer payment are separate events. The merchant needs a policy for stock reservation, promotional prices and delivery promises during that interval. An order awaiting payment should not be counted as a completed sale simply because the checkout flow reached its final screen. Likewise, inventory should not remain reserved indefinitely without a deliberate commercial decision.
Show the customer a recoverable order page containing the payment instructions and current status. If the customer returns later, retrieve the existing order rather than creating a second purchase automatically. Explain what happens when a deadline passes or stock becomes unavailable. Where the order is cancelled, coordinate the cancellation with the provider's reference lifecycle so customer instructions and internal fulfilment status do not contradict each other.
Use provider confirmation to release the order
Define the exact event or verified status that marks a reference as paid. Process repeated notifications without releasing the same order twice, and retain the provider reference for later investigation. A customer receipt can help support identify a transaction, but should not become the sole automated trigger for fulfilment. The merchant needs a dependable confirmation path under its actual integration.
Test missing and delayed notifications, amount discrepancies and a payment received near the order deadline. Decide who reviews a receipt that cannot be matched automatically. If a customer also paid by card after becoming impatient, investigate the two transactions before sending goods twice or refunding the wrong one. A clear exception queue is more useful than quietly forcing every case into paid or failed.
Separate repeated invoices from automatic collection
A business can issue repeated invoices without holding permission or technical capability to initiate automatic debits. Do not describe ordinary reference payments as a subscription mandate merely because a customer pays the same merchant every month. Explain the customer action required for each invoice under the product actually contracted.
SIBS API Market documents several MULTIBANCO services, including periodic-payment interfaces. Their existence does not establish that an ecommerce merchant's reference integration includes recurring collection. Ask the provider to identify the precise supported workflow, consent requirements and cancellation process. Design renewal reminders, service suspension and unpaid-invoice handling around those documented answers instead of assuming that a reference can be reused indefinitely.
Plan refunds and commercial comparisons together
Before accepting payments, confirm how the provider handles full and partial refunds, transaction lookup and exceptions. Ask whether refunds can use the original payment reference and what information is required when they cannot. Give support an approved process for changed customer details and restrict who can approve a new destination. Avoid promising a universal refund timetable without the provider's current terms.
Compare proposals using total operating cost rather than a single collection rate. Include any fixed fees, reporting charges, settlement timing and staff effort for unmatched receipts. Do not characterize a method as immune to complaints or recovery requests. The underlying sale still creates delivery and customer-service obligations. Keep evidence of the order, payment confirmation, fulfilment and agreed remedy together, with appropriate access and retention controls.
Reconcile from invoice to available proceeds
A daily reconciliation should connect the order reference, confirmed payment, fees, settlement batch and bank receipt. Keep the date the customer paid separate from the date funds reached the merchant account. This helps finance investigate a missing settlement without incorrectly telling the customer that an otherwise confirmed order remains unpaid.
Review exceptions by cause: expired instructions, abandoned orders, duplicate attempts, delayed confirmations and reconciliation differences. Use those findings to improve instructions and operational handling. Measure completed orders and support workload together; a checkout option that generates many references but few completed payments may need clearer instructions or a different reservation policy. Evaluate changes against your own customer experience rather than assuming a network-wide result.
What it means to Merchants
MULTIBANCO references can form a useful Portuguese payment option when the merchant treats payment instructions, confirmed receipt and settlement as separate stages. Confirm eligibility and product scope, explain the payment deadline, protect the link between reference and order, and test delayed or duplicate outcomes before launch. A reliable refund and reconciliation process matters as much as the initial checkout. The objective is a customer journey that remains understandable after the payment screen closes, with evidence that finance and support can use to resolve the transaction.