WL SIPS DOCS

When you register, Worldline makes available on Sips Download a secret key which allows to secure the exchanges between your site and the Worldline Sips server. A secret key compromised (and used by a malicious third party) might disrupt the regular operation of your shop and might in particular generate unauthorised sales or cash transactions (e.g. refunds). In the event that a secret key is compromised, you are required to ask as quickly as possible for its revocation then for its renewal via Sips Download.

To ensure compliance with the PCI DSS standard, an alerting system is set up to warn you that your secret key expires and so to renew it via the Sips Download interface. This alerting is done in 3 steps by sending informative e-mails which are by default set as follows:

• 1st alert 90 days before the key expiry date – main recipients: your Administrator and Technical contacts
• 2nd alert 45 days before the key expiry date – main recipients: your Administrator and Technical contacts; secondary recipient: your Account Manager
• 3rd alert 20 days before the key expiring date– main recipients: your Administrator and Technical contacts; secondary recipient: your Account Manager

You may request different thresholds to be set for the sending of alert e-mails. To do so, please contact our technical support.

This alerting process terminates for a given key if it is disabled before the expiry date or if the expiry date is exceeded.

This management of your secret keys allows you to be autonomous in the management of your keys by validating the actions yourself, while taking responsibility.

During the creation of a transaction and depending on the selected mode, Worldline Sips 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 Sips Paypage customisation guides.

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

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.

Worldline Sips 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, Worldline Sips refuses the transaction.

Sample means of payment selection page:

The payment confirmation page or "payment ticket" is displayed by default by Worldline Sips. 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 Worldline Sips.

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 Sips Office Extranet

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 Worldline Sips payment pages. This period begins when the customer arrives on the Worldline Sips payment pages.

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

Card number entry can be divided into blocks of four numbers. In the case of Amex and BCMC, this option is adapted to the length of the card number.

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 Sips Office Extranet interface.

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

For more information, please read the Sips 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 the acquirer, supporting MOTO channel.

Use of the mobile application does not require any acquirer configuration. To find out more about this connector, please read the Sips 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,Worldline Sips 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, Worldline Sips 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, Worldline Sips 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, Worldline Sips 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,Worldline Sips 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, Worldline Sips 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, Worldline Sips 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, Worldline Sips 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:

• Bancontact
• Bancontact mobile
• BCACB 3X 4X
• Cadhoc
• Cadocarte
• Carte Cadeau Oney
• Cetelem 3X 4X CB
• Cetelem Presto
• Chèque-Vacances Connect
• CONECS
• iDEAL
• Illicado
• Lepotcommun
• Lydia
• Spiritofcadeau

Batch payment is a deferred exchange of information (in file mode) between you and Worldline Sips. It allows you to create transaction and/or operation files and then upload them to a secure Worldline Sips 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 Sips Office Batch specifications, you create a 'request' file containing these transactions and/or operations, and upload this file to a secure Worldline Sips FTP account.
3. Worldline Sips 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 Worldline Sips.
5. Worldline Sips creates the 'response' file containing the responses to payments and/or transactions and uploads this file to your secure Worldline Sips FTP account.
6. You download the 'response' file via your secure Worldline Sips 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 Worldline Sipsserver, 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.

Dynamic currency conversion (DCC) is a financial service for Visa and Mastercard cardholders. It lets the customer pay in their currency and the merchant to be paid in theirs.

DCC enables you and the local bank, which is the acquirer (handles payment in your name), to take advantage of the exchange fees normally added to such transactions by VISA and Mastercard and the international issuing banks. You always receive the settlement in your basic currency.

To use the Dynamic Currency Conversion (DCC), you must:

• subscribe to an acquisition contract with the DCC option.
• subscribe to an exchange rate service.
• request the DCC option when enroling in the Worldline Sips service.

You have the possibility to send your authentication requests or authorisation requests to a PSP other than Worldline Sips, via the new version of the Sips Office connector.

Two use cases are possible:

• You send your authentication request to Worldline Sips, in return you receive the 3-D Secure technical data. Then, you send your authorisation request to another PSP with 3-D Secure technical data in order to benefit from the payment guarantee.
• You forward your authentication request to another PSP that can return the 3-D Secure technical data. Then, you send your authorisation request to Worldline Sips with 3-D Secure technical data in order to benefit from the payment guarantee.

For more information, please refer to the 3-D Secure guide.

Risk taking is an option you can subscribe to that allows you to force the creation of a mandate and any associated SDD. Forced payments via this option will not be guaranteed and therefore can not be compensated in case of an outstanding payment.

For more information, please refer to our SDD integration guide.

Recurring payment via Wallet is proposed by the Worldline Sips 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 Sips Paypage

Via Sips 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 Sips Walletpage without any payment

Via the Sips 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 Sips Office without any payment

Via the Sips Office or Sips 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.

For the first payment, you indicate in the request that it is the first payment of a recurring payment. You have to subscribe to the token option of the Worldline Sips solution. In return, you receive a token that you will use for future recurring payments. During a 3-D Secure kinematic, the token is also returned at the check enrollment step by the Sips Office and Sips In-App connectors.

