API

Introduction

Pour offrir une expérience facile à utiliser, nous proposons des bibliothèques Python, Perl ou PHP, et nous continuerons d’étoffer ce catalogue.

Des exemples de code sont disponibles dans chaque section. Les onglets disponibles dans le menu vous permettent de basculer vers les différents languages de programmations.

L’API est disponible via https://api.stancer.com et supporte TLS 1.2, HTTP/1.1 et HTTP/2.

Notre documentation est également disponible au format Swagger ou Redoc.

INFO

Cette documentation utilise httpie pour les exemples en shell, et nos bibliothèques pour les exemples en PHP, Python & Perl.

Par simplification des exemples, l’authentification par votre clé d’API (--auth stest_xxx:) est omise dans les lignes de commande proposées, mais vous devez la fournir à chaque appel.

Concepts clés

La même API peut être utilisée pour accéder aux ressources live traitant les paiements réels et méthodes de paiement, mais aussi des ressources de test pour le développement de vos logiciels et le débogage. Notre service API utilise des clés d’API pour authentifier les requêtes.

Pour obtenir une clé API, vous pouvez vous inscrire sur notre site web. Les clés API sont sous la forme de sprod_xxx pour vos requêtes live et stest_xxx pour vos test.

L’authentification à l’API est effectuée via HTTP Basic Auth. Vous devez utiliser votre clé API comme nom d’utilisateur et ne renseignez pas de mot de passe.

Nous vous conseillons d’utiliser le mécanisme d’authentification de base de votre bibliothèque HTTP, mais si vous devez le gérer manuellement, comme spécifié dans HTTP Basic Auth RFC, vous devez encoder votre clé API en base64 avant d’envoyer le token d'authentification correspondante dans un en-tête HTTP Authorization. Par exemple, si votre clé API est sprod_xxx, vous devez encoder sprod_xxx: (rappelez-vous, le mot de passe doit être vide) en base64 puis envoyer une en-tête HTTP avec votre clé encodée. Ainsi, si votre clé encodée est c3Byb2RfeHh4Og== votre en-tête sera Autorisation: Basic c3Byb2RfeHh4Og==.

Pour une documentation technique, veuillez consulter nos documentation OpenAPI, Swagger ou Redoc.

Si vous avez besoin d’assistance technique sur l’intégration de notre API, vous pouvez rejoindre notre communauté Slack.

Créer des paiements

Avec la page de paiement de Stancer

Pour créer un paiement, utilisez la route POST /v2/payment_intents/. Vous devez fournir un montant et une devise (eur par défaut).

Si vous souhaitez associer le paiement à un Payeur, vous pouvez utiliser le champ customer et transmettez l’ID cust_xxx correspondant.

$ http --auth stest_xxx: https://api.stancer.com/v2/customers/ \
    name="Foo Bar" email=foo.bar@example.org
{
    "id": "cust_xxx",
    …
}

$ http --auth stest_xxx: https://api.stancer.com/v2/payment_intents/ \
currency=eur amount=100 customer=cust_xxx description="Test payment"
{
    "id": "pi_xxx",
    "url" "https://payment.stancer.com/payment_intents/pi_xxx"
    …
}

Vous pouvez maintenant envoyer votre Payeur sur la page de paiement située sur https://payment.stancer.com/payment_intents/pi_xxx, pi_xxx sera remplacé par l'API par l'identifiant correspondant.

Vous pouvez trouver l'URL dans le champ url de votre payment intent, ou, avec les bibliothèques :

payment_page_url = payment.payment_page_url()

---

Procédure du 3D Secure : Création d'un paiement en ligne (autorisation + capture)

Mise en place de la commande

Le Payeur passe sa commande sur le Site du Client (panier, adresse, etc.).

Le Client commence par créer un « Payeur » côté Stancer en appelant l’API POST v2/customers. Cette requête retourne un identifiant de type cust_xxx. Ensuite, le Client crée une intention de paiement (payment intent) avec le paramètre capture = false, afin de ne demander qu'une autorisation. Cette étape s’effectue via une requête http POST v2/payment_intents.

Stancer renvoie l’identifiant de l’intention de paiement ainsi qu’une URL de page de paiement hébergée (HPP) qui sera affichée dans une iframe sur le Site du Client.

Saisie de la carte dans l'iframe

Le navigateur du Payeur charge l’iframe avec l’URL de la HPP Stancer. Dans cette iframe, le Payeur voit un formulaire carte bancaire entièrement géré par Stancer et y saisit ses données de carte.

Ouverture et déroulement du 3D Secure

Si la carte et la banque du Payeur nécessitent une authentification 3D Secure, Stancer ouvre, à l'intérieur de l'iframe, une nouvelle fenêtre ou sous-iframe dédiée au 3DS. Le Payeur est alors redirigé vers l'interface de sa banque (code SMS, validation dans l'application bancaire, etc.) pour prouver qu'il est bien le titulaire de la carte.

