Transición a las API Payment Intents y Payment Methods
Descubre cómo pasar de las API Sources y Tokens a la API Payment Methods.
La API Payment Methods reemplaza a las API Tokens y Sources actuales y es la forma recomendada de integración para recopilar y guardar información de los pagos. Funciona con la API Payment Intents para crear pagos para diversos métodos de pago.
Tenemos previsto desactivar la compatibilidad con la API Sources para los métodos de pago locales. Si actualmente gestionas métodos de pago locales utilizando la API Sources, debes migrarlos a la API Payment Methods. Enviaremos comunicaciones por correo electrónico con más información sobre el fin de la compatibilidad con las API Sources y Tokens.
Aunque no planeamos desactivar la compatibilidad con los métodos de pago con tarjeta, te recomendamos que los migres a las API Payment Methods y Payment Intents. Para obtener más información sobre la migración de métodos de pago con tarjeta, consulta Migración a la API Payment Intents.
Migra los métodos de pago locales de la API Sources a la API Payment Intents
Para migrar tu integración a métodos de pago locales, actualiza tu servidor y tu front end para usar la API PaymentIntents. Hay tres opciones de integración típicas:
- Redirige a Stripe Checkout para tu flujo de pagos.
- Usa el Payment Element de Stripe en tu propia página de pago.
- Crea tu propio formulario y utiliza el SDK de Stripe JS para efectivizar el pago.
Si utilizas Stripe Checkout o Payment Element, puedes añadir y gestionar la mayoría de los métodos de pago desde el Dashboard de Stripe sin realizar cambios en el código.
Para obtener información específica sobre la integración de un método de pago local mediante la API Payment Methods, consulta las instrucciones para ese método de pago en la documentación de los métodos de pago. En la siguiente tabla se proporciona una comparación de alto nivel de los diferentes tipos de pago.
Integración anterior | Stripe Checkout | Payment Element | Formulario propio |
---|---|---|---|
Complejidad baja | Complejidad media | Complejidad alta | |
Crear una Source en el front-end o en el servidor | Crear una sesión de Checkout en el servidor | Crea un PaymentIntent en el servidor | Crea un PaymentIntent en el servidor |
Autorizar el pago cargando un widget o redirigiendo a un tercero | No es necesario | Pasa el secreto de cliente al front-end y usa el SDK de Stripe JS para renderizar un Payment Element con el fin de efectivizar el pago | Pasa el secreto de cliente al front-end, utiliza tu propio formulario para recoger los datos de tu cliente y efectiviza el pago de acuerdo con el método de pago |
Confirmar que la fuente acepta pagos y cobrar a Source | No es necesario | No es necesario | No es necesario |
Confirmar que el Charge se ha realizado correctamente de forma asíncrona con el webhook charge. | Confirmar que la sesión de Checkout se ha realizado correctamente con el webhook payment_ | Confirmar que el PaymentIntent se ha realizado correctamente con el webhook payment_ | Confirmar que el PaymentIntent se ha realizado correctamente con el webhook payment_ |
Precaución
Un objeto PaymentIntent representa un pago en la nueva integración y crea un Charge cuando confirmas el pago en el front-end. Si has almacenado previamente referencias al Charge, puedes continuar haciéndolo obteniendo el ID de Charge del PaymentIntent después de que el cliente efectivice el pago. Sin embargo, también te recomendamos que guardes el ID de PaymentIntent.
Comprobación del estado del pago
Anteriormente, tu integración debería haber verificado tanto el estado de Source como el estado de Charge después de cada llamada a la API. Ya no necesitas comprobar dos estados; solo necesitas comprobar el estado del PaymentIntent o de la sesión de Checkout después de confirmarlo en el front-end.
payment_intent.status | Significado | Instrucciones especiales |
---|---|---|
succeeded | El pago se ha efectuado correctamente. | No aplicable |
requires_ | El pago ha fallado. | No aplicable |
requires_ | El cliente no ha completado la autorización del pago. | Si el cliente no efectiviza el pago en el transcurso de 48 horas, el PaymentIntent pasará a requires_ y podrás volver a intentar la confirmación. |
Siempre confirma el estado del PaymentIntent buscándolo en tu servidor o escuchando los webhooks en tu servidor. No confíes únicamente en que el usuario regrese a la return_
que se proporciona cuando confirmas el PaymentIntent.
Reembolsos
Puedes seguir llamando a la API Refunds con un Charge que cree el PaymentIntent. Se puede acceder al ID de Charge en el parámetro latest_
.
Como alternativa, puedes proporcionar el ID de PaymentIntent a la API Refunds en lugar del Charge.
Administración de errores
Anteriormente, tenías que manejar los errores en Sources. Con PaymentIntents, en lugar de verificar si hay errores en Sources, verificas si hay errores en el PaymentIntent cuando se crea y después de que el cliente haya autorizado el pago. La mayoría de los errores en el PaymentIntent son del tipo invalid_
, devueltos en una petición inválida.
Cuando migres tu integración, ten en cuenta que los códigos de error de PaymentIntent pueden diferir de los códigos de error correspondientes de Sources.
Webhooks
Si anteriormente has escuchado eventos Source, es posible que tengas que actualizar la integración para escuchar nuevos tipos de eventos. En la siguiente tabla se muestran algunos ejemplos.
Webhook antiguo | Nuevo webhook en Checkout | Nuevo webhook en PaymentIntents | Instrucciones especiales |
---|---|---|---|
source. | No aplicable | No aplicable | |
source. | No aplicable | No aplicable | |
source. | No aplicable | No aplicable | |
charge. | checkout. | payment_ | También se envía el webhook charge. para que no tengas que actualizar la integración para escuchar el nuevo webhook. |
charge. | No se aplica: el cliente puede volver a intentar el pago en la misma sesión de Checkout hasta que caduque, momento en el que recibirás un evento checkout. . | payment_ | También se envía el webhook charge. charge.failed’ para que no tengas que actualizar la integración para escuchar el nuevo webhook. |
charge. | charge. | charge. |
Cómo hacer la transición a la API Payment Methods
La principal diferencia entre las API Payment Methods y Sources es que Sources describe el estado de la transacción a través de la propiedad status. Eso significa que cada objeto Source
debe pasar a un estado de cobro antes de poder usarlo para un pago. Por el contrario, un PaymentMethod
no tiene estado, ya que se basa en el objeto PaymentIntent para representar el estado del pago.
Nota
En la siguiente tabla, no se presenta una lista completa de métodos de pago. Si integras otros métodos de pago con la API Sources, debes migrarlos también a la API Payment Methods.
Flujos | Integra Payment Method con la API Payment Intents | Tokens o Sources con la API Charges |
---|---|---|
Tarjetas | Pagos con tarjeta | Aceptado en Tokens; no recomendado para Sources |
Adeudo directo ACH | Adeudos directos de cuentas bancarias de EE. UU. | Aceptado en Tokens. No aceptado en Sources |
Alipay | Pagos de Alipay | Obsoleto |
Bancontact | Pagos de Bancontact | Obsoleto |
EPS | Pagos de EPS | Obsoleto |
giropay | Pagos de giropay | Obsoleto |
iDEAL | Pagos de iDEAL | Obsoleto |
Klarna | Pagos de Klarna | Obsoleto |
Multibanco | Pagos con multibanco | Beta obsoleta |
Przelewy24 | Pagos de Przelewy24 | Obsoleto |
Débito directo SEPA | Adeudos directos de la Zona Única de Pagos en Euros | Obsoleto |
Sofort | Pagos de Sofort | Obsoleto |
WeChat Pay | Pagos de WeChat Pay | Obsoleto |
Después de elegir la API con la que integrarte, utiliza la guía de métodos de pago para ayudarte a determinar los tipos de métodos de pago adecuados que necesitas admitir.
Esta guía incluye descripciones detalladas de cada método de pago y describe las diferencias en los flujos orientados al cliente, junto con las regiones geográficas en las que son más relevantes. Puedes activar cualquier método de pago disponible en el Dashboard. La activación es generalmente instantánea y no requiere contratos adicionales.
Compatibilidad con métodos de pago reutilizables heredados
Si anteriormente procesaste alguno de los siguientes métodos de pago reutilizables con Sources, las fuentes guardadas existentes no migran automáticamente:
- Alipay
- Adeudo directo Bacs
- Débito directo SEPA
Para conservar los métodos de pago guardados de tus clientes existentes, debes convertir esas fuentes en métodos de pago utilizando una herramienta de migración de datos en el Dashboard de Stripe. Para obtener instrucciones sobre cómo convertirlas, consulta la página de soporte.
Compatibilidad con objetos de tarjetas heredados
Si anteriormente recopilaste datos de pago de clientes con tarjeta con Stripe usando tarjetas o Sources, puedes empezar a usar la API Payment Methods de inmediato sin migrar ninguna información de pago.
Los instrumentos de pago compatibles que están guardados en un objeto Customer se pueden utilizar en cualquier API que acepte objetos PaymentMethod. Por ejemplo, puedes utilizar una tarjeta guardada como PaymentMethod al crear el PaymentIntent:
No olvides indicar el ID del cliente que tiene guardado el instrumento de pago compatible al asociar el objeto con el PaymentIntent.
Puedes recuperar todos los instrumentos de pago compatibles guardados a través de la API Payment Methods.
Con esta compatibilidad, no se crean objetos nuevos; la API Payment Methods proporciona una vista diferente del mismo objeto subyacente. Por ejemplo, las actualizaciones realizadas en un instrumento de pago compatible a través de la API Payment Methods se pueden ver a través de la API Sources y viceversa.