logo Sogenactif

Release 21.6

aller directement au contenu
Rechercher par mots clés

Configuration des fonctionnalités

Pour rechercher dans la page utiliser Ctrl+F sur votre clavier

  • Sogenactif

Les fonctionnalités listées ci-dessous, proposées dans l’offre Sogenactif, sont soumises à l’acceptation préalable de Société Générale. Elles ne sont donc pas disponibles pour tous les commerçants :

  • paiement échelonné ;
  • 3-D Secure sélectif ;
  • paiement récurrent ;
  • duplication.

Sogenactif est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métiers liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement échelonné, …).

Ce document est un guide de configuration des fonctionnalités de Sogenactif. Il vous explique comment utiliser les fonctionnalités disponibles dans les différentes interfaces de paiement (Sogenactif Paypage, Sogenactif Office Serveur). Il présente également un résumé de la disponibilité des fonctionnalités dans chacune des interfaces et fournit des renseignements détaillés sur l’impact éventuel sur votre configuration Sogenactif et/ou sur votre configuration acquéreur (nécessitant une vérification auprès de ce dernier).

La mise en œuvre de certaines fonctionnalités fait l’objet de guides spécifiques :

The implementation of certain functionalities is the subject of specific guides:

  • Gestion de la lutte contre la fraude : GoNoGo, Scoring ;
  • Implémentation des moyens de paiement ;
  • Personnalisation des pages de paiement ;
  • Guide d'intégration One Clic ;
  • Guide d'intégration des paiements récurrents.
Interfaces
Moyens de paiement
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Office Batch Sogenactif In-App Sogenactif Walletpage
CB oui oui oui oui oui
Visa oui oui oui oui oui
MasterCard oui oui oui oui oui
American Express oui oui oui oui oui
VPay oui oui oui oui oui
Maestro oui oui oui oui oui
Visa Electron oui oui oui oui oui
Bancontact oui oui non oui oui
Bancontact mobile oui oui non oui non
Cadhoc (pour usage futur) oui oui non non non
Carte Oney oui oui oui non oui
Carte Cadeau Oney oui oui non non non
Cetelem CPay (anciennement Cetelem Aurore) oui non non non non
Cetelem 3X 4X CB oui non non non oui
Cetelem Presto oui non non non non
Cofidis Pay 5x10x20x oui non non non non
Cofidis 3xCB oui non non non non
e-Chèques Vacances oui oui non non non
Facily Pay oui non non non non
Franfinance 3XWEB (pour usage futur) oui non non non non
Franfinance 4XWEB (pour usage futur) oui non non non non
iDEAL (anciens contrats) oui oui non non non
iDEAL (nouveaux contrats) oui non non non non
Masterpass (pour usage futur) oui oui non non non
Oney 3x 4x oui non non non non
Paylib oui oui non non non
PayPal oui oui non non oui
SEPA Direct Debit (SDD) oui oui oui non non
Sofortüberweisung oui oui non non non

Moyen de paiement disponible (oui) / Moyen de paiement indisponible (non).

L’activation des fonctionnalités peut nécessiter une configuration côté Sogenactif et/ou une vérification côté acquéreur.

  • Configuration Sogenactif : l’activation ou la désactivation de la fonctionnalité nécessite un changement de configuration sur la plateforme Sogenactif et entraîne, éventuellement, une modification du contrat d’acceptation.
  • Vérification acquéreur : l’activation ou la désactivation de la fonctionnalité peut engendrer une modification du contrat d’acquisition. Vous devez vous renseigner auprès de votre acquéreur.

L’utilisation d’une fonctionnalité peut aussi entraîner l’ajout de certains paramètres dans la requête de paiement ainsi qu’un éventuel changement de connecteurs.

Deux modes d’identification des transactions sont disponibles sur Sogenactif 2.0 : le mode transactionReference et le mode transactionId. La différence entre les 2 modes est la portée de l’identifiant, le transactionReference doit être unique durant toute la vie de la boutique alors que le transactionId doit être unique sur la journée.

Une option permet également de choisir le mode de génération :

  • vous fournissez l’identifiant de la transaction dans la requête de paiement ou
  • vous laissez Sogenactif le générer automatiquement et vous le récupérez dans la réponse.
Remarque : le transactionReference est le mode d’identification par défaut, le transactionId 1.0 a été reconduit en 2.0 pour faciliter la migration des commerçants 1.0 vers 2.0.

Lors d’une création de transaction, et en fonction du mode choisi, Sogenactif accepte ou rejette la création et génère des identifiants complémentaires.

Différents cas sont possibles :

Tableau 1. Boutique en mode TransactionReference - Le commerçant se connecte à Sogenactif avec un transactionReference qu’il a généré
Données Création de transaction via :
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionReference fourni par le commerçant Traitement standard Traitement standard proposé par Sogenactif, modifiable et affiché en rouge
transactionId fourni par le commerçant Rejet Code = 12 Rejet Code = 12 N/A
transactionId absent OK OK N/A
transactionReference absent Rejet Code = 12 Rejet Code = 12 Rejet Code = 12
Référence complémentaire générée par Sogenactif s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Tableau 2. Boutique en mode TransactionReference - Le commerçant se connecte à Sogenactif sans transactionReference (Tref auto)
Données Création de transaction via :
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionReference généré par Sogenactif Traitement standard N/A généré par Sogenactif et affiché en rouge
transactionId fourni par le commerçant Rejet Code = 12 N/A
transactionId absent OK N/A
transactionReference fourni par le commerçant Rejet Code = 12 Rejet Code = 12
Référence complémentaire générée par Sogenactif transactionReference s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference
Tableau 3. Boutique en mode TransactionId - Le commerçant se connecte à Sogenactif avec un transactionId qu’il a généré
Données Création de transaction via :
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionId fourni par le commerçant Traitement standard Traitement standard proposé par Sogenactif, modifiable et affiché en rouge
transactionId absent Rejet Code = 12 Rejet Code = 12 Rejet Code = 12
transactionReference fourni par le commerçant Rejet Code = 12 Rejet Code = 12 N/A
transactionReference absent OK OK N/A
Référence complémentaire générée par Sogenactif transactionReference transactionReference transactionReference
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Tableau 4. Boutique en mode TransactionId - Le commerçant se connecte à Sogenactif sans transactionId (Tid auto)
Données Création de transaction via :
Sogenactif Paypage Sogenactif Office Serveur Sogenactif Gestion
transactionId généré par Sogenactif Traitement standard N/A généré par Sogenactif et affiché en rouge
transactionId fourni par le commerçant Rejet Code = 12 N/A
transactionReference fourni par le commerçant Rejet Code = 12 N/A
transactionReference absent OK N/A
Référence complémentaire générée par Sogenactif s10TransactionId s10TransactionIdDate TransactionReference s10TransactionId s10TransactionIdDate TransactionReference
Contenu réponse s10TransactionId s10TransactionIdDate transactionReference

Pour les opérations de caisse, le mode d’identification d’une transaction n’est pas limité au mode choisi lors de la création.

Les tableaux ci-dessous reprennent les différentes possibilités.

Tableau 5. Boutique en mode transactionReference - Transaction d'origine générée avec un transactionReference
Données Gestion
transactionId fourni par le commerçant OK
transactionReference fourni par le commerçant OK
transactionReference et TransactionId cohérents fournis par le commerçant OK
transactionReference et transactionId ne référençant pas la même transaction fournie par le commerçant Rejet Code = 12
Nouvelle transaction (duplication, recyclage) Voir Tableau de création des transactions ci-dessus
Tableau 6. Boutique en mode transactionId - Transaction d'origine générée avec un transactionId
Données Gestion
transactionId fourni par le commerçant OK
transactionReference fourni par le commerçant OK
transactionReference et transactionId cohérents fournis par le commerçant OK
transactionReference et transactionId ne référençant pas la même transaction fournie par le commerçant Rejet Code = 12
Nouvelle transaction (duplication, recyclage) Voir Tableau de création des transactions ci-dessus

Les champs s10TransactionId, s10TransactionIdDate et transactionReference sont présents dans les journaux de transactions, d’opérations, de rapprochements et d’impayés, quel que soit le mode d’identification de transaction.