Une fois l'authentification terminée, la banque renvoie un résultat 3DS (succès ou échec) à Stancer.

Si l'authentification est réussie, Stancer demande au réseau bancaire l'autorisation du paiement : la banque réserve le montant sur le Compte Bancaire du Payeur sans encore le débiter définitivement.

Fin de l'iframe : notification au Site Client

Une fois l'autorisation réussie, Stancer met l'intention de paiement au statut "authorized".

La HPP renvoie une réponse OK dans l'iframe et, via un postMessage, informe la page du Client que la partie « paiement + 3DS » s'est bien déroulée.

Le Site Client capture cet événement et peut alors fermer ou masquer l'iframe puis passer à une page de confirmation de commande interne ou encore simplement afficher un message pour informer le Payeur final que son achat est en cours de réalisation.

Note

Interruption du funnel de paiement : Si le Payeur ferme le navigateur juste après le 3DS, le Client ne reçoit pas la notification, mais l'intention reste au statut "authorized". Les fonds sont bloqués mais pas capturés, donc la commande doit être considérée comme non confirmée.

Confirmation finale et capture des fonds

En dehors de l'iframe, le Site du Client appelle une URL de confirmation quand il est prêt à finaliser la commande.

Sur cet appel, le serveur du Client vérifie auprès de Stancer l'état de l'intention de paiement via un requête http GET v2/payment_intent/<pi_id> pour s'assurer qu'elle est bien au statut "authorized".

Si tout est correct, le Client envoie l'ordre de capture à Stancer via une requête http POST /payment_intent/<pi_id>/capture.

Stancer finalise alors la transaction : le statut passe à "to_capture" et les fonds seront prêts à être débités du Compte Bancaire du Payeur.

---

Créer un Prélèvement SEPA (Disponible uniquement via API)

Mise en service du Prélèvement SEPA

Vous pouvez utiliser le prélèvement SEPA comme méthode de paiement pour encaisser vos clients. Il faudra, au préalable, que les prérequis soient valides.

Actuellement, les paiements via Prélèvement SEPA ne sont disponibles uniquement via l’API Stancer. Il est possible de les utiliser pour procéder à des paiements uniques ou récurrents, en réutilisant l’identifiant du mandat sepa_xxx.

Plusieurs approches possibles :

• Stancer gère la création du mandat ainsi que la création et le stockage de ce dernier (recommandé)

• Vous gérez la signature du mandat de votre côté puis vous pourrez ensuite, le stocker côté Stancer afin de le tokenizer pour qu’il puisse être réutilisé.

Mise en place :

Création du mandat via Stancer (recommandé)

Pour tout nouveau mandat, suivez minutieusement les étapes ci-dessous :

• Effectuer une requête http POST sur la route v2/paiement_intents.

• Insérer le montant que vous souhaitez facturer au Payeur dans le champ amount.

• Insérer sepa ou sepa,card dans le champ methods_allowed (Il est recommandé de laisser uniquement la méthode SEPA si vous souhaitez ne pas laisser le choix à votre Payeur).

• Vous verrez apparaître la page de paiement avec la méthode d’encaissement choisie.

• Dès que celle-ci sera remplie, c’est à ce moment-là que le mandat à signer va être généré.

• Ensuite, le Payeur recevra un code à 4 chiffres par SMS pour s’authentifier avec son numéro de télphone fourni au préalable sur la page de paiement.

• La signature effectuée, le premier paiement sera validé avec le lien pour que le Payeur puisse récupérer son mandat de prélèvement.

Importation de vos mandats dans Stancer

Pour importer les mandats déjà existants de vos clients, vous devrez:

• Effectuer une requête http POST sur la route v2/sepa puis renseigner les champs demandés.

• Récupérer le sepa_id dans la réponse de la requête.

• Effectuer une nouvelle requête http POST sur la route v2/mandates.

• Renseigner le sepa_id de la requête précédente ainsi que la RUM.

• Effectuer une requête POST sur l'URL du champ upload_url aveec votre document dans le body de votre requête.

Nous vous rappelons que nous avons notre documentation à disposition si nécessaire, accessible via ce lien.

Capturer des paiements

Vous pourrez retrouver dans votre Espace Client, certains paiements au statut autorisé.
Cela provient des paiements effectués en ligne qui n'ont abouti, pour deux raisons :

• Transaction créée via http POST v2/payment_intents avec le paramètre capture=false.
• Interruption du funnel de paiement, malgré qu'une authentification 3DS ai été effectuée au préalable par le Payeur.

Par conséquent, il faudra encaisser manuellement ces paiements. Cette action entrainera le débit du moyen de paiement utilisé pour la transaction concernée.

Lorsqu'un paiement est autorisé, l'encaissement peut être effectuée de deux manières :

