Bancontact for Merchants: Checkout, Confirmation and Refund Operations

Start with the product and channel

Bancontact’s official merchant site presents separate online, terminal and Bancontact Pro solutions. Its online offering connects merchants through certified partners, while Pro includes mobile and integrated acceptance products. The current catalogue also mentions Wero within selected Pro solutions. Merchants should identify the exact product being proposed rather than treating every service under the brand as the same payment method.

This guide focuses on the operational questions behind accepting Bancontact, particularly online purchases from Belgian customers. It combines brief official facts with independent merchant analysis. It does not establish that a business is eligible for a provider account or that FixPays offers a Bancontact integration. Confirm the entity, activity, customer markets and channel before publishing an acceptance claim.

Customer journey and eligibility

Stripe’s Bancontact documentation identifies Belgian customers and euro presentment for its implementation. It describes customer authentication through a card or app journey, including desktop QR and mobile app redirection. Its documentation treats Bancontact as a single-use payment method. These are provider-specific implementation facts; a merchant using another partner should verify the corresponding product capabilities directly.

Map how the checkout behaves on the devices customers actually use. A desktop customer may complete authentication on a separate phone, while a mobile customer may leave the browser for an app. Preserve the order during that transition. The return screen should provide a clear result or an honest pending message rather than inviting another payment before the original attempt has been checked.

Merchant eligibility is a separate question from customer access. Obtain the provider’s supported business countries, settlement arrangements and prohibited or restricted activities. A Belgian customer having the necessary payment instrument does not mean every foreign merchant or business category can collect through it. Submit the real website, fulfilment model and customer locations for review, including any material changes after launch.

Build confirmation around the order record

Create a stable order reference before initiating payment. Store the expected amount, currency and provider payment identifier alongside it. Only the approved server-side status should authorise fulfilment. A customer reaching a success-looking page is not a substitute for checking that the correct payment completed for the correct amount. This distinction is especially useful when the browser closes or loses connectivity during authentication.

Design repeated notifications so that they update an existing record rather than create another shipment or access entitlement. If a customer retries, retain the relationship between attempts and the original order. Support should see which attempt succeeded and whether any other attempt remains uncertain. Do not hide failed attempts by overwriting the payment reference each time the checkout is reopened.

Test the edge of an order reservation. If stock is released while a payment is unresolved, the eventual successful payment needs an explicit fulfilment or refund decision. Assign an owner to that exception and explain the outcome to the customer. Otherwise the merchant can end up with valid receipts for goods it no longer intends to deliver, despite a technically correct payment integration.

Recurring billing needs its own design

A completed Bancontact purchase should not be interpreted as authority to debit the customer again. Stripe’s current capability table does not support recurring or off-session Bancontact payments. Where a provider proposes another recurring instrument after the initial purchase, identify that instrument and its consent requirements separately. Do not present a switch to a different rail as an invisible continuation of the same payment.

For a subscription service, decide whether each invoice will require a new customer action or whether an independently supported recurring arrangement will be used. Record the commercial subscription status separately from payment authority. Cancelling renewal, ending service access and refunding a completed period are different events. Customer messages should explain exactly which action has been completed and which obligations remain.

Refunds and customer support

Stripe documents full and partial Bancontact refunds, a submission window of 730 days and a typical bank-credit time of two to five days for its service. It describes refunds as separate credits rather than reversals and says submitted refunds cannot be cancelled. Those details should be checked against the merchant’s actual provider contract before they become a customer promise.

A practical refund case should retain the original payment reference, requested amount, approval, execution reference and final observed status. Tell the customer how the credit may appear, using wording confirmed by the provider. If the first refund remains pending, investigate its status before sending another payment. A second reimbursement can create a financial loss that is difficult to recover without confusing the customer.

Do not equate the absence of a standard card-style chargeback flow with the absence of customer complaints or fraud exposure. Maintain a clear contact route for missing goods, duplicate payments and unauthorised activity reports. Preserve relevant order and fulfilment evidence under an approved retention approach. The commercial obligation to resolve a genuine problem does not disappear because the payment method uses a different dispute process.

Pricing, settlement and reconciliation

Request a complete commercial schedule for the proposed acceptance arrangement. Compare transaction charges, recurring service charges, refund costs and any settlement or currency-conversion costs that apply. Avoid importing another provider’s advertised rate into the budget. Use representative basket values and volumes so that a fixed charge and a percentage charge can be compared in the context of the actual business.

Reconcile the order ledger to the payment report and then to the bank credit. These are three related records, not one status. Record deductions and timing differences explicitly. If the provider aggregates payments into payouts, finance needs a report that explains which transactions and refunds make up each credit. A familiar checkout brand should not conceal an unexplained balance or an unsupported assumption about when funds become usable.