Pour les opérations de duplication et de recyclage, la transaction d’origine est identifiable via les champs s10FromTransactionId, s10FromTransactionIdDate et fromTransactionReference du journal des transactions.

Pour plus de détails veuillez consulter les guides de personnalisation de Sogenactif Paypage.

La page de sélection des moyens de paiement Sogenactif n’est pas affichée automatiquement. Elle peut être gérée soit sur votre site marchand soit par Sogenactif. Une option permet d’afficher systématiquement cette page par Sogenactif.

Attention: l'affichage de la page de sélection des moyens de paiement Sogenactif est inutile dans le cas où l'option de la sélection de la marque (MIF) est activée sur votre boutique et si vous ne proposez que les moyens de paiement CB, VISA et Mastercard.

Néanmoins, dans le cas où les moyens de paiement ne sont pas du même type (carte et Paypal par exemple), la page de sélection s’affiche systématiquement. Quand plusieurs moyens de paiement sont configurés dans votre contrat, vous pouvez filtrer ceux qui s’afficheront dans la page de sélection des moyens de paiement grâce au champ paymentMeanBrandList :

  • un seul moyen de paiement : la page de sélection des moyens de paiement ne s’affiche pas ;
  • une liste de moyens de paiement : l’affichage des moyens de paiement se fait dans l’ordre d’alimentation du champ ;
  • champ non renseigné : tous les moyens de paiement configurés s’affichent.

Sogenactif affiche les moyens de paiement qui correspondent à la fois

  • à la liste des moyens de paiement prévus dans votre configuration

et

  • aux données de la transaction (contrôle de la devise de la transaction par exemple).

Si aucun moyen de paiement compatible n’est trouvé, Sogenactif refuse la transaction.

Exemple d’affichage de la page de sélection du moyen de paiement :



Table 7. En résumé
Connecteur disponible Sogenactif Paypage
Configuration Sogenactif OUI Pas d’affichage de la page de sélection des moyens de paiement par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI paymentMeanBrandList : optionnel, choix des moyens de paiement à afficher. Les valeurs possibles sont listées dans le dictionnaire des données

La page de confirmation du paiement, appelée « ticket de paiement », est affichée par défaut par Sogenactif. Néanmoins, vous pouvez choisir de l’afficher vous-même sur votre site en utilisant les éléments fournis dans le message de réponse envoyé à l’URL de réponse (normalReturnUrl). Vous pouvez également décider dynamiquement, en fonction du contexte de la transaction, de ne pas afficher le ticket produit par Sogenactif.

Table 8. En résumé
Connecteur disponible Sogenactif Paypage
Configuration Sogenactif OUI Affichage du ticket Sogenactif par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI paypageData.bypassReceiptPage : Indicateur permettant de cacher la page du ticket lors du paiement.

Habituellement, une nouvelle tentative de paiement est proposée au client uniquement en cas de saisie de PAN invalide. Cette option supplémentaire permet d’étendre les nouvelles tentatives de paiements sur d’autres types de refus :

  • refus de l’acquéreur, non typé fraude ;
  • authentification 3DS échouée ;
  • refus de l’outil de lutte contre la fraude, non typé fraude.

Le message suivant est affiché à votre client.



Attention: si le paiement renvoie un code acquéreur 03 (accepteur invalide), alors les moyens de paiements rattachés à ce même contrat acquéreur ne seront pas proposés lors de la nouvelle tentative de paiement.

Exemple de moyens de paiement rattachés à un même contrat acquéreur : CB, Visa, Mastercard, Paylib, Masterpass.
Si aucun autre moyen de paiement ne peut être proposé, alors le paiement sera définitivement refusé sans nouvelle tentative possible.

Table 9. En résumé
Connecteur disponible Sogenactif Paypage
Configuration Sogenactif OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Un délai de 15 minutes d’inactivité est accordé au client pour lui permettre de réaliser son paiement. Au-delà de ce temps imparti, la session utilisateur expire, et il n’est plus possible pour le client de finaliser son achat. Ce délai est fixé à 15 minutes, conformément à la réglementation PCI DSS (condition 8.1.7).

En complément de cette limitation réglementaire, vous avez la possibilité de proposer un délai de présence maximum sur les pages de paiement Sogenactif. Le point de départ de ce délai débute à l’arrivée du client sur la page de paiement Sogenactif.

Table 10. En résumé
Connecteur disponible Sogenactif Paypage
Configuration Sogenactif OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Le nom de la boutique configuré dans Sogenactif peut être affiché dans le bandeau de la page de paiement.



Table 11. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Walletpage
Configuration Sogenactif OUI Affichage du nom de la boutique non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

La saisie du numéro de carte peut être divisée par bloc de 4 numéros. Dans le cas d’Amex et de BCMC, cette option est adaptée à la longueur du numéro de carte.



Table 12. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Walletpage
Configuration Sogenactif OUI . Saisie du numéro de carte en blocs séparés activé par défaut.
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Cette page s’affiche en cas d’une erreur à l’initialisation de paiement uniquement via le connecteur POST (requête mal formatée par exemple).



Le bouton de redirection permet de rediriger l’internaute vers le site du commerçant (avec la réponse manuelle). L’affichage du bouton de redirection est configurable :

Table 13. En résumé
Connecteur disponible Sogenactif Paypage (POST)
Configuration Sogenactif OUI Paramètre « Afficher la page d’erreur »
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI manualErrorResponseInitPOST : URL du commerçant pour le retour à la boutique en cas d’erreur sur l’initialisation du paiement.

En parallèle, une réponse automatique peut être envoyée. L’envoi de cette réponse automatique est configurable :

Table 14. En résumé
Connecteur disponible Sogenactif Paypage (POST)
Configuration Sogenactif OUI Paramètre « Notifier les erreurs »
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI automaticErrorResponseInitPOST : URL du commerçant pour recevoir la réponse automatique en cas d’erreur sur l’initialisation du paiement.

Les pages de paiement Sogenactif peuvent être intégrées à une page de la boutique. Cela n’a aucun impact sur vos pages et vous pouvez utiliser cette fonction sans configuration Sogenactif. Pour plus d’informations, veuillez consulter le guide d’utilisation Sogenactif Paypage iFrame.

Table 15. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Walletpage
Configuration Sogenactif NON
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Pour choisir votre canal de paiement, vous devez remplir le champ orderChannel dans la requête de paiement. Cette information est importante car elle conditionne les règles d’acceptation et d’acquisition du traitement de la transaction.

Pour utiliser le canal Internet, vous devez souscrire un contrat VADS (vente à distance sécurisée) avec l’acquéreur.

Table 16. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch
Configuration Sogenactif OUI
Vérification acquéreur OUI contrat VADS obligatoire
Paramètre dans la requête de paiement OUI orderChannel : INTERNET

Dans le cas des canaux MOTO, MAIL_ORDER ou TELEPHONE_ORDER, la transaction est traitée en acceptation vente à distance. Vous devez souscrire un contrat VAD (vente à distance) acceptant le canal MOTO avec l’acquéreur.

Tip: au niveau des connecteurs, il est conseillé de différencier le canal MAIL_ORDER et TELEPHONE_ORDER, au lieu d'utiliser directement le canal MOTO.
Table 17. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch
Configuration Sogenactif OUI
Vérification acquéreur OUI contrat VAD supportant le MOTO obligatoire
Paramètre dans la requête de paiement OUI orderChannel :


MOTO
TELEPHONE_ORDER
MAIL_ORDER
FAX

Le canal SVI (Serveur Vocal Intéractif ou encore Interactive Voice Response en anglais) est assimilé au canal MOTO. Vous devez donc souscrire un contrat VAD (vente à distance) acceptant le MOTO avec l'acquéreur.

Table 18. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch
Configuration Sogenactif OUI (configuration du canal MOTO)
Vérification acquéreur OUI contrat VAD supportant le MOTO obligatoire
Paramètre dans la requête de paiement OUI orderChannel : IVR

L’utilisation du canal application mobile ne nécessite pas de configuration acquéreur. Pour en savoir plus sur ce connecteur, veuillez consulter le document Sogenactif In-App JSON.

Table 19. En résumé
Connecteur disponible Sogenactif In-App
Configuration Sogenactif OUI
Vérification acquéreur NON Assimilé au canal Internet
Paramètre dans la requête de paiement OUI orderChannel : INAPP

