logo Sogenactif

Release 22.4

go directly to content

Search by keywords

Full migration

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

  • Sogenactif

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 on despatch, deferred payment, recurring payment, payment in instalments, etc.).

The purpose of this document is to explain the migration to Sogenactif 2.0.

This document is intended to merchant of the offer Sogenactif 1.0 and who suscribe a new Sogenactif 2.0 contract (new contract / new MID) .

Its purpose is to facilitate the migration to Sogenactif 2.0.

For any technical question or request for assistance, our services are available Monday to Friday, from 9 am to 7 pm, excluding public holidays:

  • by telephone at: +33 (0) 825 090 095 (0,15 € TTC/min + price of a call – price as of 01/11/2021)
  • by e-mail: supportsogenactif@worldline.com

In order to facilitate the processing of your requests, please provide your merchantId (15-digit number).

The following comparative table introduces the benefits of the various interfaces:

Criteria Sogenactif Paypage interface Sogenactif Office Serveur interface
Suggested Equivalence Sogenactif Payment 1.0

Pages with redirection hosted by Sogenactif.

Sogenactif Office Server 1.0
Functional scope

Transaction creation only

Transaction creation and cash management.

Tip: you can use Sogenactif Paypage for payment and Sogenactif Office Serveur for cash management.
PCI/DSS

Benefits from PCI certification because the payment process is outsourced to the Sogenactif servers.

You do not know the customer's PAN.

In transaction creation, the handling of payment pages is done by you, so it is subject to the PCI-DSS certification.
Tip: you can limit your scope by not storing any PAN information in your information system (for example, replacing PAN with a token or a Wallet ID or a hashPan).
The tokeniser solution is part of the feature table (§ 3.1.1) and may be introduced to you by the Société Générale teams.
3-D Secure 3-D Secure process handled by Sogenactif and transparent to you.
You drive the 3-D Secure authentication process.
Tip: you can use the Sogenactif MPI to handle exchanges with the Visa/MC directory servers.
Integration effort Plug & Play solution easy to integrate Solution requiring more development: on-board payment on the merchant side with handling of payment pages…
Adding a means of payment

No development effort for you in most cases.

Note: you may need to populate specific fields in the payment request to take advantage of the means of payment options (PayPal example).
Development effort on the merchant side to integrate the means of payment (handling of processes, of pages, etc.).
Customer path Limited disruption between your website and the payment server thanks to the available customisation (CSS, URL) of the payment pages. No disruption between your website and the payment server.
Integration into your IS Interfaces with your shop. Interfaces with your shop or Back Office.
Reporting Consistent reporting
rcha What changes after the migration
Data and format New request and automatic/manual response format.
New payment url
New cash management url via Sogenactif Office Serveur.
Possibility to keep the transactionId and keep the1.0 reports formats.
Cash management New access only for your old transactions with Sogenactif 2.0.
Reporting New reports format.
Tip:

In case you keep the identification with the transactionId, you can keep the 1.0 reports format or benefit from the new 2.0 reports format. However, the 2.0 reports only evolve and benefit from new fields added.

Access to the extranets Acces to Portail Sogenactif (unique entry point to access to different management tools)
  • Cash management back office
  • User management back office
  • Fraud management back office
  • Custompages: tool to help to customize the payment pages
  • Sogenactif Téléchargement: tool allowing to download the secret key (which secures the exchanges between the merchant website and Sogenactif)
Fraud Autonomous management of anti-fraud controls via access to the extranet Portail Sogenactif.
Connectors Non intrusive connectors replacing the API.
New secret key (for reach webshop) which replaces the certificat Sogenactif 1.0.
Payment means
Payment means in 2.0 only.
URL New url for Sogenactif Paypage
New url for Sogenactif Office Serveur

On Sogenactif 1.0, the transaction identification system is made possible by the assembly of the following 4 fields:

  • merchantId (N15): fixed value provided by Sogenactif
  • merchantCountry (A2): fixed value provided by Sogenactif
  • transactionDate (YYYYMMDD): variable value given by Sogenactif (in French local time zone) at the moment of the payment acceptance
  • transactionId (N6): variable value given by you or by Sogenactif in your delegation at the time of the payment request (i.e. before the authorisation request). This value must be unique for the combination of the 3 above fields.

