Stancer documentation

Français

English
Italiano

Français

English
Italiano

Appearance

FAQ ​

Flux de paiement ​

Quel est le flow recommandé pour une intégration e-commerce ?

Le flow recommandé est le suivant :

  • Création d’un Payment Intent sans capture immédiate

  • Redirection du Payeur vers la page de paiement

  • Le Payeur réalise son paiement

  • Redirection vers votre application

  • Validation du paiement via l’API Stancer puis capture du Payment Intent

Ce fonctionnement correspond au flow recommandé pour les paiements e-commerce. Il permet de vérifier le succès de l’autorisation avant de capturer définitivement les fonds.

Gestion de l’URL de redirection (return_url) ​

La return_url permet-elle d’identifier automatiquement la transaction ?

Non. La return_url ne transmet pas directement d’identifiant de transaction ou de Payment Intent. Il est donc recommandé de gérer une correspondance côté Client entre :

  • Votre identifiant de commande ou panier.

  • L’identifiant du Paiement Intent Stancer.

Exemple : https://votre-webservice.com/return-url?order-id=XXXXXXXX

Vous pourrez ensuite retrouver le Payment Intent associé dans votre système. Si vous créez initialement un Payment Intent sans return_url, il est également possible d’ajouter cette information ultérieurement via une modification du Payment Intent.

Expiration des Payment Intent ​

Un Payment Intent expire-t-il automatiquement ?

Non. Un Payment Intent n’a pas de délai d’expiration automatique. Si nécessaire, vous pouvez supprimer un Payment Intent non payé afin de l’annuler.

Paiements Récurrents et Cartes enregistrées ​

Les Paiements Récurrents sont-ils supportés ?

Oui. Les paiements récurrents sont supportés par la plateforme Stancer. Lorsqu’un Client réalise un paiement, une Carte tokenisée est automatiquement créée et associée au paiement, quelle que soit la méthode utilisée :

  • I-frame
  • Page de paiement Stancer
  • Redirection
  • Intégration personnalisée.

Exemple :

sh
GET /v2/payment_intents/{id}

Response :

sh
{ 
  "id": "pi_xxxxx", 
  "card": "card_xxxxx" 
}

La valeur card_xxx correspond à l’identifiant de la Carte tokenisée.

Comment réutiliser une Carte enregistrée ?

Une fois la Carte tokenisée, vous devez conserver l’identifiant card_xxx dans votre système. Lors d’un nouveau paiement, vous pouvez réutiliser cette carte :

sh
POST /v2/payment_intents/

Response :

sh
{ 
  "amount": 1000, 
  "card": "card_xxxxx" 
}

Dans ce cas, aucun passage par la page de paiement n’est nécessaire : la transaction utilise directement la Carte tokenisée.

**Où gérer la logique d’abonnement ou de récurrence ?

La logique de récurrence doit être gérée côté Client.

Exemple :

Pour un abonnement mensuel :

  • Vous stockez l’identifiant card_xxx
  • Chaque mois, votre système crée un nouveau Payment Intent
  • Le Payeur est automatiquement débité.

Cette approche permet de conserver un maximum de flexibilité :

Modification de la date de prélèvement :

  • Changement de montant ;
  • Changement de fréquence ;
  • Personnalisation des informations de paiement ;
  • Gestion de cas particuliers.

Tokenisation d’une Carte ​

Peut-on enregistrer une Carte sans effectuer un vrai paiement ?

Oui. La tokenisation est automatiquement réalisée lorsqu’un paiement est effectué. Si vous souhaitez uniquement enregistrer une Carte sans débiter le Payeur, vous pouvez créer un Payment Intent avec un montant de 0 €.

Cela permet :

  • De récupérer une Carte tokenisée
  • De réaliser la capture plus tard si nécessaire.

Cette approche est recommandée lorsque vous souhaitez vérifier l’autorisation bancaire avant de débiter réellement le Payeur.

Le Payeur voit-il une différence entre un paiement classique et une autorisation pour une utilisation future ?

Non. Pour le Payeur final, le parcours est identique. La différence concerne uniquement la gestion technique côté Client et les informations transmises aux banques.

MIT / CIT : paiements initiés par le Client ​

Peut-on effectuer un paiement avec une Carte enregistrée sans demander une nouvelle validation du Client ?

