During the creation of a transaction and depending on the selected mode, Mercanet accepts or rejects the creation and generates complementary IDs.

There are various possible cases:

For cash management operations, the identification method of a transaction is not limited to the mode selected at creation.

The tables below outline the various possibilities.

The s10TransactionId, s10TransactionIdDate and transactionReference fields appear in the transactions, operations, reconciliations and chargebacks reports, whatever the transaction identification mode.

For duplication operation, the original transaction is identifiable via the s10FromTransactionId, s10FromTransactionIdDate and fromTransactionReference fields of the transactions report.

For further details, please read the Paypage customisation guides.

The Mercanet means of payment selection page is not displayed automatically. It can be managed either on your merchant website or by Mercanet. An option lets you automatically display this page by Mercanet.

However, in cases where the means of payment are not of the same type (card and Paypal for example), the selection page is displayed automatically. When several means of payment are configured in your contract, you can filter those that will be displayed in the means of payment selection page via the paymentMeanBrandList field:

• a single means of payment: the means of payment selection page is not displayed
• a list of means of payment: the means of payment are displayed in the feed order of the field
• blank field: all configured means of payment are displayed.

Mercanet displays the means of payment matching simultaneously with

• the list of means of payment provided in your configuration

and

• the transaction data (checking the transaction currency, for example).

If no compatible means of payment is found, Mercanet refuses the transaction.

Sample means of payment selection page:

The payment confirmation page or "payment ticket" is displayed by default by Mercanet. However, you can choose to display it yourself on your website by using the elements provided in the response message sent to the response URL (normalReturnUrl). You can also decide dynamically, depending on the context of the transaction, not to display the ticket produced by Mercanet.

You can decide on the maximum number of attempts to enter the PAN:

• when a customer accesses the payment details entry page
• or a user makes an entry via Mercanet Back Office

Beyond this limit, the transaction is refused and the following message is displayed:

Usually, a new payment attempt is proposed to the customer in case of an invalid PAN. This additional option allows to extend the new payment attempts on other cases of refusal :

• acquirer rejection (except fraud)
• 3-D Secure authentication failure
• fraud engine rejection (except fraud)

The maximum number of payment attempts is set in your merchant configuration (see previous paragraph "Number of payment attempts").

The following message is displayed to your client:

You may choose to get an automatic notification sent to your website in case of a technical error. This type of error happens in exceptional circumstances.

The customer has a 15-minute period of inactivity to carry out the payment. Beyond this allotted time, the user session expires and the customer is not able to complete their purchase. This period is set to 15 minutes in accordance with the PCI DSS regulation (condition 8.1.7).

In addition to this regulatory limit, you have the option (business session timeout) of proposing a maximum period of time spent on the Mercanet payment pages. This period begins when the customer arrives on the Mercanet payment pages.

The name of the webshop configured in Mercanet can be displayed in the banner on the payment page.

In order to secure the validity of the entry, an option allows the display of a mandatory field below the card information entry area, asking the cardholder to enter their name.

This option is available only for card payment.

This data is sent to some acquirers (mainly UK acquirers) in the authorisation request. However, this entry can be used to discourage potential fraudsters.

This page is displayed in the event of a payment initialisation error only via the POST connector (incorrectly formatted query for example).

The redirection button redirects the user to the merchant’s website (with the manual response). The display of the redirection button is configurable:

At the same time, an automatic response can be sent. The sending of this automatic response is configurable:

Sensitive information (card number and CVV) can be hidden in the means of payment entry page.

If this functionality is activated, then sensitive information will also be hidden if you create a transaction using a payment card in the Mercanet Back Office interface.

Mercanet payment pages can be integrated into a webshop page. This has no impact on your pages and you can use this feature without any Mercanet configuration.

For more information, please read the Paypage iFrame user guide.

To use the internet channel, you must subscribe to a VADS (secure distance selling) contract with the acquirer.

When using the MOTO (Mail Order Telephone Order), MAIL_ORDER or TELEPHONE_ORDER channels, the transaction is processed in distance selling acceptance. You have to subscribe to a VAD contract (distance selling) with the acquirer.

The IVR (Interactive Voice Response) channel is assimilated to the MOTO channel. The transaction is processed in distance selling acceptance. You have to subscribe to a VAD contract (distance selling) with BNP Paribas, supporting MOTO channel.

Use of the mobile application does not require any acquirer configuration. To find out more about this connector, please read the In-App JSON documentation.

In the case of end-of-day payment, all transactions accepted during the day are sent for payment collection in the evening. This method applies to the means of payment functioning on dual-message mode (a message for authorisation and a message for collection).

