Configurer de futurs paiements par carte
Utilisez la confirmation manuelle côté serveur ou présentez les moyens de paiement séparément.
Avertissement
Nous vous recommandons de suivre le guide consacré à la configuration de paiements futurs, mais seulement si vous devez exécuter une confirmation manuelle côté serveur, ou si votre intégration vous oblige à présenter les moyens de paiement dans une étape distincte. Si vous avez déjà intégré Elements, consultez le guide de migration du composant Payment Element.
L’API Setup Intents vous permet d’enregistrer la carte d’un client sans paiement initial. Cette fonction est utile si vous souhaitez configurer des paiements dès l’inscription de vos clients afin de les débiter plus tard, lorsqu’ils sont hors ligne.
Utilisez cette intégration pour configurer des paiements récurrents ou pour créer des paiements ponctuels dont le montant doit être déterminé ultérieurement, généralement après réception du service par votre client.
Remarque
Les étapes de ce guide sont entièrement mises en œuvre sur GitHub. Clonez le référentiel et suivez les instructions pour exécuter l’application de démonstration.
Configurer Stripe
Pour commencer, vous devez créer un compte Stripe.
Côté serveur
Pour cette intégration, votre serveur doit disposer de endpoints qui communiquent avec l’API Stripe. Utilisez nos bibliothèques officielles pour accéder à l’API Stripe depuis votre serveur :
Côté client
Le SDK Stripe Android est disponible en open source et fait l’objet d’une documentation complète.
To install the SDK, add stripe-android
to the dependencies
block of your app/build.gradle file:
Remarque
Pour obtenir de plus amples informations sur la version la plus récente du SDK et ses versions antérieures, consultez la page des versions sur GitHub. Pour savoir quand une nouvelle version est disponible, surveillez les versions du référentiel.
Configurez le SDK avec votre clé publique Stripe de façon à ce qu’il puisse envoyer des requêtes à l’API Stripe, par exemple à la sous-classe Application
:
Créer un objet Customer avant la configurationCôté serveur
Pour configurer une carte bancaire en vue de paiements futurs, vous devez l’associer à un client. Lorsque votre client ouvre un compte chez vous, créez un objet Customer, qui permet de réutiliser des moyens de paiement et d’assurer le suivi de plusieurs paiements.
Lorsque la création aboutit, l’objet Customer est renvoyé. Vous pouvez l’examiner pour identifier l’id
du client et stocker cette valeur dans votre base de données pour la récupérer ultérieurement.
Vous pouvez trouver ces clients sur la page Clients du Dashboard.
Créer un SetupIntentCôté serveur
Un SetupIntent est un objet qui représente votre intention de configurer un moyen de paiement pour encaisser de futurs paiements.
Cet objet contient la clé secrète du client, une clé unique que vous devez transmettre à votre application. Cette clé vous permet de réaliser diverses actions sur le client, comme confirmer la configuration et mettre à jour les informations du moyen de paiement, tout en masquant des données sensibles comme l’attribut customer
. Vous pouvez également utiliser la clé secrète du client pour valider et authentifier les informations de carte par l’intermédiaire des réseaux de cartes de crédit. La clé secrète du client est une information sensible : ne la consignez pas, ne l’intégrez pas dans une URL et ne l’exposez à personne d’autre qu’au client.
Côté serveur
Sur votre serveur, créez un endpoint qui crée lui-même un SetupIntent et renvoie la clé secrète du client à votre application.
If you only plan on using the card for future payments when your customer is present during the checkout flow, set the usage parameter to on_session to improve authorization rates.
Côté client
Côté client, demandez un SetupIntent auprès de votre serveur.
Collecter les informations de carte bancaireCôté client
Lorsque votre client soumet le formulaire de paiement, collectez ses informations de carte à l’aide du CardInputWidget, un composant d’interface utilisateur prêt à l’emploi fourni par le SDK, qui collecte le numéro de carte, la date d’expiration, le CVC et le code postal.
CardInputWidget
effectue la validation et le formatage en temps réel.
Mise en garde
Lorsque vous enregistrez des informations de carte pour de futurs paiements hors session, demandez au client l’autorisation d’enregistrer sa carte. Ceci est particulièrement important en Europe, où s’applique une réglementation particulière sur la réutilisation des cartes. Pour cela, incluez dans votre tunnel de paiement un texte qui explique à l’utilisateur les conditions d’utilisation prévues de sa carte.
Appelez la méthode getPaymentMethodCard
pour récupérer les informations de carte bancaire de votre client. Transmettez les informations collectées à de nouvelles instances de PaymentMethodCreateParams et PaymentMethod.
pour créer une instance de ConfirmSetupIntentParams
.
Pour terminer la configuration, transmettez l’objet SetupIntentParams
avec l’activité en cours à la méthode confirm de PaymentLauncher. Le SetupIntent vérifie que les informations de carte de votre client sont valides sur le réseau. Toutefois, cette vérification automatique n’est pas systématique. Pour plus d’informations à ce sujet, consultez la page Vérifier la validité d’une carte bancaire sans la débiter. Par ailleurs, ne conservez pas trop longtemps des SetupIntents non gérés, car ils risquent de ne plus être valides lors de l’appel de la méthode PaymentLauncher#confirm()
.
Certains moyens de paiement requièrent des étapes d’authentification supplémentaires pour finaliser un paiement. Le SDK gère le flux de confirmation de paiement et d’authentification, ce qui peut impliquer d’afficher des écrans supplémentaires, nécessaires pour l’authentification. Pour plus d’informations sur l’authentification 3D Secure et la personnalisation de l’expérience d’authentification, consultez la page Prise en charge de l’authentification 3D Secure sur Android.
Le résultat du flux est renvoyé à votre activité appelante par le rappel fourni, ici onPaymentResult
. Le PaymentResult renvoyé par le PaymentLauncher présente les types suivants :
Completed
: confirmation ou authentification réussieCanceled
: le client a annulé l’authentification requiseFailed
: la tentative d’authentification a échoué, au motif indiqué par la propriété throwable
Vous disposez désormais d’un flux permettant de recueillir les informations de carte et de gérer les éventuelles demandes d’authentification. Utilisez la carte de test 4000 0025 0000 3155
, ainsi qu’un CVC, un code postal et une date d’expiration postérieure à la date du jour pour tester le processus d’authentification.
Lorsque le SetupIntent aboutit, l’ID PaymentMethod généré (dans setupIntent.
) est enregistré dans l’objet Customer fourni.
Débiter ultérieurement la carte enregistréeCôté serveur
Au moment de débiter votre client hors session, utilisez les ID de client et de PaymentMethod afin de créer un PaymentIntent. Pour trouver une carte à débiter, listez les PaymentMethods associés à votre client.
Lorsque vous avez les identifiants Client et PaymentMethod, créez un PaymentIntent avec le montant et la devise du paiement. Réglez quelques autres paramètres pour effectuer un paiement hors session :
- Assignez la valeur
true
à off_session afin d’indiquer que le client n’est pas dans votre tunnel de paiement lors de cette tentative de paiement. Si une authentification est requise, le PaymentIntent générera une erreur. - Assignez la valeur
true
à la propriété confirm du PaymentIntent, ce qui aura pour effet de générer immédiatement une confirmation lors de la création du PaymentIntent. - Renseignez l’ID du PaymentMethod dans payment_method et l’ID du client dans customer.
Inspectez la propriété d’état du PaymentIntent pour confirmer que le paiement a été effectué avec succès. Si la tentative de paiement a réussi, l’état du PaymentIntent est succeeded
et que le est terminé.
Démarrer un flux de récupération
Si l’état de l’objet PaymentIntent est différent, le paiement n’a pas abouti et la requête échoue. Invitez votre client à revenir dans l’application (par e-mail, SMS ou notification Push, par exemple) afin de terminer le paiement. Nous vous recommandons de créer dans votre application un flux de récupération indiquant le motif de l’échec du paiement initial et permettant au client de réessayer.
In your recovery flow, retrieve the PaymentIntent through its client secret. Check the PaymentIntent’s lastPaymentError to inspect why the payment attempt failed. For card errors, you can show the user the last payment error’s message. Otherwise, you can show a generic failure message.
Permettre au client de réessayer
Votre flux de récupération doit permettre au client de mettre à jour ou supprimer sa carte enregistrée et de réessayer le paiement. Suivez les mêmes étapes que pour l’acceptation du paiement d’origine, à une différence près : confirmez l’objet PaymentIntent d’origine qui a échoué en réutilisant sa clé secrète de client plutôt que d’en créer une nouvelle.
Si le paiement échoue parce qu’il nécessite une authentification, réessayez avec l’objet PaymentMethod existant plutôt que d’en créer un nouveau.
Tester l'intégration
À ce stade, vous devriez avoir une intégration qui :
- Collecte les informations de carte bancaire sans débiter le client avec un SetupIntent
- Débite la carte hors session et dispose d’un flux de récupération permettant de gérer les refus de paiement et les demandes d’authentification
Pour vérifier que votre intégration est prête, vous avez à votre disposition plusieurs cartes de test. Vous pouvez les utiliser en mode test avec n’importe quel CVC, code postal et date d’expiration non échue.
Numéro | Description |
---|---|
Transaction réussie et paiement effectué immédiatement. | |
Authentification requise pour l’achat initial, mais la transaction réussit pour les paiements suivants (y compris ceux effectués hors session) dès l’instant que la carte bancaire est configurée avec setup_ . | |
Exige l’authentification pour l’achat initial, et la transaction échoue pour les paiements suivants (y compris ceux effectués hors session) avec un code de refus de paiement authentication_ . | |
Exige l’authentification pour l’achat initial, mais la transaction échoue pour les paiements suivants (y compris ceux effectués hors session) avec un code de refus de paiement insufficient_ . | |
Échoue toujours (y compris pour l’achat initial) avec un code de refus de paiement insufficient_ . |
Voir la liste complète des cartes de test.