Le document suivant vous donne un aperçu général des différents types d’intégration et de notre processus de paiement. Si vous souhaitez en savoir plus sur les différents sujets, vous trouverez dans les textes ou dans le menu des liens directs. Ils vous mèneront à une description plus détaillée comprenant des exemples.
Traiter des paiements signifie manipuler des données sensibles. En particulier lorsque vous traitez
des cartes de crédit, cela s’accompagne de responsabilités et d’obligations importantes, y compris pour les marchands. En particulier,
PCI DSS est pertinent
dans ce contexte. Si vous êtes marchand et que vous traitez des données de cartes de crédit, vous devez être au moins
level 4 compliant. Si vous stockez ou traitez des données de cartes via votre serveur, les exigences
montent au level 3 ou plus.
Notre plateforme vous offre une sécurité de classe A et est bien entendu PCI Level 1 compliant.
Notre objectif principal est de vous garder, vous le marchand, en dehors du périmètre PCI,
afin de garantir une intégration de paiement fluide et sécurisée pour votre boutique en ligne.
Nous avons conçu notre API et nos exemples pour vous permettre d’intégrer d’une manière conforme au level 4.
Depuis l’introduction de PCI V 3.0, les marchands ne sont plus autorisés à héberger les formulaires de paiement directement sur leur site web. Les formulaires dans lesquels le client saisit ses données de paiement doivent être générés et hébergés par un prestataire conforme PCI Level 1.
Il existe deux manières d’implémenter les pages de paiement dans votre boutique en ligne :
-
Intégration par page de paiement
-
Intégration par iframe
La deuxième raison pour laquelle nous avons choisi l’iframe est d’abstraire la collecte des données. La collecte des données peut différer selon les processeurs et les modes de paiement, ce qui obligerait le marchand à intégrer chaque mode de paiement individuellement. Au lieu de cela, notre iframe contient tous les champs de formulaire pour collecter les informations de paiement. Le marchand peut ainsi utiliser une seule API pour chaque mode de paiement.
L’intégration par page de paiement est une intégration dans laquelle vous redirigez le client vers notre page de paiement, où il saisit les données de paiement.
Figure 1. Exemple d’image d’une intégration par page de paiement
Vous trouverez plus d’informations techniques et des exemples d’intégration dans la section consacrée à la page de paiement.
Si vous ne voulez pas rediriger votre client hors de votre boutique, vous avez aussi la possibilité d’implémenter notre page de paiement dans un iframe directement dans votre boutique en ligne.
Nous avons conçu les pages de paiement de manière à ce que vous puissiez intégrer l’iframe directement dans le processus de paiement de votre boutique en ligne, là où le mode de paiement est sélectionné. Le JavaScript et l’iframe lui-même sont conçus de sorte que l’envoi du contenu à l’intérieur de l’iframe puisse être déclenché depuis un bouton situé en dehors de l’iframe, dans la boutique. Cela signifie que le client peut d’abord saisir toutes les données, que l’application du marchand crée la commande, puis que le formulaire est envoyé. Une validation peut également être déclenchée depuis l’extérieur de l’iframe.
Le formulaire à l’intérieur du cadre peut être stylisé en utilisant des templates Twig. Cela permet d’adapter la mise en page à celle de l’application du marchand.
Figure 2. Exemple d’image d’une intégration par iframe intégrée directement dans le processus de checkout, là où le mode de paiement est sélectionné.
Vous trouverez plus d’informations techniques et des exemples d’intégration dans la section consacrée à l’iframe.
L’API est une interface unifiée permettant de traiter tous les modes de paiement pris en charge à travers chaque processeur disponible avec un processus de paiement standardisé. En d’autres termes, une fois que vous avez intégré les requêtes obligatoires, vous pouvez ajouter des processeurs ou des modes de paiement supplémentaires sans rien changer dans votre application. Si vous ajoutez des modes de paiement qui nécessitent des informations supplémentaires qui ne nous sont pas transmises dans votre requête, nous demanderons simplement à votre client de fournir ces informations supplémentaires.
Le concept de l’API unifie les différentes intégrations des processeurs en une seule API de paiement. Pour parvenir à cette unification, nous avons dû développer une abstraction des données.
Cela présente les avantages suivants pour vous :
-
Une seule intégration pour raccorder tous vos processeurs de paiement
-
Vous pouvez ajouter des processeurs ou des modes de paiement sans modifier votre application
L’abstraction des données a également certaines implications pour vous :
-
Afin de nous adapter à toutes les différentes API et à leurs restrictions, il se peut que nous devions modifier ou tronquer certaines des données que vous nous avez envoyées dans les requêtes pour nous conformer aux différents processeurs.
-
Si certaines informations manquent, nous devons demander ces informations supplémentaires.
Nous n’avons pas seulement standardisé le modèle de données pour tous les processeurs, nous avons aussi standardisé le processus de paiement pour chaque mode de paiement et chaque processeur.
Chaque transaction effectuée sur la plateforme respecte strictement ce processus.
Lorsqu’une transaction est créée, elle est placée dans l’état Pending, dans lequel elle peut être librement modifiée.
Vous avez également la possibilité d’annuler la transaction. Elle sera alors déplacée vers l’état Voided.
Une fois qu’une transaction est Confirmed, elle ne peut plus être modifiée. Dès que le traitement de la
transaction commence, la transaction passe à l’état Processing.
Depuis Processing, le paiement peut soit passer directement à fail, soit, si le paiement réussit, être mis
à Authorized, ou, si le paiement est directement capturé, être déplacé vers l’état Completed.
Dès que nous savons que le paiement est garanti ou est arrivé sur votre compte, nous faisons passer
l’état de la transaction à Fulfill. Si le paiement n’est pas arrivé ou n’est pas garanti
dans un délai défini (selon les caractéristiques d’un mode de paiement), nous déplaçons la transaction
vers Decline. Il se peut aussi que nous devions vous demander de décider si vous voulez mettre la transaction
sur Fulfill ou Decline.
Les états Decline, Voided, Failed ou Fulfill sont des états finaux et vous indiquent clairement si
les marchandises doivent être expédiées dans le cas de biens physiques ou si le téléchargement doit être débloqué dans
le cas de biens numériques, par exemple.
La standardisation est un outil puissant pour vous en tant que marchand, car elle standardise le processus pour votre intégration, quel que soit le mode de paiement que vous intégrez. Cependant, cela s’accompagne aussi de certaines restrictions ou implications dont vous devez être conscient :
-
Certaines intégrations de paiement exigent que vous adaptiez dynamiquement les factures que vous envoyez au client. C’est pourquoi nous avons également intégré un moteur de modèles de documents et une intégration e-mail qui vous permettent d’envoyer ces documents directement à votre client.
-
Une seule complétion finale est possible. Vous pouvez modifier les postes de votre transaction, mais une fois la transaction complétée, elle ne peut plus être modifiée.
Nos pages de paiement sont entièrement responsives et optimisées pour les mobiles par défaut.
Cependant, nous savons qu’une intégration harmonieuse dans le design de la boutique en ligne est cruciale pour l’expérience d’achat de votre client. C’est pourquoi nous avons créé un éditeur de ressources qui vous permet de personnaliser entièrement et à la volée le modèle de la page de paiement. Vous trouverez des informations plus détaillées sur le langage de templates que nous utilisons ainsi que des exemples dans la documentation des ressources.
Figure 3. L’éditeur de ressources vous permet de personnaliser l’apparence de la page de paiement au sein de l’application.
Si vous avez plusieurs connecteurs pour un mode de paiement, vous pouvez router les transactions en appliquant des conditions. Les conditions vous aident également à définir quand un mode de paiement est visible en général pour votre client.
Nous fournissons un vaste ensemble de conditions différentes qu’un marchand peut sélectionner et configurer. Une liste de toutes les conditions disponibles se trouve ici
En fonction de la condition sélectionnée, vous devrez préciser quand et comment cette condition doit être appliquée. Le concept de conditions est pratique et vous permet de réaliser des arbres de décision très complexes qui devraient sinon être codés dans votre application.
Exemple
Vous avez deux contrats de processeur. L’un vous permet de traiter des transactions par carte de crédit sans 3-D Secure et l’autre contrat avec 3-D Secure. Afin de minimiser vos risques et la fraude, vous voulez traiter chaque transaction en dehors du Royaume-Uni et au-dessus de 30 GBP avec le terminal qui exige 3-D Secure. Chaque transaction en dessous de 30 GBP à l’intérieur du Royaume-Uni peut être traitée sans 3-D Secure. Pour y parvenir, vous pouvez configurer 2 conditions et les appliquer à votre configuration de connecteur :
-
Créez un filtre de pays d’adresse de facturation et de livraison et réglez-le sur le Royaume-Uni.
-
Créez un filtre de montant pour les montants inférieurs à 30 GBP.
-
Appliquez le filtre à la configuration du connecteur pour le processeur sans 3-D Secure.
Vous pouvez appliquer plusieurs conditions à une configuration de connecteur. Les conditions peuvent ensuite également être utilisées pour sélectionner le connecteur qui traitera finalement la transaction.
Exemple
Vous avez deux processeurs de paiement. Un processeur est utilisé pour l’Europe et un pour les États-Unis pour traiter les cartes. Vous voulez traiter les commandes avec une adresse de facturation et de livraison américaine via le processeur américain et le reste via votre processeur européen. Pour y parvenir, vous pouvez créer les connecteurs pour les deux processeurs.
-
Créez une condition de pays d’adresse de facturation et de livraison, réglez-la sur les États-Unis et appliquez les conditions au processeur américain.
-
Créez une condition de pays d’adresse de facturation et de livraison, réglez-la sur tout sauf les États-Unis et appliquez-la au processeur européen.
Toutes les configurations de connecteurs sont triées selon leur priorité. Lorsqu’un certain connecteur ne fonctionne pas, nous essayons le suivant. Par exemple, lorsqu’un processeur est hors ligne, nous essayons simplement le suivant. Nous essayons aussi le suivant lorsque la transaction est rejetée par l’un des processeurs.
Les produits récurrents sont de plus en plus intéressants pour les marchands. Cependant, la gestion des abonnements est complexe et nécessite une plateforme sophistiquée et puissante pour gérer les cartes de crédit expirées, les processus de relance, etc.
Nous fournissons un service abstrait pour la gestion des paiements récurrents. Le service gère la mise à jour des informations de paiement (par exemple les données de carte de crédit) et la gestion des échecs.
Nous pouvons effectuer un paiement récurrent de trois manières différentes :
1) Tokenisation : nous utilisons un token des informations de paiement créé précédemment pour débiter le client. Par exemple, pour la carte de crédit, nous utilisons un token lié à une carte enregistrée.
2) Prélèvement asynchrone : certains modes de paiement ne nécessitent aucune interaction de l’utilisateur. Dans cette situation, nous pouvons débiter le client malgré tout.
3) Prélèvement synchrone : nous envoyons un lien, par exemple par e-mail, qui pointe vers notre page de paiement et nous demandons au client de fournir sur cette page les informations de paiement dont nous avons besoin pour le débiter.
Vous pouvez appliquer ces trois méthodes dans un charge flow. Chaque charge flow se compose de différents niveaux. À chaque niveau, nous essayons les trois méthodes pour débiter le client dans l’ordre indiqué ci-dessus. Le nombre et l’intervalle de ces niveaux sont contrôlés par le marchand. Cela donne la flexibilité de rappeler plusieurs fois au client de mettre à jour les informations de paiement avant qu’une transaction soit finalement marquée comme réussie ou échouée.
La plateforme s’occupe des différents cas d’échec ou de la mise à jour des modes de paiement. Tout ce qu’un marchand
doit faire, c’est utiliser notre charge endpoint et fournir le customerID et le montant à débiter. Sur la base du
charge flow configuré, nous essayons de débiter le client. Après les échéances définies, un webhook informera
votre application si la transaction a réussi ou si l’abonnement doit être arrêté.
Exemple
Le client paie la première fois via la page de paiement habituelle et crée avec ce paiement initial un token. L’application du marchand peut stocker ce token avec le client. Pour les transactions suivantes, l’application fournit ce token à notre service. Une fois que les données de paiement stockées avec le token ne sont plus valides, plusieurs rappels doivent être envoyés au client pour mettre à jour ces informations. Cependant, comme le compte ne dispose généralement pas de fonds suffisants, nous voulons réessayer le prélèvement après 5 jours avant de commencer à relancer le client.
Le service que nous fournissons prendra en charge l’ensemble du processus. Le charge flow et les niveaux du charge flow peuvent donc être appliqués de la manière suivante :
-
Le premier niveau essaie simplement de débiter le client avec le token. En cas d’échec, aucun message e-mail ne doit être envoyé. Le niveau est fixé à une durée de 5 jours. C’est-à-dire que nous passons au niveau suivant après 5 jours.
-
Le deuxième niveau essaie à nouveau de débiter le client avec le token. En cas d’échec, un e-mail est envoyé avec un lien de paiement. Le niveau spécifie aussi le délai avant le passage au troisième niveau.
-
Le troisième niveau essaie à nouveau de débiter le client avec le token. Si cela échoue encore, nous envoyons à nouveau un message e-mail avec le lien, mais cette fois avec un message plus strict.
-
Après le troisième niveau, nous ne définissons aucun autre niveau et la transaction est donc considérée comme échouée.
Il est également possible de créer plusieurs charge flows et de les appliquer aux différents cas sur la base de conditions. Le nombre de niveaux n’est pas limité.
Pour plus d’informations, consultez la section sur les charge flows et la tokenisation.
Nous investissons aussi beaucoup de notre temps pour offrir de meilleures analyses après-vente. Afin de vous donner des statistiques plus détaillées sur les taux de conversion de vos paiements, nous avons introduit le concept de groupes de transactions.
Les transactions sont regroupées en groupes de transactions sur la base du customerID envoyé. Les transactions sont regroupées en
groupes de transactions. Les outils ordinaires effectuent leurs analyses sur la base du nombre de tentatives sur la page de paiement, puis
comparent les transactions réussies avec les transactions échouées. Cependant, une information intéressante serait d’analyser cela
par client et de regrouper les transactions en groupes de transactions. Cela permet d’identifier les multiples tentatives d’un
client, qui peuvent être réparties sur une certaine période lorsqu’un client essaie de payer plusieurs fois, et de marquer finalement une
transaction comme réussie même si, lors de la première tentative par carte de crédit, le paiement n’a pas abouti mais qu’il a finalement
réussi à payer par un autre moyen de paiement comme la facture.
|
Important
|
Les transactions sont regroupées par le customerID. Si le customerID n’est pas fourni (NULL),
chaque transaction est traitée comme un groupe de transactions distinct.
|
Toutes les transactions regroupées peuvent être consultées dans : Space > Paiement > Groupes de transactions.
Si vous souhaitez obtenir plus d’informations sur les différentes tentatives, vous pouvez ouvrir les groupes de transactions pour voir toutes les transactions associées. Vous avez également la possibilité de filtrer les groupes de transactions échoués, réussis ou en attente en appliquant les filtres en haut.