Une transaction possède différents états. La figure 1 montre les états possibles ainsi que les transitions autorisées entre ces états.
Figure 1. Les états de la transaction, y compris les transitions d’état
Les sections suivantes expliquent la signification de ces états et le moment où ils sont définis. Il est recommandé d’intégrer ces états dans l’application du marchand afin de prendre en charge tous les modes de paiement. Il est également recommandé de prendre correctement en compte la chronologie de ces états dans l’application du marchand.
Nous garantissons que toutes les transactions utilisent ces états indépendamment du mode de paiement et du processeur. Cependant, certains états peuvent être ignorés et la chronologie peut varier selon le mode de paiement.
Lorsque la transaction est créée par le marchand, l’état Pending est défini. La plupart des propriétés peuvent
être modifiées jusqu’à ce que la transaction passe à l’état Confirmed. Tant que la transaction est à l’état
Pending, le montant peut être augmenté ou diminué.
Il est possible de récupérer déjà pendant cet état les modes de paiement possibles pour cette transaction particulière.
Lorsque la transaction est Confirmed, elle ne peut plus être modifiée. Cet
état indique que le traitement de la transaction peut commencer. La raison pour laquelle des transactions peuvent rester à
l’état Confirmed sans passer à Processing est typiquement que le client n’a pas été redirigé vers
notre service et que le traitement n’a donc pas encore commencé.
|
Note
|
La durée pendant laquelle la transaction reste dans cet état est contrôlée par l’application du marchand. Dès que le client
est redirigé vers notre plateforme, l’état Processing est défini.
|
Vous pouvez accepter les paiements en utilisant notre intégration iframe. Des informations plus détaillées se trouvent dans le guide d’intégration iframe.
L’état Processing est défini lorsque le traitement de la transaction a commencé mais n’est pas terminé. Une transaction peut
rester à l’état Processing pendant quelques secondes, voire des semaines. Cette durée dépend des modes de paiement, du processus, du
charge flow utilisé, etc., ainsi que de la manière dont la transaction est traitée. Les charge flows peuvent par exemple retarder de plusieurs semaines le passage à l’état suivant, car
la transaction peut rester en Processing tant que tous les niveaux du charge flow ne sont pas traités.
|
Note
|
La temporisation des différents niveaux peut être définie dans la configuration des niveaux du charge flow. Pour plus d’informations, consultez la section sur les charge flows. |
La transaction est marquée comme Failed lorsque le paiement n’a pas pu être autorisé. Typiquement, soit le client annule
le processus d’autorisation, soit l’autorisation a été refusée par le processeur. Les détails de la raison de l’échec de la transaction
se trouvent dans les tentatives de débit associées à la transaction. Le client essaie éventuellement plusieurs fois,
avec une raison d’échec différente à chaque fois.
|
Important
|
Cet état est un état final. La transaction ne changera plus d’état. |
|
Note
|
Pour obtenir plus d’informations sur la raison pour laquelle la transaction est passée à l’état Failed, ouvrez la transaction et consultez l’onglet de processus Space > Paiement > Transaction. |
La transaction est Authorized lorsque le client a accepté la transaction et que le processus a vérifié que
le client est en mesure de payer le montant. Authorized signifie qu’il existe une réservation, mais que les fonds ne sont pas
transférés du compte du client vers le compte du marchand. Dans cet état, le marchand peut modifier le
montant de la transaction en modifiant les lignes d’articles de la transaction. Ces modifications peuvent être effectuées soit
via l’API du service web, soit via l’interface utilisateur de notre application. Lorsqu’aucune autre modification ne doit être appliquée à
la transaction, celle-ci doit être finalisée (voir Finalisations).
|
Important
|
Tous les modes de paiement ne prennent pas en charge une réservation sur le compte du client. Certains modes de paiement ignorent donc cet état et
passent directement à Completed.
|
La durée pendant laquelle la transaction reste dans cet état est contrôlable par le marchand. Le marchand peut déclencher la finalisation de la transaction via l’interface du service web.
Les transactions peuvent être finalisées via le back-office ou via l’API du service web. Pour voir des exemples de requêtes et des informations plus détaillées, consultez le guide de finalisation.
La transaction est marquée voided lorsqu’une transaction autorisée mais non finalisée ne doit plus être traitée
et est donc annulée.
|
Important
|
Cet état est un état final. La transaction ne changera plus d’état. |
Les transactions peuvent être annulées via le back-office ou via l’API du service web. Pour voir des exemples de requêtes et des informations plus détaillées, consultez le guide d’annulation.
Lorsque la transaction est à l’état Completed, le transfert de l’argent du compte du client vers le compte du marchand
a été initié. Le montant ne peut plus être modifié. Completed ne signifie pas que les biens ou services peuvent être
livrés au client. Selon le mode de paiement, les fonds doivent être transférés avant que la livraison
puisse être effectuée (par exemple en cas de prépaiement).
Pour chaque transaction, nous indiquons si les biens peuvent être livrés maintenant ou si le téléchargement doit être autorisé pour votre marchand.
Ceci est indiqué par les états Fulfill et Decline. Le marchand devrait attendre que l’un des états finaux soit atteint.
La durée pendant laquelle la transaction reste dans cet état dépend du mode de paiement et du processeur. Cela peut ne durer que quelques secondes ou des semaines.
Certains modes de paiement peuvent nécessiter une décision manuelle. Ce processus de décision manuelle est géré par le concept d’indication de livraison
expliqué dans Indications de livraison.
Exemple
Supposons que vous proposiez la banque en ligne comme mode de paiement dans votre boutique. La transaction passera à l’état Completed
une fois la transaction finalisée. Cependant, selon le mode de paiement, il peut s’écouler jusqu’à un jour avant que le fournisseur puisse
nous indiquer si l’argent est arrivé sur votre compte. La transaction restera à l’état Completed jusqu’à ce que nous ayons reçu
cette confirmation.
Dans le cas où il n’existe pas de processus automatique nous permettant d’être informés que l’argent est arrivé ou qu’il est garanti par un tiers,
vous devrez vérifier manuellement si le paiement est arrivé et faire passer manuellement les transactions à
l’état Fulfill ou Decline.
Lorsque la transaction passe à Fulfill, le marchand peut commencer à exécuter la transaction. Dans le cas de biens physiques, le
processus de livraison devrait être lancé.
|
Important
|
Ceci est un état final. |
Lorsque la transaction passe à l’état Decline, le marchand devrait refuser la transaction et ne pas l’exécuter.
Cet état est typiquement défini lorsque le client n’est pas disposé à payer ou que les chances sont élevées que le client crée une
rétrofacturation (transactions suspectes en raison de vos paramètres de fraude). Plus d’informations sur la raison pour laquelle la transaction est passée à Decline se trouvent
sur l’objet Indications de livraison.
|
Important
|
Ceci est un état final. |
|
Note
|
Au sein de l’espace, il existe un paramètre permettant de déclencher automatiquement un remboursement lorsque cet état est atteint. Cela permet de corriger automatiquement la comptabilité et de rembourser automatiquement les transactions. Utilisez cette fonction avec prudence. |
Lorsque la transaction est à l’état Authorized, le marchand peut modifier la transaction. Ces modifications sont enregistrées uniquement dans notre
application et ne sont pas communiquées au processeur. Une fois qu’aucune autre modification ne doit être appliquée à la transaction,
le marchand doit finaliser la transaction. Les modifications ainsi que la finalisation peuvent être déclenchées via
le service web et via l’interface
utilisateur de notre application. La finalisation d’une transaction est également appelée capture ou activate.
Les transactions peuvent être finalisées via le back-office ou via l’API du service web. Pour voir des exemples de requêtes et des informations plus détaillées, consultez le guide de finalisation.
Nous n’autorisons l’envoi que d’une seule finalisation par transaction afin de simplifier et de rationaliser le processus de transaction.
Vous pouvez cependant nous fournir plusieurs modifications de la transaction. Nous les enregistrons toutes et les envoyons au processeur dès que vous confirmez la transaction.
|
Note
|
Si vous ne confirmez pas la transaction, elle sera confirmée par le système en fonction de votre paramètre de délai d’expiration. Ceci peut être défini dans → describe. |
Tous les modes de paiement ne prennent pas en charge le concept de finalisation. Par conséquent, les modifications ne peuvent pas être appliquées dans tous les cas. Pour cette raison, le processus côté marchand peut devoir être adapté pour chaque mode de paiement.
Pour éviter ce type de spécialisation du processus côté marchand, nous recommandons de ne pas utiliser les finalisations. Tous les modes de paiement peuvent
être configurés pour passer directement à Completed. Le marchand peut effectuer des modifications ultérieures en créant des remboursements. Cela rationalise
le processus pour le marchand, car un seul processus doit être mis en place.
|
Note
|
Le comportement concernant la finalisation directe peut être défini dans la configuration du connecteur Space > Paiement > Configuration > Connecteurs. Comme décrit ci-dessus, il se peut que cela ne puisse pas être défini, car le mode de paiement ne connaît pas le concept de finalisation et sera capturé directement. |
Les indications de livraison constituent une étape très importante du processus de transaction, car elles vous indiquent clairement si nous vous recommandons d’expédier les biens sur la base des caractéristiques du mode de paiement. Nous avons étudié le processus et les garanties de chaque mode de paiement que nous proposons et nous pouvons donc vous indiquer clairement si le paiement sera très probablement honoré, voire, dans certains cas, garanti par le fournisseur.
Votre application devrait déclencher l’expédition d’un bien physique ou activer le téléchargement dès que l’indication de livraison passe à Fulfill.
Vous pouvez récupérer l’indication de livraison comme suit. Si vous avez correctement configuré les webhooks, nous vous notifierons dès qu’une mise à jour de la transaction sera disponible et vous devrez alors récupérer les indications de livraison auprès de notre service.