Operations associated with a transaction are identified by five-part element, the above 4 fields supplemented with an operation_sequence.

On Sogenactif, there are two ways to generate the transaction identifier:

  • Generating the id on your own
  • Automatic generation by Sogenactif

As on Sogenactif 1.0, the default mode for generating the transaction identifier is the generating you make. This mode is recommended because it allows you to store the context and prepare the reconciliation of your transaction before sending the request.

The automatic generating mode is an easy integration that is not recommended if you generate significant flows because it has some disadvantages:

  • The duplicate transaction check is performed by Sogenactif on this identifier sent by you. So, in the case of the identifier self-generating, this check cannot be performed.
  • The absence of transactionId or transactionReference in the request requires you to use other data (customer, orderId, amount) to reconcile the response and the request.
  • It is not possible to send a request to Sogenactif with the Diag method in the event of a fault (example: you did not receive the response, etc.).

On Sogenactif 2.0, the standard identification of the transaction is done through a new identifier: transactionReference.

This new identifier has the advantage of being in ANS35 format which allows:

  • to keep this unique identifier in an unlimited way (over the period during which the transaction exists in Sogenactif: 15 months) instead of one day for transactionId.
  • to use alphanumeric characters in the reference with an open format enabling the generating by yourself
  • to be independent on time zones (internationalisation)

In order to minimise any impact, the use of transactionId is maintained in Sogenactif 2.0.

On Sogenactif 2.0, you need to be in one of these two modes:

  • transactionReference mode (default mode)
  • transactionId mode

If you would like to remain in transactionId mode you need to make a request to Sogenactif when registering your merchant ID with the Sogenactif 2.0 offer.

All transactions on Sogenactif 2.0 are linked both to a transactionId + transactionIdDate and to a transactionReference.

transactionId, transactionIdDate and transactionReference are stored, returned and displayed for all transactions.

In the 2.0 interfaces, the transactionId and transactionIdDate fields have been named s10TransactionId and s10TransactionIdDate so that you can directly and easily identify the reference to Sogenactif 1.0.

In a nutshell:

  • the transactionReference is the default way to identify a transaction.
  • the s10TransactionId allows you to identify a transaction while remaining compatible with Sogenactif 1.0 (if you continue to use the transactionId).
  • the s10TransactionId + s10TransactionIdDate pair ensures the uniqueness of the transaction.

During a transaction creation, and depending on the chosen mode, Sogenactif accepts or rejects the creation and generates additional identifiers. The table below summarises the various possible cases.

Transaction creation via
Use case Data Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
Shop in transactionReference mode
You connect to Sogenactif with a transactionReference generated by you. transactionReference provided by you. Use case Use case Offered by Sogenactif, editable and displayed in red.
transactionId provided by you.

Reject

Reject Code = 12

Reject

Code = 12

N/A
Absent transactionId OK OK N/A
Absent transactionReference

Reject

Code = 12

Reject

Code = 12

Reject

Code = 12

Additional reference generated by Sogenactif.

s10TransactionId

s10TransactionIdDate

s10TransactionId

s10TransactionIdDate

s10TransactionId

s10TransactionIdDate

Content response

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

You connect to Sogenactif without transactionReference (Tref auto) transactionReference generated by Sogenactif Use case N/A Generated by Sogenactif and displayed in red.
transactionId provided by you.

Reject

Code = 12

N/A
Absent transactionId OK N/A
transactionReference provided by you.

Reject

Code = 12

N/A
Additional reference generated by Sogenactif.

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

Content response

s10TransactionId

s10TransactionIdDate

transactionReference

Shop in transactionId mode
You connect to Sogenactif with a transactionId generated by you. transactionId provided by you. Use case cas d'usage Offered by Sogenactif, editable and displayed in red
Absent transactionId

Reject

Code = 12

Reject

Code = 12

Reject

Code = 12

transactionReference provided by you.

Reject

Code = 12

Reject

Code = 12

N/A
Absent transactionReference OK OK N/A
Additional reference generated by Sogenactif. transactionReference transactionReference transactionReference
Content response

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

You connect to Sogenactif without transactionId (Auto Tid). transactionId generated by Sogenactif. Use case N/A Generated by Sogenactif and displayed in red.
transactionId provided by you.

Reject

Code = 12

N/A
transactionReference provided by you.

Reject

Code = 12