Oui. Ces paiements correspondent aux MIT (Merchant Initiated Transactions). Ils sont différents des CIT (Customer Initiated Transactions), où le Client initie directement le paiement.

Lorsqu’une Carte est utilisée et tokenisée, elle peut être réutilisée pour effectuer des paiements futurs selon les règles bancaires applicables.

Une évolution est prévue afin de permettre de préciser explicitement si un paiement est :

  • Paiement Unique (One-Time Only)
  • Paiement Récurrent

Cela permettra notamment de mieux gérer le chaînage des transactions avec les banques.

Sécurité et gestion des clés API ​

Les appels API doivent-ils être réalisés depuis le backend ?

Oui. Les opérations sensibles comme :

  • Création de paiement
  • Remboursement
  • Gestion des transactions

doivent être réalisées depuis votre backend avec votre clé privée. Votre frontend ne doit jamais exposer cette clé. Un attaquant récupérant votre clé privée pourrait :

  • Créer des paiements
  • Initier des remboursements
  • Consulter vos transactions

Le frontend doit donc appeler votre backend, qui communique ensuite avec les API Stancer.

Les données Cartes transitent-elles par mon infrastructure ?

Non. Les numéros de Carte ne doivent pas transiter par votre infrastructure. Ils sont transmis directement à Stancer afin de respecter les standards de sécurité PCI DSS.

De votre côté, vous manipulez uniquement :

  • Des identifiants tokenisés card_xxx
  • Qui ne sont pas des données sensibles

Existe-t-il un SDK frontend pour tokeniser une Carte côté Payeur ?

La tokenisation est automatique lorsqu’une carte effectue un paiement. Il n’est donc pas nécessaire de développer une logique spécifique côté frontend. Les données sensibles restent gérées par Stancer.

Gestion des Reversements ​

Peut-on tester les Reversements en environnement de test ?

Non. La gestion des Reversements n’est pas disponible dans l’environnement de test. Pour valider le comportement réel des reversements, il est recommandé de passer directement en production avec de faibles montants.

Frais de transaction ​

Comment obtenir le montant définitif des frais appliqués à une transaction ?

Les frais définitifs sont accessibles via l’API. Ils ne sont disponibles qu’une fois la transaction au statut : captured Ce statut correspond à la donnée de référence utilisée pour la facturation.

Gestion des remboursements ​

Que se passe-t-il lors d’un remboursement si le solde Stancer est à 0 après un Reversement ?

Si le solde Stancer ne permet pas de couvrir le remboursement :

  • Un Reversement négatif est créé
  • Un Prélèvement est effectué sur le Compte Bancaire du Client

Cas particulier : Si un Reversement est déjà en attente de versement, le montant du remboursement est directement déduit de ce Reversement avant que ce dernier n'ai pu arriver sur votre Compte Bancaire.

Peut-on annuler un remboursement ?

Non. Une fois qu’un remboursement est créé, il ne peut plus être annulé.

Peut-on rembourser un paiement capturé longtemps après son exécution ?

Cela dépend principalement de la validité de la Carte utilisée. Un remboursement peut être refusé si la Carte est expirée depuis trop longtemps. La décision finale dépend de la banque émettrice de la Carte. En pratique, les remboursements passent généralement plusieurs mois après l’expiration, mais cela devient progressivement plus incertain.

Comment récupérer les frais associés à un remboursement ?

À ce jour, les frais liés aux remboursements ne sont pas exposés via l’API. Ils restent visibles depuis l’Espace Client Stancer. Une évolution est prévue afin de rendre cette information disponible via API.

Statuts et historique des paiements ​

Pourquoi un paiement peut-il être affiché comme "Payé" (Paid) puis "Annulé" (Cancelled) ?

Un paiement peut avoir plusieurs états selon l’élément observé.

Exemple :

Le paiement a été capturé → statut "Payé" (Paid);

Il a ensuite été remboursé → statut "Annulé" (Cancelled).

Cette distinction peut créer une confusion dans l’interface. Une amélioration est prévue afin de mieux distinguer :

  • Paiement effectué
  • Paiement remboursé
  • Paiement annulé avant capture

Payment intent et synchronisation ​

Un Payment Intent en attente de paiement expire-t-il automatiquement ?