Les champs paymentPattern, captureMode et captureDay permettent de fixer les modalités de remise en paiement.

Pour en savoir plus sur la disponibilité de ces modalités pour chaque moyen de paiement, veuillez consulter leurs guides d’intégration.

Dans le cas du paiement en fin de journée, toutes les transactions acceptées durant la journée sont envoyées en remise en paiement le soir. Ce mode s’applique aux moyens de paiement fonctionnant dans le mode de « message double » souvent appelé « dual message » (un message pour l’autorisation et un message pour la remise).

Si cette modalité n’est pas supportée par le moyen de paiement,Sogenactif surcharge le paramètre captureMode avec la valeur par défaut du moyen de paiement concerné (pour plus de renseignements, veuillez consulter les guides d’intégration des moyens de paiement).

Table 20. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif NON
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : AUTHOR_CAPTURE
  • captureDay : 0 (0 jour de différé, remise le soir)

Dans le cas du paiement différé, la remise en paiement de la transaction est effectuée N jours après l’acceptation en ligne.

La durée de validité des autorisations du moyen de paiement et fixée dans le contrat conclu entre vous et l’acquéreur (par défaut 6 jours pour CB, VISA et Mastercard).

En fonction de la durée de validité de l’autorisation, le nombre de jours de différé de remise communiqué dans la requête de paiement peut avoir une incidence sur le cycle de vie de la transaction :

  • 1er cas : Le différé de paiement est inférieur ou égal à la durée de validité de l’autorisation. L’autorisation donnée par l’acquéreur est toujours valable pour le montant total de la transaction initiale. Si la transaction n’est pas annulée, elle est payée à la date de la transaction +N jours.
  • Cas particulier 3-D Secure : pour bénéficier du transfert de responsabilité lors d'une transaction 3-D Secure, le différé de paiement ne peut pas être supérieur à la durée maximale de validité de l’autorisation donné par l'acquéreur. Si nécessaire, Sogenactif surcharge ce différé de paiement si la valeur que vous renseignez est supérieure.
  • 2ème cas : Le différé de paiement est supérieur à la durée de validité de l’autorisation. L’autorisation donnée lors de l’achat en ligne par l’acquéreur n’est plus valable lors du paiement. En fonction de l’acquéreur, Sogenactif choisit entre l’un des scénarios suivants :
    • Acquéreur conforme avec la fonctionnalité « Demande de renseignement » : Une demande de renseignement est envoyée à l’acquéreur dans le but de vérifier le numéro de carte de la transaction avant de réaliser une autorisation. Si la réponse est positive, Sogenactif envoie la demande d’autorisation avec le montant réel de la transaction à J+N. En cas d’accord, la transaction est envoyée en remise.
    • Acquéreur non conforme avec la fonctionnalité « Demande de renseignement » : La procédure est identique mais la demande de renseignement faite en ligne est remplacée par une prise d'empreinte (demande d’autorisation d'un petit montant).
      Par conséquent,Sogenactif fait deux demandes d’autorisation :
      • La première demande d’autorisation d'un petit montant, appelée l’empreinte, pour vérifier la carte lors de l’acceptation en ligne.
      • La deuxième demande d’autorisation pour le montant réel avant la remise en paiement.

Si le moyen de paiement est incompatible avec le différé demandé par vous, Sogenactif surcharge le champ captureDay.

Table 21. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif NON
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : AUTHOR_CAPTURE
  • captureDay : N (Nombre de jours de différé de paiement)
Attention: la demande de renseignement est une évolution réglementaire de CB, VISA, MASTERCARD et AMEX qui remplace la prise d'empreinte. Cette fonctionnalité est soumise à la conformité de l’acquéreur.

Dans le cas du paiement à l’expédition, la transaction est envoyée en remise en paiement suite à votre validation. Vous indiquez dans le champ captureDay la durée de validité de votre transaction. Si vous ne validez pas une transaction donnée avant que ce délai ne prenne fin, cette transaction expire. Si vous oubliez de valider dans les délais, vous pouvez représenter la transaction grâce à l’opération de duplication. Vous pouvez valider tout ou partie du montant de la transaction mais il est impossible de valider un montant supérieur au montant initial de la transaction.

Si le mode VALIDATION n’est pas supporté par le moyen de paiement, Sogenactif le surcharge avec la modalité de paiement par défaut.

Table 22. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif OUI Option de VALIDATION à activer
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : VALIDATION
  • captureDay : N (période de validité avant la validation)

Le paiement échelonné s’adresse aux commerçants qui souhaitent offrir des facilités de paiement à leurs clients.

Pour avoir une description fonctionnelle et les modalités d’implémentation du paiement échelonné, veuillez consulter le guide du paiement échelonné.

Dans le cas du paiement immédiat, la transaction est remisée lors de l’autorisation en ligne. Cette modalité de paiement est plus rarement utilisée, et uniquement pour les moyens de paiement supportant le mode « message unique » appelé aussi « single message » (un seul message pour l’autorisation et le paiement).

Si cette modalité n’est pas supportée par le moyen de paiement, Sogenactif surcharge le paramètre captureMode avec la valeur par défaut correspondant au moyen de de paiement concerné (pour plus de renseignements, consultez les guides d’intégration des moyens de paiement).

Les moyens de paiement supportant ce mode sont les suivants :

  • Bancontact
  • Bancontact mobile
  • Cetelem 3X 4X CB
  • Cetelem Presto
  • Chèque-Vacances Connect
  • e-Chèque Vacances
  • iDEAL
  • Sofortüberweisung
Table 23. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif NON
Vérification acquéreur NON
Paramètre dans la requête de paiement OUI
  • captureMode : IMMEDIATE
  • captureDay : 0

Le paiement par fichier est un échange d’informations en temps différé (en mode fichier) entre vous et Sogenactif. Il vous permet de constituer des fichiers de transactions et/ou d'opérations puis de les déposer sur un compte FTP sécurisé Sogenactif.

Il se distingue donc d'un nombre N d'informations communiquées en temps réel (mode transactionnel).

Mode fichier :



  1. Vous disposez d’un nombre N de transactions de paiement et/ou d'opérations indépendantes (N1, N2, N3, N4, etc) ;
  2. En vous basant sur les spécifications de Sogenactif Office Batch, vous constituez un fichier « requête » rassemblant ces transactions et/ou opérations, que vous déposez sur votre compte FTP sécurisé Sogenactif ;
  3. Sogenactif effectue des contrôles de droits ainsi que de cohérence du fichier (format, taille), puis procède au traitement des informations contenues dans ce fichier et envoie les demandes d’autorisation vers les acquéreurs ;
  4. Les acquéreurs traitent les demandes d’autorisation reçues et envoient les réponses à Sogenactif ;
  5. Sogenactif construit le fichier « réponse » contenant les réponses aux paiements et/ou opérations et le dépose sur votre compte FTP sécurisé Sogenactif ;
  6. Vous récupérez le fichier « réponse » via votre compte FTP sécurisé Sogenactif puis intégrez ce fichier dans votre propre système d’information.

Le paiement par fichier s’avère particulièrement utile si vous devez traiter un très grand nombre de flux puisqu’il vous évite d’avoir à apporter une réponse en temps réel à vos clients.

Table 24. En résumé
Connecteurs disponibles Sogenactif Office Batch
Configuration Sogenactif OUI
Vérification acquéreur NON
Paramètre dans la requête de paiement N/A

L’autorisation de l’acquéreur demeure valide pour une certaine durée (par défaut 6 jours pour CB, VISA et Mastercard) :

  • durant ce délai, la transaction est envoyée en remise avec l’autorisation faite en ligne ;
  • au-delà de ce délai, une nouvelle demande d’autorisation est envoyée à l’acquéreur avant la remise en paiement.

La durée de validité peut dépendre du contrat d’acquisition conclu entre vous et l’acquéreur, c’est pourquoi une option permet de fixer la durée de l’autorisation associée à votre contrat d’acquisition. Cette fonctionnalité n’est disponible que pour certains moyens de paiement, pour plus d’information, veuillez consulter les guides d’implémentation.

