logo Sogenactif

Release 22.5

go directly to content

Search by keywords

Set-up guide

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

  • Sogenactif

The features listed below, integrated in the Sogenactif offer, are subject to the acceptance of Société Générale. They are therefore not available for all merchants:

  • payment in instalments
  • selective 3-D Secure
  • recurring payment
  • duplication

Sogenactif 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.).

This document is a Sogenactif feature setup guide. It explains how to use the available features in the various payment interfaces (Sogenactif Paypage, Sogenactif Office Serveur). It also summarises feature availability in each of the interfaces and provides detailed information on the potential impact on your Sogenactif and/or acquirer configuration (requiring verification with the latter).

Specific guides look at the setup of particular features:

  • fraud fighting management: GoNoGo, Scoring
  • means of payment implementation
  • payment pages customisation
  • recurring

This tables indicates, for each payment method, which connector you can use to create a payment. It does not deal with cash management. The connectors compatible for the cash management are listed in the "cash management" section and the operation you can perform for each payment method are summarized in appendix.

Means of payment \ Interfaces Sogenactif Paypage Sogenactif Office Serveur Sogenactif Office Batch Sogenactif In-App Sogenactif Walletpage
CB yes yes yes yes yes
Visa yes yes yes yes yes
MasterCard yes yes yes yes yes
American Express yes yes yes yes yes
VPay yes yes yes yes yes
Maestro yes yes yes yes yes
Visa Electron yes yes yes yes yes
Bancontact yes yes no yes yes
Bancontact mobile yes yes no yes no
Cadhoc
(for future usage)
yes yes no no no
Carte Oney yes yes yes no yes
Carte Cadeau Oney yes yes no no no
Cetelem CPay (formerly Cetelem Aurore) yes no no no no
Cetelem 3X 4X CB yes no no no yes
Cetelem Presto yes no no no no
Cofidis Pay 5x10x20x yes no no no no
Cofidis 3xCB yes no no no no
Facily Pay yes no no no no
Franfinance 3XWEB yes no no no no
Franfinance 4XWEB yes no no no no
iDEAL (old contracts) yes yes no no no
iDEAL (new contracts) yes no no no no
Oney 3x 4x yes no no no no
PayPal yes yes no no yes
SEPA Direct Debit (SDD) yes yes yes no no
Sofortüberweisung yes yes no no no

Means of payment available (yes) / Means of payment unavailable (no)

Features activation may require configuration on the Sogenactif and/or acquirer side.

  • Sogenactif configuration: activation or deactivation of the feature requires a change of configuration on the Sogenactif platform and may involve, eventually, an amendment of the acceptance contract.
  • Acquirer verification: activation or deactivation of the feature may involve an amendment of the acquisition contract.You need to check with your acquirer.

Use of a feature may also involve the addition of certain parameters in the payment request and a possible change of connectors.

Two transaction identification modes are available on Sogenactif 2.0: the TransactionReference mode and the TransactionId mode. The difference between the two modes is the scope of the identification: the TransactionReference must be unique throughout the life of the store, whereas the TransactionId must be unique for the day.

An option also lets you choose the generation mode:

  • you supply the transaction ID in the payment request or
  • you let Sogenactif generate it automatically and you retrieve it in the response.
Note: the TransactionReference is the default identification mode, the transactionId 1.0 has been continued in 2.0 to facilitate the migration of 1.0 merchants to 2.0.

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

There are various possible cases:

