Developers API & Widget
FR

Paiements

Sécurité et tests des paiements

Intégrez d’abord le bac à sable. Publier une véritable institution nécessite une configuration privée, une connectivité validée, des limites opérationnelles et un test de bout en bout approuvé.

Contrôles inclus

  • Clé d’accès à haute entropie, utilisée uniquement serveur-à-serveur, avec une autorisation de paiement distincte.
  • Intention durable avant tout début externe.
  • Profil, bénéficiaire, concept, montant et institution définis et validés par le serveur.
  • État sensible chiffré ; jeton widget lié à l’entreprise, à l’intention, à l’expiration et à l’origine, conservé uniquement comme hachage.
  • Identifiants de tentative déterministes et mécanisme de fencing pour empêcher un redémarrage automatique après un résultat ambigu.
  • Rappel dédié, consommation unique, contrôle optimiste de version et lease.
  • Audit expurgé : N’inclut jamais les identifiants, l’IBAN complet, l’IP, les rappels, les réponses complètes ou le statut opaque.
  • Destinations et redirections explicitement autorisées, avec HTTPS, des temps maximaux et des réponses limitées.
  • Messagerie widget avec origine exacte, validation event.source et schéma versionné.

Intégrer le bac à sable

Demandez à Wealth Reader :

  1. une clé d’accès privée autorisée pour les paiements et pour le profil requis ;
  2. la source HTTPS exacte qui hébergera le widget ;
  3. les limites de montant et de fréquence convenues ;
  4. Accès au mode bac à sable, qui ne fait pas de transfert d’argent.

Vérifiez toujours profile-institutions; en sandboxing, cela ne retournera qu’une institution simulée. Créez l’intention avec expected_mode: "mock" et vérifiez que l’attestation de la réponse indique également mock avant de livrer le jeton au navigateur.

Essayez au moins :

  • la répétition de la création avec la même clé et le conflit avec un autre corps ;
  • institution ou mode modifié ;
  • jeton expiré et origine interdits ;
  • Fenêtre popup verrouillé et retour SCA;
  • en attente de statut intermédiaire, de rapprochement et de fermeture du widget ;
  • Confirmation uniquement à la réception payment_status: settled.

Demande d’activation réelle

Avant un test avec de l’argent réel, confirmez avec Wealth Reader:

  • que l’institution figure dans la préconsultation effectuée avec votre clé d’accès ;
  • que le profil et sa version soient approuvés ;
  • que l’origine, le rappel et le flux étaient SCA validés d’un bout à l’autre ;
  • qu’il existe des limites sur le montant, la fréquence, la conciliation et la désactivation d’urgence ;
  • qu’il existe un humain autorisé responsable du test minimum.

Le compte source peut être requis pour une institution, et dans ce cas, il est demandé par le widget lors de l’autorisation. L’adresse réseau de l’utilisateur est dérivée à la frontière contrôlée de l’API; le client ne doit pas la soumettre. Ni ces données ni l’IBAN du débiteur ne sont exposées lors des événements.

La séquence avec curl prépare et interroge l’intention, mais ne complète pas l’authentification bancaire. L’utilisateur doit continuer dans le navigateur bancaire ou l’application.

L’activation du profil nécessite trois contrôles de déploiement indépendants et précis : WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 et l’entreprise de l’identifiant inclus dans WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Ces valeurs ne remplacent pas l’autorisation de paiement et ne permettent pas, à eux seuls, d’activer une institution réelle.

Le contrat actuellement publié indique que psuIp n’est pas utilisé, mais les tests historiques du connecteur l’exigeaient. Wealth Reader maintient l’activation verrouillée jusqu’à ce que le déploiement cible soit vérifié, via un test de bout en bout approuvé et d’options, à la fois le champ exact et la politique de proxy de confiance. Il ne doit pas être activé en utilisant des en-têtes transférés arbitraires ni en supposant que la déclaration publiée reflète un comportement historique.

La résolution DNS privée et la terminaison TLS vers le service interne dépendent de chaque déploiement : ce SDK ne présume pas qu’ils existent ou sont accessibles. Ils doivent être vérifiés à partir de l’environnement d’exécution de l’API avant d’activer la sortie ou d’accepter de nouvelles intentions.

Que ne pas faire

  • Envoyez la clé API , le bénéficiaire complet ou les données internes au navigateur.
  • Inventer une institution non restituée par la préconsultation.
  • Répétez automatiquement un début ambigu.
  • Journaliser un IBAN, une adresse réseau, un callback ou une réponse bancaire complète.
  • Interprétez la fin de l’interaction comme une liquidation.
  • Réutilisez les routes d’agrégation bancaire, les jetons ou les rappels.
Dernière mise à jour