N/A
Absent transactionReference OK N/A
Additional reference generated by Sogenactif.

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

Content response

s10Transaction Id

s10TransactionIdDate

transactionReference

For cash operations, the identification of a transaction is not limited to the chosen mode.

The table below shows the various options available.

Use case Data Cash management
Shop in transactionReference mode
Original transaction generated with a transactionReference. transactionId provided by you. OK
transactionReference provided by you. OK
Consistent transactionReference and transactionId provided by you. OK
transactionReference and transactionId (not referencing the same transaction) provided by you.

Reject

Code = 12

New transaction (duplication, recycling and cardholder credit) See the transactions creation table above.
Shop in transactionId mode
Original transaction generated with a transactionId. transactionId provided by you. OK
transactionReference provided by you. OK
Consistent transactionReference and transactionId provided by you. OK
transactionReference and transactionId (not referencing the same transaction) provided by you.

Reject

Code = 12

New transaction (duplication, recycling and cardholder credit). See the transactions creation table above.
  • transactionId mode

To make a payment in instalments in transactionId mode, you need to send a transactionId list and a transactionIdDate list in the payment request. Sogenactif automatically generates a transactionReference for each transaction.

If the transactionId list is not sent, the transaction is rejected with a responseCode = 12.

  • transactionReference mode

To make a payment in instalments via the transactionReference mode, you need to send a transactionReference list and the date of each due date in the payment request. Sogenactif automatically generates a transactionId for each transaction.

If the transactionReference list is not sent, the transaction is rejected with a responseCode = 12.

Payment in instalments is not compatible with the above mode in which the transaction reference is automatically generated by Sogenactif.

  • Reports

The s10TransactionId, s10TransactionIdDate and transactionReference fields are included in the 2.0 Transactions, Operations, Reconciliation and Chargebacks reports, regardless of the enabled transaction identification mode.

For duplicate and recycling operations, the original transaction can be identified via the s10FromTransactionId, s10FromTransactionIdDate and transactionTransferReference fields in the Transactions report.

  • Sogenactif Gestion

Searching for a transaction in Sogenactif Gestion can be done with either a transactionId or a transactionReference.

If you have opted for the transactionReference, both columns will always be present in Sogenactif Gestion in the following screens:

  • list of transactions following a searching
  • detail of a transaction.

Adding a PAN to gray lists via the transaction reference is possible via the use of transactionId or transactionReference.

In 1.0 checks are made on the 1.0 fraud check tool.

In 2.0, you use the new 2.0 fraud engine manageable from the Sogenactif Portal.

On Sogenactif 1.0, in order to bypass one or more additional checks, you need to notify the keyword corresponding to the checking in the DATA field of the API. On Sogenactif 2.0, you need to enter the values of the bypassCtrlList and bypassInfoList fields.

The bypass keywords correlation is described in the 1.0 / 2.0 Data correlation guide.

The checkings not linked to the means of payment (ex. customer outstanding payments, gray list, etc.) are not shared between 1.0 and 2.0.

  • The migration of gray lists from 1.0 to 2.0 is supported by the migration process.

The main features of 2.0 fraud management are:

  • Go-No-Go mode (some of the controls correspond to what is already present in Sogenactif 1.0), it is a fraud control module present by default in Sogenactif 2.0
  • Go-No-Go+ mode (optional in the Sogenactif 2.0 offer)
Mode Géolocalisation Velocity Black, grey and white lists Miscellaneous Basket controls
Go-No-Go
  • IP country
  • card country
  • Ip and card country
  • card
  • IP
  • customer id
card number PAN
  • Oppotota
  • card/client and client/card
  • commercial card
  • virtual card
  • amount
  • card with mandatory authorization
  • card expiry date
  • risky products list
  • risky products quantity
  • risky product ratio
  • products quantity
Go-No-Go+
  • IP country
  • card country
  • Ip and card country
  • billing and delivery adress
  • billing and card country
  • billing and delivery postal code
  • card
  • IP
  • customer id
  • card number PAN
  • IP adress
  • customer id
  • postal codes
  • e-mail
  • name
  • phone number
  • Oppotota
  • card/client and client/card
  • commercial card
  • virtual card
  • amount
  • card with mandatory authorization
  • card expiry date
  • CB scheme
  • card number and IP adress
  • free email
  • number of customer by card
  • Ip adress reputation
  • email adress syntax
  • risky products list
  • risky products quantity
  • risky product ratio
  • products quantity
  • RMS (Risk Management system) GUI: viewing / updating of the configuration

