Log des modifications de la version bêta d'Elements avec l'API Checkout Sessions
Suivez les modifications apportées à Elements grâce à l'intégration bêta de l'API Checkout Sessions.
Avertissement
Ce document contient les listes des modifications relatives aux versions bêta d’Elements avec l’API Checkout Sessions.
Si vous utilisez déjà la version Basil d’Elements avec l’API Checkout Sessions, ce document ne s’applique pas à vous.
Migration vers Basil
Modifications
- Breaking Les méthodes asynchrones, telles que confirm ou applyPromotionCode, sont résolues avec un schéma différent :
- En cas de réussite, le nouvel état de la session est renseigné sous la clé
session
. Auparavant, cette information se trouvait sous la clésuccess
.
- En cas de réussite, le nouvel état de la session est renseigné sous la clé
- Breaking Une erreur est désormais générée lors de la transmission de returnUrl sur confirm lorsque return_url a déjà été défini sur la session Checkout.
- Breaking L’URL de redirection utilisée après une confirmation réussie présentait auparavant des paramètres de requête incohérents. Les paramètres supplémentaires sont désormais supprimés et l’URL ne contient que ce qui est fourni dans returnUrl sur confirm ou return_url sur la session Checkout.
- Breaking Améliore le temps de latence de l’API Checkout Session pour les sessions en mode abonnement et corrige un bogue qui empêchait vos clients de mettre à jour une session après la première tentative de paiement.
- La modification crée l’abonnement une fois que l’utilisateur a effectué le paiement, de sorte que
payment_
présente la valeurintent. invoice null
jusqu’à la fin de la session Checkout. - Nous vous recommandons d’utiliser le webhook
checkout_
si vous utilisez actuellementsession. completed payment_
, qui garantit la présence deintent. invoice payment_
.intent. invoice - Pour en savoir plus, consultez la liste des modifications de l’API.
- La modification crée l’abonnement une fois que l’utilisateur a effectué le paiement, de sorte que
- Ajout de percentOff à discountAmounts en tant qu’option d’affichage des remises.
Mise à niveau
Avant de migrer vers Basil, commencez par mettre à jour votre intégration sur custom_
.
- Si vous utilisez des paquets NPM Stripe, vous devez d’abord mettre à niveau
@stripe/stripe-js
vers la version7.
, et0. 0 @stripe/react-stripe-js
vers la version3.
(ou une version supérieure).6. 0 - Si vous chargez Stripe.js à l’aide de la balise de script, mettez à jour la balise de script pour qu’elle utilise Stripe.js versionné en remplaçant la balise comme suit :
<head> <title>Checkout</title> <script src="https://js.stripe.com/v3"></script> <script src="https://js.stripe.com/basil/stripe.js"></script> </head>
- Supprimez l’en-tête bêta de Stripe.js lors de l’initialisation de Stripe.js.
- Supprimez l’en-tête bêta de la version de l’API et spécifiez que la version de l’API doit être au moins
2025-03-31.
sur votre intégration back-end.basil
Journal des modifications, version bêta
Elements avec la bêta de l’API Checkout Sessions utilise deux types de versions bêta :
- Un en-tête bêta Stripe.js (par exemple,
custom_
), qui est défini sur votre intégration front-end.checkout_ beta_ 6 - Un en-tête de version bêta d’API (par exemple,
custom_
), qui est défini sur votre intégration de back-end.checkout_ beta=v1
Versions bêta du front-end
Spécifiez la version bêta du front-end lors de l’initialisation de Stripe.js.
custom_checkout_beta_6
Si vous utilisez des paquets NPM Stripe, vous devez d’abord mettre à niveau @stripe/stripe-js
vers la version 6.
, et @stripe/react-stripe-js
vers la version 3.
(ou une version supérieure).
- Breaking Le signe de total.appliedBalance a été inversé. Un nombre positif augmente désormais le montant à payer, tandis qu’un nombre négatif le diminue.
- Breaking Remplacement de
clientSecret
par fetchClientSecret. Mettez à jour votre intégration de manière à transmettre une fonction asynchrone aboutissant à la clé secrète du client au lieu de transmettre une valeur statique. - Breaking Les méthodes Elements ont été renommées.
- Si vous utilisez React Stripe.js, vous n’avez rien d’autre à faire que de mettre à niveau
@stripe/react-stripe-js
. - Si vous utilisez HTML/JS :
- Utilisez
createPaymentElement()
au lieu decreateElement('payment')
. - Utilisez
createBillingAddressElement()
au lieu decreateElement('address', {mode: 'billing'})
. - Utilisez
createShippingAddressElement()
au lieu decreateElement('address', {mode: 'shipping'})
. - Utilisez
createExpressCheckoutElement()
au lieu decreateElement('expressCheckout')
. - Utilisez
getPaymentElement()
au lieu degetElement('payment')
. - Utilisez
getBillingAddressElement()
au lieu degetElement('address', {mode: 'billing'})
. - Utilisez
getShippingAddressElement()
au lieu degetElement('address', {mode: 'shipping'})
. - Utilisez
getExpressCheckoutElement()
au lieu degetElement('expressCheckout')
.
- Utilisez
- Si vous utilisez React Stripe.js, vous n’avez rien d’autre à faire que de mettre à niveau
- Breaking Mise à jour des champs liés à la confirmation pour refléter plus précisément l’état de la session.
- canConfirm répond désormais à tout composant Billing Address Element ou Shipping Address Element monté.
- canConfirm devient désormais
false
en cas de confirmation à la volée. - Suppression de
confirmationRequirements
.
- Breaking updateEmail génère désormais une erreur si customer_email a été fourni lors de la création de la session Checkout. Si vous avez l’intention de préremplir une adresse e-mail que votre client pourra modifier, appelez
updateEmail
dès le chargement de la page au lieu de transmettrecustomer_
.email - Breaking returnUrl doit être une URL absolue (par exemple une adresse commençant par
https://
, par opposition à une URL relative, comme/success
). - Breaking Les champs de tarification ont été modifiés en un objet imbriqué pour faciliter l’affichage.
- Les valeurs numériques ont été remplacées par un objet contenant les attributs
amount
(une chaîne de devise formatée, par exemple$10.
) et00 minorUnitsAmount
, un entier représentant la valeur dans la plus petite unité de la devise. Si vous lisez déjà le montant, lisez-le plutôt à partir deminorUnitsAmount
.- Remplacez par exemple
total.
partotal total.
.total. minorUnitsAmount
- Remplacez par exemple
- Vous devez lire soit
total.
, soit l’ensemble des attributstotal. amount total.
,total. minorUnitsAmount currency
etminorUnitsAmountDivisor
de l’objetcheckout
, et les afficher dans votre interface utilisateur, sinon une erreur sera générée. Cela permet de synchroniser votre page de paiement avec toutes les mises à jour de CheckoutSession, y compris tout ajout de nouvelles fonctionnalités par Stripe, avec des modifications minimes du code de votre interface utilisateur.
- Les valeurs numériques ont été remplacées par un objet contenant les attributs
- Il est désormais possible de collecter les numéros fiscaux des clients. Découvrez comment collecter les numéros fiscaux.
- Un assistant spécifique au mode test est désormais disponible au bas de votre page de paiement. Il vous propose des conseils pour votre intégration et des raccourcis pour des scénarios de test courants.
custom_checkout_beta_5
- Breaking La fonction
initCustomCheckout
a été renommée initCheckout- Dans React Stripe.js,
CustomCheckoutProvider
a été renomméCheckoutProvider
etuseCustomCheckout
a été renomméuseCheckout
.
- Dans React Stripe.js,
- Breaking Pour confirmer l’Express Checkout Element, appelez confirm, en transmettant l’événement confirm comme
expressCheckoutConfirmEvent
- Auparavant, l’Express Checkout Element était confirmé par un appel à
event.
.confirm()
- Auparavant, l’Express Checkout Element était confirmé par un appel à
- Breaking Lorsque confirm est appelé, le Payment Element et l’Address Element valident les entrées de formulaire et affichent les erreurs éventuelles.
- Breaking Les messages d’erreur ont été standardisés et améliorés.
- Les erreurs renvoyées/résolues par une fonction représentent des scénarios connus, tels que des informations de paiement non valides ou des fonds insuffisants. Il s’agit de problèmes prévisibles qui peuvent être signalés au client en affichant le
message
sur la page de paiement. - Les erreurs renvoyées/rejetées par une fonction représentent des erreurs dans l’intégration elle-même, telles que des paramètres ou des configurations non valides. Ces erreurs ne sont pas destinées à être transmises à vos clients.
- Les erreurs renvoyées/résolues par une fonction représentent des scénarios connus, tels que des informations de paiement non valides ou des fonds insuffisants. Il s’agit de problèmes prévisibles qui peuvent être signalés au client en affichant le
- Breaking Les méthodes asynchrones, telles que confirm ou applyPromotionCode, sont résolues avec un schéma différent :
- Un champ discriminant
type="success"|"error"
a été ajouté. - En cas de réussite, le nouvel état de la session est renseigné sous la clé
success
. Auparavant, cette information se trouvait sous la clésession
. - Dans le cas contraire, l’erreur continue d’être renseignée sous la clé
error
.
- Un champ discriminant
- Ajout des options
email
,phoneNumber
,billingAddress
etshippingAddress
à confirm. - Breaking L’Address Element ne met plus automatiquement à jour les champs billingAddress et shippingAddress de la session.
- Tant que l’Address Element est monté, les valeurs du formulaire seront automatiquement utilisées lors de l’appel de confirm.
- Écoutez l’événement de modification pour utiliser la valeur de l’Address Element avant confirmation.
custom_checkout_beta_4
- Ajout d’images à l’objet Session.
- Added fields as an option when creating the Payment Element.
- Added paymentMethods as an option when creating the Express Checkout Element.
- Majeur Passing invalid options to createElement now throws an error. Previously, unrecognized options would be silently ignored.
- Breaking updateEmail et updatePhoneNumber appliquent les modifications de manière asynchrone. L’appel de ces méthodes avant que le client n’ait fini d’entrer des valeurs complètes peut nuire aux performances.
- Au lieu d’appeler
updateEmail
ouupdatePhoneNumber
à chaque événement de modification d’entrée, attendez que votre client ait terminé la saisie, par exemple quand l’utilisateur clique en dehors du champ de saisie ou quand il envoie le formulaire pour paiement. updateEmail
valide désormais que l’entrée est une adresse e-mail correctement formée et renvoie une erreur si une entrée non valide est utilisée.updatePhoneNumber
n’effectue toujours aucune validation sur la chaîne d’entrée.
- Au lieu d’appeler
custom_checkout_beta_3
- Les champs suivants ont été ajoutés à l’objet Session :
- Les cartes enregistrées peuvent désormais être réutilisées. Découvrez comment enregistrer et réutiliser des moyens de paiement.
- Breaking La disposition par défaut de Payment Element a été remplacée par
accordion
.- Pour continuer à utiliser la mise en page par défaut précédente, vous devez spécifier explicitement
layout='tabs'
.
- Pour continuer à utiliser la mise en page par défaut précédente, vous devez spécifier explicitement
- Breaking Le comportement par défaut de confirm a été modifié pour toujours rediriger vers votre
return_
après une confirmation réussie.url - Auparavant,
confirm
redirigeait uniquement si le client choisissait un moyen de paiement avec redirection. Pour continuer à utiliser l’ancien comportement, vous devez basculer redirect=‘if_required’ surconfirm
.
- Auparavant,
custom_checkout_beta_2
- Breaking Le champ
lineItem.
a été supprimé et remplacé par lineItem.recurring.intervalCount.recurring. interval_ count - Breaking Le champ
lineItem.
a été supprimé et remplacé par le suivant :amount
custom_checkout_beta_1
Il s’agit de la version bêta initiale du front-end.
Log des modifications du back-end
Spécifiez la version bêta du back-end lors de la configuration de la bibliothèque de votre serveur.
Aucun changement n’a été apporté à la version bêta du back-end.