WL SIPS DOCS

Release 24.2

go directly to content

Search by keywords

  1. Means of payment
  2. Prepaid
  3. Conecs

Conecs

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 Conecs means of payment integration into Worldline Sips.

Who does this document target?

This document is intended to help you implement the Conecs 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 Conecs payments with Worldline Sips

General principles

Worldline Sips offers the Conecs prepaid means of payment :

To pay with Conecs:

  • the customer fills in the dematerialised restaurant voucher data.
  • if the voucher does not cover the total amount of the basket, the customer pays the complement with their credit card.

The payment with CB complement is subject to a 3-D Secure payment process. If the card complement is not accepted or the 3-D Secure authentication is not successful, the entire transaction is cancelled and the amount of the restaurant voucher is not consumed.

Acceptance rules

Available functionalities
Payment channels
Internet V Default payment channel
MOTO X
Fax X
IVS X
Means of payment
Immediate payment V
End-of-day payment V Default method
Deferred payment V Limited to 6 days.
Payment upon shipping V Limited to 6 days.
Payment in instalments X
Subscription payment X
Batch payment X
OneClick payment X
Currency management
Multicurrency acceptance X
Currency settlement X
Dynamic currency conversion X
Payment pages

The customer selects the Conecs means of payment.

They are then redirected to the page to enter the information of their dematerialised restaurant voucher:



If the amount of their restaurant voucher is not sufficient, a CB complement is requested.

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

Payment review

During the payment kinematics, it is possible that we don't receive the expected return (timeout), the status of the transaction can be one of the followings.

  • TO_CONFIRM_CAPTURE
  • TO_CONFIRM_CREDIT

A batch processing is carried out daily to update these transactions to final statuses:

  • REFUSED
  • CAPTURED
  • CREDITED

The diagram of the Making a payment paragraph illustrates these statuses as well as the transitions.

The final status will appear in your transaction report to allow you to continue processing the order.

Attention: the cash management operations are not available for transactions with the TO_CONFIRM_CAPTURE or TO_CONFIRM_CREDIT status.

Signing your Conecs acceptance contract

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

So that the CB complement is proposed to the customer, you also have to send us your secure distance selling CB contract number signed with your bank.

Making a Conecs payment

Worldline Sips offers you two solutions to integrate the Conecs means of payment:

  • 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.

The remittance modes available for a Conecs transaction are:

  • Cancellation mode: default mode allowing transaction remittance on a predefined date, called capture delay. When this capture delay is reached, the remittance is sent automatically. This delay is set via the captureDay field with its 0 default value (end-of-day payment).
  • Validation mode: you must validate the transaction to trigger the remittance. A capture delay must also be defined. When this capture delay is reached or exceeded, you will not be able to validate the transaction, which will therefore expire automatically.
  • Immediate mode: the authorisation and remittance are executed online simultaneously.

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


Description of the possible statuses for a Conecs transaction

In validation mode (captureMode = VALIDATION), if the transaction is accepted, it is set to status TO_VALIDATE. In cancellation mode (captureMode = AUTHOR_CAPTURE), if the transaction is accepted, it is set to TO_CAPTURE status. In immediate mode (captureMode = IMMEDIATE), if the transaction is accepted, it is set to status CAPTURED. In the event of a timeout, the transaction temporarily goes into TO_CONFIRM_CAPTURE status. Regardless of the capture mode, if the transaction is refused (responseCode not equal to 00), it is set to status REFUSED.

Making a Conecs payment with Sips Paypage

The payment process for Sips Paypage is described below:


Steps of a Conecs payment via Paypage

1) The customer proceeds with the payment. 2) They are redirected to the means of payment selection page hosted by Worldline Sips, they select Conecs and enter their card number. 3) They are redirected to the payment page where they authenticate themselves. 4) They are redirected to a Worldline Sips page. 5) If they click on the back to eshop button, they are redirected to your website which triggers the manual response to be sent. 6) Worldline Sips sends an automatic response.
Setting the payment request

The following fields have a particular behaviour:

Field name Remarks/rules
captureDay The value sent in the request must be 6 at a maximum.
A larger value will be forced to 6.
paymentPattern Tհe value sent in the request is ignored.
The payment type is forced to ONE_SHOT.
orderId Mandatory
customerContact.email Mandatory
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).
paymentMeanBrand = CONECS
paymentMeanType = PROVIDER
responseCode = 00
 You can deliver the order.
Pending transaction acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 60
 The transaction is still being processed.
You will receive a new response with a final status in 30 minutes.
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 Conecs payment with Sips Office

The payment process for Sips Office is described below:


Steps of a Conecs payment via Paypage

1) The customer proceeds with the payment directly on your website. 2) You initialise the payment with Worldline Sips (PaymentProviderInitialize). 3) You redirect the customer to the Conecs identification and payment pages (redirectionUrl). 4) The customer is then redirected to your website (merchantReturnUrl). 5) You finalise the payment with Worldline Sips (PaymentProviderFinalize). 6) You display the payment result to the customer.
Initialising a payment (PaymentProviderInitialize)

The payment initialisation is done by calling the method paymentProviderInitialize.

Payment initialisation request

The following generic fields are populated in the case of a Conecs payment initialisation:

Field name Remarks/rules
merchantReturnUrl Merchant return URL.
paymentMeanBrand Must be populated with CONECS.

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

Field name Remarks/rules
captureDay The value sent in the request must be 6 at a maximum.
A larger value will be forced to 6.
paymentPattern Tհe value sent in the request is ignored.
The payment type is forced to ONE_SHOT.
orderId Mandatory
customerContact.email Mandatory
Payment initialisation response

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

Status Response fields Action to take
Payment initialisation accepted acquirerNativeResponseCode = 00
messageVersion = message version retrieved in response to the payment initialisation.
responseCode = 00
redirectionData = redirection data retrieved in response to the payment initialisation.
redirectionUrl = redirection URL to the mean of payment website.
 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.

Redirecting the customer to their online banking website

The customer must be redirected to the redirectionUrl URL provided in response to the paymentProviderInitialize method. This redirection consists in making a POST call on the redirectionUrl URL received in response to the payment initialisation. The POST settings to be transmitted are redirectionData and messageVersion also received in the response to the payment initialisation.

At the end of the payment process, the customer is redirected to the URL provided in the merchantReturnUrl initialisation request. The following fields are sent in POST and must be retrieved to finalise the payment.

Field name Remarks/rules
responseCode Redirection processing response code
redirectionData Redirection data retrieved in response to the payment initialisation.
messageVersion Message version retrieved in response to the payment initialisation.
amount Transaction amount in cents
merchantId Shop identifier
transactionReference Transaction reference
transactionId Transaction identifier
transactionDate Transaction date
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 means of payment 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 provide the following specific fields in the finalisation request for a payment CONECS.

Field name Remarks/rules
redirectionData Redirection data retrieved after the customer returns to your website (cf. Redirecting the customer to their online banking website).
messageVersion Message version retrieved after the customer returns to your website (cf. Redirecting the customer to their online banking website).
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).
acquirerResponseMessage = information on the amounts paid by each means of payment.
Format = field1:field2:[...]field7
field1 = SPLIT
field2 = prepayed payment mean name
field3 = prepayed payment reference partner
field4 = amount payed with the prepayed payment mean
field5 = supplement means of payment
field6 = masked PAN
field7 = amount payed with the supplement payment mean
paymentMeanBrand = CONECS
responseCode = 00
transactionStatus = (cf. the Data Dictionary).
 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.

Managing your transactions

Available cash operations

The following operations are available on Conecs transactions:

Cash management
Cancellation V
Validation V Validation available on the partial amount of the transaction.
Refund V Refund available only on the CB part for the partial amount of the transaction and on amounts higher than the initial amount (unlimited refund).
Duplication X
Credit X

The diagram below allows you to know which cash management operation is available when a transaction is in a given state:


Diagram very complex to describe, please contact support sips@worldline.com

Viewing your 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 Conecs 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 Conecs transactions, the paymentMeanBrand field is populated with the value CONECS.

Sips Office Extranet

You can view your Conecs 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