Passer au contenu principal

Passerelle de paiement fictive pour les tests : Fournisseur Dummy de Casdoor, Mode test Stripe et Bac à sable PayPal

· Lecture de 11 minutes
Yang Luo
Yang Luo
Casdoor Maintainer

Une passerelle de paiement fictive est un fournisseur de paiement qui accepte tous les paiements comme payés sans contacter une banque ou un réseau de cartes, afin que vous puissiez tester les commandes, les abonnements et le traitement des commandes sans argent ni compte de passerelle. Casdoor en inclut un : le Fournisseur de paiement Dummy. Ajoutez-le à un produit, achetez le produit, et Casdoor enregistre le paiement et la commande comme Paid, démarre l'abonnement et écrit la transaction, le tout sans quitter votre serveur. Utilisez Dummy en développement, et passez à un bac à sable fournisseur (mode test Stripe, bac à sable PayPal, bac à sable Paddle) en préproduction, où vous avez également besoin de cartes refusées, de 3-D Secure et de redirections réelles.

Aperçu de Dummy, Balance et bacs à sable fournisseurs​

FournisseurEnvironnement de testComment Casdoor choisit test ou productionType de fournisseur Casdoor
DummyAucun nécessaire, chaque paiement réussitToujours simuléDummy
BalanceInterne, financé par un produit de rechargeToujours interneBalance
StripeBac à sable avec les clés sk_test_ / pk_test_Selon les clés saisiesStripe
PayPalApplications bac à sable et comptes bac à sableUn runmode autre que prod utilise le bac à sablePayPal
PaddleCompte bac à sable séparé chez sandbox-vendors.paddle.comUn runmode autre que prod utilise sandbox-api.paddle.comPaddle
AdyenEnvironnement de test (checkout-test.adyen.com)Un runmode autre que prod utilise l'environnement de testAdyen
AirWallexSeparate sandbox accountrunmode other than prod calls api.sandbox.airwallex.comAirWallex
Lemon SqueezyMode test de la boutique avec des clés API de testSelon la clé API saisieLemon Squeezy
FastSpringVitrine de test avec .test. dans l'hôteSelon l'Host saisiFastSpring
PolarSandbox sur sandbox.polar.shDéfinissez Host du fournisseur sur https://sandbox-api.polar.shPolar

runmode est l'option dans conf/app.conf (ou la variable d'environnement runmode) décrite dans la référence de configuration. Sa valeur par défaut est dev, donc une nouvelle instance de Casdoor communique avec les bacs à sable de PayPal, Paddle, Adyen et AirWallex jusqu'à ce que vous la régliez sur prod.

Signification d'une transaction fictive​

Une transaction fictive suit les mêmes enregistrements qu'un achat réel (commande, paiement, abonnement, écriture comptable) mais ne déplace aucun argent. Elle diffère d'une transaction en bac à sable. Un bac à sable appelle toujours l'API du fournisseur, affiche la page de paiement du fournisseur et envoie des webhooks ; seul l'argent est faux. Une transaction fictive ne quitte jamais votre système.

Cette différence décide de ce que chacun peut tester. Une passerelle fictive est bonne pour votre propre logique : le plan accorde-t-il le bon rôle, la commande apparaît-elle, le coupon est-il compté comme utilisé, l'utilisateur arrive-t-il sur la bonne page. Un bac à sable est bon pour l'intégration : identifiants, redirections, refus de carte, défis d'authentification et livraison des webhooks. Vous avez besoin des deux, à des étapes différentes.

Comment fonctionne le fournisseur Dummy de Casdoor​