Table 25. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif OUI Par défaut 6 jours pour les cartes CB / Visa / Mastercard.
Vérification acquéreur OUI
Paramètre dans la requête de paiement NON

Dans le cas des transactions multidevises, l’acceptation porte sur la devise du client mais le paiement est réglé dans votre devise.

Vous devez souscrire cette option auprès de l’acquéreur.

Les étapes de l’acceptation des transactions multidevises sont les suivantes :

  1. vous devez gérer le prix de vos ventes en ligne en plusieurs devises ;
  2. lorsque vous soumettez la transaction au serveur Sogenactif, vous renseignez la devise que vous désirez dans le champ currencyCode ;
  3. la transaction est envoyée pour autorisation et pour la remise du paiement avec le même code de devise ;
  4. lors de l’acquisition du paiement, l’acquéreur convertit la transaction dans votre devise de règlement.
Table 26. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif OUI Les devises acceptées doivent être définies dans la configuration Sogenactif
Vérification acquéreur OUI
Paramètre dans la requête de paiement OUI currencyCode : Code devise de la transaction. Les valeurs possibles sont listées dans document Dictionnaire des données.

Dans le cas du règlement en devise, l’acceptation et le règlement sont effectués dans la même devise.

Vous indiquez le code de la devise utilisée par le client dans la requête de paiement. Vous devez disposer d’un contrat d’acquisition et d’un compte bancaire dans les devises concernées.

Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 27. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif OUI Les devises acceptées doivent être définies dans la configuration Sogenactif
Vérification acquéreur OUI Contrat d’acquisition avec règlement en devises
Paramètre dans la requête de paiement OUI currencyCode : Code devise de la transaction. Les valeurs possibles sont listées dans le dictionnaire des données.


La conversion dynamique de devise (DCC – Dynamic Currency Conversion) est un service financier prévu pour les titulaires des cartes VISA et MasterCard qui permet au client de payer dans sa devise et au commerçant d’être payé dans la sienne.

Le DCC permet à la banque locale qui est l’acquéreur (celle qui prend en charge le paiement en votre nom) et à vous de profiter des frais de change ajoutés normalement à de telles transactions par VISA, MasterCard et les banques émettrices internationales. Vous recevez toujours le règlement dans votre devise de base.

Pour utiliser la conversion dynamique de devise (DCC), vous devez :

  • souscrire un contrat d’acquisition avec l’option DCC ;
  • souscrire à un service de taux de change ;
  • demander l’option DCC lors de l’inscription au service Sogenactif.
Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.
Table 28. En résumé
Connecteur disponible Sogenactif Paypage
Configuration Sogenactif OUI Les devises acceptées doivent être définies dans la configuration Sogenactif et convenues avec l’acquéreur et le changeur.
Vérification acquéreur OUI
Contrat de change OUI
Paramètre dans la requête de paiement OUI currencyCode : indiquez le code de votre devise de base. Les valeurs possibles sont listées dans le dictionnaire des données.

3-D Secure est un protocole d’authentification obligatoire destiné à réduire les risques de fraude liés au paiement sur Internet. Il a pour but de s’assurer que la carte est bien utilisée par son véritable titulaire. Outre cet aspect sécuritaire, 3-D Secure vous permet de bénéficier du transfert de responsabilité vers la banque émettrice de la carte, selon des règles édictées par les réseaux CB, VISA, MASTERCARD, AMEX et Bancontact.

Pour en avoir une description fonctionnelle détaillée et les modalités d’implémentation, veuillez consulter le Guide 3-D Secure.

Le paiement récurrent définit les règles et modalités du paiement d'un service sur une période donné, validées entre le commerçant et son client. Son usage est adapté pour le paiement des services liés à un abonnement.

Dans son cas d'usage, le paiement récurrent se passe en 2 phases :

  • 1ère phase : la collecte des coordonnées carte s’effectue en présence du client et est associée ou non à un paiement. Ce sont ces coordonnées cartes que vous utiliserez pour les paiements futurs selon des conditions validées par le client.
  • 2ème phase : les Nième paiements que vous soumettez sans intervention du client à partir des données cartes stockées lors de la 1ère phase.

Moyens de paiement supportés

CB, Visa, Mastercard, American Express, Bancontact et SDD.

Sécurisation 3-D Secure des paiements récurrents carte

Pour sécuriser la récurrence, il est obligatoire de dérouler la transaction initiale (1er paiement) en mode 3-D Secure pour authentifier le titulaire de la carte. Les Nème paiements se déroulent nécessairement hors contexte 3-D Secure car le porteur n’intervient pas.

Traiter les paiements récurrents en respectant les exigences PCI

La solution Sogenactif vous permet d’utiliser les coordonnées cartes en toute sécurité sans être soumis aux exigences PCI liées au stockage des données cartes. Plusieurs possibilités pour traiter les Nème paiements :

  • duplication de la transaction initiale ;
  • paiement via Wallet (carte stockée dans le wallet) ;
Attention: vous devez informer vos clients du stockage de leurs coordonnées et des modalités des paiements récurrents (durée, montant, périodicité…)

La gestion des abonnements via la duplication est décrite de manière détaillée dans le guide du paiement par abonnement via duplication.

Pour avoir une description fonctionnelle et les modalités d’implémentation du paiement récurrent, veuillez consulter le document Paiement récurrent.

Voici en synthèse les principaux cas d’utilisation.

Enregistrement du moyen de paiement dans le wallet lors d’un paiement Sogenactif Paypage

Via Sogenactif Paypage, vous pouvez demander l’enregistrement automatique du moyen de paiement dans le wallet en cas de paiement accepté.

Attention: s'il s'agit d'un paiement par carte, vous devez conserver la valeur du schemeTransactionIdentifier en réponse. Vous devrez transmettre cette donnée dans le champ InitialSchemeTransactionIdentifier lors des paiements récurrents pour chaîner les chaîner avec la transaction initiale (conformité DSP2).
Table 29. En résumé
Connecteur disponible Sogenactif Paypage
Configuration Sogenactif OUI Option Enrôlement automatique dans le wallet lors d’un paiement Sogenactif Paypage accepté
Vérification acquéreur NON
Paramètre dans la requête

OUI
  • merchantWalletID : identifiant du wallet
  • paymentPattern : RECURRING_1
  • challengeMode3DS : valeur forcé à CHALLENGE_MANDATE
Reporting

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sogenactif Gestion : OUI

Enregistrement du moyen de paiement dans le wallet via Sogenactif Walletpage hors contexte de paiement

Via l’interface Walletpage, vous pouvez demander à votre client de créer un wallet en y ajoutant un moyen de paiement.

IMPORTANT: cette interface ne doit pas être utilisée pour la mise en place d'un abonnement avec une carte car vous ne disposerez pas d'un identifiant de chainage à envoyer pour chaque nouvelle récurrence. Si vous utilisez cette interface pour mettre en place un abonnement, vousne serez pas en conformité avec la DSP2.
Table 30. En résumé
Connecteur disponible Sogenactif Walletpage
Configuration Sogenactif OUI Option Sogenactif Walletpage
Vérification acquéreur NON
Paramètre dans la requête

OUI
  • merchantWalletID : Identifiant dans lequel va être stocké le PAN ou le mandat
  • walletActionNameList : ADDPM pour ajout d’un moyen de paiement
  • PaymentMeanBrandList : SEPA_DIRECT_DEBIT
Reporting

  • Journal des transactions : NON
  • Journal des opérations : NON
  • Sogenactif Gestion : NON

Enregistrement d’un mandat dans le wallet via la méthode addDirectDebit de Sogenactif Office Serveur hors contexte de paiement

Via les interfaces Sogenactif Office Serveur ou Sogenactif Office Batch, vous pouvez créer un wallet pour votre client avec son numéro de mandat.

Table 31. En résumé
Connecteurs disponibles Sogenactif Office Serveur,
Configuration Sogenactif OUI Option wallet
Vérification acquéreur OUI Option recurring
Paramètre dans la requête OUI
  • merchantWalletID : Identifiant du wallet
  • mandateId : Identifiant du mandat
  • paymentMeanBrand : SEPA_DIRECT_DEBIT
Reporting

  

  • Journal des transactions : NON
  • Journal des opérations : NON
  • Sogenactif Gestion : NON

