Cas d'utilisation

Cas d'utilisation

Le cadre COF des systèmes de cartes définit l'utilisation équitable des données de carte stockées en vous guidant à travers un ensemble de questions :

• Une fois que vos clients ont traité la transaction initiale, qui initie les paiements ultérieurs ?
  Votre client lui-/elle-même (pour une CIT) ?
  Vous en son nom (pour une MIT) ?
• Avez-vous besoin d'utiliser un token ou le payment.id pour les paiements ultérieurs ?
• Avez-vous besoin du consentement explicite de vos clients pour réutiliser les données de carte (pour suivre des instructions permanentes, c'est-à-dire pour un service récurrent ou un plan de paiement échelonné) ? Ou est-il justifié de ne pas en tenir compte (ce qui s'applique à certaines pratiques de l'industrie, c'est-à-dire pour facturer des frais supplémentaires pour certains produits/services) ?
• Les futures instructions permanentes se produiront-elles de manière récurrente / (non) programmée ?
• Votre client doit-il passer un contrôle 3-D Secure pour les paiements individuels ?
• Les paiements ultérieurs auront-ils des montants fixes ou variables ?

Mais comment pouvez-vous respecter ce cadre et l'implémenter dans votre logique commerciale ? Pour ce faire, vous devez identifier les cas d'utilisation individuels qui s'appliquent à votre service.

Utilisez ce diagramme de flux pour identifier comment demander à la fois les transactions initiales et ultérieures. En fonction du résultat, vous devez :

• Inclure certaines propriétés dans votre requête – nous fournissons des JSONs en conséquence.
• Cibler un API endpoint spécifique de notre API Direct.

En fonction de votre situation, vous identifierez un cas d'utilisation spécifique. Chaque cas d'utilisation est associé à un JSON et à un API endpoint pour le paiement initial (pour lancer la série de paiements) et le paiement ultérieur (pour continuer la série de paiements) :

Aperçu

Cas d'utilisation	Actions du commerçant	JSON/API endpoint
Vos clients peuvent initier activement une transaction (une CIT) dans votre boutique en ligne pour des paiements futurs quand ils le souhaitent.	Paiement initial : Créer et stocker le token.  Déployer 3-D Secure, ce qui vous permet de sauter cette étape pour les paiements ultérieurs. Paiements ultérieurs : Utilisez le token. Choisissez de déployer/ignorer 3-D Secure.	Paiement initial : Exemple B Paiements ultérieurs : Exemple C
Votre entreprise nécessite que vous initiiez des paiements futurs (MITs) au nom de vos clients sans leur approbation explicite en tant que pratique de l'industrie.	Paiement initial : Ne pas stocker le token mais le payment.id. Déployer 3-D Secure pour garantir l'utilisation équitable du payment.id sans 3-D Secure pour les paiements futurs. Paiements ultérieurs : Utilisez le payment.id. Notre plateforme sautera automatiquement 3-D Secure car vos clients ne sont pas présents pour effectuer le paiement.	Paiement initial : Exemple X Paiements ultérieurs : Exemple G / H / I / J
Vos clients achètent un service récurrent pour une période prolongée. Ils vous autorisent à facturer des montants fixes (MITs) sur une base récurrente à des intervalles fixes en tant qu'instruction permanente.	Paiement initial : Ne pas stocker le token mais le payment.id. Déployer 3-D Secure pour garantir l'utilisation équitable du payment.id sans 3-D Secure pour les paiements futurs. Paiements ultérieurs : Utilisez le payment.id. Notre plateforme sautera automatiquement 3-D Secure car vos clients ne sont pas présents pour effectuer le paiement.	Paiement initial : Exemple A Paiements ultérieurs : Exemple E
Vos clients achètent un service récurrent pour une période prolongée. Ils vous autorisent à facturer des montants pour les paiements futurs (MITs), mais à la fois le montant et les intervalles peuvent varier entre les paiements en tant qu'instruction permanente.	Paiement initial : Ne pas stocker le token mais le payment.id. Déployer 3-D Secure pour garantir l'utilisation équitable du payment.id sans 3-D Secure pour les paiements futurs. Paiements ultérieurs : Utilisez le payment.id. Notre plateforme sautera automatiquement 3-D Secure car vos clients ne sont pas présents pour effectuer le paiement.	Paiement initial : Exemple B Paiements ultérieurs : Exemple F
Vos clients achètent un bien / service. Ils vous autorisent à facturer le montant sur une certaine période via des versements (MITs). À la fois le montant et les intervalles sont fixes en tant qu'instruction permanente.	Paiement initial : Ne pas stocker le token mais le payment.id. Déployer 3-D Secure pour garantir l'utilisation équitable du payment.id sans 3-D Secure pour les paiements futurs. Paiements ultérieurs : Utilisez le payment.id. Notre plateforme sautera automatiquement 3-D Secure car vos clients ne sont pas présents pour effectuer le paiement.	Paiement initial : Exemple B Paiements ultérieurs : Exemple D