If this method is not supported by a specific means of payment,Mercanet overrides the captureMode parameter with the default value of the means of payment in question (for more information, please read the integration guides of the means of payment).

In the case of deferred payment, payment collection of the transaction is done N days after online acceptance.

The validity period of the authorisations of the means of payment is set out in the contract between you and the acquirer (six days by default for CB, VISA and Mastercard).

Depending on the validity period of the authorisation, the number of days of deferred collecting that is communicated in the payment request can have an impact on the transaction life cycle:

• 1st case: the deferred payment is lower or equal to the validity period of the authorisation. The authorisation given by the acquirer is always valid for the total amount of the initial transaction. If the transaction is not cancelled, it is paid on the date of the transaction +N days.
• 3-D Secure specific case: in order to benefit from the liability shift during a 3-D Secure transaction, the deferred payment cannot be greater than the maximum validity period of the authorisation given by the acquirer. If needed, Mercanet overrides the payment deferral if the value you enter is greater.
• 2nd case: the deferred payment is greater than the validity period of the authorisation. The authorisation given during the online purchase by the acquirer is no longer valid during the payment. Depending on the acquirer, Mercanet chooses one of the following scenarios:
  • Acquirer is compliant with the "Account verification" feature: an account verification is sent to the acquirer with the objective to check the transaction card number before performing an authorisation. If the response is positive, Mercanet sends the authorisation request with the real amount of the transaction at D+N. In the case of acceptance, the transaction is sent for collecting.
  • Acquirer is not compliant with the "Account verification" feature: the procedure is the same, but the information request made online is replaced by an imprint (an authorisation request of a small amount).
    As a result,Mercanet makes two authorisation requests:

    • The first authorisation request (of a small amount), called the imprint, to check the card during online acceptance.
    • The second authorisation request for the real amount before payment collecting.

If the means of payment is not compatible with the deferral you have requested, Mercanet overrides the captureDay field.

In the case of payment upon shipping, the transaction is sent for payment collecting following your validation. You indicate the validity period for your transaction in the captureDay field. If you do not validate a given transaction before this period ends, this transaction expires. If you forget to validate within the periods, you can submit the transaction again via the duplication operation. You can validate all or part of the transaction amount, but it is not possible to validate an amount greater than the initial transaction amount.

If the VALIDATION method is not supported by the means of payment, Mercanet overrides it with the default payment modality.

In the case of immediate payment, the transaction is captured during online authorisation. This payment method is not used very frequently and only for means of payment supporting single-message mode (a single message for authorisation and payment).

If this method is not supported by the means of payment, Mercanet overrides the captureMode parameter with the default value corresponding to the means of payment in question (for more information, see the means of payment integration guides).

The means of payment supporting this mode are the following:

• Cetelem 3X 4X CB
• Chèque-Vacances Connect
• CONECS

Batch payment is a deferred exchange of information (in file mode) between you and Mercanet. It allows you to create transaction and/or operation files and then upload them to a secure Mercanet FTP Account.

It is therefore different from a number N of information communicated in real time (transaction mode).

File mode:

1. You have a number N of individual payment transactions and/or operations (N1, N2, N3, N4, etc.).
2. Based on the Office Batch specifications, you create a 'request' file containing these transactions and/or operations, and upload this file to a secure Mercanet FTP account.
3. Mercanet performs rights and file consistency checks (format, size), then processes the information contained in this file and sends authorisation requests to the acquirers.
4. The acquirers process the authorisation requests received and send the responses to Mercanet.
5. Mercanet creates the 'response' file containing the responses to payments and/or transactions and uploads this file to your secure Mercanet FTP account.
6. You download the 'response' file via your secure Mercanet FTP account and then integrate this file into your own information system.

Batch payment proves particularly useful if you have to process a very large number of flows since it saves you from having to provide a real-time response to your customers.

The acquirer's authorisation remains valid for a certain time (six days by default for CB, VISA and Mastercard):

• during this period, the transaction is sent for collecting with the authorisation carried out online
• beyond this period, a new authorisation request is sent to the acquirer prior to payment collecting

The validity period may depend on the acquisition contract concluded between you and the acquirer, this is why an option lets you fix the authorisation period associated with your acquisition contract. This feature is available only for certain means of payment. For more information, see the implementation guides.

In the case of multi-currency transactions, acceptance relates to the customer's currency, but payment is settled in your currency.

You must subscribe to this option with the acquirer.

The acceptance stages for multi-currency transactions are as following:

1. You must manage the price of your online sales in several currencies.
2. When you submit the transaction to the Mercanetserver, you fill in the currency you want in the currencyCode field.
3. The transaction is sent for authorisation and for payment collecting with the same currency code.
4. During payment acquisition, the acquirer converts the transaction into your settlement currency.