Le fournisseur Dummy n'a aucun paramètre ni page de paiement. Voici le flux complet sur la branche master de Casdoor :

  1. Lorsque l'utilisateur paie, l'appel Pay du fournisseur renvoie la page de résultat Casdoor comme URL de paiement. Il encode le prix et la devise dans l'ID de commande au lieu de créer quoi que ce soit chez un vendeur.
  2. Casdoor stocke le paiement avec l'état Created et redirige directement le navigateur vers la page de résultat. Il n'y a pas de formulaire de carte bancaire, même simulé.
  3. La page de résultat voit un paiement Created et appelle POST /api/notify-payment environ une seconde plus tard.
  4. L'appel Notify du fournisseur répond toujours Paid, avec le prix qu'il avait encodé précédemment, de sorte que la vérification du prix passe.
  5. Casdoor exécute ensuite le chemin de succès normal : le paiement et la commande deviennent Paid, les abonnements créés pour le paiement sont mis à jour, une transaction Purchase est écrite, le stock du produit est réduit et un coupon sur la commande est marqué comme utilisé. Si le produit est un produit de recharge, une transaction Recharge ajoute également le montant au solde de l'utilisateur.

Donc oui, Dummy marque la commande comme payée immédiatement, et l'utilisateur voit la page de succès sans étape intermédiaire.

Deux limites découlent de cette conception. Dummy ne peut pas échouer : il n'y a aucun moyen de lui faire retourner Canceled, Timeout ou Error, donc les chemins d'échec nécessitent un bac à sable (sandbox). Et Dummy ne peut pas renouveler : Casdoor n'autorise le renouvellement automatique que pour Balance et Stripe, donc un abonnement acheté avec Dummy a toujours le renouvellement automatique désactivé.

Sur une nouvelle base de données, Casdoor crée un fournisseur Dummy intégré nommé provider_payment_dummy dans l'organisation admin, à côté d'un fournisseur Balance intégré. Vous pouvez également ajouter le vôtre : dans Identity > Providers, définissez Category sur Payment et Type sur Dummy.

Gardez Dummy hors de la production​

/api/notify-payment is open to anonymous callers, because real gateways call it without a Casdoor session. For a real provider that is safe, since Notify checks the payment with the vendor. Dummy checks nothing and reports Paid, so for a Dummy payment Casdoor only accepts the call from the payment's own user or an admin of its organization. That still leaves the main risk: any product that lists Dummy in its Payment providers shows it at checkout, and any signed-in user who picks it gets the product for free. Remove Dummy from every product before you go live, and do not put it on products in an organization that real users can reach.

Balance : le portefeuille interne que vous pouvez alimenter avec Dummy​

Le fournisseur Balance permet aux utilisateurs de payer depuis leur solde de compte. Casdoor vérifie le solde d'abord, déduit le prix, et marque le paiement et la commande Paid dans la même requête. Balance est une vraie fonctionnalité de production, pas un outil de test, mais il se marie bien avec Dummy : mettez Dummy sur un produit de recharge, "approvisionnez" un utilisateur de test, et le solde est crédité sans argent impliqué.

Cela importe pour les abonnements, car Balance est l'un des deux fournisseurs qui prennent en charge le renouvellement automatique. Avec Dummy plus Balance, vous pouvez tester toute la boucle de renouvellement sur un ordinateur portable sans compte de passerelle.

Bacs à sable des vendeurs pour le staging​

Stripe. Stripe sépare les données de test et de production par clés : les clés de bac à sable commencent par pk_test_ et sk_test_, les clés de production par pk_live_ et sk_live_, et les objets dans un mode ne sont pas visibles dans l'autre. Casdoor utilise les clés que vous placez dans le fournisseur Stripe ; runmode ne change rien pour Stripe. Les cartes de test de Stripe couvrent les chemins que Dummy ne peut pas : 4242 4242 4242 4242 réussit, 4000 0000 0000 0002 est refusée, et 4000 0000 0000 3220 nécessite 3-D Secure. Utilisez une date d'expiration future et n'importe quel CVC. Les conditions de Stripe interdisent de tester en mode production avec de vraies informations de carte.