Pour les Nème paiements, vous utilisez la méthode walletOrder en renseignant l’identifiant du wallet dans le champ merchantwalletID

Attention: si le moyen de paiement associé au wallet est une carte, vous devez renseigner le champ initialSchemeTransactionIdentifier avec la valeur du champ schemeTransactionIdentifier reçue lors de la mise en place de l'abonnement.
Table 32. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur OUI Option recurring, Option WIP pour Bancontact
Paramètre dans la requête OUI
  • paymentPattern : RECURRING_N
  • merchantWalletID : identifiant du wallet dans lequel est stocké le moyen de paiement
  • initialSchemeTransactionIdentifier : identifiant de chainage obtenu lors du premier paiement (uniquement pour les paiements par carte)
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : NON
  • Sogenactif Gestion : OUI
Note: le wallet est limité à 1 seul moyen de paiement pour simplifier la mise en œuvre du paiement récurrent. (1 wallet = 1 moyen de paiement)

Vous n’avez à gérer que l’identifiant du wallet et pas l’identifiant du moyen de paiement à l’intérieur du wallet.

Le paiement One Clic s’adresse aux commerçants qui souhaitent simplifier le paiement de leurs clients.

Ce service permet aux clients d’enregistrer leurs coordonnées de paiement dans un espace sécurisé appelé Wallet et ainsi d’éviter la ressaisie de ces informations lors de futurs paiements.

Le paiement One Clic simplifie l’acte de paiement, améliore l’expérience utilisateur notamment pour les achats effectués via mobiles et augmente donc le taux de conversion.

Pour avoir une description fonctionnelle et les modalités d’implémentation du paiement One Clic, veuillez consulter le document One Clic.

Les cycles de vie des transactions diffèrent selon les moyens de paiement, le nouvel état de la transaction peut donc lui aussi différer. Les cycles de vie détaillés sont disponibles dans les guides d’intégration des moyens de paiement.

Tip: si vous obtenez en réponse de votre opération de gestion de caisse un refus suite à une erreur technique (responseCode 90 ou 99) ou un refus lié à l'état de la transaction (responseCode 24), nous vous conseillons de retenter votre opération.

Vous pouvez annuler les transactions, non remisées, partiellement ou totalement en utilisant la fonction Annuler disponible dans les interfaces de Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion.

Pour les moyens de paiement CB, Visa et Mastercard, l’opération d'annulation n’est plus possible sur une transaction dès l’exécution de son traitement de remise en banque.

Exemple : si une transaction (CB, Visa ou Mastercard) est effectuée à J, avec un captureDay paramétré à 2 et un captureMode AUTHOR_CAPTURE, il ne sepra plus possible de l'annuler à J+2 à partir de 22h00 CET.



Pour la majorité des autres moyens de paiement, les opérations d'annulation sont indisponibles tous les jours durant le traitement de la remise (voir Annexe 3 pour le détail des horaires), même sur les transactions non inclues dans la remise. La durée de traitement peut varier selon le nombre de transactions à remiser.

Il est possible de connaître la date de remise en paiement d'une transaction soit via Sogenactif Gestion, soit les journaux, soit en utilisant la fonction GetTransactionData via Sogenactif Office Serveur (dans le champ captureLimitDate).

Dans le cas d’une annulation totale, l’état de la transaction passe à « annulée » (transactionStatus CANCELLED), mais pour une annulation partielle, l’état reste inchangé.

Les contrôles suivants sont effectués :

  • vous disposez du droit d’annulation. Dans le cas contraire un responsCode 40 est retourné ;
  • la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné ;
  • la transaction est au statut "TO_CAPTURE" ou "TO_VALIDATE" ou "TO_AUTHORIZE" ou "TO_CHALLENGE". Dans le cas contraire un responseCode 24 est retourné. Vous pouvez consulter les heures de remise par acquéreur / privatif en Annexe 3 ;
  • le montant à annuler est égal ou inférieur au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
  • aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 33. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  • Journal des transactions : NON
  • Journal des opérations : OUI, CANCEL
  • Sogenactif Gestion : OUI

Les transactions créées dans le mode validation (captureMode = VALIDATION), doivent être validées partiellement ou totalement pour déclencher le paiement en utilisant la fonction Valider disponible dans les interfaces de Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion.

La transaction passe alors à l’état « à valider » (transactionStatus = TO_VALIDATE) ou à l’état « en attente d’une validation avec demande d’autorisation » (transactionStatus = TO_REPLAY), puis à l'état « à remiser » (transactionStatus = TO_CAPTURE) ou directement à l’état « remisée » (transactionStatus = CAPTURED) en fonction des règles du moyen de paiement.

Vous ne pouvez valider une transaction qu’une seule fois. Dans le cas d’un paiement partiel, le complément peut être réalisé grâce à l’opération de duplication.

Les contrôles suivants sont effectués :

  • vous disposez du droit de validation. Dans le cas contraire un responseCode 40 est retourné ;
  • la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné ;
  • la transaction est au statut "TO_VALIDATE". Dans le cas contraire un responseCode 24 est retourné ;
  • le montant à valider est inférieur ou égale au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
  • la demande d'autorisation est acceptée par l’acquéreur dans le cas d'une validation avec demande d’autorisation (spécifique à quelques moyens de paiement). Dans le cas contraire un responseCode autre que 00 est retourné ;
  • aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.

Tip: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 34. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Configuration Sogenactif OUI VALIDATE
Vérification acquéreur NON
Reporting

  • Journal des transactions : NON
  • Journal des opérations : OUI, VALIDATE
  • Sogenactif Gestion : OUI

Cas des validations immédiates après le paiement

Votre métier de vente sur Internet vous a peut-être contraint à implémenter vos paiements en mode validation (champ captureMode = VALIDATION), et à envoyer une requête de validation via Sogenactif Office Serveur immédiatement après le paiement, soit au retour de votre client sur votre site marchand, soit à réception de la réponse automatique. Ce mode de fonctionnement est valable, mais vous devez prendre quelques précautions de mise en œuvre et échanger avec votre chargé de compte pour qu'il(elle) valide votre choix.

Afin d'optimiser la réussite de vos ventes sur Internet, nous utilisons un système d'écriture en base de données de type asynchrone. Grâce à ce système d'écriture asynchrone, nous restons en capacité d'accepter vos transactions de paiement en temps réel, même si notre système base de données venait à subir quelques perturbations ou à ralentir.

Toutefois, lors d'une maintenance ou en cas d'engorgement ponctuel de notre système de base de données, les transactions s'enregistrent avec un temps de décalage par rapport au traitement temps réel du paiement. Il est par conséquent nécessaire de suivre les conseils ci-dessous pour votre implémentation de validations automatisées .

Code réponse Description Causes possibles Conseils de mise en oeuvre
00 La validation est acceptée RAS RAS
25 Validation refusée, car la transaction n'est pas trouvée en base de données Cas 1 : vous avez commis une erreur dans la requête. Les données d'identification de la transaction (transactionReference ou transactionId ou transactionDate) sont fausses, ou vous tentez de valider un paiement qui ne s'est pas terminé (par exemple l'acheteur a abandonné)

Cas 2 : la transaction de paiement a bien été traitée jusqu'à sa fin , mais elle n'est pas encore enregistrée en base de données, dû à notre système asynchrone d'écriture en base de données Nous conseillons de mettre en place un batch de recyclage automatique de ces tentatives de validation échouée, et d'exécuter ce batch 30 minutes minimum après le paiement, de manière à laisser le temps nécessaire d'insertion de la transaction en base de données. Si vous recevez un nouveau code 25, nous ne sommes pas dans le cas 2, mais certainement dans le cas 1 décrit ci-contre

99 Validation échouée, car notre système de gestion de caisse est ponctuellement inaccessible Cas 1 : nous subissons un incident technique, nous mettons tout en œuvre pour rétablir la situation au plus tôt. Vous allez recevoir une communication par e-mail décrivant l'incident.

Nous conseillons de mettre en place un batch de recyclage automatique de ces tentatives de validation échouée, et d'exécuter ce batch 30 minutes minimum après le paiement, de manière à laisser le temps nécessaire au rétablissement du service. Tant que vous recevez un code 99, recyclez votre requête de validation.
Cas 2 : nous sommes en maintenance. S'il s'agit d'une maintenance programmée, un e-mail vous a été transmis quelques semaines auparavant.