For the Nth payments, you send in the request the token given back during the first transaction.

You may cancel non captured transaction either partially or totally by using the Cancel function available in the Sips Office, Sips Office Batch and Sips Office Extranet 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 Sips Office Extranet, via the reports or via the Sips Office 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 Sips Office, Sips Office Batch and Sips Office Extranet 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 Sips Office 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 Sips Office, Sips Office Batch and Sips Office Extranet 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 do an unlimited refund, i.e. you can refund an amount greater than the paid transaction.

To do an unlimited refund, you use the same function as in the case of a standard refund, but you must have an additional option and define an authorised excess percentage compared to the original transaction amount.

If the limit is exceeded, the refund is refused.

The below checks are carried out:

• Checks identical to those carried out for a standard refund, except for the amount check.
• The amount to refund is equal or lower than the authorised exceedance. 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.

You can create a transaction based on an existing transaction by using the "Duplication" function available in the Sips Office, Sips Office Batch et Sips Office Extranet 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 Worldline Sips. 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.

You can create a transaction based on an existing transaction initiated by one of your other webshops by using the Extended duplication function available in Sips Office and Sips Office Batch.

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

Duplicated transactions are handled in the same way as new transactions in recurring mode (paymentPattern field set to RECURRING_N).

The below checks are carried out:

• Same checks as the ones carried out on a standard duplication.
• The webshop used to do the duplication has to be set up with the extended duplication right. If not, a responseCode 40 is returned.

If you have the card or token (see the Tokenisation paragraph) details of your customer's card, you can refund the customer without referring to a previous transaction via the creditHolder function of the Sips Office, Sips Office Batch and Sips Office Extranet connectors.

If you have subscribed to the OneClick option and the card is saved in the wallet, you can also do a cardholder credit from the wallet instead of the original card number (PCI compliant) via the walletCreditHolder function of the Sips Office and Sips Office Batch connectors.

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

The manual response is sent when the customer is redirected to your website once online payment ( Sips Paypage connector) or wallet management (Sips 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 (Sips Paypage and Sips In-App connectors) or to the wallet management request (Sips 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 card number can be converted into a token during the payment process and returned in the manual and automatic responses.

The token is also returned in response of check enrolment service in a 3DS payment process via the Sips Office and Sips In-App connectors.

You can then use this token to submit recurrent payments via the Sips Office connectors.

In the event that the tokenisation processing cannot be completed, an option is used to interrupt the payment process.

You may also continue the payment process and then choose to tokenise the transaction by using the “transaction tokenisation” feature described below.

This feature encrypts one or more card numbers into one or more tokens. The order of the tokens is not guaranteed, i.e. the first number entered in the connector is not necessarily the first token to appear in the response. The tokenPanId field is used to retrieve the token associated with the number of the sent card.

The output data in the response contains as many tokens as there are pairs of filled in tokenPanId and tokenPan fields.

This feature encrypts one card number from an existing transaction into one token. You can use this feature with the transactionId or the transactionReference mode (see the transaction identification mode).

You have the possibility to send only one transaction per request.

This feature decrypts one or several tokens into one or several card numbers. The order of the card numbers is not guaranteed, i.e. the first token entered in the connector is not necessarily the first card number to appear in the response. The panId field is used to retrieve the card number associated with the token sent.

The output data in the response contains as many card numbers as there are pairs of populated panId and pan fields.

You can send a payment request by specifying the token instead of the PAN via the cardOrder function of the Sips Office and Sips Office Batch connectors or via the orderInitialize function of the Sips In-App connector.

You must firstly retrieve the customer's token either in return of a payment or through the tokenisation feature.

You can refund a customer from their own token. This is the secure version of the cardholder credit feature as you do not need to know your customer's card number.

Via the CreditHolder feature of the Sips Office interfaces, you carry out a cardholder credit transaction using a token instead of a PAN.

First, you have to retrieve the customer's token either in return for a payment or through the tokenisation feature.

At the end of the payment process, one or two hashPan calculated from the card number can be returned in the automatic and/or manual responses.

The hashed (hashPan field) PAN (Primary Account Number or card number) is calculated based on an irreversible cryptographic function (unlike the token). ). It lets you check the frequency of use of a card in return for payment.

The automatic and/or manual response contains as many hashPan as there are hashSalt and hashAlgorithm fields entered in the payment request.

HashSalt is used to increase the complexity of the calculated hash and prevent finding the card number using a reverse hash dictionary function.

Worldline Sips offers to return two hashPan to enable you to change algorithm and so to avoid a break in the checks carried out in return of the payment.

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 CHALLENGE option allows you to put in hold transactions with an ORANGE score. It allows you to check the risk before proceeding with the other acceptance steps: validation, re-authorisation or capturing the transaction (settlement).

If you do not have the CHALLENGE option, the transaction is accepted.

You have X days to measure the fraud risk and to validate or refuse the transaction. X is the maximum value between the validity of the authorisation and the capture time (captureDay) you have set up in the payment request.

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

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.