PayPal. Le bac à sable PayPal est un environnement séparé avec ses propres applications et comptes de test. PayPal crée un compte personnel par défaut et un compte professionnel par défaut lorsque vous vous connectez pour la première fois au tableau de bord développeur ; vous payez avec le personnel. Créez l'application en mode bac à sable, placez ses identifiants dans le fournisseur PayPal, et gardez runmode à dev.

Paddle. Le bac à sable est un compte séparé sur sandbox-vendors.paddle.com avec ses propres clés et produits ; rien n'est partagé avec la production. Les cartes de test de Paddle incluent 4242 4242 4242 4242 (réussit) et 4000 0000 0000 0002 (refusée).

Lemon Squeezy has a test mode per store, and API keys created in test mode only see test data. FastSpring test orders go through a test storefront: insert .test. into the store host, for example yourstore.test.onfastspring.com, and enter that as the provider's Host. Polar has a sandbox with its own tokens; set the provider's Host to https://sandbox-api.polar.sh to use it, and leave Host empty for live Polar. Alipay in Casdoor is also hard-wired to production.

Un plan de test pour les produits, plans et abonnements de Casdoor​

Développement, avec Dummy​

  1. Créez un produit et ajoutez Dummy à ses Payment providers.
  2. Créez un plan pour ce produit et une page de tarification qui le liste (voir l'aperçu de la tarification).
  3. En tant qu'utilisateur de test, ouvrez la page de tarification et achetez le plan. Vérifiez que le paiement et la commande sont Paid, que l'abonnement est Active, et qu'une transaction Purchase apparaît sur l'utilisateur.
  4. Connectez-vous en tant qu'utilisateur et vérifiez que le rôle du plan a pris effet dans votre application.
  5. Si le plan a Is exclusive activé, achetez-le à nouveau et attendez-vous à l'erreur indiquant que l'utilisateur a déjà un abonnement actif.
  6. Appliquez un coupon lors du paiement et vérifiez que son utilisation est enregistrée.
  7. Créez un produit de recharge avec Dummy, approvisionnez l'utilisateur de test, puis achetez le plan avec Balance et Auto renew activé.
  8. Pour tester le renouvellement sans attendre un mois, modifiez l'End time de l'abonnement sur sa page d'édition afin qu'il se termine dans les 24 heures. Casdoor vérifie les abonnements une fois par heure ; attendez-vous à ce que l'Renewal state soit Renewed et qu'un nouvel abonnement soit créé pour la période suivante. Puis achetez le plan à nouveau avec un solde trop faible pour la période suivante, déplacez son heure de fin de la même manière, et attendez-vous à Failed avec la raison dans Renewal message. La documentation sur les abonnements décrit les règles exactes.

Staging, avec un bac à sable​

  1. Exécutez l'environnement de préproduction avec runmode = dev et uniquement des identifiants sandbox ou de test.
  2. Remplacez Dummy par le fournisseur que vous utiliserez en production, configuré avec ses clés sandbox.
  3. Répétez l'achat et vérifiez que le navigateur redirige vers la page de paiement du vendeur puis revient sur la page de résultat Casdoor.
  4. Avec Stripe, effectuez un paiement avec la carte de refus et un autre avec la carte 3-D Secure, puis vérifiez les états du paiement et de la commande pour chacun.
  5. Avec Stripe et Auto renew activé, Casdoor enregistre la carte lors du paiement et procède lui-même au débit lors du renouvellement, ce qui permet à l'astuce sur l'heure de fin mentionnée ci-dessus de fonctionner également dans l'environnement sandbox.

Passage en production​

Supprimez Dummy de tous les produits, définissez runmode = prod si vous utilisez PayPal, Paddle, Adyen ou AirWallex, et remplacez les clés par vos clés de production. Vérifiez les enregistrements de paiement des premières commandes réelles.

Si vous testez également les e-mails d'inscription dans le même environnement, un collecteur de courrier local empêche ces messages d'atteindre de vraies boîtes de réception ; consultez MailHog vs Mailpit.

Références​