Dans le cas d’un paiement déjà remisé, vous pouvez rembourser la transaction partiellement ou totalement en utilisant la fonction Rembourser disponible dans les interfaces de Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion.

Note: tous les jours, durant le traitement de remise des transactions en banque (qui a lieu entre 22h00 et 23h00 CET pour la majorité des moyens de paiement), les opérations de remboursement sont indisponibles sur l'ensemble des transactions.

Exemple : si un transaction (CB, Visa ou Mastercard) est effectuée à J, avec un captureDay paramétré à 2, il sera possible de la rembourser en totalité ou partiellement à J+2 après la fin du traitement de la remise.



Dans le cas d’un remboursement total, la transaction passe à l’état « à rembourser » (transactionStatus = TO_CREDIT) ou à l’état « remboursée » (transactionStatus = CREDITED) en fonction des règles du moyen de paiement.

En cas de remboursement partiel, l’état de la transaction redevient « envoyée en banque » (transactionStatus = CAPTURED) après le traitement de la remise.

Les contrôles suivants sont effectués :

  • vous disposez du droit de remboursement. Dans le cas contraire un responseCode 40 est retourné ;
  • la transaction existe dans notre bas de données. Dans le cas contraire un responseCode 25 est retourné ;
  • la transaction est au statut CAPTURED ou TO_CREDIT. Dans le cas contraire un responseCode 24 est retourné. Vous pouvez consulter les heures de remise par acquéreur / privatif en Annexe 3 ;
  • le montant à rembourser doit être inférieur ou égale au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
  • la transaction à rembourser n'est pas en impayé. Dans le cas contraire, un responseCode 57est retourné ;
  • aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.
Tip: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 35. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : NON
  • Journal des opérations : OUI, REFUND
  • Sogenactif Gestion : OUI

Vous pouvez créer une transaction à partir d’une transaction existante en utilisant la fonction « Duplication » disponible dans les interfaces Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion. Cette fonction permet par exemple de recréer une transaction à partir d’une transaction qui a expiré par erreur, mais également de faire du paiement en plusieurs fois.

Les coordonnées du moyen de paiement sont récupérées de la transaction initiale par Sogenactif. Toutefois, vous pouvez modifier les données métier (numéro de commande, modalité de remise en paiement, …).

Les transactions dupliquées sont traitées comme une nouvelle transaction en mode récurrent (champ paymentPattern fixé à RECURRING_N).

Les contrôles suivants sont effectués :

  • vous disposez du droit de duplication. Dans le cas contraire un responseCode 40 est retourné;
  • la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné;
  • le moyen de paiement utilisé est compatible et permet la duplication. Dans le cas contraire, un responseCode 24 est retourné ;
  • la date d’expiration du moyen de paiement est toujours valide. Dans le cas contraire, un responseCode 14 est retourné ;
  • la demande d’autorisation est acceptée pas l’acquéreur et un responseCode 00 a été obtenu.
Tip: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 36. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : OUI, DUPLICATE
  • Sogenactif Gestion : OUI

Cette fonctionnalité vous permet de générer plusieurs remises en paiement d’une même transaction autorisée. Cette fonction permet notamment de gérer l’envoi en plusieurs lots d’une même commande en ne facturant le client que lors de l’expédition de chaque produit.

Comme pour la duplication, vous créez une transaction à partir d’une transaction existante mais il y a une différence essentielle entre recyclage et duplication :

  • pour le recyclage, le montant est limité au montant résiduel (non encore envoyé en paiement) de la transaction initiale.

Dans le cas où la demande d’autorisation de la transaction initiale n’est plus valide (délai dépassé), alors la transaction est dupliquée avec une nouvelle demande d’autorisation (comme pour la duplication standard), mais cette duplication n’est possible que dans les limites du montant qui restait à percevoir.

Vous pouvez recycler une transaction plusieurs fois, tant que le montant initial non réglé n’est pas atteint. Il n’est pas possible de recycler une transaction recyclée.

Les contrôles suivants sont effectués :

  • vous disposez du droit de recyclage. Dans le cas contraire, un responseCode 40 est retourné ;
  • la transaction existe dans notre base de données. Dans le cas contraire, un responseCode 25 est retourné ;
  • le moyen de paiement est compatible et permet le recyclage. Dans le cas contraire, un responseCode 24 est retourné ;
  • le statut de la transaction sur laquelle est effectuée l’opération est au statut « CAPTURED ». Dans le cas contraire, un code refus 24 est retourné ;
  • le montant à recycler est inférieur ou égale à ce qui est autorisé. Dans le cas contraire un responseCode 51 est retourné ;
  • la demande d'autorisation est acceptée pas l’acquéreur et un responseCode 00 a été obtenu.
Note: vous retrouvez l’ensemble des codes réponse dans le dictionnaire des données ici.
Table 37. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Reporting

  

  • Journal des transactions : OUI
  • Journal des opérations : OUI, RECYCLE
  • Sogenactif Gestion : OUI

La fonctionnalité de diagnostic vous permet de connaître l’état détaillé d’une transaction indiquée dans votre requête via la fonction getTransactionData des interfaces Sogenactif Office Serveur.

Table 38. En résumé
Connecteur disponible Sogenactif Office Serveur
Configuration Sogenactif OUI Diagnostic non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de diagnostic OUI transactionReference ou s10TransactionId + s10TransactionIdDate

La réponse manuelle vous est envoyée lorsque le client est redirigé vers votre site une fois le paiement en ligne (connecteur Sogenactif Paypage ) ou la gestion de wallet (connecteur Sogenactif Walletpage) effectué. Néanmoins, vous n’avez pas de garantie de récupérer la réponse manuelle car, le client peut décider de fermer son navigateur ou ne pas cliquer sur le bouton de retour à la boutique une fois son paiement réalisé ou sa gestion de wallet terminée.

Les champs retournés dans la réponse sont variables en fonction du résultat de la transaction (refusée ou réussie).

Table 39. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Walletpage
Configuration Sogenactif NON
Vérification acquéreur NON
Paramètre dans la requête

OUI normalReturnUrl : <url> Adresse URL pour la réponse manuelle (obligatoire)

Pour assurer la récupération de la réponse à la requête de paiement (connecteurs Sogenactif Paypage et Sogenactif In-App) ou à la requête de gestion de wallet (connecteur Sogenactif Walletpage), vous pouvez demander l’envoi de la réponse dite automatique. La réponse est envoyée indépendamment du retour boutique du client. Les champs de la réponse sont variables en fonction du résultat de la transaction (refusée ou réussie).

L’adresse URL de la réponse automatique peut être fournie dans la requête, si elle n’est pas fournie, c’est celle de la configuration marchande qui est utilisée. Si elle n’est pas fournie et qu’aucune configuration n’a été faite, la réponse automatique n’est pas envoyée.

Le résultat de l’envoi de la réponse automatique vers le commerçant est renseigné dans le champ automaticResponseStatus d’une transaction de paiement. Les valeurs de ce champ (SENT, FAILED, TIMED_OUT) sont conditionnées par le code HTTP renvoyé.

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 40. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif In-App, Sogenactif Walletpage,
Configuration Sogenactif OUI Réponse automatique non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI automaticResponseUrl : <url> Adresse URL pour la réponse automatique (optionnel)

Cette notification est reçue par le client à la fin du processus de la transaction. Vous pouvez en recevoir une copie par e-mail sur une adresse configurée lors de l’activation de cette option. Le contenu de la notification est variable en fonction du résultat de la transaction (refusée ou réussie).

La notification au client peut être envoyée par e-mail ou SMS, si les deux champs sont renseignés, la notification par e-mail est choisie.

Tip: pour la mise en œuvre de cette fonctionnalité avancée (notification par SMS), veuillez contacter l’assistance technique.
Table 41. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App
Configuration Sogenactif OUI Confirmation non activée par défaut
Vérification acquéreur NON
Paramètre dans la requête

  

OUI
  • customerContact.email : <adresse mail du client> Pour la notification par courrier électronique
  • customerContact.mobile : <numéro de téléphone du client> Pour la notification par SMS

