CYCLE DE VIE DES TRANSACTIONS

CYCLE DE VIE DES TRANSACTIONS Version 1.1 21/12/2009 Ce document et son contenu sont strictement confidentiels et la propriété de Natixis Paiements. Il n est pas contractuel. Toute reproduction et/ou distribution de ce document ou de toute ou partie de son contenu à une entité tiers sont strictement interdits ou sujet à une autorisation écrite préalable de Natixis Paiements. Tous droits réservés

Sommaire 1. DÉFINITION DES DIFFÉRENTS TYPES DE PAIEMENT... 3 1.1. PAIEMENT STANDARD... 3 1.2. PAIEMENT DIFFÉRÉ... 3 1.3. PAIEMENT EN PLUSIEURS FOIS... 3 1.3.1. CRÉATION VIA REQUÊTE DE PAIEMENT HTTP POST... 4 1.3.2. CRÉATION VIA SAISIE MANUELLE... 4 2. LE PAIEMENT VU DU COMMERÇANT... 5 2.1. MODE VALIDATION AUTOMATIQUE... 5 2.1.1. CYCLE DE VIE D UNE TRANSACTION DE PAIEMENT STANDARD... 5 2.1.2. CYCLE DE VIE D UNE TRANSACTION DE PAIEMENT DIFFÉRÉ... 6 2.1.3. CYCLE DE VIE D UNE TRANSACTION DE PAIEMENT EN PLUSIEURS FOIS... 7 2.2. MODE VALIDATION MANUELLE... 8 2.2.1. CYCLE DE VIE D UNE TRANSACTION DE PAIEMENT «STANDARD»... 8 2.2.2. CYCLE DE VIE D UNE TRANSACTION DE PAIEMENT DIFFÉRÉ... 9 2.2.3. CYCLE DE VIE D UNE TRANSACTION DE PAIEMENT EN PLUSIEURS FOIS... 10 2.3. SPÉCIFICITÉS LIÉES AUX PROCÉDURES DE FORÇAGE... 11 Cinématique des transactions V1.1 - Copyright Natixis Paiements page 2/11

1. Définition des différents types de paiement 1.1. Paiement standard Un paiement est considéré comme standard dès lors qu il fait l objet d un débit du client en une fois, et que la date de présentation en remise positionnée lors de l enregistrement du paiement n est pas strictement supérieure à 6 jours par rapport à la date du jour. 1.2. Paiement différé Un paiement est considéré comme différé dès lors que la date souhaitée est supérieure de 6 jours par rapport à la date d enregistrement du paiement. Ce type de paiement n est pas garanti pour le commerçant. Fonctionnellement, une demande d empreinte (demande d un montant de 1 ) est effectuée au moment de l enregistrement du paiement pour s assurer de la validité de la carte. Si cette demande d empreinte est acceptée, le paiement est enregistré. Le jour pour la remise en banque, une demande du montant à débiter au client est effectuée. Le résultat de la demande n est nullement lié au résultat de la demande d empreinte. Ainsi, le paiement peut être refusé à ce moment. Le commerçant doit donc être très vigilant sur ce type de paiement avant de délivrer le bien à son client. En cas d échec de la demande, un e-mail est adressé au commerçant par la plateforme. Dans la réponse à la requête de paiement http POST et dans les webservices, le fait qu une demande d empreinte ait été réalisée à la place d une demande est indiqué dans le paramètre AUTH_MODE qui est alors valorisé à MARK. Dans l outil de gestion de caisse, ce type de paiement est identifiable par la valorisation de la rubrique «mention empreinte» dans le détail de la transaction : 1.3. Paiement en plusieurs fois Un paiement est dit «en plusieurs fois» dès lors que le client est débité du montant de son achat en plusieurs échéances. Cinématique des transactions V1.1 - Copyright Natixis Paiements page 3/11

Seule la première échéance peut faire l objet d une garantie pour le commerçant sous réserve que celle-ci ne fasse pas l objet d un différé et sous réserve des conditions de réalisation de la transaction. 1.3.1. Création via requête de paiement http POST Dans la requête de paiement http POST, le commerçant positionne les informations suivantes : AMOUNT= montant total du paiement PAYMENT_CONFIG=MULTI:first= montant de la 1 ère échéance ;count= Nbre d échéances ; période=intervalle entre chaque échéance Le système calcule alors automatiquement les échéances de paiement selon la méthode suivante : N échéance Montant de l échéance Date de présentation (remise) de l échéance 1 Montant de la 1ère échéance Date du paiement + capture_delay 2 Valeur entière de [(montant total montant de la 1ère échéance) / (nombre d échéance 1)] Date du paiement + capture_delay + intervalle entre 2 échéances... N (=nbre d échéances) Valeur entière de [(montant total montant de la 1ère échéance) / (nombre d échéance 1)] + reste de la division Date du paiement + capture_delay + (n-1)* intervalle entre 2 échéances 1.3.2. Création via saisie manuelle Le paiement en plusieurs fois peut aussi faire l objet d une saisie manuelle par le commerçant. Pour cela, cliquer sur la case à cocher «paiement en plusieurs fois». Renseigner le nombre d échéances, le montant du 1 er paiement, et l intervalle entre chaque échéance. NB : La calculatrice permet de calculer automatiquement le montant de la 1 ère échéance en fonction du montant total de la transaction et du nombre d échéances positionné. Cinématique des transactions V1.1 - Copyright Natixis Paiements page 4/11