Table 1. Shop in TransactionReference mode - The merchant logs into Sogenactif with a transactionReference that they generated
Data Transaction creation via:
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionReference supplied by the merchant Standard use case Standard use case proposed by Sogenactif, can be amended and is displayed in red
transactionId supplied by the merchant Rejection Code = 12 Rejection Code = 12 N/A
transactionId absent OK OK N/A
transactionReference absent Rejection Code = 12 Rejection Code = 12 Rejection Code = 12
Complementary reference generated by Sogenactif s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate
Response content s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Table 2. Shop in TransactionReference mode - The merchant logs into Sogenactif without a TransactionReference (Tref auto)
Data Transaction creation via:
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionReference generated by Sogenactif Standard use case N/A generated by Sogenactif and displayed in red
transactionId supplied by the merchant Rejection Code = 12 N/A
transactionId absent OK N/A
transactionReference supplied by the merchant Rejet Code = 12 Rejection Code = 12
Complementary reference generated by Sogenactif transactionReference s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate
Response content s10TransactionId s10TransactionIdDate transactionReference
Table 3. Shop in TransactionId mode - The merchant logs into Sogenactif with a transactionId that they generated
Data Transaction creation via:
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionId supplied by the merchant Standard use case Standard use case proposed by Sogenactif, can be amended and is displayed in red
transactionId absent Rejection Code = 12 Rejection Code = 12 Rejection Code = 12
transactionReference supplied by the merchant Rejection Code = 12 Rejection Code = 12 N/A
transactionReference absent OK OK N/A
Complementary reference generated by Sogenactif transactionReference transactionReference transactionReference
Response content s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Table 4. Shop in TransactionId mode- The merchant logs into Sogenactif without a TransactionId (Tid auto)
Données Transaction creation via:
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionId generated by Sogenactif Standard use case N/A generated by Sogenactif and displayed in red
transactionId supplied by the merchant Rejection Code = 12 N/A
transactionReference supplied by the merchant Rejection Code = 12 N/A
transactionReference absent OK N/A
Complementary reference generated by Sogenactif s10TransactionId s10TransactionIdDate TransactionReference s10TransactionId s10TransactionIdDate TransactionReference
Response content s10TransactionId s10TransactionIdDate transactionReference

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.

Table 5. Shop in transactionReference mode - Original transaction generated with a transactionReference
Data Cash management
transactionId supplied by the merchant OK
transactionReference supplied by the merchant OK
Consistent transactionReference and transactionId supplied by the merchant OK
transactionReference and transactionId not referencing the same transaction supplied by the merchant Rejection Code = 12
New transaction (duplication) See transaction creation table above
Table 6. Shop in transactionId mode - Original transaction generated with a transactionId
Data Cash management
transactionId supplied by the merchant OK
transactionReference supplied by the merchant OK
Consistent transactionReference and transactionId supplied by the merchant OK
transactionReference and transactionId not referencing the same transaction supplied by the merchant Rejection Code = 12
New transaction (duplication) See transaction creation table above

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 Sogenactif Paypage customisation guides.

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

Attention: the display of the Sogenactif means of payment selection page is useless if the brand selection option (MIF) is activated on your webshop and if you only offer the CB, VISA and Mastercard means of payment.

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.

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

Sample means of payment selection page:



Table 7. Summary
Available connectors Sogenactif Paypage
Sogenactif configuration YES Means of payment selection page not displayed by default.
Acquirer checking NO
Parameter in the payment request YES paymentMeanBrandList: optional, choice of means of payment to be displayed. Possible values are listed in the data dictionary.

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

Table 8. Summary
Available connectors Sogenactif Paypage
Sogenactif configuration YES Sogenactif ticket displayed by default
Acquirer checking NO
Parameter in the payment request YES paypageData.bypassReceiptPage: indicator that lets you hide the ticket page during payment.

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 following message is displayed to your client:


screenshot with the message: your payment attempt failed, please try again

Attention: if the payment returns an acquirer code 03 (invalid acceptor) then all the means of payment attached to this same acquirer contract will not be offered during the new payment attempt.

Example of means of payment linked to a same acquiring contract: CB, Visa, Mastercard.
If no other means of payment can be offered, the payment will be definitely refused witthout possible retry.

Table 9. Summary
Available connectors Sogenactif Paypage
Sogenactif configuration YES
Acquirer checking NO
Parameter in the payment request NO

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

Table 10. Summary
Available connectors Sogenactif Paypage
Sogenactif configuration YES
Acquirer checking NO
Parameter in the payment request NO

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



Table 11. Summary
Available connectors Sogenactif Paypage, Sogenactif Walletpage
Sogenactif configuration YES Display of webshop name not activated by default
Acquirer checking NO
Parameter in the payment request NO
Entry of card number in seperate blocks

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.



Table 12. Summary
Available connectors Sogenactif Paypage, Sogenactif Walletpage
Sogenactif configuration YES Card number entry in separate blocks activated by default
Acquirer checking NO
Parameter in the payment request NO

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


screenshot with the following message : an error has occured. Please contact your merchant.

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

Table 13. Summary
Available connectors Sogenactif Paypage (POST)
Sogenactif configuration YES Parameter “Display the error page”
Acquirer checking NO
Parameter in the payment request YES manualErrorResponseInitPOST: merchant's URL to return to the website in case of payment initialisation error.

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