• Depuis l'Espace Client, pour les paiements effectués en ligne uniquement (Lien de paiement, API, SDK, CMS).
• Depuis l'API, pour les intentions de paiement créées avec le paramètre capture=false.

Depuis l'Espace Client

Pour les paiements effectués en ligne, vous pouvez également effectuer la capture directement depuis l'Espace Client.

Depuis le détail du paiement, cliquez sur Encaisser.

Depuis l'API

Pour effectuer l'encaissement, envoyez une requête http POST sur la route suivante :

POST /v2/payment_intents/pi_xxx/capture

Remplacez pi_xxx par l'identifiant de l'intention de paiement à encaisser.

Une fois l'action effectuée, le paiement passe successivement par les statuts suivants :

authorized → to_capture → capture_sent → captured

Le statut captured confirme que l'encaissement du paiement a été effectuée avec succès.

Webhooks

Les webhooks (actuellement synchrones) permettent à Stancer de transmettre au marchand les informations nécessaires pour poursuivre le traitement d’un paiement pendant le parcours de paiement.

Cas nominal : le paiement se déroule correctement

Lorsque le parcours se déroule normalement, le Payeur suit l’ensemble des étapes du paiement :

• Le Payeur saisit les informations de sa carte sur la page de paiement.
• Stancer redirige le Payeur vers sa banque pour effectuer l’authentification 3DS.
• La banque valide l’authentification 3DS.
• Le Payeur revient sur la page de paiement.
• Stancer demande l’autorisation du paiement auprès de la banque.
• La banque autorise le paiement.
• Stancer redirige le Payeur vers le site marchand.
• Le marchand demande la capture du paiement.
• Le marchand peut finaliser la commande.

Dans ce scénario, le parcours utilisateur et les échanges entre Stancer et le marchand permettent de mener le paiement jusqu'à sa capture et à la finalisation de la commande.

Cas non nominal : le flow est interrompu

Le parcours peut être interrompu par le Payeur à différents moments. Le comportement dépend alors de l’étape à laquelle l’interruption intervient.

Si le Payeur interrompt le parcours avant l’autorisation du paiement, par exemple après l’authentification 3DS :

• Le paiement n’est pas encore autorisé.
• Le marchand ne doit pas considérer le paiement comme réussi.
• Aucune capture ne doit être effectuée.

Le simple fait que le Payeur ait validé son authentification 3DS ne signifie donc pas que le paiement est autorisé.

Le Payeur peut également interrompre le parcours après l’autorisation du paiement, par exemple en fermant son navigateur avant de revenir sur le site marchand.

Dans ce cas :

• La banque a autorisé le paiement.
• Les fonds sont retenus sur le Compte Bancaire du Payeur.
• Le marchand peut ne pas avoir reçu le retour du navigateur.
• Le marchand peut alors déclencher la capture manuellement et poursuivre son traitement.

Avec des webhooks synchrones, le marchand doit donc traiter ces événements directement dans le parcours de paiement afin de ne pas dépendre uniquement du retour du navigateur.

Afin d’être notifié en temps réel des modifications (paiement échoué, abonnement impayé…) et réagir rapidement en conséquence, vous pouvez définir des webhooks.

Flow fonctionnel avec les webhooks synchrones Le webhook intervient directement dans le parcours de paiement. Stancer transmet l’événement au marchand, qui effectue l’action nécessaire avant de poursuivre le traitement.

Après l’autorisation du paiement :

1. Stancer redirige le payeur vers le site marchand.
2. Stancer transmet au marchand le webhook payment.authorized.
3. Le marchand reçoit l’événement et demande la capture du paiement.
4. Stancer effectue la capture.
5. Stancer transmet au marchand le webhook payment.to_captured.
6. Le marchand reçoit la confirmation et finalise la commande.

.

L’utilisation des webhooks nécessite un serveur web de votre côté en capacité de recevoir les différents évènements de modification, répondant par exemple sur l’adresse https://example.org/stancer/webhooks/.

Vous devez ensuite créer un endpoint sur notre API via POST /v2/webhooks/ :

$ http https://api.stancer.com/v2/webhooks/ url=https://example.org/stancer/webhooks/
{
  "id": "we_xxx",
  "secret": "xxx",
  …
}

L’envoi d’un évènement se fait via un POST <url> sur votre infrastructure, qui doit présenter un certificat HTTPS valide et doit répondre avec une réponse HTTP 200 OK ou 204 NO CONTENT. Tout autre code de retour sera considéré comme une erreur et l’évènement sera retenté ultérieurement, via un mécanisme de backoff exponentiel. Notre infrastructure tente de délivrer le message 15×, soit environ 1 jour et demi, avant d’abandonner:

Tentative	Délai	Total
1	0:00:15	0:00:15
2	0:00:16	0:00:31
3	0:00:31	0:01:02
4	0:01:36	0:02:38
5	0:04:31	0:07:09
6	0:10:40	0:17:49
7	0:21:51	0:39:40
8	0:40:16	1:19:56
9	1:08:31	2:28:27
10	1:49:36	4:18:03
11	2:46:55	7:04:58
12	4:04:16	11:09:14
13	5:45:51	16:55:05
14	7:56:16	1 jour, 0:51:21
15	10:40:31	1 jour, 11:31:52

Lors de l’envoi d’un évènement, le contenu de la requête est signé avec la clef secrète fournit lors de la création du endpoint, ceci afin de vous permettre d’identifier l’émetteur et de ne conserver que le contenu légitime.

La signature est un HMAC SHA256 d’un champ constitué du timestamp correspondant à la date d’envoi de la requête et du corps de la requête, séparés par un .. Cette signature est transmise dans l’entête Stancer-Signature de la requête HTTP.

def compute(secret: str, payload: str, date: datetime) -> [int, str]:
    secret = bytes.fromhex(secret)
    timestamp = int(date.timestamp())
    signed_payload = (str(timestamp) + ".").encode() + payload
    return hmac.digest(secret, signed_payload, hashlib.sha256).hex()


def parse(signature: str, version="v1") -> [int, str]:
    tmp = signature.split(",")
    parts = {}
    for t in tmp:
        t = t.split("=")
        parts[t[0]] = t[1]
    timestamp = int(parts["t"])
    return timestamp, parts[version]


def verify(
    secret: str,
    payload: str,
    signature: str,
    now=datetime.now(tz=timezone.utc),
    delta=timedelta(minutes=1),
) -> None:
    timestamp, expected = parse(signature)
    date = datetime.fromtimestamp(timestamp, tz=timezone.utc)
    if now - date > delta:
        raise Exception("Expired signature")
    _, computed = compute(secret, payload, date)
    ok = hmac.compare_digest(expected, computed)
    if not ok:
        raise Exception("Invalid signature")

Lors de la vérification de la signature, afin de vous prémunir d’une attaque par rejeu, vous devez vérifier que le timestamp transmis n’est pas trop éloigné de celui courant, par exemple moins de 1 minute.

Actuellement seules des signatures v1 sont émises, mais ce paramètre est nécessaire pour permettre un changement futur d’algorithme et votre code doit donc être robuste à la présence :

• de plusieurs versions dans une même signature
• de versions non supportées de votre côté

Vous ne devez valider la signature que de la version la plus élevée supportée par votre environnement.

L’évènement reçu dans le corps de la requête est sous la forme

{
  "id": "<evt_xxx>",
  "type": "<object_type>.<event>",
  "data": { … }
}

Les données présentes dans data sont celles présentes dans l’API sur la récupération des informations d’un objet (GET /v2/<object_type>/<object_id>)

Les types d’évènements disponibles sont:

• customer
  • created
  • deleted
• card
  • created
• mandate
  • created
  • signed
• payment_intent
  • created
  • updated
  • authorized
  • captured (async mode: actuellement non disponible)
• payment
  • created
  • updated
  • authorized
  • succeeded
  • captured (async mode: actuellement non disponible)
  • refused
  • disputed (async mode: actuellement non disponible)
• product
  • created
  • updated
  • deleted
• price
  • created
  • updated
  • deleted
• subscription
  • created
  • updated
  • deleted
  • past_due
  • unpaid (async mode: actuellement non disponible)
  • canceled
  • resumed

Attention

Les webhooks sont dépendants d’éléments extérieurs à Stancer (connexion réseau à vos points de terminaison, disponibilité et réponse de vos systèmes, validité de vos certificats HTTPS, rate limiting interne pour éviter les DDoS sortants, mise en file en cas de surcharge…) et sont fournis à ce titre en mode « best effort ».

Il n’y a aucune garantie :

• de délivrabilité : un webhook peut ne jamais vous être délivré
• de latence : un webhook peut arriver dans la seconde ou dans plusieurs heures
• d’unicité : un webhook peut être délivré plusieurs fois

Vos services doivent en conséquence être conçus en tenant compte de ces limitations.

Statuts et codes de l'API

Statuts de paiement

Le champ status de l’objet payment indique dans quel état se trouve le paiement.

Champ status	Sens
📋 authorized	La banque a autorisé le paiement, mais la transaction ne sera traitée qu'après la demande de capture
📋 to_capture	La banque a autorisé le paiement, la capture sera traitée ce jour
📋 capture_sent	L'opération de capture est en cours de traitement, Le paiement ne peut plus être annulé, un remboursement devra attendre la fin du processus de capture
📋 captured	Le montant du paiement a été crédité sur votre compte
📋 disputed	Le Payeur a décliné le paiement après qu'il ait été capturé sur votre compte
📋 expired	L'autorisation n'a pas été capturée, le paiement a expiré au bout de 7 jours
📋 failed	Le paiement a échoué, se référer au champ response pour plus de détails
📋 refused	Le paiement a été refusé