In the case of settlement in various currencies, acceptance and settlement are done in the same currency.

You specify the code for the currency used by the customer in the payment request. You must have an acquisition contract and a bank account in the concerned currencies.

Recurring payment via Wallet is proposed by the Mercanet subscription solution.

Please refer to the document subscription to have a functional description and to get the subscription payment implementation methods.

Here are the main use cases:

Saving a payment mean in the wallet during a payment via Paypage

Via Paypage, you can ask for the automatic enrollment of the payment mean in the wallet when the payment is accepted.

Saving the payment mean in the wallet via Walletpage without any payment

Via the Walletpage interface you may can your customer to create a wallet by adding a payment mean.

Saving a mandate in the wallet via the addDirectDebit method of Office (M2M) without any payment

Via the Office (M2M) or Office Batch interfaces, you may create a wallet for your customer with their mandate Id.

For the Nth payments, use the walletOrder method entering the wallet id in the merchantWalletID field.

You may cancel non captured transaction either partially or totally by using the Cancel function available in the Office (M2M), Office Batch and Mercanet Back Office interfaces.

For CB, Visa and Mastercard means of payment, the cancellation operation is no longer possible on a transaction as soon as its bank remittance processing is carried out.

Example: if a transaction (CB, Visa or Mastercard) is carried out on day 1 (D), with captureDay set with 2 and captureMode set with AUTHOR_CAPTURE, it will not be possible to cancel the transaction from day 3 (D+2) 10:00 p.m. CET onwards.

For most other means of payment, the cancellation operations are unavailable every day during the transaction remittance process to the bank (please read appendix 3 ), even on transactions not included in the remittance file.

The process duration may vary depending on the number of transactions to sent for remittance.

It is possible to know a transaction settlement date via Mercanet Back Office, via the reports or via the Office (M2M) getTransactionData function (captureLimitDate field).

In the case of a complete cancellation, the transaction status is set with "cancelled" (transactionStatus CANCELLED), but for a partial cancellation, the status remains unchanged.

The below checks are carried out:

• You have the right of cancellation. If you do not, a responseCode 40 is returned.
• The transaction exists in our database. If it does not, a responseCode 25 is returned.
• The transaction status is "TO_CAPTURE" or "TO_VALIDATE" or "TO_AUTHORIZE" or "TO_CHALLENGE". If not, a responseCode 24 is returned. You may consult the remittance hours per acquirer / private in Appendix 3.
• The amount to cancel is equal or lower than the transaction amount. If it is not, a responseCode 51 is returned.
• No cash management operation is already in progress on the transaction. Otherwise, a responseCode 24 is returned.

Transactions created in validation mode (captureMode = VALIDATION), must be validated fully or partially in order to trigger the payment, by using the Validate function available in the Office (M2M), Office Batch and Mercanet Back Office interfaces.

The transaction is then set to the "to validate" status (transactionStatus = TO_VALIDATE) or to the "waiting for a validation with authorisation request" status (transactionStatus = TO_REPLAY), then to the "to capture" status (transactionStatus = TO_CAPTURE) or directly to the "captured" status (transactionStatus = CAPTURED) depending on the means of payment rules.

You can validate a transaction only once. In the case of a partial payment, the complement can be carried out via the duplication operation.

The below checks are carried out:

• You have the right of validation. Otherwise, a responseCode 40 is returned.
• The transaction exists in our database. Otherwise, a responseCode 25 is returned.
• The transaction status is "TO_VALIDATE". Otherwise, a responseCode 24 is returned.
• The amount to validate is equal or lower than the transaction amount. Otherwise, a responseCode 51 is returned.
• The authorisation request is accepted by the acquirer in the case of a validation with authorisation request (specific to some means of payment). Otherwise, a responseCode other than 00 is returned.
• No cash management operation is already in progress on the transaction. If not, a responseCode 24 is returned.

Case of immediate validations after payment

Your Internet sales business may have forced you to implement your payments in validation mode (captureMode field = VALIDATION), and to send a validation request via Office (M2M) immediately after the payment, either when your customer returns to your merchant website, or when you receive the automatic response. This operation mode is valid, but you must take some implementation precautions and talk with your account manager in order he/she validates your choice.

We use an asynchronous database writing system to optimise your Internet sales success. Through that asynchronous writing system, we are able to accept your payment transactions in real time, even if our database system has just experienced some disruption or slowed down.

However, during a maintenance or in case of an occasional blockage of our database system, the transactions are recorded with a lag time, compared to the payment real time processing. It is therefore necessary to follow the below tips for your automated validations implementation.

