WL SIPS DOCS

Release 24.2

go directly to content

Search by keywords

  1. Means of payment
  2. Wallets and mobile payment
  3. Bancontact Mobile

Bancontact Mobile

To search in the page use Ctrl+F on your keyboard

Introduction

Worldline Sips is a secure multi-channel e-commerce payment solution that complies with the PCI DSS standard. It allows you to accept and manage payment transactions by taking into account business rules related to your activity (payment upon shipping, deferred payment, recurring payment, payment in instalments, etc.).

The purpose of this document is to explain the Bancontact Mobile means of payment integration into Worldline Sips.

Who does this document target?

This document is intended to help you implement the Bancontact Mobile means of payment on your e-commerce site.

It includes:

  • functional information for you
  • implementation instructions for your technical team

To get an overview of the Worldline Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide

Understanding Bancontact Mobile payments with Worldline Sips

General principles

Bancontact is the market leader in electronic payments in Belgium. The Bancontact card is the Belgian national card.

The Bancontact Mobile means of payment allow customers to pay with their Bancontact card via their mobile phone or tablet.

To pay with a Bancontact card via the Bancontact Mobile application, cardholders must have the Bancontact application installed on their mobile device (computer, smartphone, tablet), and than, they can initialise the transaction. During the payment stage, the Bancontact Mobile application will be launched via two methods, depending on the device:

  • If the transaction is initialised on a different computer or mobile device than the one used for the payment, the Bancontact Mobile application will be launched by the customer on the device used for the payment. By scanning the QR code displayed on the payment page, the customer is redirected to the authentication page.
  • If the transaction is initialised on a mobile device that also serves as a payment device via the dedicated mobile application, that application is launched by clicking on the button URL-intent on the payment page.

As with the standard Bancontact card payments, an authentication step is required. You benefit from a guarantee of payment under certain conditions, according to the current banking regulations. During a Bancontact Mobile payment, the cardholder proceeds to the authentication through the same name application.

If the amount is greater than €1500.00, the transaction will be rejected (Worldline Sips response code 05).

Acceptance rules

Available functionalities
Payment channels
Internet V Default payment channel
MOTO X
Fax X
IVS X
Means of payment
Immediate payment V Default method
End-of-day payment X
Deferred payment X
Payment upon shipping X
Payment in instalments X
Subscription payment V With WIP option.
Batch payment X
OneClick payment X
Currency management
Multicurrency acceptance X EURO only
Currency settlement X EURO only
Payment pages
Shopping on the desktop platform (QR code)

On a desktop platform (computer), the customer selects the Bancontact means of payment.

The customer can choose the Bancontact means of payment: standard (by card) or via mobile application. They choose to pay via the mobile application:



While the customer scans online the QR code and authenticates via the mobile device, a waiting message is displayed on the desktop platform:



The payment ticket is displayed, then the customer returns to your website.

If Worldline Sips is unable to establish a connection with the Bancontact server, once the customer has selected the Bancontact logo on the payment selection page, the card payment entry is offered by Worldline Sips:



Shopping on the smartphone (URL-intent)

On smartphone, only mobile payments with URL-intent and standard Bancontact card payments are available on the payment page.

The customer selects to pay with the Bancontact Mobile application:



A Bancontact waiting message is displayed on the smartphone:



The customer is then redirected to the Bancontact pages. They choose the card, enter the PIN and confirm the payment:



The payment ticket is displayed, then the customer returns to your website.

Shopping on the tablet (QR code and URL-intent)

On the tablet, all mobile payments with QR code and URL-intent as well as standard Bancontact card payments are available on the payment page.

If the customer selects the option Scan the QR code, a QR code is displayed:





A Bancontact waiting message is displayed on the tablet:



The customer can also select the Open App option. The Bancontact mobile application will be launched automatically:



A waiting message is displayed on the payment page:



The payment ticket is displayed, then the customer returns to your website.

Signing your Bancontact Mobile acceptance contract

In order to offer the Bancontact Mobile means of payment on your website, you have to sign an acceptance contract with Worldline Acquiring Belgium. Thereafter, you transmit us the contract number for recording in our information system.

These means of payment are also co-badged with Maestro and soon with V-Pay (Visa debit), which means that they can be accepted as international Maestro or Visa cards.

WIP service