Statuts de paiement authentifié

Le champ status de l'objet auth indique l'état d'autorisation pour une authentification.

Champ status	Sens
📋 available	L'authentification forte du Payeur est possible
📋 requested	L'authentification forte attend plus d'information
📋 attempted	Le Payeur a été redirigé vers sa banque pour l'authentification
📋 success	L'authentification a réussi, le processus peut continuer
📋 declined	L'authentification a été déclinée
📋 expired	La session d'authentification a expiré après 6 heures.
📋 failed	L'authentification a échoué
📋 unavailable	L'authentification forte n'est pas disponible pour cette méthode de paiement

Statuts de reversement

Le champ status de l'objet payout (reversement) indique l'état du transfert de crédit entre Stancer et votre banque.

Champ status	Sens
📋 pending	Le reversement a été créé et est en cours de validation
📋 to_pay	Le reversement est prêt à être transféré
📋 sent	Le reversement a été envoyé et est en cours de traitement
📋 paid	Le transfert du crédit a été traité : les fonds ont été reçus par votre banque
📋 failed	Le transfert du crédit a échoué : se reporter à l'Espace Client pour plus d'information

Codes de réponse du paiement

Le champ response de l'objet payment indique la réponse à l'authentification de la transaction auprès de la banque du porteur (Payeur).

Les codes et raisons sont des informations de flux bancaires, pour cette raison, ils ne sont pas traduits.

⚠️ = Le code et la raison réelles ne doivent pas être envoyés au Payeur, remplacez les par un code générique: 05 do-not-honor.

Code (champ response)	Raison
📋 00	Successful approval/completion or that VIP PIN verification is valid
📋 01	Refer to card issuer
📋 02	Refer to card issuer, special condition
📋 03	Invalid merchant or service provider
📋 04	Pickup
📋 05	Do not honor
📋 06	General error
📋 07	Pickup card, special condition (other than lost/stolen card)
📋 08	Honor with identification
📋 09	Request in progress
📋 10	Partial approval
📋 11	VIP approval
📋 12	Invalid transaction
📋 13	Invalid amount (currency conversion field overflow) or amount exceeds maximum for card program
📋 14	Invalid account number (no such number)
📋 15	No such issuer
📋 16	Insufficient funds
📋 17	Customer cancellation
📋 19	Re-enter transaction
📋 20	Invalid response
📋 21	No action taken (unable to back out prior transaction)
📋 22	Suspected Malfunction
📋 25	Unable to locate record in file, or account number is missing from the inquiry
📋 28	File is temporarily unavailable
📋 30	Format error
📋 34⚠️	Suspected fraud
📋 41⚠️	Merchant should retain card (card reported lost)
📋 43⚠️	Merchant should retain card (card reported stolen)
📋 51	Insufficient funds
📋 52	No checking account
📋 53	No savings account
📋 54	Expired card
📋 55	Incorrect PIN
📋 56	Card missing from file
📋 57	Transaction not permitted to cardholder
📋 58	Transaction not allowed at terminal
📋 59⚠️	Suspected fraud
📋 61	Activity amount limit exceeded
📋 62⚠️	Restricted card (for example, in country exclusion table)
📋 63⚠️	Security violation
📋 65⚠️	Activity count limit exceeded
📋 68	Response received too late
📋 75	Allowable number of PIN-entry tries exceeded
📋 76	Unable to locate previous message (no match on retrieval reference number)
📋 77	Closed account
📋 78	’Blocked, first used’—The transaction is from a new cardholder, and the card has not been properly unblocked.
📋 80	Visa transactions: credit issuer unavailable. Private label and check acceptance: Invalid date
📋 81	PIN cryptographic error found (error found by VIC security module during PIN decryption)
📋 82	Negative CAM, dCVV, iCVV, or CVV results
📋 83	Unable to verify PIN
📋 85	No reason to decline a request for account number verification, address verification, CVV2 verification; or a credit voucher or merchandise return
📋 91	Issuer unavailable or switch inoperative (STIP not applicable or available for this transaction)
📋 92	Destination cannot be found for routing
📋 93⚠️	Transaction cannot be completed, violation of law
📋 94	Duplicate transmission
📋 95	Reconcile error
📋 96	System malfunction, System malfunction or certain field error conditions
📋 98	Server inaccessible
📋 A0	Authentication Required, you must do a card inserted payment with PIN code
📋 A1	Authentication Required, you must do a 3-D Secure authentication
📋 A2	Pin request in Single TAP mode
📋 B1	Surcharge amount not permitted on Visa cards (U.S. acquirers only)
📋 N0	Force STIP
📋 N3	Cash service not available
📋 N4	Cashback request exceeds issuer limit
📋 N7	Decline for CVV2 failure
📋 P2	Invalid biller information
📋 P5	PIN change/unblock request declined
📋 P6	Unsafe PIN
📋 Q1	Card authentication failed
📋 R0	Stop payment order
📋 R1	Revocation of authorization order
📋 R3	Revocation of all authorizations order
📋 XA	Forward to issuer
📋 XD	Forward to issuer
📋 Z1	Offline-declined
📋 Z3	Unable to go online
📋 7810⚠️	Refusal count exceeded for this card / SEPA
📋 7811⚠️	Exceeded payment volume for this card / SEPA
📋 7812⚠️	Card temporarily frozen by the customer's bank
📋 7840⚠️	Stolen or lost card
📋 7898	Bank server unavailable