Les journaux suivants vous permettent de suivre l’activité de votre boutique :

  • Journal des transactions
  • Journal des opérations
  • Journal de rapprochement bancaire
  • Journal de rapprochement des impayés
  • Journal des cartes arrivant à échéance

Par défaut les journaux sont envoyés quotidiennement par mail sauf le journal d’expiration qui est envoyé mensuellement.

Vous pouvez choisir les journaux qui vous sont envoyés.

Table 42. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif In-App, Sogenactif Walletpage
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON/OUI Dépend de l’acquéreur ou de l’établissement financier pour les journaux de rapprochement bancaire et de rapprochements des impayés

Par défaut, les opérations de remise n’apparaissent pas dans le journal des opérations. Si vous souhaitez les inclure, vous pouvez souscrire à une option spécifique.

Par défaut, les transactions non rapprochées n’apparaissent pas dans le journal de rapprochement bancaire. Si vous souhaitez les inclure, vous pouvez souscrire à une option spécifique.

Pour plus d’information, veuillez consultez le document description des journaux.

Le contrôle Oppotota avant remise (gestion des cartes en opposition), permet de vérifier que la carte utilisée n’a pas été mise en opposition entre la demande d’autorisation et la validation de la transaction ou sa remise en paiement.

Ce contrôle ne s’applique qu’aux transactions CB, VISA, MASTERCARD et n’est pertinent que si vos transactions sont traitées par une banque française du réseau CB.

Le fichier des cartes en opposition est alimenté en se basant sur la liste des cartes en opposition du réseau CB. La mise à jour du fichier est effectuée plusieurs fois par jour.

Table 43. En résumé
Connecteurs disponibles Sogenactif Paypage, Sogenactif Office Serveur,Sogenactif Office Batch,Sogenactif In-App
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête NON

L’option CHALLENGE vous permet de mettre en attente les transactions dont le score est ORANGE. Ceci vous permet de vérifier le risque avant de poursuivre les autres étapes d’acceptation : validation, ré autorisation ou remise en banque.

Si vous ne disposez pas de l’option CHALLENGE la transaction est acceptée.

Vous avez X jours pour mesurer le risque de la fraude et valider ou refuser la transaction. X est la valeur maximale entre la validité de l’autorisation et le délai de capture (captureDay) que vous avez défini lors du paiement.

Une fois la vérification effectuée, si vous décidez d’accepter la transaction, vous utilisez l’opération acceptChallenge.

Attention: aucune opération ne doit déjà être en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné (Table des responseCode).
Table 44. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion, Portail Sogenactif
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

Une fois la vérification effectuée, si vous décidez de refuser la transaction, vous utilisez l’opération refuseChallenge.

Attention: aucune opération ne doit déjà être en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné (Table des responseCode).
Table 45. En résumé
Connecteurs disponibles Sogenactif Office Serveur, Sogenactif Office Batch, Sogenactif Gestion, Portail Sogenactif
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

La fonctionnalité de diagnostic vous permet de récupérer des informations relatives au contrôle anti-fraude d'une transaction indiquée dans votre requête via la fonction getFraudData.

Table 46. En résumé
Connecteur disponible Sogenactif Office Serveur
Configuration Sogenactif OUI Diagnostic non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête OUI transactionReference ou s10TransactionId + s10 TransactionIdDate

Le moteur de lutte contre la fraude s’adresse à tous les commerçants qui ont souscrit à l’offre « Gestion de la lutte contre la fraude – Scoring » et souhaitent bénéficier d’un outil de lutte contre la fraude administrée par eux-mêmes sur le Portail Sogenactif.

Le moteur de lutte contre la fraude s’appuie sur des profils antifraudes afin d’évaluer les transactions. Ceux-ci sont composés de règles que vous pouvez configurer.

Pour avoir une description fonctionnelle et les modalités d’implémentation du contrôle des fraudes en ligne, veuillez consulter les documents Gestion de la lutte contre la fraude Go-No-Go et Gestion de la lutte contre la fraude Scoring.

Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.

Le filtrage des cartes permet au commerçant de sélectionner les marques et usages qu'il souhaite accepter et qui concerne les réseaux CB, Visa et Mastercard.

Par défaut, sans l'activation de cette fonctionnalité, et si le commerçant à un contrat CB/VISA/MASTERCARD, toutes les marques et usages seront acceptées.

Les marques du réseau sélectionnables sont :
  • CB
  • VISA
  • VPAY
  • ELECTRON
  • MASTERCARD
  • MAESTRO
Les usages sélectionnables sont :
  • Crédit
  • Débit
  • Prépayé
  • Commercial
Tip: pour la mise en œuvre de cette fonctionnalité avancée, veuillez contacter l’assistance technique.

La solution Sogenactif 2.0 en tant que solution d’acceptation de paiement, est assujettie à la réglementation européenne MIF (JO EU 2015/751 L123 du 19/05/2015). Parmi ces règles, la « Sélection de la Marque » vous impose de proposer au client porteur d’une carte cobadgée le choix de la marque au moment du paiement ce qui impacte la page de paiement.

Une carte cobadgée est une carte qui supporte au moins deux marques. La plupart des cartes émises en France sont cobadgées avec CB (carte CB/VISA, CB/MASTERCARD, CB/MAESTRO, …).

Pour la mise en œuvre de la sélection de la marque, veuillez consulter le document Intégration Carte Bancaire Nationale.

L’AVS est une fonctionnalité de lutte contre la fraude, utilisée dans certains pays comme la Grande-Bretagne. L’AVS vous permet de demander l’adresse du porteur de carte (voir les champs concernés ci-dessous), de l’envoyer dans la demande d’autorisation et de laisser l’émetteur de carte comparer cette adresse avec celle qu’il connaît.

L’AVS contient des contrôles sur la rue et le code postal.

La réponse d’une autorisation et le résultat du contrôle AVS sont indépendants, c’est-à-dire qu’il est possible que l’acquéreur approuve la demande d’autorisation avec les contrôles AVS faux.

Vous devez indipquer dans la requête les modalités de vérification des données AVS lors de l’acceptation en ligne de la transaction. Si vous indiquez que le résultat du contrôle AVS conditionne l’acceptation de la transaction alors une autorisation accordée avec un contrôle AVS échoué sera refusée par Sogenactif. Dans ce cas, une opération de redressement (Reversal) automatique sera envoyée à l’acquéreur par Sogenactif pour remettre à jour le plafond de la carte.

Paramètres Valeurs Note
checkAVS Y/N Indique si le contrôle AVS doit être exécuté. Désactivé par défaut.
ignorePostcodeCheckResult Y/N Ignore le résultat du contrôle du code postal (inactif par défaut)
ignoreAddressCheckResult Y/N Ignore le résultat du contrôle de la rue (inactif par défaut)
holderAddress.addressAdditional1 Adresse Contient les informations sur la rue du porteur
holderAddress.addressAdditional2 Adresse
holderAddress.addressAdditional3 Adresse
holderAddress.streetNumber Numéro
holderAddress.street Rue
holderAddress.postbox Boîte postale
holderAddress.city Ville
holderAddress.state État
holderAddress.zipCode Code postal Contient les informations sur le code postal du porteur

Les transactions refusées suite à un échec de l’AVS retournent un code réponse 14 et un code réponse acquéreur 00.

Deux codes réponses dédiés à l’AVS (avsPostcodeResponseCode and avsAddressResponseCode) vous sont retournés dans la réponse de paiement (pas encore disponible sur Sogenactif Paypage) et présents dans le journal des transactions.

Une « Surcharge de frais » est un frais supplémentaire s’ajoutant à un paiement par chèque ou carte (les paiements en espèces ne sont pas concernés) dans le but de couvrir le coût du service d’acceptation impactant le commerçant. Elle peut être interdite par les émetteurs de carte – complètement (par exemple Visa et MasterCard aux États-Unis) – ou lorsque le commerçant applique un taux interdit. La réglementation peut autoriser ou interdire la surcharge de frais. Sans surcharge signifie qu’elle est incluse dans le prix (même en cas de paiement en espèces).