When you subscribe to the WIP service with Bancontact, Bancontact provides 2 id:

  • Merchant Wallet ID: Unique identifier assigned by BANCONTACT to the WIP merchant. Disposition: 71xxxx.
  • WIP BEPAF or WIP TOKEN: alphanumeric id on 16 positions, provided by Bancontact to each merchant and that must be provided in BPAF field for each WIP transaction

You must provide those two id to Worldline Sips to complete the subscription to WIP service.

Making a Bancontact Mobile payment

Worldline Sips offers you three solutions to integrate the Bancontact Mobile payment method:

  • Sips Paypage which directly acts as the payment interface with customers via their web browser.
  • Sips Office which gives you the opportunity to display your payment pages and works through a server-to-server dialog.
  • Sips In-App which is an interface dedicated to mobile payments.

For Bancontact Mobile payments, it is not allowed to defer the remittance, you cannot adjust the date of funds transfers.

The diagram below explains the different transaction statuses according to the chosen capture mode:


description of the possibles status for a bancontact mobile payment

The only capture mode is IMMEDIATE. Three status are possibles: the transaction is waiting to be captured (status TO_CAPTURE, responseCode 00) or the transaction has been interrupted (status ABORTED, responseCode 17) or the transaction has been refused (status REFUSED, responseCode different from 00 et de 17).

Making a Bancontact Mobile payment with Sips Paypage

The payment process for Sips Paypage is described below:


steps of a bancontact mobile payment with paypage

1) The client pays. 2) The client is redirected to the payment method selection page hosted by Worldline Sips, he chooses Bancontact and chooses to pay via the mobile app. 3) He uses Bancontact Mobile to authenticate himself. 4) The client is redirected on Worldline Sips pages. 5) If the client clicks on "back to webshop" button, Worldline Sips sends the manual response. 6) Worldline Sips sends the automatic response.
Setting the payment request

Bancontact Mobile payment is a commercial option. No specific information (relative to the standard Bancontact payment) is required to submit a Bancontact Mobile payment request.

Analysing the response

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
holderAuthentMethod = PASSWORD
holderAuthentStatus = SUCCESS
holderAuthentProgram = BCMCMOBILE
panEntryMode = WALLET
paymentMeanBrand = BCMC
paymentMeanType = CARD
responseCode = 00
walletType = BCMCMOBILE
 You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 05
 The authorisation is refused for a reason unrelated to fraud.
If you have not opted for the "new payment attempt" option (please read the Functionality set-up Guide for more details), you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to the number of attempts reached responseCode = 75 The customer has made several attempts that have all failed.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

Making a Bancontact Mobile payment with Sips Office

The payment process for Sips Office is described below:


steps of a bancontact mobile payment with office

1) The client pays on the payment page you host on your web site. 2) You initialize the payment sending a paymentProviderInitialize request to Worldline Sips who sends you a response. 3) You launch Bancontact mobile app thanks to the redirectionUrl provided by Worldline Sips in the paymentProviderInitialize response. 4) Worldline Sips informs you wether the authentication has succeeded or not. 5) You send a paymentProviderFinalize request to Worldline Sips who sends you the payment result. 6) You display the payment result to your customer.
Initialising a payment (PaymentProviderInitialize)

The Bancontact Mobile payment initialisation is done by calling the paymentProviderInitialize method.

Payment initialisation request

You must populate the following specific fields in the initialisation request for a Bancontact mobile payment:

Field name Remarks/rules
merchantReturnUrl The URL for sending the authentication notification.
paymentMeanBrand Must be populated with BCMCMOBILE.
responseKeyVersion The secret key version used to encrypt the authentication notification.
paymentMeanData.bcmcMobile.defaultRedirectUrl The optional URL for the Bancontact mobile application that can be used as a merchant callback URL for notifications. This callback can be triggered by the mobile application when the payment has not been successful, or if the connection between the mobile application and the payment service has been lost during the processing of the transaction.
paymentMeanData.bcmcMobile.completionRedirectUrl The optional URL for the Bancontact mobile application that can be used as a merchant callback URL for notifications. This callback can be triggered by the mobile application after displaying the payment result to the client.
Payment initialisation response

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Payment initialisation accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
messageVersion = message version retrieved in response to the payment initialisation.
outerRedirectionUrl = QRCode
paymentMeanBrand = BCMCMOBILE
responseCode = 00
redirectionData = redirection data retrieved in response to the payment initialisation.
redirectionUrl = URL-intent
 Redirect the customer to redirectionUrl.