Codes de réponse des contestations (carte)

Le champ response de l'objet dispute(contestation) indique la raison de la contestation par la banque du porteur (Payeur).

Les codes et raisons sont des informations de flux bancaires, pour cette raison, ils ne sont pas traduits.

⚠️ = Le code et la raison réelles ne doivent pas être envoyés au Payeur, remplacez les par un code générique: 45 transaction-disputed.

Code (champ response)	Réseau	Raison
📋 14	National	Transaction not authorized
📋 42	National	Duplicate processing
📋 45	National	Transaction disputed
📋 1040⚠️	Visa	Fraud; card Absent Environment
📋 1261	Visa	Duplicate processing
📋 4808	Mastercard	Requested/required authorization not obtained. Transaction not authorized
📋 4834	Mastercard	Duplicate processing
📋 4837⚠️	Mastercard	Fraudulent transaction; no cardholder authorization
📋 4853	Mastercard	Cardholder Dispute Defective/Not as Described
📋 4863⚠️	Mastercard	Cardholder does not recognize. Potential fraud

Codes de réponse des contestations (SEPA)

Le champ response de l'objet dispute(contestation) indique la raison de la contestation par la banque du porteur (Payeur).

Les codes et raisons sont des informations de flux bancaires, pour cette raison, ils ne sont pas traduits.

Ces codes sont défini par l'Universal financial industry message scheme.

Code (champ response)	Définition ISO	Liste exhaustive des cas d'usages
AC01	Incorrect Account Number	SDD B2B collection presented to a payment account whereby the Debtor account holder is a consumer or the payment account type is designed to consumers only.
AC04	Closed Account Number	The account of the Debtor is closed at the Debtor PSP. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
AC06	Blocked Account	Account blocked for any financial transaction.
AC13	Invalid Debtor Account Type	SDD B2B collection presented to a payment account whereby the Debtor account holder is a consumer or the payment account type is designed to consumers only.
AG01	Transaction Forbidden	A SDD collection cannot be booked from this type of account (account not allowed for direct debit for regulatory reasons e.g., savings account). Important note: AG01 cannot be used in the situation of an SDD B2B collection presented to a Debtor account that is a consumer account. The code AC13 needs to be used.
AG02	Invalid Bank Operation Code	Recurrent after a one-off / One-off after a recurrent / Identification code of the scheme (i.e. service level or local instrument) specified in the message is incorrect
AM04	Insufficient Funds	There are not enough funds on the Debtor account to debit the full amount of the collection. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative
AM05	Duplication	CSM or Debtor PSP considers that an identical SDD collection had been sent or processed very recently
BE05	Unrecognised Iniating Party	Creditor Identifier (CI) is not correct or has been changed without an amendment been reported.
CNOR	Creditor Bank Is Not Registered	Creditor PSP is not/ no longer registered as a SDD scheme participant under this BIC at the CSM.
DNOR	Debtor Bank Is Not Registered	Debtor PSP is not/ no longer registered as a SDD scheme participant under this BIC at the CSM.
ED05	Settlement Failed	The Debtor PSP or the CSM must report a settlement failure.
FF01	Invalid File Format	Issues with XML-file specific settings: • XML file was not duly filled out or is not correct • There is a syntax error in the file • Creditor PSP, its intermediary PSP or the CSM did not complete a XSD check before submitting the file into the scheme.
MD01	No Mandate	• No mandate is existing • B2B mandate not yet confirmed by the Debtor • Refund for an unauthorised transaction (until 13 months after debit date) (For SDD Core collections only) • Mandate cancellation
MD02	Missing Mandatory Mandate Information in Mandate	• Mandate data in the mandate related information is not identical to those in the mandate (amendments had not been communicated) • Mandate data not consistent with version already received for the UMR • In case of mandate amendment: the original IBAN
MD06	Refund Request By End Customer	Unconditional Refund of a collection (SDD Core – until 8 weeks after debit date).
MD07	End Customer Deceased	Debtor deceased. Note: This code cannot be used in certain SEPA countries for reasons of data protection. In this case MS03 can be used as alternative.
MS02	Not Specified Reason Customer Generated	Refusal by Debtor at presentation.
MS03	Not Specified Reason Agent Generated	Only to be used in case national legislation (e.g., data protection laws) does not allow the use of AC04, AM04, MD07, RR01, RR02, RR03 and RR04. Note: limit the use of the reason code MS03 and select the appropriate reason code in the list.
RC01	Bank Identifier Incorrect	BIC of the scheme participant is not correct.
RR01	Missing Debtor Account Or Identification	Missing details about the Debtor account or identification. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
RR02	Missing Debtor Name Or Address	Missing Debtor name (address is optional field for EEA SDD collections); Missing address of the Debtor for non-EEA SDD collections. Note: This code cannot be used in certain SEPA countries forreasons of data protection. MS03 could be used as an alternative.
RR03	Missing Creditor Name OR Address	Missing Creditor name (address is an optional field). Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
RR04	Regulatory Reason	Only to be used for regulatory reasons other than RR01, RR02 or RR03. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
SL01	Specific Service Offered By Debtor Agent	All Debtor-invoked consumerright rejects: • Creditor blocking • Collection amount limitations • Collection frequency limitations. Other services offered by the Debtor PSP.