We have identified a list of steps that are essential for a successful migration from Sogenactif 1.0 to Sogenactif 2.0. These steps can be schematised as follows:


Diagram describing the different steps of the technical migration and the contractual modifications.

You start your migration. On the one hand the technical migration. Step 1, Worldline studies the services and options used by the Worldline customer and presents the different migration scenarios to the customer and provides the appropriate documents. Step 2, you implement the necessary changes to migrate to Worldline Sips 2.0 and perform your tests on the 2.0 recipe store. Step 3, you recover your secret on Sips download and set it up to go live. Concerning the contractual modification steps, step 1, you exchange with Worldline concerning the amendment to the Worldline Sips contract. Step 2, Worldline sends you the amendment for signature. Step 3, you send the completed and signed amendment to your sales contact. Once all these steps have been completed, your migration is finished

The successive steps below refer to the 'Timing' part. You will need to follow these to successfully complete your migration to Sogenactif 2.0:

  • Choose migration modalities
    • Choice of connectors depending on your operation mode
    • Decision to remain in transactionId or to switch to transactionReference
  • Install the connectors

    • Transposition of 1.0 / 2.0 data (reports, fraud, etc.)
  • Customise payment pages if you choose the paypage mode

    • Make local tests with a tool provided by Société Générale
    • Send CSS to Sogenactif
  • Use the customer test environment to test the Sogenactif Paypage and Sogenactif Office Serveur applications using the available test shop

    • Retrieve test identifiers
    • Make tests on the test environment
    • Check the tests performed
    • Send a migration report to Société Générale
  • Start in production

    • Check the shop configuration in configuration
    • Send the request to start in production
    • Integrate the production shop IDs
    • Activate the switch to Sogenactif 2.0
    • Monitor the post-switch data
  • Remove references to Sogenactif 1.0 on your site: certificate, setting files, executable files, etc.

You have a shop in 1.0, so you have a merchantId which allows to log in. All your transactions are made with this merchantId and you enjoy consolidated reports and a visualisation of all your transactions on Sogenactif Gestion with all means of payment combined.

You pilot the migration. After issuing your migration report, the decision of the date and time of migration is taken jointly between you and Société Générale. A close monitoring of the first flows is done by you and Société Générale to ensure the smooth running of the 2.0 migration.

In case you detect an anomaly (unidentified issue during the test phase of your internal developments), flows can be migrated back to Sogenactif 1.0 via the APIs.

This solution remains possible as long as you and Sogenactif keep valid 1.0 login credentials. The 1.0 accesses removing is done during the last step. The removal of the 1.0 accesses is performed during the last step. Your access to the Sogenactif 1.0 tools will be maintained to allow you to access to the transaction history and to manage transactions until you express your wish to close your shop permanently. closing your shop permanently Sogenactif 1.0.

Société Générale has developed a new Sogenactif platform, allowing you to:

  • simplify Sogenactif integration and standardise connection methods thank to new state of the art Sogenactif connectors.
  • optimise the customer experience thanks to new features and new ergonomics of the customer interfaces (InApp application, webresponsive, etc.).
  • have greater autonomy in the management of transactions and settings thanks to a new Extranet interface.
  • facilitate the deployment on the international market thanks to new means of payment.
  • enjoy advanced features such as an effective anti-fraud tool, dashboard, etc.

If you have created a new shop in 2.0 you will have two separate merchantId.

From the 2.0 interfaces you cannot access and manage transactions created in Sogenactif 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in Sogenactif 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in Sogenactif 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in Sogenactif 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in Sogenactif 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

However, you can can use the extended duplication feature that allows from a 2.0 shop to duplicate a transaction from another shop, even if the transaction is in 1.0.

In the case where you keep the identification by TransactionId, you have the option to keep your reports in the old 1.0 format or to enjoy the new 2.0 reports format at your convenience.

However, only 2.0 reports evolve and enjoy new added fields. If you keep the 1.0 format, you will not enjoy the updates (ex. adding a means of payment related additional data in the reports).

The s10TransactionId and s10TransactionIdDate fields have been added to the Transactions, Operations, Reconciliations and Chargebacks 2.0 reports.

