Elements con el registro de cambios de la API Checkout SessionsVista previa pública

Mantente al día de los cambios en Elements con la integración de la API Checkout Sessions.

Elements con la API Checkout Sessions utiliza dos tipos de versiones beta:

Un encabezado de Stripe.js beta (p. ej., custom_checkout_beta_5), que se configura en tu integración de front end.
Un encabezado beta de la versión de la API (p. ej., custom_checkout_beta=v1), que está configurado en tu integración de back end.

Versiones beta del front end

Especifica la versión beta del front end al inicializar Stripe.js.

custom_checkout_beta_5

Breaking Se ha cambiado el nombre de la función initCustomCheckout a initCheckout
- Dentro de React Stripe.js, a CustomCheckoutProvider se le ha cambiado el nombre por CheckoutProvider y a useCustomCheckout se le ha cambiado el nombre por useCheckout.
Breaking Para confirmar el Express Checkout Element, llama a confirm y especifica el evento de confirmación como expressCheckoutConfirmEvent
- Anteriormente, el Express Checkout Element se confirmaba llamando a event.confirm().
Breaking Al llamar a confirm, el Payment Element y el Address Element validarán las entradas del formulario y mostrarán los errores.
Breaking Los mensajes de error se han estandarizado y mejorado.
- Los errores devueltos/resueltos por una función representan escenarios conocidos, como datos de pago no válidos o fondos insuficientes. Estos son problemas predecibles que se le pueden comunicar a tu cliente mostrándole el message en la página del proceso de compra.
- Los errores arrojados/rechazados por una función representan errores en la propia integración, como parámetros o configuraciones no válidos. Estos errores no están pensados para mostrárselos a los clientes.
Breaking Los métodos asincrónicos, como confirm o applyPromotionCode, se resuelven con un esquema diferente:
- Se ha añadido un campo discriminador type="success"|"error".
- Si se realiza correctamente, el estado actualizado de la sesión se rellena con la clave success. Anteriormente, era con la clave session.
- De lo contrario, el error se sigue rellenando debajo de la clave error.
Se han añadido las opciones email, phoneNumber, billingAddress y shippingAddress a confirm.
Breaking El Address Element ya no actualiza automáticamente los campos billingAddress o shippingAddress en la Sesión.
- Siempre que el Address Element esté montado, los valores del formulario se usarán automáticamente al llamar a confirm.
- Escucha el evento de cambio para usar el valor del Address Element antes de la confirmación.

custom_checkout_beta_4

Se han añadido imágenes al objeto Session.
Se ha añadido fields como opción al crear el Payment Element.
Se ha añadido paymentMethods como opción al crear el Express Checkout Element.
Breaking Si se pasan opciones no válidas a createElement, ahora se produce un error. Anteriormente, las opciones no reconocidas se ignoraban sin ningún otro efecto.
Breaking updateEmail y updatePhoneNumber aplican los cambios de forma asincrónica. Llamar a estos métodos antes de que el cliente termine de introducir los valores completos puede provocar un rendimiento deficiente.
- En lugar de llamar a updateEmail o updatePhoneNumber en cada evento de modificación de entrada, espera hasta que tu cliente finalice la entrada, por ejemplo, en el desenfoque de entrada o cuando envíe el formulario para el pago.
- updateEmail ahora valida que la entrada sea una dirección de correo electrónico con el formato correcto y devuelve un error si se utiliza una entrada no válida.
- updatePhoneNumber sigue sin realizar ninguna validación en la cadena de entrada.

custom_checkout_beta_3

Se han añadido los siguientes campos al objeto Session:
Ahora se pueden reutilizar las tarjetas guardadas. Descubre cómo guardar y reutilizar los métodos de pago.
Breaking El diseño predeterminado del Payment Element se ha cambiado a accordion.
- Para seguir utilizando el diseño predeterminado anterior, debe especificar layout='tabs' explícitamente.
Breaking Se ha cambiado el comportamiento predeterminado de confirm para que siempre se redirija a tu return_url después de una confirmación correcta.
- Hasta ahora, confirm solo se redireccionaba si el cliente elegía un método de pago basado en redireccionamiento. Para continuar usando el comportamiento anterior, debes pasar el redireccionamiento=‘if_required’ a confirm.

custom_checkout_beta_2

Breaking El campo lineItem.recurring.interval_count se ha quitado y se ha reemplazado por lineItem.recurring.intervalCount.
Breaking Se ha eliminado el campo lineItem.amount y se ha sustituido por el siguiente:

custom_checkout_beta_1

Esta es la versión beta inicial del front end.

Registro de cambios de back end

Especifica la versión beta del back end cuando configures la biblioteca de tu servidor.

No hay cambios en la versión beta del back end.