Non. Un Payment Intent reste actif sans limite de temps automatique. Il n’est pas annulé automatiquement après une période donnée.

Existe-t-il des webhooks pour suivre les changements de statut ?

Les webhooks sont en cours d’évolution. À terme, ils permettront de synchroniser plus facilement vos systèmes avec les événements Stancer. En attendant, une synchronisation via appels API périodiques reste possible.

Captures et annulations ​

Quelle différence entre une annulation ‘avant capture’ et un ‘remboursement’ ?

Un paiement annulé ‘avant capture’ ne provoque pas de mouvement de fonds. Un ‘remboursement’ concerne un paiement déjà capturé.

E-mails envoyés par Stancer ​

Quels e-mails sont envoyés automatiquement par Stancer ?

Stancer peut envoyer :

  • Les tickets de caisse si cette option est activée
  • Les e-mails de remboursement lorsque celui-ci est réalisé depuis l’Espace Client Stancer et que le Client a configuré.

Lorsqu’un remboursement est effectué via API, aucun e-mail automatique n’est envoyé au Payeur final.

Peut-on désactiver ou personnaliser les e-mails envoyés ?

Non. Il n’est pas possible actuellement :

  • De choisir précisément les e-mails envoyés ;
  • De modifier leur contenu.

Pourquoi le message indique "vous serez remboursé dans les prochains jours" alors que le paiement n’était pas capturé ?

Ce message peut être trompeur dans le cas d’une annulation avant capture. Dans cette situation :

  • Aucun mouvement financier n’a lieu
  • Aucun remboursement bancaire n’est effectué

Une évolution est prévue afin de distinguer clairement "Annulation" et "Remboursement"

Liens de paiement ​

Peut-on utiliser plusieurs fois le même numéro de commande ?

Oui. Le numéro de commande sert uniquement d’identifiant métier pour retrouver un paiement. Il ne garantit pas l’unicité d’une transaction. Il est donc possible d’avoir plusieurs paiements avec le même numéro de commande, aussi bien en test qu’en production.

Pourquoi un lien de paiement peut-il être affiché dans une autre langue ?

La langue du lien de paiement dépend de la langue de l’Espace Client. Il est possible de forcer la langue via un paramètre :

  • Français : ?lang=fr
  • Anglais : ?lang=en
  • Italien : ?lang=it

Exemple : https://votre-lien-paiement.com?lang=fr

Interface i-Frame et choix du réseau Carte ​

Pourquoi demander au Payeur de choisir son type de Carte alors que celui-ci est détecté automatiquement ?

Le choix du réseau Carte doit rester disponible pour le Payeur conformément aux directives du GIE Carte Bancaire. Le réseau peut être détecté automatiquement grâce au numéro de Carte, mais le Payeur doit pouvoir choisir son réseau. Si le choix effectué n’est pas compatible :

  • Stancer tente automatiquement les autres réseaux disponibles
  • Le paiement reste fonctionnel

Le choix utilisateur n’empêche donc pas le paiement d’aboutir.

Calcul des frais ​

Comment sont calculés les frais lors d’un remboursement partiel ?

Les frais sont calculés avec la même méthode que pour les paiements classiques.

Espace Client Stancer ​

Pourquoi les sessions sur l’Espace Client Stancer expirent-elles rapidement ?

La durée actuelle d’une session est courte : 5 minutes sans activité. Cette configuration suit les recommandations de sécurité concernant la gestion des sessions.

La double authentification (2FA) est-elle disponible ?

Oui. La 2FA est déjà activée.

Elle est demandée :

  • Tous les 90 jours
  • Lors d’actions sensibles.

Il n’est actuellement pas possible d’imposer une demande systématique de 2FA à chaque connexion.

Peut-on bannir un Payeur depuis Stancer ?

Non, cette fonctionnalité n’est pas disponible actuellement.

Sécurité en cas de compromission de clé privée ​

Que se passe-t-il si une clé privée est compromise ?

Une personne ayant accès à votre clé privée pourrait :

  • Créer des paiements
  • Consulter les transactions
  • Initier des remboursements

En revanche, elle ne pourrait pas récupérer directement les fonds capturés, car les Reversements sont toujours effectués vers votre Compte Bancaire. Comme pour tout service de paiement, la protection de la clé privée est essentielle.