Table 14. Summary
Available connectors Sogenactif Paypage (POST)
Sogenactif configuration YES Parameter “Display the error page”
Acquirer checking NO
Parameter in the payment request YES automaticErrorResponseInitPOST: merchant's URL to receive the automatic response in case of payment initialisation error.

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

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

Table 15. Summary
Available connectors Sogenactif Paypage, Sogenactif Walletpage
Sogenactif configuration NO
Acquirer checking NO
Parameter in the payment request NO

To select your payment channel, you must fill in the orderChannel field in the payment request. This information is important because it determines the rules of acceptance and acquisition for transaction processing.

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

Table 16. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur Sogenactif Office Batch
Sogenactif configuration YES
Acquirer checking YES mandatory VADS contract
Parameter in the payment request YES orderChannel: INTERNET

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.

Tip: on connectors side, it is adviced using MAIL_ORDER or TELEPHONE_ORDER instead of MOTO.
Table 17. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch
Sogenactif configuration YES
Acquirer checking YES mandatory VAD contract supporting MOTO
Parameter in the payment request YES orderChannel:

MOTO
TELEPHONE_ORDER
MAIL_ORDER
FAX

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.

Table 18. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch
Sogenactif configuration YES (MOTO channel configured)
Acquirer checking YES mandatory VAD contract supporting MOTO
Parameter in the payment request YES orderChannel: IVR

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

Table 19. Summary
Available connectors Sogenactif In-App
Sogenactif configuration YES
Acquirer checking NO Assimilated to the internet channel
Parameter in the payment request YES orderChannel: INAPP

The paymentPattern, captureMode and captureDay fields let you set the payment collecting methods.

To find out more about the availability of these methods for each means of payment, please refer to their integration guides.

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,Sogenactif 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).

Table 20. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration NO
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: AUTHOR_CAPTURE
  • captureDay: 0 (0 deferred day, evening collecting)

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, Sogenactif 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, Sogenactif 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, Sogenactif 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,Sogenactif 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, Sogenactif overrides the captureDay field.

Table 21. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration NO
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: AUTHOR_CAPTURE
  • captureDay: N (Number of days of deferred payment)
Note: the account checking is a regulatory development of CB, VISA, MASTERCARD and AMEX and replaces the imprint. This feature is subject to the acquirer compliance.

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, Sogenactif overrides it with the default payment modality.

Table 22. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration YES VALIDATION option to activate
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: VALIDATION
  • captureDay: N (validity period before the validation)
Note: For 3-D Secure payments, if you wish to validate the transaction more than 6 days after its creation or if you are sending the order in several instalments, please refer to the multiple payments upon shipping.

The payment in instalments is addressed to the merchant who want to offer payment facilities to their customers.

To get a functional description and implementation instructions for the payment in instalments, please refer to the payment in instalments guide.

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, Sogenactif 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
  • Cetelem 3X 4X CB
  • Cetelem Presto
  • Chèque-Vacances Connect
  • CONECS
  • iDEAL
  • Sofortüberweisung
Table 23. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration NO
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: IMMEDIATE
  • captureDay: 0

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

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

File mode:


diagram representign the kinematics of files processing

  1. You have a number N of individual payment transactions and/or operations (N1, N2, N3, N4, etc.).
  2. Based on the Sogenactif Office Batch specifications, you create a 'request' file containing these transactions and/or operations, and upload this file to a secure Sogenactif FTP account.
  3. Sogenactif 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 Sogenactif.
  5. Sogenactif creates the 'response' file containing the responses to payments and/or transactions and uploads this file to your secure Sogenactif FTP account.
  6. You download the 'response' file via your secure Sogenactif 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.

Table 24. Summary
Available connectors Sogenactif Office Batch
Sogenactif configuration NO
Acquirer checking NO
Parameter in the payment request N/A

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.

Table 25. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration YES By default six days for CB / Visa / Mastercard cards
Acquirer checking YES
Parameter in the payment request NO

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 Sogenactifserver, 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.
Table 26. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration YES The accepted currencies must be defined in the Sogenactif configuration.
Acquirer checking YES
Parameter in the payment request YES currencyCode: Transaction currency code. The possible values are listed in document Data dictionary.

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.