2. Le paiement vu du commerçant Dans tous les schémas suivants, la légende suivante est adoptée : Légende : : Action commerçant nécessaire - manuelle (outil gestion de caisse) ou automatique (webservice) - 2.1. Mode validation automatique 2.1.1. Cycle de vie d une transaction de paiement standard REALISATION PAIEMENT Authentification 3D-Secure Contrôles locaux D autorisation Envoi e-mail client au jour de présentation Suite à la demande de paiement (par l intermédiaire d une requête de paiement automatisée ou d une saisie manuelle), plusieurs contrôles sont automatiquement mis en oeuvre : L authentification 3D-Secure (si la transaction a lieu en ligne et si le commerçant a l option active); Cinématique des transactions V1.1 - Copyright Natixis Paiements page 5/11

Différents contrôles locaux réalisés directement par la plateforme de paiement (ceux-ci incluent potentiellement les contrôles liés la souscription au service additionnel Contrôle Risques), Une demande est également effectuée auprès de la banque du client. Si l un de ces contrôles échoue, la demande de paiement n est pas acceptée. Dans le cas d une transaction en ligne, le client est informé du refus à l écran. Dans l outil de gestion de caisse, la transaction est consultable avec le statut refusé. Dans le cas contraire, la transaction prend l un des 2 statuts suivants : : Le client est informé de l acceptation de sa demande de paiement, et est destinataire, dans le cas où le commerçant a l activation de cette option, d un e-mail lui confirmant l enregistrement de son paiement. La transaction partira automatiquement en remise le jour e par le commerçant. Dans l attente de cette présentation, le commerçant peut modifier la date de présentation ainsi que le montant à remettre en banque (modification du montant uniquement à la baisse, ce cas correspond à une livraison partielle par le commerçant). Si nécessaire, il peut également annuler la transaction : celle-ci prend alors le statut annulé. : ce statut apparaît occasionnellement lorsqu un client a le plafond des paiements autorisés pour sa carte sans que sa banque ne fasse pour autant un refus. Dans ce cas un accord doit être par téléphone à la banque. (cf 2.3 spécifique au forçage expliquant la procédure à mettre en oeuvre). Si la transaction a été réalisée en ligne, le client est par défaut informé du refus de la transaction. 2.1.2. Cycle de vie d une transaction de paiement différé Toute transaction de paiement différé réalisée avec le mode de validation automatique, et dont la demande d empreinte a été réalisée avec succès, est consultable dans l outil de gestion de caisse avec le statut en attente La demande est automatiquement effectuée 6 jours avant la présentation en remise. Dans l attente, le commerçant peut annuler la transaction ou en modifier le montant (à la baisse uniquement) et/ou la date de présentation en remise. Le diagramme suivant résume les différents statuts pouvant être pris par ce type de transaction : Cinématique des transactions V1.1 - Copyright Natixis Paiements page 6/11

REALISATION PAIEMENT Authentification 3D-Secure Contrôles locaux D empreinte Envoi e-mail client D autorisarion au jour de présentation 2.1.3. Cycle de vie d une transaction de paiement en plusieurs fois La première échéance du paiement en plusieurs fois se comportera exactement comme une transaction de paiement standard ou une transaction de paiement différé selon la date de présentation en remise positionnée à l enregistrement du paiement. Les échéances suivantes sont par défaut positionnées en statut en attente. Leur bonne fin n est pas garantie pour le commerçant. En effet, la banque émettrice de la carte peut refuser la demande. La plateforme de paiement informe alors le commerçant du refus de la transaction par e-mail. Les échéances ultérieures suivent donc le diagramme d état suivant : Cinématique des transactions V1.1 - Copyright Natixis Paiements page 7/11

D autorisarion au jour de présentation NB : L annulation d une échéance n implique pas l annulation automatique des échéances suivantes restant à remettre en banque. 2.2. Mode validation manuelle 2.2.1. Cycle de vie d une transaction de paiement «standard» Suite à la demande de paiement (par l intermédiaire de la page de paiement ou d une saisie manuelle du paiement), des contrôles sont automatiquement mis en oeuvre : L authentification 3D-Secure (si la transaction a lieu en ligne et si le commerçant a l option active) Différents contrôles locaux effectués par la plateforme de paiement (ceux-ci incluent potentiellement les contrôles liés à la souscription au service additionnel Contrôle Risques), Une demande est effectuée auprès de la banque du client. Si l un de ces contrôles échoue, la demande de paiement n est pas acceptée. Dans le cas d une transaction en ligne, le client est informé du refus à l écran. Dans l outil de gestion de caisse, la transaction est consultable avec le statut refusé. Dans le cas contraire, la transaction prend l un des 2 statuts suivants en fonction de la réponse à la demande, tous deux nécessitant une action du commerçant : A valider : Le commerçant doit alors obligatoirement valider la transaction avant la date e, sinon, la transaction passe en statut expiré et ne peut plus être remise en banque. : ce statut apparaît occasionnellement lorsqu un client a le plafond des paiements autorisés pour sa carte, auquel cas un accord doit être par téléphone à la banque. (cf 2.3 spécifique au forçage expliquant la procédure a mettre en oeuvre). Cinématique des transactions V1.1 - Copyright Natixis Paiements page 8/11

