Tests automatiques

Les tests automatiques font partie intégrante du processus de développement d’applications, tant pour le code côté serveur que côté client. Les interfaces front-end, telles que Stripe Checkout ou le Payment Element, sont soumises à des mesures de sécurité visant à empêcher ces tests automatiques. En outre, le nombre de requêtes aux API Stripe que vous pouvez effectuer est limité. Cependant, vous avez la possibilité de simuler la sortie de nos interfaces et des requêtes API à l’aide de données fictives afin de tester le comportement de votre application ainsi que la gestion des erreurs.

Tests côté client

Si vous souhaitez tester la capacité de votre application à récupérer après des erreurs, telles que le refus d’une transaction lors de l’utilisation de l’élément de paiement, vous pouvez renvoyer un objet d’erreur simulé en codant en dur des objets d’erreur dans votre code de test ou en créant un service API qui renvoie des erreurs fictives dans une réponse HTTP. L’objet d’erreur représente ce que la fonction confirmPayment renvoie lorsqu’une carte est refusée. La section suivante vous montre comment générer un objet d’erreur simulé.

Générer un objet Error

Tout d’abord, utilisez un composant d’interface utilisateur Stripe, tel que le composant Payment Element, pour générer manuellement un objet d’erreur en confirmant une PaymentIntent en mode test à l’aide d’un numéro de carte pour les paiements refusés. Enregistrez l’erreur pendant le processus de confirmation, comme indiqué ci-dessous.

const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: {
    return_url: 'https://example.com'
  },
}) ;
if (error) {
  console.log(error)
}

Cette action génère un objet d’erreur consigné dans la console du navigateur, similaire à l’exemple ci-après. Les valeurs des propriétés telles que error_code dépendent de la carte utilisée et du type d’erreur généré.

{
  "charge": "{{CHARGE_ID}}",
  "code": "card_declined",
  "decline_code": "generic_decline",
  "doc_url": "https://docs.stripe.com/error-codes#card-declined",
  "message": "Your card has been declined.",
  "payment_intent": {"id": "{{PAYMENT_INTENT_ID}}", …},
  "payment_method": {"id": "{{PAYMENT_METHOD_ID}}", …},
  "request_log_url": "https://dashboard.stripe.com/test/logs/req_xxxxxxx",
  "type": "card_error"
}

Modifiez vos tests afin qu’ils renvoient cet objet d’erreur au lieu d’appeler les fonctions Stripe.js et les API Stripe. Vous pouvez utiliser différentes cartes de test pour générer des erreurs avec différents codes d’erreur afin de vous assurer que votre application gère correctement chaque type d’erreur.

Tests côté serveur

Vous pouvez utiliser la même approche pour tester les appels à l’API côté serveur. Vous pouvez générer manuellement des réponses API Stripe pour différents types d’erreurs et simuler la réponse renvoyée dans les tests automatisés back-end.

Par exemple, si vous souhaitez rédiger un test destiné à vérifier que votre application traite correctement les paiements hors session nécessitant 3DS, vous pouvez générer la réponse en créant un PaymentIntent à l’aide du PaymentMethod pm_card_authenticationRequired et en définissant confirm sur true.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=2099 \
  -d currency=usd \
  -d payment_method=pm_card_authenticationRequired \
  -d confirm=true \
  -d off_session=true

Cette opération génère un PaymentIntent à l’état requires_confirmation, ainsi que d’autres propriétés associées à l’authentification 3DS telles que next_action.

{
  "id": "{{PAYMENT_INTENT_ID}}",
  "object": "payment_intent",
  ...
	"next_action": {
        "type": "use_stripe_sdk",
    ...
  },
  ...
  "status": "requires_confirmation",
  ...
}

En générant des objets PaymentIntent reflétant différentes phases du cycle de vie des paiements, vous pouvez tester le comportement de votre application tout au long de l’évolution des PaymentIntents. Utilisez cette approche dans le cadre de vos tests automatiques afin de vérifier que votre intégration réagit correctement à différentes situations, par exemple lorsque votre client rouvre une session pour authentifier un paiement qui nécessite une action de sa part.