Intégration Stripe pour Django

L'intégration Stripe pour Django comprend le SDK Python officiel de Stripe, des vues Django ou des points de terminaison DRF qui créent des intentions de paiement ou des sessions de paiement, une vue webhook signée, des mises à jour de l'état des commandes sur vos modèles, des tests par rapport aux événements de test Stripe et des notes de transfert. Vous recevez le source Django dans votre projet. Les frais Stripe et votre compte Stripe sont distincts.

Oui. Stripe Integration for Django est conçu pour un projet Django que vous possédez déjà. Nous insérons les URL, les vues et les paramètres dans votre application Django actuelle au lieu de livrer un site de démonstration distinct comme livrable.

Non. Django ne doit pas stocker de PAN. Les clients utilisent Stripe Checkout ou Elements. Stripe Integration pour Django possède des PaymentIntents, des webhooks et des écritures de commandes côté serveur. Un formulaire de carte Django personnalisé qui publie des données brutes de carte est hors de portée par défaut.

Stripe Integration pour Django utilise la bibliothèque officielle Stripe Python pour PaymentIntents, Checkout Sessions et construct_event. Nous n'encapsulons pas les paiements Django dans un plugin non documenté, sauf si vous en avez explicitement besoin.

Oui pour l'accomplissement. Stripe doit POST sur un point de terminaison Django HTTPS accessible. Django local a besoin de Stripe CLI ou d'un tunnel pendant le développement. Un hôte statique ne peut pas exécuter ce webhook Django.

Non. L'intégration Stripe par défaut pour Django fonctionne avec les vues Django. DRF n'est utilisé que si votre API Django l'utilise déjà et nous en convenons lors de la vérification de compatibilité Django.

Django peut créer une session PaymentIntent ou Checkout et stocker l'identifiant client Stripe sur votre modèle. Les produits de facturation Stripe récurrents, le portail client et la logique de facturation restent sur le serveur. Les travaux Django nécessitant beaucoup d'abonnement peuvent nécessiter un devis personnalisé.

Le processus Django utilise la clé secrète et le secret de signature du webhook de l'environnement/paramètres. Les modèles ou tout SPA reçoivent uniquement la clé publiable. Stripe Integration for Django ne met pas de clés secrètes dans les modèles Django.

Nous implémentons Stripe Integration pour Django sur les clés de test Stripe et testons d'abord les événements de webhook. La mise en ligne est une transition documentée de clé et de point de terminaison dans vos paramètres Stripe Dashboard et Django, et non une activation de licence complémentaire.

Django crée des PaymentIntents qui prennent en charge SCA. Le client complète 3-D Secure avec Stripe.js ou Checkout. Django ne se réalise qu'après payment_intent.succeeded sur le webhook, pas après une seule redirection du navigateur.

Oui pour l'exécution après une session PaymentIntent ou Checkout créée par Django. Une vue de remerciement Django n'est pas la source de la vérité. La vue webhook vérifie les signatures puis marque la commande payée.

Oui. L'intégration Stripe pour Django ajoute généralement des champs ou un enregistrement de paiement léger à côté de votre modèle de commande Django existant au lieu de remplacer votre catalogue ou votre schéma de réservation.

Non. Vous créez et possédez le compte Stripe, les clés API et les frais de traitement Stripe. Le prix du module complémentaire Django est une implémentation dans votre projet Django, et non une licence de paiement Bacodo.

Non. Les biens numériques vendus dans une boutique d’applications nécessitent souvent encore un IAP. L'intégration Stripe pour Django concerne les frais Stripe que votre API Django est autorisée à créer pour votre type de produit.

Oui. Les métadonnées PaymentIntent ou Checkout Session, les enregistrements client et les champs que vous conservez après la confirmation du webhook sont alignés sur votre modèle de commande Django existant lors de l'intégration Stripe pour Django.

La source Django est dans votre dépôt, afin que votre équipe puisse la maintenir. Le support inclus de 30 jours couvre les questions techniques et les défauts dans la portée de l'intégration Stripe pour Django fournie, ainsi que le travail sur les fonctionnalités Django sans rapport.

Pendant la période de 30 jours, nous aidons en cas de rupture de l'intégration Django livrée causée par une API Stripe documentée ou un changement de package Stripe. Les mises à niveau en cours de Django après cela constituent votre maintenance, ou le support technique étendu si vous l'achetez.

Nous documentons comment lire l'état de PaymentIntent, les journaux du tableau de bord Stripe et la livraison du webhook Django. L'assistance de 30 jours comprend le dépannage des échecs de signature, des tentatives et des clés mal configurées pour le flux Django fourni.

Nous confirmons vos versions Django et Python par rapport à la version Stripe que nous épinglons au moment de l'intégration. Les environnements d'exécution Django plus anciens ou fortement fourchus peuvent nécessiter une portée supplémentaire.

30 jours après la remise sont inclus pour le chemin Django Stripe livré. Le support technique étendu est facultatif à 20 % du prix de ce module complémentaire Django et couvre six mois supplémentaires d'assistance technique sur cette même intégration Django, et non sur une nouvelle version de produit.