Payment initialisation rejected
responseCode = <> 00
 See the field errorFieldName, then fix the request.
If the problem persists, contact the technical support.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 05
 The authorisation is refused for a reason unrelated to fraud, you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
 Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

Customer redirection

At this point, you can choose the process to activate:

  • with the redirectionUrl field, you are able to provide the URL-intent received via the PaymentProviderInitialize response on your mobile application.
  • with the outerRedirectionUrl field, you can also generate a QR code to display on your pages.

Both processes will generate the launch of the mobile Bancontact application installed on the customer's mobile device. The customer will then have to identify himself.

Attention: when the initialize process is done, the customer has a limited time to authorize the payment. The QR code and/or the URL intent must be displayed just after calling the PaymentProviderInitialize method.
Finalising a payment (PaymentProviderFinalize)

This last step allows you to obtain the payment status. The settings obtained during the redirection after the payment process on the Bancontact Mobile website are to be transmitted during this call. The method used to finalise a payment is paymentProviderFinalize.

Tip: you can obtain a code 24 "Operation impossible" in response to your paymentProviderFinalize request. This code means that this request has already been sent and processed for the transaction in question. If you are unable to identify this processing, please use the GetTransactionData function of the diagnostic service: this operation allows you to retrieve information relating to a transaction previously created using the Worldline Sips.
Payment finalisation request

You must populate the following specific fields in the finalisation request for a Bancontact mobile payment:

Field name Remarks/rules
redirectionData Redirection data
messageVersion Message version
Payment finalisation response

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
panEntryMode = WALLET
paymentMeanBrand = BCMCMOBILE
responseCode = 00
walletType = BCMCMOBILE
 You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 05
 The authorisation is refused for a reason unrelated to fraud, you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
 Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

Cardholder authentication notification

A notification in HTTP POST is sent to the URL provided in the merchantReturnUrl field related to the initialisation method.

You have to configure a system receiving the notification message to make a call following the PaymentProviderFinalize method (for example, a control service waiting for notification).

Four fields are set in the request (case sensitive):

Field name Remarks/rules
Data The field concatenation is necessary to finalise the transaction.
Setting example: keyVersion=1|merchantId = 099974849505999|…
Encode Coding type in use
Seal Message signature
InterfaceVersion Context message version

If the encoding value is "base64", the data must have a Base64.decode encoding to retrieve the concatenated string.

The concatenated string is structured as follows: key1 = value1 | key2 = value2...

Example:

merchantId=002474849505153|transactionReference=TEST87190508400|redirectionData=+n
lCo8T13xEspDheo56uxiYJql7rAoAVM...1aNpi9l85BveUkuoco=|messageVersion=0.1|keyVersion=1

The following fields are populated in the "Data" field.

These fields must be used to process the payment finalisation.

Field name Remarks/rules
keyVersion The secret key version used to encrypt the authentication notification.
merchantId Merchant Identifier
messageVersion Message version
redirectionData Redirection data
transactionReference Transaction reference

Managing your Bancontact Mobile transactions

Available cash operations

The following operations are available on Bancontact transactions:

Cash management
Cancellation X

Validation X
Refund V
Maximum amount allowed per refund: €3,000 (several partial refunds required for any transaction over €3,000).
Duplication V With WIP option
Credit X

The diagram below explains which cash management operation is available when a transaction is in a given status:


possible status after a cash management operation for a bancontact transaction

When the transaction is created, the status is TO_CONFIRM_CAPTURE. If the capture fails, the status becomes CAPTURE_REFUSED. if the capture succeeds, the status becomes CAPTURED. Once the transaction is captured, it can be refunded partially or completely. If the whole transaction is refunded, the status becomes CREDITED. If only a part of the transaction is refunded, the status remains CAPTURED.

Viewing your Bancontact Mobile transactions

Reports

The reports provided by Worldline Sips allow you to have a comprehensive and consolidated view of your transactions, cash operations, accounts and chargebacks. You can use this information to improve your information system.

The availability of Bancontact Mobile transactions for each type of report is summarised in the table below:

Reports availability
Transactions report V
Operations report V
Reconciliations report X
Chargebacks report X
Note: for Bancontact Mobile transactions, the paymentMeanBrand field is populated with the value BCMC.

Sips Office Extranet

You can view your Bancontact Mobile transactions and perform various cash management operations with Sips Office Extranet.



Back to top Need help?

This site uses trackers to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of trackers on your device.

Configuration