Dès lors qu une transaction est validée, elle passe en statut en attente. Cela signifie que la transaction partira automatiquement en remise le jour e par le commerçant. Dans l attente de cette présentation, le commerçant peut modifier la date de présentation ainsi que le montant à remettre en banque (à la baisse uniquement). Il peut également annuler la transaction si nécessaire. La transaction prend alors le statut annulé. REALISATION PAIEMENT Authentification 3D-Secure Contrôles locaux D autorisation Envoi e-mail client au jour de présentation A valider Validation Mise en attente & Réactivation 2.2.2. Cycle de vie d une transaction de Paiement différé Toute transaction de paiement différé enregistrée avec succès sur la plateforme est consultable sur l outil de gestion de caisse en statut A valider et à autoriser. La demande est automatiquement effectuée le jour souhaité pour la présentation en remise, sous réserve que le commerçant ait précédemment validé la transaction. Dans l attente de la remise, le commerçant peut annuler la transaction ou en modifier le montant et/ou la date de présentation en remise. Cinématique des transactions V1.1 - Copyright Natixis Paiements page 9/11

Ces transactions suivent le diagramme d état suivant : REALISATION PAIEMENT Authentification 3D-Secure Contrôles locaux d empreinte Envoi e-mail client A valider & autoriser Validation A autoriser J-6 avant la date de présentation e J-6 avant la date de présentation e Émetteur à contacter Mise en attente & Réactivation A valider Validation au jour de présentation Légende : : Action commerçant nécessaire 2.2.3. Cycle de vie d une transaction de paiement en plusieurs fois La première échéance du paiement en plusieurs fois se comportera exactement comme une transaction de paiement standard ou une transaction de paiement différé, selon la date de présentation en remise positionnée à l enregistrement du paiement. Les échéances suivantes sont par défaut positionnées en statut à valider et autoriser tant que la première échéance n aura pas été validée par le commerçant. Leur bonne fin n est pas garantie pour le commerçant. En effet, la banque émettrice de la carte peut refuser la demande. NB : La validation de la 1ère échéance vaut validation de toutes les échéances suivantes. Par contre, l annulation d une échéance ne vaut pas annulation des échéances ultérieures. Cinématique des transactions V1.1 - Copyright Natixis Paiements page 10/11

A valider & autoriser Validation A autoriser J-6 avant la date de présentation e J-6 avant la date de présentation e Émetteur à contacter Mise en attente & Réactivation A valider Validation au jour de présentation Légende : : Action commerçant nécessaire 2.3. Spécificités liées aux procédures de forçage Lorsqu un internaute a le plafond des dépenses autorisées avec sa carte bancaire sur une période donnée, certaines banques, plutôt que de refuser la demande, demandent à être contactées par téléphone pour donner leur accord. Cette cinématique s appelle le «referral» ou en français «l appel phonie». Elle est de moins en moins mise en œuvre. En général les Banques françaises ne mettent pas en œuvre la procédure «d appel phonie» dans le contexte du commerce électronique. En conséquence, nombreux seront les commerçants à ne jamais être confrontés à cette situation. La mise en œuvre de cette cinématique relativement lourde est bien sûr optionnelle, le commerçant a toujours la possibilité de laisser le paiement en l état ou de l annuler, il ne sera alors jamais remis en Banque. La plateforme de paiement considère que ces transactions, de statut, doivent faire l objet d un traitement spécifique entre le commerçant et son client. De fait, elle affiche par défaut un message de refus de la transaction aux internautes dans le cas d un paiement online. Pour finaliser ces paiements, le commerçant doit prendre contact avec son client pour lui demander le numéro de sa carte, puis contacter son centre d appel referral en communiquant le numéro de la carte et le montant du paiement (ce numéro de téléphone est communiqué par la banque du commerçant). Ce centre d appel demande alors à la banque du client si elle souhaite autoriser ou refuser le paiement. Dans le cas d une autorisation, un numéro est communiqué. Il s agit du numéro à saisir par le commerçant suite au forçage sur son outil de gestion de gestion de caisse. Le commerçant doit alors prévenir lui-même son client du bon enregistrement de la transaction. Cinématique des transactions V1.1 - Copyright Natixis Paiements page 11/11