logo Mercanet

Release 24.6

go directly to content

Search by keywords

  1. Payment means
  2. Prepaid
  3. Prepaid payment means with CB complement

Prepaid payment means with CB complement

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

Introduction

Mercanet 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 Cadhoc, Illicado, Spirit Of Cadeau, Le Pot Commun and CadoCarte means of payment integration into Mercanet.

Who does this document target?

This document is intended to help you implement the Cadhoc, Illicado, Spirit Of Cadeau, Le Pot Commun and CadoCarte 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 Mercanet solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide

Understanding prepaid payments on Mercanet with CB complement

General principles

Mercanet offers several prepaid means of payment (as ). The principle is as follows:

  • Customers enter their mean of payment data (prepaid card number or other).
  • If the prepaid payment mean does not cover the entire amount of the cart, the customers pay the rest with the 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 prepaid mean of payment is not consumed.

Note: some prepaid means of payment may impose a minimum and/or maximum usable amount. We advise you to view the concerned prepaid mean of payment General Conditions of Sale in order to know the details.

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 X
Batch payment X
OneClick payment X
Currency management
Multicurrency acceptance X
Currency settlement X
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_AUTHOR
  • TO_CONFIRM_CAPTURE
  • TO_CONFIRM_CREDIT

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

  • REFUSED
  • TO_CAPTURE/TO_VALIDATE
  • CAPTURED
  • TO_CREDIT

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_AUTHOR or TO_CONFIRM_CAPTURE status.

Signing your prepaid means of payment acceptance contract with CB complement

In order to offer one of the prepaid means of payment on your website, you have to sign an acceptance contract with the distributor of the chosen mean of payment. 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 payment

Mercanet offers you two solutions to integrate the Cadhoc, Illicado, Spirit Of Cadeau, Le Pot Commun and CadoCarte means of payment:

  • Paypage which directly acts as the payment interface with customers via their web browser.
  • Office (M2M) which gives you the possibility to display your payment pages and works through a server-to-server dialog.

The only remittance mode available for a transaction made with a prepaid mean of payment is the immediate mode (the transaction remittance is executed at the time of the online payment acceptance).

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


diagram showing the different statuses of a transaction

In the immediate mode, the transaction will either go to the Captured state if it has been accepted (response code 00), or to the Refused state if it has been refused (response code other than 00). In the event of a timeout, the transaction temporarily goes into TO_CONFIRM_CAPTURE status.

Making a payment with Paypage

The payment process for Paypage is described below:


image showing the kinematics of a payment via Paypage

1) After finalising the order on the merchant website, the customer proceeds to payment. 2) The customer is redirected to the payment pages hosted on the <keyword keyref="Sips"/> side and selects one of the prepaid payment methods. 3) The customer is redirected to the prepaid payment method page. They can make an additional payment with a CB, Visa or Mastercard. 4) When the customer returns to <keyword keyref="Sips"/>, the ticket with the payment result is displayed. 5) If the customer clicks on the return to shop button, he is redirected to the merchant's website which unlocks the manual response. 6) The <keyword keyref="Sips"/> engine also sends an automatic response to the merchant website.
Setting the payment request

The following fields have a particular behaviour:

Field name Remarks/rules
captureMode Tհe value sent in the request is ignored.
The capture mode is forced to IMMEDIATE.
captureDay Tհe value sent in the request is ignored.
The capture delay is forced to 0.
customerLanguage Allows to choose the language used on Mercanet and CB complement payment pages.
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 =
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 payment with Office (M2M)

The payment process for Office (M2M) is described below:


image showing the kinematics of a payment via Office

1) After finalising the order on the merchant website, the customer proceeds to payment. 2) The merchant initiates the payment on the engine &lt;keyword keyref="Sips"/&gt. 3) The merchant redirects the customer to the payment page of the selected prepaid payment method. 4) Once the payment is completed, the customer is redirected to the merchant's website. 5) The merchant finalises the payment on the engine &lt;keyword keyref="Sips"/&gt. 6) The merchant displays the payment result on its website. Translated with www.DeepL.com/Translator (free version)
Initialising a payment (PaymentProviderInitialize)

The payment initialisation is done by calling the method paymentProviderInitialize.

Payment initialisation request

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

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

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

Field name Remarks/rules
captureMode Tհe value sent in the request is ignored.
The capture mode is forced to IMMEDIATE.
captureDay Tհe value sent in the request is ignored.
The capture delay is forced to 0.
customerLanguage Allows to choose the language used on Mercanet and CB complement pages.
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 Mercanet.
Payment finalisation request

You must provide the following specific fields in the finalisation request for a payment .

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 =
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 transactions:

Cash management
Cancellation X
Validation X
Refund V In case of a partial refund, the CB part is reimbursed in priority.
For prepaid refundable payment means, it is specified in the transaction confirmation email sent to customers that they should keep their gift cards which will be credited in case of refund.
Duplication X

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


diagram showing the different statuses of a transaction

The transaction will go from the Captured status to the Credited status once it is full refund.

Viewing your transactions

Reports

The reports provided by Mercanet 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 transactions for each type of report is summarised in the table below:

Reports availability
Transactions report V
Operations report V
Reconciliations report V Unless CADHOC.
Chargebacks report V Unless CADHOC.
Note: the paymentMeanBrand field is populated depending on the payment mean used for the transaction, meaning here: .
Note:

The acquirerReconciliationDetail field is displayed on the prepaid payment method reconciliation logs.

This data is generated at the time of reconciliation from the information provided by the acquirer for Prepaid means of payment.

The value of this data is the concatenation of seven fields separated by the character ":" which contain detailed information on the amounts paid by each means of payment.

It is structured as follows:
  • field 1 = SPLIT
  • field 2 = name of the prepaid payment mean
  • field 3 = masked PAN of the prepaid payment mean
  • field 4 = amount paid with the prepaid payment mean (with 2 decimal places)
  • field 5 = additional payment mean
  • field 6 = hidden PAN of the additional payment mean
  • field 7 = amount paid with the additional payment mean (with 2 decimal places)

Mercanet Back Office

You can view your transactions details and perform various cash management operations with Mercanet Back Office.

Here are the details of a transaction:



Back to top Need help?