Sur Sogenactif Paypage, la surcharge est calculée par Sogenactif lors du paiement. Vous devez vous inscrire à l’option « Surcharge » et configurer le montant de la surcharge lié au code produit de la carte. Deux types de surcharges peuvent être appliqués : un montant fixe ou un pourcentage de la transaction. Le montant de l’autorisation envoyé à l’acquéreur est égal au montant total de la transaction + la surcharge.

Pour configurer la surcharge, vous devez fournir le « Scheme » de la carte, le code produit de la carte, la devise et le montant ou le pourcentage fixé.

Sur Sogenactif Office Serveur, la surcharge doit être calculée par vous. Le montant total dans la requête de paiement envoyée à Sogenactif contient la surcharge.

ARP est l’appellation employée dans Sogenactif pour les solutions MARP (Mastercard Advanced Registration Program) et MUPP (Mastercard Utility Payment Program) de Mastercard.

L’objectif de cette fonction est de proposer le contournement automatique du processus 3-D Secure si la carte a déjà passé le premier contrôle de sécurité 3-D (dans le cadre du même contrat avec l’acquéreur). Ainsi, le parcours de paiement est simplifié pour les titulaires de confiance.

Le processus 3-D Secure est déclenché lors du premier paiement avec la carte. Le paiement suivant avec la même carte (dans le cadre du même contrat) sera identifié comme une transaction ARP et le processus 3-D Secure ne s’affichera pas.

Dans le cas d’un paiement où l’authentification 3-D est contourné par l’ARP, le champ HolderAuthentProgram est valorisé à ARP dans les réponses.

Les conditions d’utilisation d’ARP sont les suivantes :

  • vous devez souscrire au programme 3-D Secure ;
  • l’option ARP doit être activée dans Sogenactif ;
  • il doit s’agir d’une carte MasterCard ou Maestro ;
  • votre acquéreur est conforme ARP.
Table 47. En résumé
Connecteurs disponibles Sogenactif Paypage
Configuration Sogenactif OUI Non activé par défaut
Vérification acquéreur NON
Paramètre dans la requête de paiement NON

Sogenactif Paypage Sogenactif Office Serveur Sogenactif Office Batch Sogenactif In-App Sogenactif Walletpage
Identification des transactions
Identification à la création oui oui non non oui
Identification en gestion de caisse non oui oui non non
Identification dans le reporting oui oui non non oui
Gestion des paypages sécurisées
Personnalisation des pages de paiement oui non non non oui
Affichage des moyens de paiement oui non non non non
Affichage du ticket par Sogenactif oui non non non non
Nombre de tentatives de paiement oui non non non oui
Nouvelle tentative de paiement oui non non non non
Durée de présence sur les pages de paiement oui non non non non
Affichage du nom de la boutique oui non non non oui
Saisie du numéro de carte en blocs séparés oui non non non oui
Affichage de la page d’erreur oui non non non non
Affichage du message d’attente oui non non non non
Balise iframe oui non non non oui
Canal de paiement
Internet oui oui oui non non
MOTO oui oui oui non non
Application mobile non non non oui non
Modalités de remise en paiement
Paiement en fin de journée oui oui oui oui non
Paiement différé oui oui oui oui non
Paiement à l’expédition oui oui oui oui non
Paiement échelonné oui non non non non
Paiement immédiat oui oui oui oui non
Période de validité de l’autorisation oui oui oui oui non
Paiement en devises
Acceptation multidevise oui oui oui oui non
Règlement en devise oui oui oui oui non
Conversion dynamique des devises oui non non non non
3-D Secure
3D Secure oui oui non oui oui
Blocage des transactions non garanties 3D oui oui non oui non
Sécurisation Safekey
Sécurisation Safekey oui oui non non oui
Paiement One Clic
Enrôlement One Clic avec paiement oui non non oui non
Enrôlement One Clic sans paiement non oui oui non oui
Paiement One Clic oui oui oui oui non
Paiement récurrent
Enregistrement de l’abonné avec 1er paiement oui non non non non
Enregistrement de l’abonné sans paiement non oui oui non oui
Paiement récurrent non oui oui non non
Gestion de caisse
Annulation non oui oui non non
Validation non oui oui non non
Remboursement non oui oui non non
Duplication non oui oui non non
Recyclage non oui oui non non
Reporting en ligne
Diagnostic non oui non non non
Réponse manuelle oui non non non oui
Réponse automatique oui non non oui oui
Confirmation de fin de transaction vers le client oui oui oui oui non
Reporting fichier
Journal des transactions oui oui oui oui non
Journal des opérations oui oui oui oui non
Journal de rapprochement bancaire oui oui oui oui non
Journal de rapprochement des impayés oui oui oui oui non
Journal des cartes arrivant à échéance oui oui oui oui non
Fraude
Détection de la fraude avant remise (contrôle Oppotota) oui oui oui oui non
acceptChallenge non oui oui non non
refuseChallenge non oui oui non non
Diagnostic Fraude non oui non non non
Spécificité pays
Sélection de la marque (MIF) oui oui oui oui non

Fonctionnalité disponible (oui) / Fonctionnalité indisponible (non).

Oui = fonctionnalité disponible

Non = fonctionnalité indisponible

Conditionnel = fonctionnalité disponible avec spécificité, se référer au guide d'intégration du moyen de paiement en question

C : Consultation A : Annulation
V : Validation R : Remboursement
D : Duplication
Cartes / Moyens de paiement Fonctions autorisées Validité demande d’autorisation
C A V R D
CB Oui Oui Oui Oui Oui 6 jours*
Visa Oui Oui Oui Oui Oui 6 jours*
Mastercard Oui Oui Oui Oui Oui 6 jours*
American Express Oui Oui Oui Oui Oui 6 jours*
Vpay Oui Oui Oui Oui Oui 6 jours*
Maestro Oui Oui Oui Oui Oui 6 jours*
Visa Electron Oui Oui Oui Oui Oui 6 jours*
Bancontact Oui Non Non Oui Oui Paiement immédiat
Bancontact mobile Oui Non Non Non Non Paiement immédiat
Carte Oney Oui Oui Oui Oui Oui Paiement différé
Carte Cadeau Oney Oui Non Non Oui Oui Paiement immédiat
Cetelem CPay (anciennement Cetelem Aurore) Oui Oui Oui Conditionnel Oui 60 jours
Cetelem 3X 4X CB Oui Non Non Oui Non Paiement immédiat
Cetelem Presto Oui Conditionnel Non Non Non Paiement immédiat
Cofidis Pay 5x10x20x Oui Oui Oui Oui Non 99 jours
Cofidis 3xCB Oui Oui Oui Oui Non 8 jours
e-Chèques Vacances Oui Non Non Conditionnel Non Paiement immédiat
Facily Pay Oui Oui Conditionnel Conditionnel Non 30 jours
Franfinance 3xWEB(pour usage futur) Oui Oui Oui Oui Non 99 jours
Franfinance 4xWEB(pour usage futur) Oui Oui Oui Oui Non 99 jours
iDeal Oui Non Non Oui Non Paiement immédiat
Masterpass(pour usage futur) Oui Oui Oui Oui Oui 6 jours
Oney 3x 4x Oui Oui Oui Oui Non 30 jours
Paylib Oui Oui Oui Oui Conditionnel 6 jours
Paypal Oui Oui Oui Oui Oui 29 jours
SEPA Direct Debit (SDD) Oui Oui Oui Conditionnel Oui Paiement différé
Sofortüberweisung Oui Non Non Conditionnel Non Paiement immédiat

*par défaut la validité de la demande d’autorisation est à 6 jours, mais elle est aussi configurable.

Ci-dessous un tableau reprenant la programmation horaire actuelle des lancements des remises par acquéreur / privatif.

Acquéreur Heure* de début du lancement de la remise
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
Cofinoga 22h00
Diners 22h00
Franfinance 22h00
La Banque Postale 22h00
Natwest 22h00
Paypal 17h00
Société Générale 22h00
SPS 22h00

* les heures sont indiquées sous le fuseau horaire CET (Central European Time).

Retourner en haut de page besoin d'aide ?

besoin d'aide ?

Fermer

Ce site utilise des traceurs pour améliorer votre expérience de navigation, effectuer des analyses et des recherches sur votre utilisation du site web de documentation Sogenactif.
En fermant ce bandeau vous refusez notre utilisation des traceurs sur votre appareil.

Paramètres