Introduction
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étier liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement échelonné…).
L’objectif du présent document est d’expliquer l'intégration du moyen de paiement SDD (SEPA Direct Debit) dans Sogenactif.
À qui s’adresse ce document ?
Ce document a pour objectif de vous aider à implémenter le moyen de paiement SDD sur votre site de commerce électronique.
Il comprend :
- des informations fonctionnelles à votre attention ;
- des instructions d'implémentation à destination de votre équipe technique.
Pour avoir une vue d’ensemble de la solution Sogenactif, nous vous conseillons de consulter les documents suivants :
- Présentation fonctionnelle
- Configuration des fonctionnalités
Contacter l'assistance
Pour toute question technique ou demande d'assistance, nos services sont disponibles du lundi au vendredi, hors jours fériés, de 9 h à 19 h :
- par téléphone au : +33 (0) 825 090 095 (0,15 € TTC/min + prix d’un appel local – Tarif au 12/09/2022)
- par e-mail : supportsogenactif@worldline.com
Pour faciliter le traitement de vos demandes, veuillez communiquer votre identifiant de commerçant : merchantId (numéro à 15 chiffres).
Comprendre les paiements SDD avec Sogenactif
Principes généraux
Le SDD (SEPA Direct Debit) est un moyen de paiement par prélèvement utilisé par les débiteurs et créanciers de la zone SEPA.
Le prélèvement est un paiement à l’initiative du créancier (le commerçant), autorisé préalablement par le débiteur (le client) grâce à l’établissement d’un mandat. Ce moyen de paiement est utilisable pour des paiements récurrents ou ponctuels.
Règles d’acceptation
Fonctionnalités disponibles
Canaux de paiement | ||
---|---|---|
Internet | V | Canal de paiement par défaut |
MAIL_ORDER, TELEPHONE_ORDER | V | |
Télécopie | X | |
SVI | X |
Typologies de paiement | ||
---|---|---|
Paiement immédiat | X | |
Paiement en fin de journée | V | |
Paiement différé | V | |
Paiement à l'expédition | V | |
Paiement échelonné | V | |
Paiement récurrent | V | |
Paiement par fichier | V | |
Paiement One Clic | V |
Gestion des devises | ||
---|---|---|
Acceptation multidevise | X | Euro uniquement |
Règlement en devise | X | Euro uniquement |
Devise
Le prélèvement SEPA est un instrument de paiement en euro. L’ordre de paiement ne peut être exprimé qu'en euros. Néanmoins, les comptes des clients peuvent être tenus dans une autre devise. Dans ce cas, la banque du client assure la conversion, qui a lieu en dehors de la transaction de prélèvement SEPA elle-même.
Mandat
L’accord que votre client vous a donné pour émettre des ordres de prélèvements et les présenter au débit de son compte est formalisé par la signature d’un mandat de prélèvement SEPA. Le prélèvement repose sur un contrat clair conclu entre vous et votre client, matérialisé par un consentement explicite : le mandat.
Le mandat de prélèvement SEPA matérialise le consentement du client auprès de son commerçant. Sogenactif attribue une Référence Unique de Mandat (RUM) à chaque mandat. Vous pouvez également attribuer les Références Uniques de Mandat vous-même (voir les parties "Paramétrer la requête de paiement" du connecteur Sogenactif Paypage ou Sogenactif Office Serveur). Dans ce cas, vous devez assurer leur unicité.
Des changements peuvent intervenir sur le mandat au cours de la vie de ce dernier (changement de numéro de compte du client, etc.). Par conséquent vous devez disposer du mandat mis à jour.
Schémas du SDD
Le prélèvement SEPA se décline dans deux schémas :
- Le prélèvement SEPA CORE possible pour tout type de clientèle. Ce
schéma se décline dans Sogenactif en deux sous-types :
- Core (BtoC). Ce schéma s'applique à tous les payeurs, particuliers ou entreprises.
- Core Entreprise (BtoF) destiné aux associations avec ou sans numéro de SIRET. Ce sous-type a été créé afin de permettre de véhiculer des informations supplémentaires, mais il reste soumis aux règles générales applicables au schéma CORE.
Le prélèvement SEPA BtoB (ou interentreprises) réservé exclusivement aux paiements entre entreprises, professionnels et associations, et qui a des règles de gestion spécifiques. Il est interdit à un créancier de prélever un particulier avec un SDD BtoB. La banque du débiteur a l’obligation de s’assurer auprès de son client de la validité du mandat BtoB avant de pouvoir engager les paiements par SDD. Le débiteur doit donc transmettre une copie du mandat de SDD BtoB à sa banque dès signature pour que celle-ci enregistre les caractéristiques du mandat dans son système d'informations. Si la banque du débiteur n'est pas informée du mandat signé, le prélèvement sera automatiquement rejeté. Le débiteur s’engage aussi à informer sa banque de toute modification ou suppression de mandat. Le débiteur ne peut pas contester un SDD BtoB dès lors qu’il a été régulièrement payé (i.e. existence d’un mandat), il n'est donc pas possible de demander à sa banque le remboursement d'un prélèvement BtoB.
Type de prélèvement
Le prélèvement SEPA peut être utilisé pour des opérations récurrentes ou ponctuelles :
- mandat récurrent : le mandat est valable pour une série de prélèvements. Il est révocable à tout moment par le créancier ou le débiteur et devient caduc en cas d’inutilisation durant une période de 36 mois.
- mandat ponctuel : le mandat n’est valable que pour un prélèvement unique, il expire automatiquement.
Limitation de montant
Le montant d’un ordre de prélèvement SEPA doit être compris entre 0,01 et 999.999.999,99 euros.
Validation électronique du mandat
La validation électronique des mandats de prélèvement SEPA est utilisée lors de la création d’un mandat en ligne par le client ou lors de la création d’un mandat version électronique dans Sogenactif Gestion ou via Sogenactif Office Serveur par vous.
La validation électronique fait appel à un certificat serveur unique au nom de la SG, qui garantit l’intégrité du document et permet l’horodatage et le scellement des preuves des actions ayant conduit à la validation du mandat.
La validation électronique est compatible avec la norme européenne ETSI 102-042 (organisme de normalisation européen du domaine des télécommunications).
Un prélèvement SEPA peut donner lieu à contestation pour opération non autorisée, mais en cas d’action judiciaire, c’est l’existence du consentement au contrat principal (liant le commerçant et le client - ex : contrat d’abonnement) qui sera prioritairement considérée.
La validation du mandat peut se faire au travers de deux cinématiques :
- validation par saisie d’un code reçu par e-mail ;
- validation par saisie d’un code reçu par SMS.
Le choix de la solution relève d’un arbitrage entre le risque à couvrir, la garantie de paiement et l’ergonomie du processus.
C'est à vous de préciser le choix lors de l’envoi de la requête permettant de créer le mandat.
Validation par saisie d’un code
Principes
Le client valide son mandat de prélèvement en saisissant un code qu'il a reçu :
- par SMS à un numéro de téléphone connu du commerçant ;
- par e-mail à une adresse électronique connue du commerçant.
Prérequis pour le commerçant
- Vous devez être en capacité de transmettre les données concernant le client : civilité, nom, prénom pour un client particulier ; raison sociale, nom et prénom du responsable légal pour une entreprise cliente.
- Vous devez disposer du numéro de téléphone ou de l’adresse électronique du client : le client ne peut ni saisir ni modifier son adresse de messagerie électronique ou son numéro de téléphone lors de la session permettant de valider son mandat.
Pages de paiement
- Lorsque le client clique sur le logo Prélèvement SEPA, le serveur vérifie si le client a déjà un mandat de prélèvement (option One Clic).
- Si le client ne détient pas de mandat, il lui est proposé de valider son mandat de prélèvement en ligne.
- Vous devez transmettre les données d’identification et les coordonnées du client. Ces dernières ne peuvent pas être modifiées par le client lors de la création de son mandat.
- Le client valide les informations le concernant, communique ses
coordonnées bancaires (IBAN) puis confirme que le mandat prérempli
contient bien les bonnes informations.
- Le client reçoit un code sur son téléphone portable ou son adresse
électronique qu'il doit ressaisir sur la page pour valider et signer son
mandat.
- Si vous cliquez sur TELECHARGER LE MANDAT DE PRELEVEMENT, vous
pouvez vérifier les informations qu'il contient.
. - Le client a la confirmation que son mandat est bien enregistré. Il
peut télécharger le mandat au format PDF ou l’imprimer. Le montant de
son achat ou de sa prochaine échéance sera prélevé sur son compte
bancaire.
- La date du prochain prélèvement est indiquée sur le ticket récapitulatif.
Délais de présentation
Contrairement aux transactions cartes, un délai de présentation est à respecter avant l’échange interbancaire.
Ainsi, pour un règlement/échéance à J, le prélèvement SEPA doit être présenté en compensation à J-1 JOB (Jour Ouvré Bancaire) au plus tard.
Remise en banque des paiements
Sogenactif effectue la remise en banque.
Pré-notification
Vous êtes tenu de fournir au débiteur une notification préalable au moins 14 jours calendaires (sauf accord bilatéral sur un délai différent) avant la date d’échéance du prélèvement SEPA et par tout moyen : facture, avis, échéancier, etc.
Vérification de paiement
Au cours de la cinématique de paiement, il est possible que nous ne recevions pas le retour SDD escompté (timeout), l'état de la transaction est :
- TO_CONFIRM_AUTHOR
- TO_CONFIRM_CAPTURE
- TO_CONFIRM_CREDIT
Un traitement par fichier est exécuté quotidiennement pour mettre à jour ces transactions vers des états finaux :
- REFUSED
- TO_CAPTURE/TO_VALIDATE
- CAPTURED
- TO_CREDIT
Le diagramme du paragraphe Effectuer un paiement SDD schématise ces états ainsi que les transitions.
Le statut final apparaîtra dans vos journaux des transactions pour vous permettre de continuer le traitement de la commande.
Ouvrir votre contrat d'acceptation SDD
Afin d'émettre des prélèvements SEPA, vous devez au préalable :
- signer un contrat de service avec votre banque (= Convention d’émission de prélèvement SEPA) ;
- avoir un Identifiant Créancier SEPA (ICS), délivré par la Banque de France pour la France ;
Opérations possibles par interfaces
Certaines opérations ne sont possibles que via certaines interfaces. Voici un tableau récapitulatif des actions possibles sur chaque interface :
Actions/Interfaces | Sogenactif Paypage | Sogenactif Office Serveur | Sogenactif Gestion | Sogenactif Office Batch |
---|---|---|---|---|
Création d'un mandat et paiement | Oui | Oui | Oui | Non |
Effectuer un paiement à partir d'un mandat déjà signé. | Oui si le mandat a été enregistré en mode One Clic lors de sa création. | Oui : fonction directDebitOrder | Oui | Oui : fonction directDebitOrder |
Gestion de caisse sur les prélèvements | Non | Oui | Oui | Oui |
Recherche d'un mandat | Non | Oui : fonction searchMandate | Oui | Non |
Récupération d'un mandat pdf signé | Non | Oui : fonction getPdfMandate | Oui | Non |
Récupération/Consultation d'un mandat | Non | Oui : fonction getMandateData | Oui (rechercher un mandat et l'ouvrir dans l'interface) | Non |
Effectuer un paiement SDD
Sogenactif vous offre trois solutions pour intégrer le moyen de paiement SDD :
- Sogenactif Paypage qui assure l’interface de paiement directement avec le client via son navigateur Web.
- Sogenactif Office Serveur qui vous laisse la possibilité d’afficher vous-même vos pages de paiement et qui fonctionne par un dialogue de serveur à serveur.
- Sogenactif Office Batch qui vous permet de traiter des paiements par échange de fichiers.
Les modes de remise disponibles pour une transaction SDD sont les suivants :
- Mode annulation : mode par défaut, il permet de remiser la transaction à une date prédéfinie, appelée délai de capture. Lorsque ce délai de capture est atteint, la remise est automatiquement envoyée. Ce délai est paramétré via le champ captureDay, sa valeur par défaut est 0 (paiement en fin de journée).
- Mode validation : vous devez valider la transaction pour déclencher la remise. Un délai de capture doit aussi être défini. Lorsque ce délai de capture est atteint ou dépassé, vous ne pourrez plus valider la transaction, celle-ci expirera donc automatiquement.
Le diagramme ci-dessous explique les différents états par lesquels peuvent passer les transactions selon le mode de capture choisi :
Effectuer un paiement SDD avec Sogenactif Paypage
La cinématique de paiement pour Sogenactif Paypage est décrite ci-dessous :
Paramétrer la requête de paiement
Dans le cadre de l’acceptation de SDD il est nécessaire de :
- vous assurer de l’identification du client ;
- pré-remplir la page de création de mandat et favoriser ainsi la transformation de transaction de type SDD.
La Référence Unique de Mandat (RUM) peut être transmise dans la requête. Si elle n’est pas envoyée, elle est générée automatiquement.
Attention : dans le cas de l’envoi de la RUM dans la requête, il est de votre responsabilité de vous assurer de l’unicité de la RUM. En cas de doublon, la signature du mandat sera refusée, et l’acheteur ne pourra pas effectuer le règlement de son achat.
Vous trouverez ci-dessous la liste des paramètres permettant le passage des informations personnelles du porteur.
Nom du champ | Remarques / règles |
---|---|
customerContact.email | Obligatoire si méthode d’authentification par MAIL_OTP |
customerContact.firstname | Obligatoire |
customerContact.gender | Facultatif |
customerContact.lastname | Obligatoire |
customerContact.mobile | Obligatoire si méthode d’authentification par
SMS_OTP. Le format avec code régional est attendu (+33
…). |
customerContact.legalId | Facultatif, seulement utilisé avec un mandat de type (transactionActors) BTOF. |
customerContact.positionOccupied | Facultatif, seulement utilisé avec un mandat de type (transactionActors) BTOF. |
customerAddress.city (*) | Facultatif. Si non valorisé, le client devra saisir
cette information sur la page de saisie de mandat |
customerAddress.country (*) | Facultatif. Si non valorisé, le client devra saisir
cette information sur la page de saisie de mandat |
customerAddress.street (*) | Facultatif. Si non valorisé, le client devra saisir
cette information sur la page de saisie de mandat |
customerAddress.streetNumber (*) | Facultatif. Si non valorisé, le client devra saisir
cette information sur la page de saisie de mandat |
customerAddress.zipCode (*) | Facultatif. Si non valorisé, le client devra saisir
cette information sur la page de saisie de mandat |
customerAddress.company | Obligatoire si le champ transactionActors est valorisé à BTOF. |
customerAddress.businessName | Facultatif. Seulement utilisé avec un mandat de type
(transactionActors) BTOF. |
customerLanguage | Permet de choisir la langue utilisée sur les pages Sogenactif et SDD. |
mandateId | Facultatif. Si elle n’est pas valorisée la référence
unique du mandat est générée par Sogenactif. ATTENTION, il est de la responsabilité du
marchand de s’assurer de son unicité s’il le fournit. |
paymentMeanData.sdd.mandateAuthentMethod | Facultatif. Doit être fourni pour utiliser la fonction
searchMandate |
paymentMeanData.sdd.mandateAuthentMethod | Facultatif. Valeurs possibles : MAIL_OTP,
SMS_OTP. Si non renseigné, valeur par défaut =
MAIL_OTP. |
paymentMeanData.sdd.mandateUsage | Facultatif. Valeurs possibles : ONE_OFF,
RECURRENT. Si non renseigné, valeur par défaut =
RECURRENT. |
statementReference | Facultatif. Disponible pour certains
acquéreurs. |
transactionActors | Facultatif. valeurs possibles : BTOC ou
BTOF Si non renseigné, valeur par défaut =
BTOC |
(*) Vous devez nécessairement renseigner les 5 champs : city, country, street, streetNumber et zipCode, afin que l'adresse soit prise en compte et pré-renseignée sur la page de saisie du mandat.
Analyser la réponse
Le tableau suivant récapitule les différents cas de réponse à traiter :
État | Champs de la réponse | Action à réaliser |
---|---|---|
Paiement accepté | acquirerResponseCode = 00
authorisationId = (voir le
Dictionnaire des données).captureDay = en mode
AUTHOR_CAPTURE, la valeur est corrigée par Sogenactif
en fonction des règles de présentation choisie par l'acquéreur
(captureDay = captureLimitDate - date du jour).En mode
VALIDATION, la valeur reste inchangée par rapport à la
requête. captureLimitDate = la date de
présentation n’est retournée dans la réponse qu'en mode
AUTHOR_CAPTURE. En mode VALIDATION, la date de présentation du
prélèvement est retournée lors de la validation de la transaction
SDD.customerBusinessName = la
raison sociale renseignée en entrée ou chez Sogenactif.customerLegalId = le numéro
SIRET renseigné en entrée ou chez Sogenactif.customerPositionOccupied = le
titre du représentant légal renseigné en entrée ou chez Sogenactif.maskedPan = règle de masquage
BIC.IBANExemple :
AXABFRPP314.FR76######################44 BIC : en
clair ; IBAN : 4 premiers et 2 derniers chiffres en
clair. mandateId = RUM que vous
devez conserver.mandateUsage = ONE_OFF ou
RECURRENTpaymentMeanBrand =
SEPA_DIRECT_DEBITpaymentMeanType =
DIRECT_DEBITresponseCode =
00secureReference = référence
de sécurisation de la transaction dans le cadre de l'option
SafeDebit. Cette référence devra être transmise à SSP en cas
de demande d'indemnisation. transactionActors = BTOB,
BTOF ou BTOC |
Vous pouvez livrer la commande. |
Refus acquéreur | acquirerResponseCode = (voir
le Dictionnaire des données).responseCode =
05 |
L’autorisation est refusée pour un motif non lié à la
fraude. Si vous n’avez pas opté pour l’option « nouvelle
tentative de paiement » (pour plus de détails veuillez consulter
le Configuration des fonctionnalités), vous pouvez proposer à votre
client de payer avec un autre moyen de paiement en générant une
nouvelle requête. |
Refus nombre max essais atteint | responseCode = 75 |
Le client a fait plusieurs tentatives qui ont toutes échoué. |
Refus suite problème technique | acquirerResponseCode = 90-98
responseCode = 90, 99
|
Problème technique temporaire lors du traitement de la transaction. Proposez à votre client de refaire un paiement ultérieurement. |
Pour connaître l'intégralité des codes réponses (responseCode
) et codes réponses
acquéreur (acquirerResponseCode
), veuillez vous
référer au Dictionnaire des
données.
Effectuer un paiement SDD avec Sogenactif Office Serveur
Le processus de paiement pour Sogenactif Office Serveur est décrit ci-dessous :
Initialiser un mandat (initializeMandate)
L’initialisation d’un mandat SEPA est effectuée en appelant la méthode initializeMandate.
Requête d’initialisation de création de mandat (InitializeMandate)
Vous devez valoriser les champs spécifiques suivants dans la requête d'initialisation pour une création de mandat SDD :
Nom du champ | Remarques / règles |
---|---|
iban | Obligatoire. Les IBAN français comportent 27
chiffres. |
mandateId | Facultatif (déterminé par Sogenactif si non fourni) |
merchantReturnUrl | Obligatoire |
transactionActors | Facultatif. Valeurs possibles = BTOC, BTOB,
BTOF Si non renseigné, valeur par défaut =
BTOC |
customerId | Facultatif. Doit être fourni pour utiliser la fonction
searchMandate |
customerLanguage | Permet de choisir la langue utilisée sur les pages Sogenactif et SDD. |
statementReference | Facultatif. Disponible pour certains
acquéreurs |
customerContact.email | Obligatoire si méthode d’authentification par MAIL_OTP. |
customerContact.firstname | Obligatoire |
customerContact.gender | Facultatif |
customerContact.lastname | Obligatoire |
customerContact.mobile | Obligatoire si méthode d’authentification par
SMS_OTP. Le format avec code régional est attendu (+33
…). |
customerContact.legalId | Obligatoire si transactionActors à BTOB Facultatif si
transactionActors à BTOF Ne pas renseigner si
transactionActors à BTOC |
customerContact.positionOccupied | Facultatif si transactionActors à BTOB ou BTOF Ne pas
renseigner si transactionActors à BTOC |
customerAddress.city | Obligatoire |
customerAddress.country | Obligatoire |
customerAddress.street | Obligatoire |
customerAddress.streetNumber | Obligatoire |
customerAddress.zipCode | Obligatoire |
customerAddress.company | Obligatoire si transactionActors est valorisé à BTOB ou
BTOF. Ne pas renseigner si transactionActors à
BTOC. |
customerAddress.businessName | Obligatoire si transactionActors est valorisé à BTOB ou
BTOF. Ne pas renseigner si transactionActors à
BTOC. |
Exemple de requête : initializeMandate via Sogenactif Office Serveur JSON
{
"customerAddress":
{
"city":"PARIS",
"country":"FRA",
"street":"Rue de la Bastille",
"streetNumber":"19",
"zipCode":"75000"
},
"customerContact":
{
"email":"julie.dupont@mail.com",
"firstname":"Julie",
"gender":"F",
"lastname":"DUPONT"
},
"customerId":"JAU001"
"iban":"FR7617906001120227366700148",
"interfaceVersion":"MR_WS_2.19",
"keyVersion":"1",
"merchantId":"210011990011607",
"merchantReturnUrl":"https://merchantReturnUrl.com",
"paymentMeanAlias":"SEPA_DIRECT_DEBIT",
"paymentMeanData":
{
"sdd":
{
"mandateAuthentMethod":"MAIL_OTP"
}
},
"transactionActors":"BTOC",
"seal":"12682c81e701f171b9f33061846c60dcade2afb73eb064027fbb88cc6068382e"
}
Réponse d’initialisation de création de mandat
Le tableau suivant récapitule les différents cas de réponse à traiter :
État | Champs de la réponse | Action à réaliser |
---|---|---|
Initialisation de création de mandat acceptée | acquirerResponseCode =
00messageVersion = version du
message récupérée en réponse à l’initialisation du
paiement.mandateId = numéro de mandat
(identique à celui de la requête si fournie, sinon généré par
Sogenactif).mandateResponseCode = code
réponse du serveur Sogenactif.redirectionData = données de
redirection récupérées en réponse à l’initialisation du
paiement.redirectionUrl = URL de
redirection vers le site Web de SDD. |
Redirigez le client vers redirectionUrl . |
Initialisation de création de mandat rejetée | responseCode <>
00 |
Consultez le champ errorFieldName , puis corrigez
la requête.En cas d’erreur persistante, contactez
l'assistance technique. |
Refus acquéreur | acquirerResponseCode = (voir
le Dictionnaire des données).responseCode =
05 |
L’autorisation est refusée pour un motif non lié à la fraude, vous pouvez proposer à votre client de payer avec un autre moyen de paiement en générant une nouvelle requête. |
Refus suite problème technique | acquirerResponseCode = 90-98
responseCode = 90, 99
|
Problème technique temporaire lors du traitement de la transaction. Proposez à votre client de refaire un paiement ultérieurement. |
Pour connaître l'intégralité des codes réponses (responseCode
) et codes réponses
acquéreur (acquirerResponseCode
), veuillez vous
référer au Dictionnaire des
données.
Rediriger le client vers les pages SDD
Le client doit être redirigé vers l’URL fournie en réponse de la méthode « initializeMandate ». La redirection s’effectue en faisant un appel HTTP POST vers la « redirectionUrl » reçue avec les paramètres « messageVersion » et « redirectionData ».
A la fin de la cinématique de signature de mandat, le client est redirigé sur l’URL fournie dans la requête d’initialisation, « merchantReturnUrl ». Les champs suivants sont transmis en POST et doivent être récupérés pour finaliser la création du mandat :
Nom du champ | Remarques / règles |
---|---|
responseCode | Code réponse du processus |
redirectionData | Données de redirection récupérées en réponse à l’initialisation du paiement. |
messageVersion | Version du message récupérée en réponse à l’initialisation du paiement. |
amount | Montant de la transaction en centimes |
merchantId | Identifiant de la boutique |
transactionReference | Référence de la transaction |
transactionId | Identifiant de la transaction |
transactionDate | Date de la transaction |
Finaliser la création d’un mandat (finalizeMandate)
Une fois que le client a signé son mandat sur les pages SDD, il est redirigé vers l’URL qui a été fourni lors de l’appel à initializeMandate dans le champ merchantReturnUrl.
La redirection s’effectue par Sogenactif en faisant un appel HTTP POST vers cette URL avec les paramètres messageVersion, redirectionData. Ce sont ces paramètres qui doivent être transmis dans l’appel à la méthode finalizeMandate pour terminer la création de mandat.
Requête de finalisation de création de mandat
Vous devez valoriser les champs spécifiques suivants dans la requête de finalisation pour un paiement SDD.
Nom du champ | Remarques / règles |
---|---|
redirectionData | Redirection data retrieved after the customer returns to your website (cf. Rediriger le client vers les pages SDD). |
messageVersion | Message version retrieved after the customer returns to your website (cf. (cf. Rediriger le client vers les pages SDD). |
Réponse de finalisation de création de mandat
Le tableau suivant récapitule les différents cas de réponse à traiter :
État | Champs de la réponse | Action à réaliser |
---|---|---|
Paiement accepté | acquirerResponseCode =
00authorisationId = (voir le
Dictionnaire des données).bic = code d'identification
de banque (BIC).iban = numéro
international de compte bancaire (IBAN). Les IBAN français
comportent 27 chiffres.mandateId = numéro de mandat
(identique à celui de la requête si fournie, sinon généré par
Sogenactif).mandateResponseCode = code
réponse retourné par Sogenactif (indique le résultat
global de la création de mandat).paymentMeanBrand =
SEPA_DIRECT_DEBIT paymentMeanAlias = alias du
moyen de paiement défini et utilisé par le client dans son
portefeuille.responseCode =
00transactionActors = schéma de
mandat : BTOC|BTOB|BTOF |
Vous pouvez livrer la commande. |
Refus acquéreur | acquirerResponseCode = (voir
le Dictionnaire des données).responseCode =
05 |
L’autorisation est refusée pour un motif non lié à la fraude, vous pouvez proposer à votre client de payer avec un autre moyen de paiement en générant une nouvelle requête. |
Refus suite problème technique | acquirerResponseCode = 90-98
responseCode = 90, 99
|
Problème technique temporaire lors du traitement de la transaction. Proposez à votre client de refaire un paiement ultérieurement. |
Pour connaître l'intégralité des codes réponses (responseCode
) et codes réponses
acquéreur (acquirerResponseCode
), veuillez vous
référer au Dictionnaire des
données.
Transmettre une demande de prélèvement SEPA
Requête de prélèvement SEPA
Pour créer un prélèvement SDD, il faut utiliser la fonction directDebitOrder et indiquer dans la requête le type de paiement SDD et la référence unique de mandat.
Nom du champ | Remarques / règles |
---|---|
paymentMeanBrand | Doit être valorisé avec SEPA_DIRECT_DEBIT. |
Exemple de requête : directDebitOrder via Sogenactif Office Serveur JSON
{
"amount":"1000",
"captureDay":"0",
"captureMode":"AUTHOR_CAPTURE",
"currencyCode":"978",
"customerId":"customerId1",
"customerIpAddress":"127.0.0.1",
"interfaceVersion":"IR_WS_2.18",
"keyVersion":"1",
"mandateId":"000000000000000031",
"merchantId":"210043956120001",
"merchantTransactionDateTime":"2017-10-16T16:13:11.602+02:00",
"orderChannel":"INTERNET",
"paymentMeanBrand":"SEPA_DIRECT_DEBIT",
"transactionOrigin":"SIPS-SIM",
"transactionReference":"SIM20171016161311",
"seal":"108458787fe9dfe063605b21f946c727aab94468683482da1a5e2eb7ac08a016"
}
Réponse de demande de prélèvement SEPA
Dans le cas des paiements SDD, les champs spécifiques suivants sont remplis:
Nom du champ | Remarques / règles |
---|---|
maskedPan | Règle masquage : BIC.IBAN comme suit :
AXABFRPP314.FR76######################44 BIC : en clair ; IBAN
: 4ers et 2 derniers chiffres en clair. Le BIC peut
varier de 8 à 11 caractères, l’IBAN varie dans chaque pays et a
une taille maximum de 34 caractères. |
transactionActors | Valeurs possibles :
Cette valeur provient du type du mandat. |
mandateId | RUM à conserver par le commerçant. |
captureLimitDate | Format AAAAMMJJ. La date de présentation n’est
retournée dans la réponse qu’en mode AUTHOR_CAPTURE. En mode
VALIDATION, c’est la date du jour additionnée au captureDay qui
est retournée, la date réelle de prélèvement est retournée lors de
la validation de la transaction SDD. |
captureDay | Valeur corrigée par Sogenactif en fonction des
règles de présentation choisie par l'acquéreur. captureDay =
captureLimitDate - date du jour |
authorisationId | En mode VALIDATION c’est un « 0 » qui est retourné, la valeur réelle est retournée lors de la validation de la transaction SDD. |
Exemple de réponse : directDebitOrder via Sogenactif Office Serveur JSON
{
"authorisationId":"32100000010020171016",
"acquirerResponseCode":"00",
"complementaryCode":"00",
"responseCode":"00",
"transactionDateTime":"2017-10-16T16:14:06+02:00",
"holderAuthentStatus":"NO_AUTHENT",
"scoreProfile":"10_GONOGO_PRE_AUTHORISATION",
"maskedPan":"SOGEFRPPXXX/FR7630003005050005001582616",
"captureLimitDate":"20171018",
"transactionActors":"BTOC",
"mandateId":"000000000000000031",
"valueDate":"20171018",
"s10TransactionReference":
{
"s10TransactionId":"10",
"s10TransactionIdDate":"20171016"
},
"transactionReference":"SIM20171016161311",
"seal":"d87ab3c1fac4d3eb53cdf3fb02d31b9da7483cb72898b4c639eeb1b52ed5a708",
"preAuthorisationProfile":"10_GONOGO_PRE_AUTHORISATION",
"preAuthorisationProfileValue":"unknown",
"captureDay":2,
"captureMode":"AUTHOR_CAPTURE",
"transactionPlatform":"PROD"
"secureReference":"SF_16957"
}
Gérer vos transactions SDD
Opérations de caisse disponibles
Les opérations suivantes sont disponibles sur les transactions SDD :
Gestion de caisse | ||
---|---|---|
Annulation | V | Il est possible d’annuler un prélèvement SDD via Sogenactif Office Serveur ou Sogenactif Gestion. Aucun champ
spécifique à ce moyen de paiement n’est à envoyer. L’annulation peut porter sur le montant
total ou partiel de la transaction
d’origine. L’annulation doit se faire avant l’ordre de
remise en banque, et il est de votre responsabilité de vérifier
que la remise n’a pas été effectuée. |
Validation | V | La validation via Sogenactif Office Serveur ou Sogenactif Gestion peut porter sur le
montant total ou partiel de la transaction
d’origine. Lors de la validation d’une transaction SDD,
la date de présentation du prélèvement créé est retournée dans le
champ captureLimitDate. Conformément à la
réglementation SEPA, il est de votre responsabilité de présenter
cette date au client. |
Remboursement | V | Le remboursement d’un prélèvement SDD via Sogenactif Office Serveur ou Sogenactif Gestion génère un SCT. Il
n’est pas possible d’effectuer plusieurs remboursements sur un
même SDD. Le remboursement unique
peut être partiel ou total. Les éventuels impayés sur remboursements
apparaissent dans le journal de rapprochement des
impayés. |
Duplication | V | Il est possible de dupliquer un prélèvement SDD via
Sogenactif Office Serveur ou Sogenactif Gestion. Aucun champ
spécifique à ce moyen de paiement n’est à envoyer.
Conformément à la réglementation SEPA, il est de votre
responsabilité de présenter au client la date du prélèvement créé
par duplication. |
Abandon de transactions SDD | V | L’opération de révocation de mandat disponible uniquement dans Sogenactif Gestion provoque automatiquement l’abandon de toutes les transactions programmées et non remisées en banque sans aucune intervention supplémentaire nécessaire de votre part. |
Le diagramme ci-dessous vous permet de savoir quelle opération de gestion de caisse est disponible lorsqu'une transaction est dans un état donné :
Consulter vos transactions SDD
Journaux
Les journaux mis à disposition par Sogenactif vous permettent d’avoir une vision exhaustive et consolidée de vos transactions, opérations de caisse, situation comptable et impayés. Vous pouvez utiliser ces informations pour enrichir votre système d’information.
La disponibilité des transactions SDD pour chaque type de journal est récapitulée dans le tableau ci-dessous :
Disponibilité des journaux | |
---|---|
Journal des transactions | V |
Journal des opérations | V |
Journal de rapprochement bancaire | V |
Journal de rapprochement des impayés | V |
Sogenactif Gestion
Vous pouvez consulter vos transactions SDD et effectuer différentes opérations de gestion de caisse grâce à Sogenactif Gestion.
Gérer ses mandats via Sogenactif Office Serveur
Rechercher un mandat
Vous pouvez rechercher l’ensemble des mandats d’un client donné si l’identifiant du client a été fourni lors de la création de mandat (lors de l’appel à initializeMandate sur Sogenactif Office Serveur ou lors de la demande de paiement sur Sogenactif Paypage).
Requête searchMandate
Nom du champ | Remarques / règles |
---|---|
customerId | Identifiant du client |
Un exemple de requête : searchMandate est disponible sur cette page.
Réponse searchMandate
Nom du champ | Remarques / règles |
---|---|
mandateResponseCode | Code réponse retourné par Sogenactif (indique le résultat global de la recherche de mandat). |
mandateList | Liste des mandats associés au client. |
Données du mandat renvoyées (mandateList) :
Nom du champ | Remarques / règles |
---|---|
bic | Code d'identification de banque. |
iban | Numéro international de compte bancaire : les IBAN français comportent 27 chiffres. |
mandateLastUpdateDate | Date de dernière mise à jour du mandat. |
mandateCreationDate | Date de création du mandat. |
mandateId | Numéro de mandat. |
mandateSignatureDate | Date de signature du mandat. |
mandateStatus | Statut du mandat. |
mandateUsage | Type d’utilisation du mandat. |
transactionActors | Type du mandat. |
Un exemple de réponse : searchMandate est disponible sur cette page.
Récupérer le PDF d’un mandat
Vous pouvez récupérer le contenu d’un PDF via Sogenactif Office Serveur pour, par exemple, en proposer le téléchargement aux clients directement depuis votre site Web. La méthode getPdfMandate permet de recevoir le contenu du PDF sous une forme encodée en Base64. Il faut alors la décoder pour reconstruire le fichier PDF.
Requête getPdfMandate
Nom du champ | Remarques / règles |
---|---|
mandateId | Numéro de mandat |
Un exemple de requête gePdftMandate est disponible sur cette page.
Réponse getPdfMandate
Nom du champ | Remarques / règles |
---|---|
mandateResponseCode | Code réponse retourné par Sogenactif (indique le résultat global de la récupération du PDF du mandat). |
mandatePdf | Contenu du PDF encodé en Base64. |
Un exemple de réponse gePdftMandate est disponible sur cette page.
Exemple d’implémentation pour décoder la réponse getPdfMandate
L’exemple ci-dessous est codé en Java et permet de proposer au client le téléchargement d’un PDF à partir du champ mandatePdf reçu :
byte[] decodedBytes = Base64.decodeBase64(%MANDATE_PDF_RECEIVED%).getBytes("UTF-8"));
response.setContentType("application/pdf");
response.setHeader("Content-disposition", "attachment; filename=MandatePDFFile.pdf");
try (final ByteArrayInputStream in = new ByteArrayInputStream(decodedBytes);
final OutputStream out = response.getOutputStream()) {
final byte[] buffer = new byte[4096];
int length;
while ((length = in.read(buffer)) > 0) {
out.write(buffer, 0, length);
}
}
Récupérer les données d’un mandat
Vous pouvez récupérer les données globales d’un mandat. Il s’agit des données propres au mandat (statut, IBAN, BIC, …), des données du client qui a créé ce mandat, ainsi que de la liste des transactions associées à ce mandat, le cas échéant.
Requête getMandateData
Nom du champ | Remarques / règles |
---|---|
mandateId | Numéro de mandat |
Un Exemple de requête getMandateData est disponible sur cette page.
Réponse getMandateData
Données relatives au mandat et au client :
Nom du champ | Remarques / règles |
---|---|
mandateResponseCode | Code réponse retourné par Sogenactif (indique le résultat global de la recherche du mandat). |
acquirerResponseCode | Code réponse retourné par Sogenactif. |
mandateId | Numéro de mandat. |
mandateCreationDate | Date de création du mandat. |
mandateLastUpdateDate | Date de dernière mise à jour du mandat. |
mandateSignatureDate | Date de signature du mandat. |
mandateUsage | Type d’utilisation du mandat : ONE_OFF|RECURRENT |
mandateStatus | Statut du mandat. |
bic | Code d'identification de banque. |
debtorName | Nom complet de débiteur associé au mandat. |
iban | Numéro international de compte bancaire : les IBAN français comportent 27 chiffres. |
transactionActors | Type du mandat : BTOB|BTOC|BTOF |
directDebitList | Contient la liste des prélèvements créés à partir du mandat (voir tableau ci-dessous). |
customerContact.email | Contient l’e-mail du client. |
customerContact.gender | Indique si le client est un homme (=M) ou une femme (=F). |
customerContact.mobile | Contient le numéro de téléphone portable. |
customerContact.legalId | Numéro de SIRET. |
customerContact.positionOccupied | Titre du représentant légal. |
customerAddress.city | Contient la ville de l’adresse du client. |
customerAddress.country | Contient le code pays de l’adresse du client. |
customerAddress.street | Contient le nom de rue de l’adresse du client. |
customerAddress.streetNumber | Contient le numéro de rue de l’adresse du client. |
customerAddress.zipCode | Contient le code postal de l’adresse du client. |
customerAddress.company | Contient la dénomination commerciale de la société. |
customerAddress.businessName | Raison sociale. |
Données des prélèvements renvoyées (directDebitList) :
Nom du champ | Remarques / règles |
---|---|
amount | Montant du prélèvement. |
dueDate | Date de remise en banque de la transaction. |
directDebitCreationDate | Date de la création du prélèvement. |
directDebitStatus | Statut du prélèvement. |
Un Exemple de requête getMandateData est disponible sur cette page.