Données de test

Cartes de test

⚠️ Note

Ces cartes de test sont destinées uniquement à la simulation de scénarios spécifiques (exemples : Contestations, Paiements capturés...).
Leur utilisation dans un flux de paiement en production peut entraîner des comportements inattendus et compromettre l’intégrité de vos intégrations.

À utiliser uniquement dans un environnement de test.

Numéro	Marque	Pays	3DS	Code retour	Libellé	Status	Utilisation
📋 4000000400000008	Visa	AT 🇦🇹	Optional	00	OK	Accepted	Page de paiement
📋 4000000560000004	Visa	BE 🇧🇪	Optional	00	OK	Accepted	Page de paiement
📋 4000002080000001	Visa	DK 🇩🇰	Optional	00	OK	Accepted	Page de paiement
📋 4000002460000001	Visa	FI 🇫🇮	Optional	00	OK	Accepted	Page de paiement
📋 4000002500000003	CB	FR 🇫🇷	Optional	00	OK	Accepted	Page de paiement
📋 4000002760000016	Visa	DE 🇩🇪	Optional	00	OK	Accepted	Page de paiement
📋 4000003720000005	Visa	IE 🇮🇪	Optional	00	OK	Accepted	Page de paiement
📋 4000003800000008	Visa	IT 🇮🇹	Optional	00	OK	Accepted	Page de paiement
📋 4000004420000006	Visa	LU 🇱🇺	Optional	00	OK	Accepted	Page de paiement
📋 4000005280000002	Visa	NL 🇳🇱	Optional	00	OK	Accepted	Page de paiement
📋 4000005780000007	Visa	NO 🇳🇴	Optional	00	OK	Accepted	Page de paiement
📋 4000006200000007	Visa	PT 🇵🇹	Optional	00	OK	Accepted	Page de paiement
📋 4000006430000009	Visa	RU 🇷🇺	Optional	00	OK	Accepted	Page de paiement
📋 4000007240000007	Visa	ES 🇪🇸	Optional	00	OK	Accepted	Page de paiement
📋 4000007520000008	Visa	SE 🇸🇪	Optional	00	OK	Accepted	Page de paiement
📋 4000007560000009	Visa	CH 🇨🇭	Optional	00	OK	Accepted	Page de paiement
📋 4000008260000000	Visa	GB 🇬🇧	Optional	00	OK	Accepted	Page de paiement
📋 4242424242424242	Visa	US 🇺🇸	Not required	00	OK	Accepted	Page de paiement
📋 4444333322221111	Visa	US 🇺🇸	Not required	00	OK	Accepted	Page de paiement
📋 4111111111111111	Visa	US 🇺🇸	Not required	00	OK	Accepted	Page de paiement
📋 5555555555554444	Mastercard	US 🇺🇸	Optional	00	OK	Accepted	Page de paiement
📋 5200828282828210	Mastercard	US 🇺🇸	Optional	00	OK	Accepted	Page de paiement
📋 5105105105105100	Mastercard	US 🇺🇸	Optional	00	OK	Accepted	Page de paiement
📋 4000000000003055	Visa	US 🇺🇸	Not enrolled	00	OK	Accepted	Page de paiement
📋 4000000760000002	Visa	BR 🇧🇷	Optional	00	OK	Accepted	Page de paiement
📋 4000001240000000	Visa	CA 🇨🇦	Optional	00	OK	Accepted	Page de paiement
📋 4000004840000008	Visa	MX 🇲🇽	Optional	00	OK	Accepted	Page de paiement
📋 4000000000000077	Visa	FR 🇫🇷	Optional	00	OK	Captured	API (HPP, TTPOI, TPE, CMS etc)
📋 4000000000003220	Visa	US 🇺🇸	Required	A1	Must perform 3DS	Refused	Page de paiement
📋 4000000000000002	Visa	FR 🇫🇷	Optional	05	Do not honor	Refused	Page de paiement
📋 4000000000009995	Visa	FR 🇫🇷	Optional	51	Insufficient fund	Refused	Page de paiement
📋 4000000000009987	Visa	FR 🇫🇷	Optional	41	Lost card	Refused	Page de paiement
📋 4000000000000259	Visa	FR 🇫🇷	Optional	00	OK	Disputed	API (HPP, TTPOI, TPE, CMS etc)
📋 4000000000001976	Visa	FR 🇫🇷	Optional	00	OK	Disputed	API (HPP, TTPOI, TPE, CMS etc)
📋 4000000000005423	Visa	FR 🇫🇷	Optional	00	OK	Disputed	API (HPP, TTPOI, TPE, CMS etc)

