Environnement de bac à sable
L'environnement de bac à sable Cardflo permet aux développeurs d'intégrer et de tester des solutions de paiement sans affecter les transactions en direct.
Cet espace isolé reproduit notre environnement de production, permettant des tests approfondis de toutes les fonctionnalités Cardflo, du traitement des paiements aux webhooks et aux interactions API, assurant une transition en douceur vers les opérations en direct.
- Catégorie
- Développeur
- Capacités
- 10
- Disponible sur
- Tous les plans
L'aperçu
Un environnement de bac à sable agit comme une instance non-production d'une passerelle de paiement ou d'une plateforme d'orchestration, permettant aux développeurs de modéliser l'ensemble du cycle de vie des transactions sans déplacer de fonds réels.
Il fonctionne comme une réplique de l'API en direct, y compris les composants pour l'autorisation, la capture et le règlement.
Dans ce conteneur isolé, les équipes techniques peuvent vérifier leur logique d'intégration, les structures de requête et les en-têtes d'authentification par rapport à des règles de validation strictes.
En utilisant des identifiants de test et des numéros d'identification de carte (BIN) simulés, les commerçants peuvent évaluer comment leur backend réagit à diverses réponses, telles que les paiements réussis, les refus souples ou les invites d'authentification 3DS.
Le bac à sable se situe entre l'application du commerçant et l'acquéreur simulé, offrant un espace sûr pour s'assurer que le code gère les cas limites, tels que les fonds insuffisants ou les cartes expirées,
avant de passer à un environnement de production en direct où les erreurs pourraient entraîner une perte de revenus ou une augmentation des taux de rétrofacturation.
Comment ça marche
Génération et authentification des identifiants
Les développeurs obtiennent un ensemble spécifique de clés API ou de jetons Bearer désignés pour l'environnement de test. Ces identifiants acheminent les requêtes vers un processeur fictif plutôt que vers les systèmes de paiement en direct.
Cela garantit qu'aucun numéro d'identification de commerçant (MID) n'est facturé pour les frais de traitement et qu'aucune donnée réelle de titulaire de carte n'entre dans les systèmes de production.
Traitement simulé des transactions
Le commerçant envoie une demande de paiement en utilisant des numéros de carte de test prédéfinis qui déclenchent des résultats spécifiques. Par exemple, l'utilisation d'un BIN peut simuler une autorisation réussie, tandis qu'un autre déclenche une non-concordance CVV ou un refus ferme.
Le bac à sable renvoie une structure de réponse JSON identique à l'API en direct pour assurer la compatibilité.
Notification d'événement Webhook
Une fois qu'un statut de transaction change dans le bac à sable, le système génère des webhooks asynchrones. Le serveur du commerçant reçoit ces notifications à un point de terminaison désigné pour vérifier que son système met correctement à jour la base de données interne.
Cette étape est essentielle pour tester la logique d'exécution automatique des commandes ou de gestion des abonnements en temps réel.
Changement d'état et règlement
Les utilisateurs peuvent manuellement ou par programmation faire passer l'état d'une transaction d'autorisée à réglée ou remboursée dans le tableau de bord de test.
Cela permet de vérifier les flux de travail post-achat, y compris la gestion des demandes de récupération ou des remboursements partiels, garantissant que l'interface utilisateur du commerçant reflète l'état financier correct.
Pourquoi c'est important
Atténuation des risques lors du déploiement
L'implémentation de nouveaux flux de paiement directement en production crée un risque opérationnel élevé. En utilisant un bac à sable, les développeurs peuvent identifier les erreurs logiques ou les requêtes API mal formées qui autrement conduiraient à des échecs de paiement.
Cet isolement protège l'intégrité du numéro d'identification de commerçant en direct et empêche les déclenchements accidentels de filtres anti-fraude qui pourraient survenir lors de tests agressifs de nouvelles logiques d'intégration de carte présente ou de carte non présente.
Validation de la logique complexe
Les paiements modernes impliquent souvent des processus en plusieurs étapes comme l'authentification forte du client (SCA) ou la facturation récurrente.
Un bac à sable permet des tests rigoureux des transactions initiées par le titulaire de carte et par le commerçant sans le coût financier des transactions réelles.
Il garantit que le système interprète correctement les différents codes de refus et messages de réponse des émetteurs, permettant l'affinement de la logique de relance et des stratégies de nouvelle tentative pour optimiser les taux de conversion finaux.
Cas d'usage
Intégration API initiale
Les nouveaux commerçants utilisent le bac à sable pour mapper leurs systèmes internes de gestion des commandes aux points de terminaison API de la passerelle de paiement.
Cela confirme que les champs de données comme les codes de devise et les codes de catégorie de commerçant sont correctement formatés pour l'autorisation.
Vérification de la facturation récurrente
Les entreprises basées sur l'abonnement testent leurs séquences de relance en simulant l'expiration de la carte ou des fonds insuffisants. Cela garantit que le système tente correctement les nouvelles tentatives et envoie les notifications appropriées au client avant la suspension du service.
Débogage des points de terminaison Webhook
Les développeurs utilisent l'environnement de test pour vérifier que leur pare-feu et leurs configurations de serveur permettent les notifications webhook entrantes. Cela évite les problèmes où les commandes restent 'en attente' malgré une autorisation réussie au niveau de l'acquéreur.
Test des méthodes de paiement alternatives
Avant d'activer les méthodes de paiement locales, les commerçants peuvent simuler les flux de redirection requis pour les APM. Cela garantit que l'expérience utilisateur reste cohérente lorsque le client est envoyé vers un portefeuille tiers ou un portail bancaire.
En chiffres
Gains d'efficacité typiques observés par les équipes techniques lors de l'utilisation d'un bac à sable complet par rapport à la révision manuelle de la documentation et aux tests de production directs.
Estimation de la réduction des bogues post-déploiement liés à la logique de paiement lorsque des tests rigoureux en bac à sable sont mis en œuvre dans le cadre du pipeline CI/CD.
Temps de réponse standard de l'industrie pour les points de terminaison API fictifs, permettant une itération rapide pendant le cycle de vie du développement logiciel.
Termes associés
Talk to our team about a live rollout on your acquiring stack.
Ce que vous obtenez avec Environnement de bac à sable
- Vérifier les structures de requête et de réponse API par rapport à la documentation officielle dans un environnement sécurisé.
- Simuler des raisons spécifiques de refus d'autorisation pour valider la gestion des erreurs et la messagerie client.
- Déclencher et recevoir des notifications webhook pour les mises à jour de statut comme la capture, le remboursement et le litige.
- Tester les flux d'authentification 3-D Secure pour assurer la conformité avec les exigences PSD2 et SCA.
- Valider le traitement des jetons réseau et des notifications de mise à jour de compte sans données réelles.
- Effectuer des tests de charge sur la logique d'intégration avant de passer à des environnements de production à volume plus élevé.
- Configurer plusieurs profils de commerçant pour tester la conversion de devises et le traitement national par rapport à l'international.
- Auditer l'enregistrement des ID de transaction, des ARN et des horodatages pour la réconciliation financière interne.
- Modéliser le comportement des captures partielles et des remboursements multiples sur une seule transaction.
- Examiner l'impact des codes de catégorie de commerçant sur les taux d'autorisation simulés et les structures de frais.
A short scoping call, then a written plan for your MIDs.
Questions à propos de Environnement de bac à sable
Les transactions du bac à sable apparaissent-elles sur de vrais relevés bancaires ou entraînent-elles des frais de système ?
Non, les transactions traitées dans un environnement de bac à sable n'interagissent pas avec les systèmes de paiement réels comme Visa ou Mastercard. Elles sont gérées par un processeur fictif qui simule la réponse de l'émetteur.
Par conséquent, aucun fonds réel n'est déplacé, aucun titulaire de carte n'est débité et le commerçant n'encourt aucun frais d'interchange ou de système. L'environnement est entièrement isolé pour éviter tout impact financier.
Puis-je tester l'authentification forte du client (SCA) et 3D Secure dans le bac à sable ?
Oui, les environnements de bac à sable de haute qualité fournissent des cartes de test spécifiques ou des drapeaux pour déclencher les flux 3DS.
Cela permet aux développeurs de tester la redirection vers un serveur de contrôle d'accès (ACS) simulé et de gérer les résultats d'authentification qui en découlent, tels que le succès, l'échec ou le contournement.
C'est une étape essentielle pour les commerçants européens afin d'assurer la conformité avec les mandats PSD2 pour les paiements électroniques.
Comment simuler un refus ferme par rapport à un refus souple lors des tests ?
La simulation est généralement réalisée en utilisant différents numéros de carte de test ou montants de transaction spécifiés dans la documentation. Un BIN spécifique peut être mappé à une réponse 'Perdu ou volé' (refus ferme), tandis qu'un autre peut déclencher 'Fonds insuffisants' (refus souple).
Tester ces variantes est vital pour les développeurs afin de mettre en œuvre une logique de nouvelle tentative appropriée et de distinguer les échecs permanents des échecs temporaires.
Les données de titulaire de carte stockées dans le bac à sable sont-elles soumises à la conformité PCI-DSS ?
Bien que le bac à sable ne doive pas contenir de données réelles de titulaire de carte, la sécurité des clés API et des données simulées reste importante.
La plupart des environnements de bac à sable utilisent des pseudo-données qui ressemblent à de vrais PAN mais échouent aux vérifications de l'algorithme de Luhn ou appartiennent à des plages non attribuées.
Cependant, les développeurs doivent maintenir de bonnes pratiques de sécurité et ne jamais utiliser de données client réelles dans un environnement de test pour éviter les risques potentiels de fuite de données.
Mes points de terminaison webhook recevront-ils la même charge utile que l'environnement de production ?
La charge utile JSON ou XML livrée à votre URL webhook dans le bac à sable doit refléter exactement le schéma de production. Cela inclut les mêmes champs pour l'ID de transaction, le montant, la devise et les codes de statut.
Tester cela garantit que votre analyseur backend est correctement configuré pour gérer le flux de données en direct sans avoir besoin d'apporter des modifications de code pendant la transition vers la production.
Puis-je tester le processus de règlement et de réconciliation dans le bac à sable ?
Vous pouvez simuler les transitions qui mènent au règlement, comme le passage d'une transaction de 'autorisée' à 'capturée'. Certains bacs à sable vous permettent de générer des rapports fictifs qui ressemblent aux fichiers de règlement fournis par les acquéreurs.
Cela aide à construire des outils de réconciliation automatisés qui font correspondre les ID de commande internes avec les références de transaction fournies par le prestataire de services de paiement.
Prêt à accélérer ?
Parlez-nous de votre activité. Nous vous mettrons en relation avec les bons partenaires acquéreurs et la bonne route, généralement en moins d'une semaine.