Tip: to implement this advanced feature, please contact the technical support.
Table 27. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration YES The accepted currencies must be defined in the Sogenactif configuration.
Acquirer checking YES Acquisition contract with settlement in various currencies.
Parameter in the payment request YES currencyCode: transaction currency code. The possible values are listed in the data dictionary.


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 Sogenactif service.
Tip: to implement this advanced feature, please contact the technical support.
Table 28. Summary
Available connectors Sogenactif Paypage
Sogenactif configuration YES The accepted currencies must be defined in the Sogenactif configuration and agreed with the acquirer and the exchanger.
Acquirer checking YES
Exchange contract YES
Parameter in the payment request YES currencyCode: indicate in this field the code of your basic currency. Possible values are listed in the data dictionary.

3-D Secure is a mandatory authentication protocol designed to reduce the risk of payment fraud on the Internet. Its purpose is to ensure that the card is used by its true owner. In addition to this security aspect, 3-D Secure allows you to benefit from the liability shift to the bank issuing the card, according to rules issued by the CB, VISA, MASTERCARD, AMEX and Bancontact networks.

Recurring payment defines the rules and conditions for the payment of a service over a given period, validated between the merchant and their client. Using recurring payment is a good way for paying services linked to subscriptions.

In its use case, there are two phases in recurring payment:

  • 1st phase: the collection of card details is done with the customer being present and is associated or not with a payment. This card information will be used for the following payments under the agreement between you and the customer.
  • 2nd phase: the Nth payments are sent without customer action, using card information stored during the 1st phase.

Supported means of payment: CB, Visa, Mastercard, American Express, Bancontact and SDD.

3-D Secure for card recurring payments

To secure recurring payments, it is mandatory to do the initial transaction (first payment) in 3-D Secure mode in order to authenticate the card holder. The Nth following payments are not in 3-D Secure mode because the card holder is not present.

Processing recurring payments according to PCI requirements

Sogenactif allows you to use card information in a secure way, avoiding PCI constraints linked to card data storage. It is possible to send the Nth payments using several ways:

  • duplicate the initial transaction
  • payment via a Wallet (card stored in the wallet)
Attention: you have to inform your customers that you store their information and you have to inform them about the terms of recurring payments (duration, amount, periodicity…)

Details on how to handle subscription payments using duplication method is fully described on subcription payment using duplication guide.

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

Here are the main use cases:

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

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

Attention: If the payment mean used is a card, you must keep track of the schemeTransactionIdentifier returned in response. You will have to transmit this value in the field InitialSchemeTransactionIdentifier for the recurring payments to chain them with the initial transaction (PSD2).
Table 29. Summary
Available connectors Sogenactif Paypage
Sogenactif configuration YES Automatic enrolment option in the wallet when a Sogenactif Paypage payment is accepted.
Acquirer checking NO
Parameter in the request

YES
  • merchantWalletID: Wallet Id
  • paymentPattern: RECURRING_1
  • challengeMode3DS : value forced to CHALLENGE_MANDATE
Reporting

  • Transactions report: YES
  • Operations report: NO
  • Sogenactif Gestion: YES

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

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

IMPORTANT: this interface can no longer be used to set up a subscription with a card because as there is no payment involved, you will not receive any chaining identifier on response. Therefore, you will not be able to provide it on the recurring payments.
Table 30. Summary
Available connectors Sogenactif Walletpage
Sogenactif configuration YES Sogenactif Walletpage option
Acquirer checking YES Recurring option
Parameter in the request

YES
  • merchantWalletID: Id in which the PAN or the mandate will be stored
  • walletActionNameList: ADDPM to add a payment mean
  • PaymentMeanBrandList: SEPA_DIRECT_DEBIT
Reporting

  • Transactions report: NO
  • Operations report: NO
  • Sogenactif Gestion: NO

Saving a mandate in the wallet via the addDirectDebit method of Sogenactif Office Serveur without any payment

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

Table 31. Summary
Available connectors Sogenactif Office Serveur,
Sogenactif configuration YES Wallet option
Acquirer checking YES Recurring option
Parameter in the request YES
  • merchantWalletID: wallet Id
  • mandateId: mandate Id
  • paymentMeanBrand: SEPA_DIRECT_DEBIT
Reporting

  

  • Transactions report: NO
  • Operations report: NO
  • Sogenactif Gestion: NO

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

Attention: If the payment mean associated to the wallet is a card, you have to set the field initialSchemeTransactionIdentifier with the value of the schemeTransactionIdentifier you received when the subscription was set up.
Table 32. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch
Sogenactif configuration YES Not activated by default
Acquirer checking YES Recurring option
Parameter in the request YES
  • paymentPattern: RECURRING_N
  • merchantWalletID: Id of the wallet in which the payment mean is stored
  • initialSchemeTransactionIdentifier : chaining identifier received when the subscription was set up (only applicable if the payment mean is a card)
