Liste des modifications de Elements avec l'API Checkout SessionsAperçu public

Suivez les modifications apportées à Elements grâce à l’intégration de l’API Checkout Sessions.

L’API Elements with Checkout Sessions utilise deux types de versions bêta :

Un en-tête bêta Stripe.js (par exemple, custom_checkout_beta_5), qui est défini dans votre intégration frontale.
Un en-tête bêta de l’API (p. ex., custom_checkout_beta=v1), défini dans l’application dorsale de votre intégration.

Versions bêta dorsales

Indiquez la version bêta de l’application frontale lors de l’initialisation de Stripe.js.

custom_checkout_beta_5

Breaking La fonction initCustomCheckout a été renommée initCheckout
- Dans React Stripe.js, CustomCheckoutProvider a été renommé à CheckoutProvider et useCustomCheckout a été renommé à useCheckout.
Breaking Pour confirmer Express Checkout Element, appelez la confirmation, en transmettant l’événement de confirmation comme expressCheckoutConfirmEvent
- Auparavant, Express Checkout Element était confirmé en faisant appel à event.confirm().
Breaking Lorsque la confirmation est appelée, 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é normalisé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 communiqués à votre client en affichant le message sur la page de paiement.
- Les erreurs envoyées/rejetées par une fonction représentent des erreurs dans l’intégration elle-même, telles que des paramètres ou une configuration non valides. Ces erreurs ne sont pas destinées à être affichées à vos clients.
Breaking Les méthodes asynchrones, telles que confirm ou applyPromotionCode, se résolvent avec un schéma différent :
- Un champ discriminateur type="success"|"error" a été ajouté.
- En cas de réussite, l’état de la session mise à jour est indiqué sous la clé success. Auparavant, il était indiqué sous la clé session.
- Dans le cas contraire, l’erreur continue d’être renseignée sous la clé error.
Ajout des options email, phoneNumber, billingAddress, et shippingAddress à confirmer.
Breaking L’Address Element ne met plus automatiquement à jour les champs billingAddress ou shippingAddress de la session.
- Tant que l’Address Element est monté, les valeurs de formulaire seront automatiquement utilisées lors de l’appel de confirmation.
- Écoutez l’événement de changement pour utiliser la valeur de l’Address Element avant la confirmation.

custom_checkout_beta_4

Ajout d’images à l’objet Session.
Ajout de champs comme option lors de la création du composant Payment Element.
Ajout de paymentMethods comme option lors de la création du composant Express Checkout Element.
Breaking La transmission d’options non valides à createElement provoque désormais une erreur. Auparavant, les options non reconnues étaient ignorées.
Breaking updateEmail et updatePhoneNumber appliquent les modifications de manière asynchrone. L’appel de ces méthodes avant que le client n’ait fini de saisir des valeurs complètes peut entraîner de faibles performances.
- Au lieu d’appeler updateEmail ou updatePhoneNumber lors de l’événement de modification de chaque saisie, attendez que votre client ait terminé la saisie, par exemple lorsque le focus est retiré de la saisie ou lorsqu’il soumet le formulaire pour paiement.
- updateEmail valide désormais la saisie comme étant une adresse de courriel correctement formatée et renvoie une erreur en cas de saisie non valide.
- updatePhoneNumber ne valide toujours pas la chaîne de caractères saisie.

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 les moyens de paiement.
Breaking L’affichage par défaut du composant Payment Element a été modifié par accordion.
- Pour continuer à utiliser l’ancienne mise en page par défaut, vous devez explicitement spécifier layout='tabs'.
Breaking Le comportement par défaut de confirm a été modifié pour toujours rediriger vers votre return_url après une confirmation de réussite du paiement.
- Auparavant, confirm ne redirigeait le client que s’il choisissait un moyen de paiement basé sur la redirection. Pour continuer à utiliser l’ancien comportement, vous devez transmettre redirect=‘if_required’ sur confirm.

custom_checkout_beta_2

Breaking Le champ lineItem.recurring.interval_count a été retiré et remplacé par lineItem.recurring.intervalCount.
Breaking Le champ lineItem.amount a été supprimé et remplacé par le champ suivant :

custom_checkout_beta_1

Il s’agit de la version bêta frontale initiale.

Journal des modifications de l’application dorsale

Indiquez la version bêta de l’application dorsale lors de la configuration de la bibliothèque de votre serveur.

Il n’y a aucun changement dans la version bêta de l’application dorsale.