In the case of a payment that has already been captured, you can refund the transaction partially or totally using the Refund function available in the Office (M2M), Office Batch and Mercanet Back Office interfaces.

Example: if a transaction (CB, Visa or Mastercard) is carried out on day 1 (D), with captureDay set with 2, it will be possible to refund the transaction totally or partially as soon as the settlement process is finished.

In case of a full refund, the transaction is set to the "refund" status (transactionStatus = TO_CREDIT) or to the "refunded" status (transactionStatus = CREDITED) depending on the means of payment rules. It means that the unavailability rule described above will apply if another refund (total or partial) is carried out.

In case of a partial refund, the transaction status is set back to "sent to bank" (transactionStatus = CAPTURED) after the settlement process.

The below checks are carried out:

• You have the right of refund. If you do not, a responseCode 40 is returned.
• The transaction exists in our database. If it does not, a responseCode 25 is returned.
• The transaction status is "CAPTURED", or "TO_CREDIT". If not, a responseCode 24 is returned. You may consult the remittance hours per acquirer / private in Appendix 3.
• The amount to refund is equal or lower than the transaction amount. If it is not, a responseCode 51 is returned.
• The transaction to refund is not in a chargeback status. If it is, a reponseCode 24 is returned.
• No cash management operation is already in progress on the transaction. Otherwise, a responseCode 24 is returned.

You can create a transaction based on an existing transaction by using the "Duplication" function available in the Office (M2M), Office Batch et Mercanet Back Office interfaces. For example this function lets you recreate a transaction based on a transaction that has expired by mistake, but also lets you make payments in instalments.

The means of payment details are retrieved from the initial transaction by Mercanet. However, you can amend the business details (order number, payment collection method, etc.).

Duplicated transactions are handled just like a new transaction in recurring mode (paymentPattern field set to RECURRING_N).

The below checks are carried out:

• You have the right of duplication. If you do not, a responseCode 40 is returned.
• The transaction exists in our database. If it does not, a responseCode 25 is returned.
• The means of payment used is compatible and allows duplication. If it is/does not, a responseCode 24 is returned.
• The means of payment expiry date is still valid. If it is not, a responseCode 14 is returned.
• The authorisation request is accepted and a responseCode 00 was returned.

The diagnostics feature gives you a detailed status of a transaction specified in your request via the getTransactionData feature of the Office (M2M) interfaces.

The manual response is sent when the customer is redirected to your website once online payment ( Paypage connector) or wallet management (Walletpage connector) is completed. However, you have no guarantee of retrieving the manual response as the customer can decide to close the browser or not to click the 'return to shop' button once payment or wallet management is complete.

The fields returned in the response vary depending on the transaction result (refused or successful).

To ensure the retrieval of the response to the payment request (Paypage and In-App connectors) or to the wallet management request (Walletpage connector), you can request the sending of the so-called automatic response. The response is sent regardless of whether or not the customer returns to your webshop. The response fields vary depending on the result of the transaction (refused or successful).

The URL address of the automatic response can be provided in the request. If it is not provided, the URL address of the merchant configuration is used. If the latter is not provided and no configuration has been made, the automatic response is not sent.

The result of the delivery of the automatic response to the merchant is entered in the automaticResponseStatus field of a payment transaction. The values of this field (SENT, FAILED, TIMED_OUT) are conditioned by the returned HTTP code.

In the case of a failure in the sending of the automatic response (status FAILED or TIMED_OUT), a return is carried out after 15 minutes. In all 5 attempts to send the automatic response are made in case of failure.

This notification is received by the customer at the end of the transaction process. You can get a copy of it by e-mail on a configured address when activating this option. The content of the notification varies depending on the result of the transaction (refused or successful).

The notification to the customer can be sent by e-mail or text message. If both fields are filled in, the notification is sent by email.

The Oppotota check before collecting (card cancellation management) lets you check whether the card used has been cancelled between the authorisation request and the transaction validation or payment collecting.

This check applies only to CB, VISA and MASTERCARD transactions and is relevant only if your transactions are processed by a French bank in the CB network.

The file containing blocked/cancelled cards is populated based on the list of blocked/cancelled cards of the CB network. This file is updated several times a day.

The diagnostic feature allows you to retrieve information about the fraud control of a transaction specified in your request through the getFraudData function of Office (M2M)

The anti-fraud engine is aimed at all merchants who have subscribed to the "Fraud risk management – Business Score" offer and wish to benefit from an anti-fraud tool administered by themselves on the Merchant Extranet.

The anti-fraud engine relies on anti-fraud profiles to evaluate transactions. These are composed of rules that you can configure.

For a functional description and how to implement fraud control online, please consult the Fraud risk management - Go-No-Go and Fraud risk management - Business Score documentation.