Reporting

  

  • Transactions report: YES
  • Operations report: NO
  • Sogenactif Gestion: YES
Note: the wallet is limited to one means of payment to ease the recurring payment. (1 wallet = 1 means of payment).

You only have to manage the wallet Id and not the Id of the means of payment stored in the wallet.

One Clic payment is for merchants who want to ease the payment for their customers.

This service allows customers to register their payment details in a secure area called Wallet and thus avoid having to re-enter this information for future payments.

One Clic payment simplifies the payment act, improves the user experience particularly for mobile purchases, and thus increases the conversion rate.

For a functional description and the implementation methods of the One Clic payment, please read the One Clic document.

Transaction life cycles differ depending on the means of payment, so the new status of the transaction can differ as well. The detailed life cycles are available in the means of payment integration guides.

Tip: if you receive a response due to a technical error (responseCode 90 or 99) or a transaction status refusal (responseCode 24) in response to your cash management operation, we advise you to try again.

You may cancel non captured transaction either partially or totally by using the Cancel function available in the Sogenactif Office Serveur, Sogenactif Office Batch and Sogenactif Gestion 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 Sogenactif Gestion, via the reports or via the Sogenactif Office Serveur 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.
Note: you may find all the response codes in the Data Dictionary here.
Table 33. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Sogenactif configuration YES Not activated by default
Acquirer checking NO
Reporting

  • Transactions report: NO
  • Operations report: YES, CANCEL
  • Sogenactif Gestion: YES

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 Sogenactif Office Serveur, Sogenactif Office Batch and Sogenactif Gestion 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.
Tip: you may find all the response codes in the Data Dictionary here.
Table 34. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Sogenactif configuration YES VALIDATE
Acquirer checking NO
Reporting

  • Transactions report: NO
  • Operations report: YES, VALIDATE
  • Sogenactif Gestion: YES

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 Sogenactif Office Serveur 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.

Response code Description Possible causes Implementation tips
00 The validation is accepted. NTR NTR
25 The validation is rejected as the transaction cannot be found in the database Case 1: you have made a mistake in the request. The transaction identification data (transactionReference, transactionId or transactionDate) is wrong, or you are trying to validate a payment that has not ended (for example, the customer has stopped the payment).
Case 2: the payment transaction has been processed to the end but it is not yet recorded in the database due to our asynchronous database writing system. We advise to set up an automatic recovery batch of these failed validation attempts and to run this batch at least 30 minutes after the payment, to allow the necessary time to insert the transaction in the database. If you receive a new code 25, this is not a case 2, but certainly a case 1, described below.
99 The validation failed as our cash management system is punctually unreachable Case 1: we are experiencing a technical incident, we are making every effort to restore the situation as soon as possible. You will receive an e-mail describing the incident. We advise to set up an automatic recovery batch of these failed validation attempts and to run this batch at least 30 minutes after the payment, to allow the necessary time for the service restoration. While receiving a code 99, recover your validation request.
Case 2: we are in maintenance. In case of a scheduled maintenance, an e-mail has been sent to you a few weeks ago.

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 Sogenactif Office Serveur, Sogenactif Office Batch and Sogenactif Gestion interfaces.

Note: every day, during the transaction remittance process to the bank (which takes place between 10 p.m. and 11 p.m. CET for the majority of means of payment), refund operations are unavailable on all transactions.

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.
Tip: you may find all the response codes in the Data Dictionary here.
Table 35. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Sogenactif configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: NO
  • Operations report: YES, REFUND
  • Sogenactif Gestion: YES

You can create a transaction based on an existing transaction by using the "Duplication" function available in the Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion 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 Sogenactif. 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.
Tip: you may find all the response codes in the Data Dictionary here.
Table 36. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Sogenactif configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: YES
  • Operations report: YES, DUPLICATE
  • Sogenactif Gestion: YES

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

Table 37. Summary
Available connectors Sogenactif Office Serveur
Sogenactif configuration YES Diagnostic not activated by default
Acquirer checking NO
Parameter in the diagnostics request YES transactionReference or s10TransactionId + s10TransactionIdDate

The manual response is sent when the customer is redirected to your website once online payment ( Sogenactif Paypage connector) or wallet management (Sogenactif 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).

Table 38. Summary
Available connectors Sogenactif Paypage, Sogenactif Walletpage
Sogenactif configuration NO
Acquirer checking NO
Parameter in the payment request