You can opt for transactionReference mode at any time. For example, you have the opportunity to migrate to Sogenactif 2.0 by keeping the transactionId mode to facilitate the migration and then opt for the transactionReference in order enjoy the advantages of this new format.

If you have opted for the transactionReference mode you can no longer switch to the transactionId mode, because if you are in transactionId mode, the extranet display is not changed, and the transactionReference is not visible. This would prevent manipulating transactions generated with the transactionReference mode.

Customising payment pages is an optional step to start in 2.0. Sogenactif offers customisation by default.

There is no migration tool that reproduces the customisation of 1.0 payment pages. We do not recommend attempts to reproduce exactly the visuals of the 1.0 payment pages on the 2.0 payment pages. Indeed, it would be a shame to be deprived of the new opportunities offered by the 2.0 payment pages, especially from the responsiveness point of view.

It is recommended to change the payment pages customisation in order to enjoy the advantages of the 2.0 payment pages.

A page customisation guide is available.

The wallet database is shared between Sogenactif 1.0 and 2.0.

The SUBSCRIPTION subscribers data base is already migrated to the wallet database.

The list of means of payment available in 2.0 is provided in § 3.1.2 of this guide.

Fraud checks available in 2.0 are detailed in the "Anti-fraud management" guide.

Please contact your usual contact.

Société Générale provides you with a test shop that allows you to validate your internal developments.

When you have finished your test phase, you provide a migration report and determine jointly with Société Générale the date and time of your migration.

Following this migration, a careful monitoring of the first flows is performed.

The first scenario described here is to open a new shop in 2.0.

This scenario may be suitable in case you would like to quickly implement a new means of payment for a shop without having to migrate all your flows, or you use some means of payment not yet available in 2.0.

You will have two shops, a Sogenactif 1.0 one for your current means of payment, and a Sogenactif 2.0 shop for one or more new means of payment.

Both shops are attached to the same customer, but you will have 2 merchantId.

The standard procedure for registering a new 2.0 shop should be used.

You access and manage the transactions in the 1.0 or 2.0 environments/interfaces in which you created those transactions.

Reports: you receive your reports by shop, 1.0 and 2.0 reports are not consolidated. The 2.0 reports isolate flows related to Sogenactif 2.0 transactions.

This scenario allows you to benefit from the new 2.0 report format for your second shop. However, this option is not mandatory, you can keep the 1.0 format if you want to keep the existing reporting processing in your Back Office. This is valid for Transactions report, Operations report, Reconciliation report and Chargebacks reports types.

IMPORTANT: if you would like to keep reports in 1.0 format, you will not get strictly 2.0 data. The impacts are to be measured depending on the features and means of payment you have selected.

Extranet: you can keep the same URL and your existing login/password by using the super-user feature.

However, you do not have access to a consolidated history of your 1.0 and 2.0 transactions since you keep your existing login for your 1.0 shop and use a new login for your new 2.0 shop.

In 1.0 checks are made on the 1.0 fraud check tool.

In 2.0, you use the 2.0 fraud engine accessible from Sogenactif Portal.

Checks not related to the means of payment (ex. customer outstanding payments, gray list, etc.) are not shared between 1.0 and 2.0.

The creation of lists in 2.0 is handled via a specific request. Please contact your Société Générale privileged interlocutor.

There is a coexistence of 1.0 and 2.0 billing items.

Both shops are linked to the same charged customer with the same billing model.

  • Compartmentatlisation of fraud 1.0 and fraud 2.0.
  • Do not use the same means of payment in 1.0 AND in 2.0 with a single distance selling contract because the reconciliation does not work properly when several shops of the same merchant have the same acquisition contract.

Please find in this appendix a summary table of the reference documents available to accompany your migration:

Need Reference documentation
Connectors Sogenactif Paypage documentation
Sogenactif Office Serveur documentation
Sogenactif Office Batch documentation
Pages customisation Pages customisation
Reports 1.0 2.0 reports correlation guide
Fields 1.0 2.0 data correlation guide
Data dictionary Data dictionary
Online documentation https://documentation.sips.worldline.com/en/
Sogenactif Gestion Sogenactif Gestion
Sogenactif Téléchargement Sogenactif Téléchargement
Sogenactif CustomPages Sogenactif CustomPages

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