Bancontact

Bancontact transactions can be processed via the Saferpay JSON API. However, as Bancontact is a third party provider, there are a few things to consider.

Requirements

The handling of Bancontact payments with Saferpay requires:

• A corresponding license and thus a valid identification with a username and password for the Saferpay system.

• Availability of at least one active Saferpay terminal by which payments can be carried out and availability of the associated Saferpay TerminalId.

• A valid Bancontact contract.

For Bancontact activation on the Saferpay terminal, please contact your sales contact.

Supported features

Feature	Support
Capture/Cancel	❌
Multipart Captures	❌
Secure Card Data	✅
Refunds	✅ Needs attention!
Recurring Payments	❌
3D Secure	✅
Dynamic Currency Conversion (DCC)	❌
Mail Phone Order	✅
Testing	✅
Omni-Channel	❌

Integration

The general integration of Bancontact can be done either via the Payment Page, or the Transaction Interface and does not require any special attention, besides what is mentioned in the respective chapters.

Furthermore, for other flows (Refunds etc.), please also refer to the table above.

Special Cases

• Refunds for Bancontact are limited to Referenced Refunds only.

• Bancontact Secure Card Data aliases may only be used for "card on file" 3D Secure transactions.

Bancontact Direct Mode

The Bancontact Direct Mode allows the merchant to directly integrate Bancontact into their site or mobile app. This chapter handles the technical details and flow of this type of integration.

(click to enlarge)

Flow description

1. First, the merchant's application initiates the payment via the Transaction AlternativePayment Request. Note that this should always be a centralized server, even if the payer/shopper interacts with the merchant system via an app!

2. Saferpay forwards the merchant request to the Bancontact system, where the IntentUrl and QR-Code data is generated.

3. The generated data is forwarded towards the merchant application through the Transaction AlternativePayment Response.

4. The merchant then has multiple options, how to proceed, also depending on the application:

   1. The merchant displays the QR-Code data, so his customer may scan it via the bancontact app.

   2. The IntentUrl is used to perform a direct switch towards the Bancontact payment app

5. The payer performs the payment. Bancontact authorizes her/his card and sends the necessary data to Saferpay.

6. Once the payment is finished, two things happen in parallel:

   • A.1: The payment data is forwarded to the Saferpay system, which saves the data. Once a definitive transaction status has been determined, Saferpay will then call the StateNotificationUrl, which has been defined with the Transaction AlternativePayment Request, to notify the merchant application that the data for this transaction is ready to be pulled.

   • A.2: The merchant application performs the Transaction QueryAlternativePayment Request to ask for the outcome of the transaction.

   • A.3: The merchant application validates the payment.

   • B: While the merchant application is notified of the transaction, in the background, the Bancontact app will redirect the payer towards the respective App-RedirectUrl, defined within Transaction AlternativePayment Request, depending on the outcome.

Testing

Please refer to this chapter, if you want to test Bancontact.