SEPA de test

⚠️ Note

Ces SEPA de test sont destinés uniquement à la simulation de scénarios spécifiques (exemples : Contestations, Paiements capturés...).
Leur utilisation dans un flux de paiement en production peut entraîner des comportements inattendus et compromettre l’intégrité de vos intégrations.

À utiliser uniquement dans un environnement de test.

IBAN	Pays	Nom	Date de naissance	Code retour	Libellé	Status
📋 AT611904300234573201	AT 🇦🇹	Otto Normalverbraucher	1971-02-02	00	OK	Accepted
📋 BE62510007547061	BE 🇧🇪	Jef Van Pijperzele	1972-03-03	00	OK	Accepted
📋 CH2089144321842946678	CH 🇨🇭	Leonhard Euler	1973-04-04	00	OK	Accepted
📋 DE89370400440532013000	DE 🇩🇪	Max Mustermann	1974-05-05	00	OK	Accepted
📋 EE382200221020145685	EE 🇪🇪	Friedrich Robert Faehlmann	1975-06-06	00	OK	Accepted
📋 ES0700120345030000067890	ES 🇪🇸	Juan Pérez	1976-07-07	00	OK	Accepted
📋 FI2112345600000785	FI 🇫🇮	Maija Meikäläinen	1977-08-08	00	OK	Accepted
📋 FR1420041010050500013M02606	FR 🇫🇷	Pierre Martin	1978-09-09	00	OK	Accepted
📋 GB33BUKB20201555555555	GB 🇬🇧	John Doe	1970-01-01	00	OK	Accepted
📋 IE29AIBK93115212345678	IE 🇮🇪	John Kilkenny	1979-10-10	00	OK	Accepted
📋 LT121000011101001000	LT 🇱🇹	Jonas Petraitis	1980-11-11	00	OK	Accepted
📋 LU280019400644750000	LU 🇱🇺	Adalbert Boros	1981-12-12	00	OK	Accepted
📋 IT02A0301926102000000490887	IT 🇮🇹	Piero Pers	1982-01-13	00	OK	Accepted
📋 NL39RABO0300065264	NL 🇳🇱	Jan Modaal	1983-02-14	00	OK	Accepted
📋 NO9386011117947	NO 🇳🇴	Peder Aas	1984-03-15	00	OK	Accepted
📋 PT50000201231234567890154	PT 🇵🇹	Jan Kowalski	1985-04-16	00	OK	Accepted
📋 SE3550000000054910000003	SE 🇸🇪	Lisa Svensson	1986-05-17	00	OK	Accepted
📋 FR9430003000409249176322Z50	FR 🇫🇷	Gilles Dupont	1987-06-18	00	OK	Accepted
📋 FR2990665286926539507769811	FR 🇫🇷	Jean Banbois	1992-11-23	AC01	Incorrect Account Number	Refused
📋 FR8191676442817818484578833	FR 🇫🇷	Marie-Jeanne Sansbanque	1993-12-24	AC04	Closed Account Number	Refused
📋 FR3083648641551044006702169	FR 🇫🇷	Marc Barrer	1994-01-25	AC06	Blocked Account	Refused
📋 FR4200838098473368525032012	FR 🇫🇷	Sophie Fontek	1995-02-26	AG01	Transaction Forbidden	Refused
📋 FR7099253427049384102178149	FR 🇫🇷	Hector Fauché	1996-03-27	AM04	Insufficient Funds	Refused
📋 FR7240745948453163519978561	FR 🇫🇷	Lillianne Sansmandat	1997-04-28	MD01	No Mandate	Refused
📋 FR5533686478441573584650545	FR 🇫🇷	Vincent Refusé	1998-05-29	MD06	Refund Request By End Customer	Refused
📋 FR2488294045573706143240475	FR 🇫🇷	Eric Indécis	1999-06-30	MS02	Not Specified Reason Customer Generated	Refused
📋 BE08510007547063	BE 🇧🇪	Camille Honnête	1988-07-19	AM04	Insufficient Funds	Disputed
📋 ES5000120345030000067892	ES 🇪🇸	Pepito Pérez	1990-09-21	AC04	Closed Account Number	Disputed