YES normalReturnUrl: <url> URL address for manual response (mandatory)

To ensure the retrieval of the response to the payment request (Sogenactif Paypage and Sogenactif In-App connectors) or to the wallet management request (Sogenactif 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.

HTTP 200 HTTP 201 HTTP 204 HTTP 205 HTTP 301 HTTP 301 HTTP 404 HTTP 408 HTTP 504 HTTP 500 HTTP 503 default
SENT X X X X X X
FAILED X X X X
TIMED

_OUT

X X
Table 39. Summary
Available connectors Sogenactif Paypage, Sogenactif In-App, Sogenactif Walletpage,
Sogenactif configuration YES Automatic response not activated by default
Acquirer checking NO
Parameter in the payment request YES automaticResponseUrl : <url> URL address for automatic response (optional)

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.

Tip: to implement this advanced feature (text message confirmation), please contact the technical support.
Table 40. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Sogenactif configuration YES Confirmation not activated by default
Acquirer checking NO
Parameter in the payment request

  

YES
  • customerContact.email: <customer email address> For notification by e-mail
  • customerContact.mobile: <customer phone number> For notification by text message

The following reports allow you to follow your shop activity:

  • Transactions report
  • Operations report
  • Reconciliations report
  • Chargebacks report
  • Expired cards report

The reports are sent by e-mail daily by default, except for the expired cards report, which is sent monthly. You can choose the reports you want to be sent.

Table 41. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App, Sogenactif Walletpage
Sogenactif configuration YES Not activated by default
Acquirer checking NO/YES Depends on the acquirer or financial establishment for reconciliations reports and chargebacks reports

By default, settlements operations are not listed in the operations report. If you want to include them in this report, you may subscribe to a specific option.

By default, transactions which have not been reconciled are not listed in the reconciliations report. If you want to include them in this report, you may subscribe to a specific option.

For more information, please read the Reports documentation.

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.

Table 42. Summary
Available connectors Sogenactif Paypage, Sogenactif Office Serveur,Sogenactif Office Batch , Sogenactif In-App
Sogenactif configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request NO

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.

Once the check done, if you decide to accept the transaction, you will use the acceptChallenge operation.

Attention: no cash management operation should already be in progress on the transaction. Otherwise, a responseCode 24 is returned (responseCode chart).
Table 43. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion, Portail Sogenactif
Sogenactif configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES transactionReference or s10TransactionId + s10 TransactionIdDate

Once the check done, if you decide to refuse the transaction, you will use the refuseChallenge operation.

Attention: no cash management operation should already be in progress on the transaction. Otherwise, a responseCode 24 is returned (responseCode chart).
Table 44. Summary
Available connectors Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion, Portail Sogenactif
Sogenactif configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES transactionReference or s10TransactionId + s10 TransactionIdDate

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

Table 45. Summary
Available connectors Sogenactif Office Serveur
Sogenactif configuration YES Diagnostic not activated by default
Acquirer checking NO
Parameter in the payment request YES transactionReference or s10TransactionId + s10 TransactionIdDate

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

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 - Scoring documentation.

Tip: to implement this advanced feature, please contact the technical support.

The Honor All Cards functionality allows merchants to select the brands and usages they wish to accept and which involve the CB, Visa and Mastercard schemes.

By default, without the activation of this functionality and for a merchant with a CB/Visa/Mastercard contract, all brands and usages are accepted.

The selectable brands are:
  • CB
  • VISA
  • VPAY
  • ELECTRON
  • MASTERCARD
  • MAESTRO
The selectable usages are:
  • Credit
  • Debit
  • Prepaid
  • Commercial
Tip: to implement this advanced feature, please contact the technical support.

As a payment acceptance solution, the Sogenactif 2.0 solution is subject to the European MIF Regulation (OJ EU 2015/751 L123 of 19/05/2015). Among these rules, "Brand Selection" requires you to offer the customer with a co-branded card the choice of brand at the time of payment, which impacts the payment page.

A co-branded card is a card that supports at least two brands. Most cards issued in France are co-branded with CB (CB/VISA, CB/MASTERCARD, CB/MAESTRO, etc.).

To implement the brand selection, please read the 'Integration of National Bank Card' documentation

AVS is a feature used in certain countries such as the United Kingdom to fight fraud. AVS lets you request the cardholder's address (see the fields affected below), send it in the authorisation request, and let the card issuer compare this address with the one it has on record. AVS includes checks of street names and postcodes.

The response of an authorisation and the result of the AVS check are independent, i.e. it is possible for the acquirer to approve the authorisation request with false AVS checks.

In the request you must specify the AVS data check methods during online acceptance of the transaction. If you specify that the result of the AVS check should condition acceptance of the transaction, then an authorisation granted with a failed AVS check will be refused by Sogenactif. In this case, an automatic reversal operation is sent to the acquirer by Sogenactif to reset the card authorisation limit.

Parameters Values Note
checkAVS Y/N Specifies whether the AVS check must be carried out. Deactivated by default.
ignorePostcodeCheckResult Y/N Ignores the result of the postcode check (inactive by default).
ignoreAddressCheckResult Y/N Ignores the result of the street name check (inactive by default).
holderAddress.addressAdditional1 Address Contains information about the cardholder's street.
holderAddress.addressAdditional2 Address
holderAddress.addressAdditional3 Address
holderAddress.streetNumber Number
holderAddress.street Street
holderAddress.postbox Postbox
holderAddress.city City
holderAddress.state State
holderAddress.zipCode Postcode Contains information about the cardholder's postcode.

Transactions refused following a failed AVS return a response code 14 and an acquirer response code 00.

Two dedicated AVS response codes (avsPostcodeResponseCode and avsAddressResponseCode) are returned in the payment response (not currently available on Sogenactif Paypage) and appear in the transactions report.

A surcharge is an additional fee added to a cheque or card payment (cash payments are not affected) with the objective of covering the cost of acceptance incurred by the merchant. The surcharge can be prohibited by the card issuers – completely (e.g. Visa and Mastercard in the US) – or when the merchant applies a prohibited rate. Regulations can authorise or prohibit the surcharge. "Without surcharge" means that the surcharge is included in the price (even in the case of cash payment).

On Sogenactif Paypage, the surcharge is calculated by Sogenactif during the payment. You need to enroll in the "Surcharge" option and configure the surcharge amount linked to the product code of the card. Two types of surcharge can be applied: a fixed amount or a percentage of the transaction. The authorisation amount sent to the acquirer equals the total amount of the transaction + the surcharge.

To configure the surcharge, you need to provide the card scheme, the product code of the card, the currency and the fixed amount or percentage.

On Sogenactif Office Serveur, you are responsible for calculating the surcharge. The total amount in the payment request sent to Sogenactif contains the surcharge.

ARP is the name used in Sogenactif for the MARP (Mastercard Advanced Registration Program) and MUPP (Mastercard Utility Payment Program) solutions by Mastercard.

The goal of this feature is to suggest automatically the bypassing of the 3-D Secure process if the card has already undergone the first 3-D security check (as part of the same contract with the acquirer). It therefore simplifies the payment process for trusted cardholders.

The 3-D Secure process is triggered upon the first payment with the card. The following payment with the same card (as part of the same contract) is identified as an ARP transaction and the 3-D Secure process is not displayed.

In the case of a payment where 3-D authentication is bypassed by ARP, the value in the HolderAuthentProgram field in the responses is ARP.

The conditions of use for ARP are the following:

  • you need to subscribe to the 3-D Secure programme
  • the ARP option must be activated in Sogenactif
  • it must be a Mastercard or Maestro card
  • your acquirer must be ARP compliant
Table 46. Summary
Available connectors Sogenactif Paypage
Sogenactif configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request NO

Sogenactif Paypage Sogenactif Office Serveur Sogenactif Office Batch Sogenactif In-App Sogenactif Walletpage
Transactions identification
Identification at creation yes yes no no yes
Cash management identification no yes yes no no
Identification in reporting yes yes no no yes
Secure Paypages management
Page customisation yes no no no yes
Display of payment means yes no no no no
Ticket displayed by Sogenactif yes no no no no
Number of payment attempts yes no no no yes
New payment attempt yes no no no no
Duration of time on payment pages yes no no no no
Display of webshop name yes no no no yes
Card number entry in separate blocks yes no no no yes
Error page display yes no no no no
Display of waiting message yes no no no no
iFrame tag yes no no no yes
Payment channel
Internet yes yes yes no no
MOTO yes yes yes no no
Mobile application no no no yes no
Payment collection methods
End-of-day payment yes yes yes yes no
Deferred payment yes yes yes yes no
Payment on dispatch yes yes yes yes no
Payment by instalments yes no no no no
Immediate payment yes yes yes yes no
Validity period for the authorisation yes yes yes yes no
Payment in different currencies
Multi-currency acceptance yes yes yes yes no
Settlement in different currencies yes yes yes yes no
Dynamic currency conversion yes no no no no
3-D Secure
3-D Secure yes yes no yes yes
Blocking non-guaranteed 3D transactions yes yes no yes no
Safekey security
Safekey security yes yes no no yes
One Clic Payment
One Clic enrollment with payment yes no no yes no
One Clic enrollment without payment no yes yes no yes
One Clic payment yes yes yes yes no
Subscription payment
Subscriber registration with 1st payment yes no no no no
Subscriber registration without payment no yes yes no yes
Subscription payment no yes yes no no
Cash management
Cancellation no yes yes no no
Validation no yes yes no no
Refund no yes yes no no
Duplication no yes yes no no
Online reporting
Diagnostic no yes no no no
Manual response yes no no no yes
Automatic response yes no no yes yes
End of transaction confirmation to customer yes yes yes yes no
Reporting file
Transactions report yes yes yes yes no
Operations report yes yes yes yes no
Reconciliations report yes yes yes yes no
Chargebacks report yes yes yes yes no
Wallet expiration report yes yes yes yes no
Fraud
Fraud detection before collecting (Oppotota checks) yes yes yes yes no
acceptChallenge no yes yes no no
refuseChallenge no yes yes no no
Fraud diagnostic no yes no no no
Country-specific aspect
Brand selection (MIF) yes yes yes yes no

Feature available (yes) / Feature unavailable (no).

Yes = feature available

No = feature unavailable

Conditional = feature available with specificity, please refer to the integration guide in question

L : List C : Cancel
V : Validation R : Refund
D : Duplication
Cards / Payment means Authorised features Validity of the authorisation request
L C V R D
CB Yes Yes Yes Yes Yes 6 days*
Visa Yes Yes Yes Yes Yes 6 days*
Mastercard Yes Yes Yes Yes Yes 6 days*
American Express Yes Yes Yes Yes Yes 6 days*
Vpay Yes Yes Yes Yes Yes 6 days*
Maestro Yes Yes Yes Yes Yes 6 days*
Visa Electron Yes Yes Yes Yes Yes 6 days*
Bancontact Yes No No Yes Yes Immediate payment
Bancontact mobile Yes No No No No Immediate payment
Oney card Yes Yes Yes Yes Yes Deferred payment
Oney gift card Yes No No Yes Yes Immediate payment
Cetelem CPay (formerly Cetelem Aurore) Yes Yes Yes Conditional Yes 60 days
Cetelem 3X 4X CB Yes No No Yes No Immediate payment
Cetelem Presto Yes Conditional No No No Immediate payment
Cofidis Pay 5x10x20x Yes Yes Yes Yes No 99 days
Cofidis 3xCB Yes Yes Yes Yes No 6 days
Facily Pay Yes Yes Conditional Conditional No 30 days
Franfinance 3xWEB Yes Yes Yes Yes No 99 days
Franfinance 4xWEB Yes Yes Yes Yes No 99 days
iDeal Yes No No Yes No Immediate payment
Oney 3x 4x Yes Yes Yes Yes No 30 days
Paypal Yes Yes Yes Yes Yes 29 days
SEPA Direct Debit (SDD) Yes Yes Yes Conditional Yes Deferred payment
Sofortüberweisung Yes No No Conditional No Immediate payment

*by default the authorization request is 6, but it is also configurable.

Below is a table showing the current hourly programming of remittance batches per acquirer / owner.

Acquirer Settlement start time*
AMEX 22h00
Armoney 22h00
Banksys 22h00
Barclays 22h00
Bancontact 05h00
BNP Paribas 22h00
Crédit Agricole Consumer Finance 19h00
Caisse Centrale Banques Populaires 22h00
Crédit Commercial de France 22h00
Crédit Du Nord 22h00
Cedicam 22h00
Cetelem Crédit 22h00
Cetelem Débit 17h00
CIC 22h00
Crédit Lyonnais 22h00
Crédit Mutuel Centre Est Europe 22h00
Crédit Mutuel de Bretagne 22h00
Caisse Nationale des Caisses d'Epargne 22h00
Cofidis 05h00
Diners 22h00
Franfinance 22h00
La Banque Postale 22h00
Natwest 22h00
Paypal 17h00
Société Générale 22h00
SPS 22h00
* Indicated time is CET (Central European Time).

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

Configuration