Informations d'identification stockées

Selon la manière et le moment où un payment est traité, il peut provenir de transactions initiées par le client (CIT) ou de transactions initiées par le commerçant (MIT).

Pour garantir le stockage et l'utilisation responsables des informations relatives aux titulaires de cartes, Visa et Mastercard ont établi des lignes directrices et des réglementations concernant les données d'identification stockées.

Nous avons simplifié le processus pour que vous puissiez vous conformer à ces règles, ce qui vous permet de stocker en toute sécurité les détails de la carte dans Yuno pour une utilisation ultérieure tout en restant en conformité.

⚠️

Important : ceci n'est pas la même chose que les abonnements.

Réfléchissez à qui contrôle la récurrence :

• Identifiants enregistrés: vous contrôlez la récurrence et êtes responsable de l'envoi de chaque transaction selon votre propre calendrier et votre propre logique de récurrence.
• API d'abonnement: Yuno la contrôle. Vous fournissez des instructions une seule fois, puis Yuno envoie automatiquement les transactions en votre nom. Voir Abonnements.

• Catégorisation
• Considérations générales
• Créer un Paiement
• ID de l'accord d'abonnement
• ID de la transaction réseau

Catégorisation

Déterminer si une transaction est initiée par le commerçant ou le client a des implications significatives en termes de sécurité, d'expérience utilisateur, de prévention de la fraude et de conformité réglementaire. Cela garantit un processus de payment efficace et sûr pour toutes les parties concernées.

Considérations générales

• Responsabilité: Dans le contexte de l'authentification forte du client (SCA) en vertu de la réglementation PSD2 dans l'Union européenne, le CIT exige généralement une authentification plus élevée par rapport au MIT.
• La fréquence: Les transactions MIT sont souvent récurrentes et périodiques, tandis que les CIT sont des événements plus ponctuels basés sur les actions des clients.

Créer un paiement avec type de traitement

Pour spécifier un payment avec un type de traitement, utilisez le stored_credentials à l'intérieur de la structure payment_method.detail.card lors de la création d'un payment.

❗️

Important : remplissez tous les champs obligatoires.

• Lorsque vous travaillez avec des transactions CIT et MIT, il est essentiel de remplir correctement le champ usage, reasonet  network_transaction_id champs. Si vous ne remplissez pas correctement ces champs, cela peut entraîner taux d'approbation en baisse  et  perte liée aux litiges en matière de rétrofacturation.
• Certains fournisseurs (par exemple, Adyen) exigent que le reason champ reste cohérent tout au long du cycle de vie de la transaction. Si votre première transaction (usage=FIRST) utilise reason=SUBSCRIPTION, toutes les transactions ultérieures (usage=USED) doit également utiliser reason=SUBSCRIPTION.

Stocker les motifs d'authentification

Exemple de Request

curl --request POST \
     --url https://api-sandbox.y.uno/v1/payments \
     --header 'X-Idempotency-Key: <Your idempotency-key>' \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'private-secret-key: <Your private-secret-key>' \
     --header 'public-api-key: <Your public-api-key>' \
     --data '
{
    "description": "Test",
    "account_id": "{{account-code}}",
    "merchant_order_id": "0000023",
    "country": "DE",
    "merchant_reference" : "reference-{{$randomUUID}}",
    "amount": {
        "currency": "EUR",
        "value": 5000
    },
    "customer_payer": {
        "id":"967ecd18-d898-4b88-9400-dd5b01b18edc"
    },
    "workflow": "DIRECT",
    "payment_method": {
        "type":"CARD",
        "vaulted_token": "eb8caa17-6407-457b-960e-125d8d7a90c1",
        "detail": {
           "card": {
               "stored_credentials":{
                  "reason":"CARD_ON_FILE",
                  "usage": "USED",
                  "network_transaction_id":"583103536844189"
              }
           }
        }
    }
}
'

Accord de souscription

Pour certains marchés (MX par exemple) et certains processeurs de paiement, lorsqu'un paiement lié à un abonnement est effectué, l'identifiant de l'accord avec le client doit être spécifié dans la demande de paiement afin de garantir un traitement correct. Pour faciliter cela, nous avons activé le subscription_agreement_id à l'intérieur du champ stored_credentials vous permettant de partager l'accord conclu avec le client.

📘

Note

Le champ subscription_agreement_id  et  network_transaction_id sont des domaines indépendants. Y compris un subscription_agreement_id ne remplace pas la nécessité d'un network_transaction_idLes deux doivent être fournis, le cas échéant, afin de garantir des taux d'approbation optimaux et une protection contre les rétrofacturations.

"payment_method": {
        "type":"CARD",
        "vaulted_token": "eb8caa17-6407-457b-960e-125d8d7a90c1",
        "detail": {
           "card": {
               "stored_credentials":{
                  "reason":"CARD_ON_FILE",
                  "usage": "USED",
                  "subscription_agreement_id":"AA0001",
                  "network_transaction_id":"583103536844189"
              }
           }
        }
    }

ID de la transaction réseau

Un identifiant de transaction réseau est un identifiant unique attribué à une transaction par le réseau de cartes. Il est utilisé pour suivre et référencer des transactions spécifiques, en particulier dans les scénarios de payment récurrents, afin d'assurer la cohérence et la traçabilité tout au long du cycle de vie du payment .

Si la transaction est initiée par le client (CIT), la référence de la transaction de réseau sera disponible dans la section card.stored_credentials.network_transaction_id champ. Ce champ représente l'identifiant de transaction pour Visa et l'identifiant de trace pour Mastercard, qui sont recommandés pour les futurs paiements d'abonnements.

"payment_method": {
        "type":"CARD",
        "vaulted_token": "eb8caa17-6407-457b-960e-125d8d7a90c1",
        "detail": {
           "card": {
               "stored_credentials":{
                  "reason":"CARD_ON_FILE",
                  "usage": "USED",
                  "network_transaction_id":"583103536844189"
              }
           }
        }
    }

Utilisation

Nous associons les network_transaction_id avec l'objet  vaulted_token pour les transactions futures, de sorte que vous n'ayez pas à gérer la logique pour chaque cas. Nous effectuerons l'association lorsqu'un payment sera créé avec :

• Méthode de paiement:
  • Une carte vaulted_tokenou
  • Données de la carte avec vault_on_success fixé à true
• Informations d'identification stockées:
  • usage fixé à FIRST

⚠️

Lors de l'utilisation de vault_on_success = true Dans le cadre d'une intégration directe, vous devez d'abord créer le client et transmettre son customer_payer.id dans la demande de paiement. L'envoi des coordonnées du client en ligne ne crée pas le client du côté de Yuno, de sorte que la carte ne peut pas être enregistrée et qu'aucun vaulted_token sera renvoyé.

Si vous avez déjà le network_transaction_id pour la carte, vous pouvez l'inclure dans le payment dans le champ correspondant. Sinon, pour les paiements MIT (avec stored_credentials.usage=USED), nous enverrons le network_transaction_id associée à la vaulted_token au prestataire.

❗️

N'oubliez pas de spécifier l'utilisation dans le champ stored_credentials Nous déclenchons la section network_transaction_id logique basée sur ces champs.