En el dinámico mundo del e-commerce, las plataformas de pago online se han convertido en un pilar fundamental. No solo facilitan transacciones rápidas y seguras, sino que también han transformado la experiencia de compra, haciéndola más accesible y amigable para el usuario. Esta evolución ha sido impulsada por la necesidad de adaptarse a un mercado cada vez más globalizado y digitalizado. En este contexto, Stripe no es solo una herramienta, sino que es todo un ecosistema de gestión de pagos. Su flexibilidad y enfoque en la experiencia de usuario lo posicionan como un actor relevante en el panorama actual de las soluciones de pago online
Stripe tiene la ventaja de que, a nivel de documentación para desarrolladores, es una de las mejores documentaciones que hemos visto jamás y aparte tiene un montón de productos avanzados de cobro, como Connect para la creación de plataformas en las que tengamos que cobrar una parte en la plataforma y pagar una comisión a un proveedor, por ejemplo, o al revés, que el cobro lo haga el proveedor directamente y la plataforma se quede una comisión (que es como funcionan Uber y similares).
Otras plataformas
Hay otras plataformas, claro, no solo está Stripe, nosotros en concreto hace años habíamos usado mucho Adyen.
PayPal, por ejemplo, es super reconocido y aceptado, especialmente por su facilidad de uso y seguridad, pero a nivel desarrollo e introducción de nuevas funcionalidades se ha quedado muy anticuado.
Square sobresale por sus soluciones físicas de punto de venta, ideales para negocios que combinan ventas en línea y en tienda.
Adyen, por otro lado, ofrece una solución global de pago, apreciada por su capacidad de manejar transacciones en diversos mercados y monedas, lo que la hace ideal para empresas con una fuerte presencia internacional y en conjunto es la más parecida a Stripe en cuanto a capacidades más allá de un simple procesador de pagos, pero la documentación y la facilidad de uso para desarrolladores es mucho mayor la de Stripe.
Existen más, claro está, pero no es este un artículo en el que queramos comparar métodos de pago, si no introducir algunas formas de personalización del pago con Stripe.
Aunque podemos ir documentando por aquí los casos más habituales que nos encontramos, hoy explicamos un caso que no está muy bien detallado en la documentación y no hemos encontrado muchas referencias en la web.
El método recomendado ahora mismo por Stripe para introducir un pago en una web, cuando no se quiere hacer con alguna de las opciones no-code que da el propio Stripe (su checkout por ejemplo), porque son URL's de Stripe y queremos hacer algo propio, es usar un Payment Element con un Payment Intent o un Setup Intent.
Payment Intent vs Setup Intent
En el uso de Stripe, distinguimos claramente entre Setup Intent y Payment Intent, dos herramientas con propósitos específicos. El Setup Intent se utiliza para configurar los detalles de pago, como la tarjeta de crédito, para cobros futuros. Esta herramienta es ideal para escenarios donde el cliente espera realizar pagos recurrentes o suscripciones. Durante este proceso, no se realiza un cobro inmediato, sino que se prepara el terreno para una experiencia de pago ágil en transacciones futuras.
El Payment Intent, por otro lado, se centra en ejecutar pagos en el momento. Esta funcionalidad es crucial para transacciones únicas o compras instantáneas. Además de la inmediatez en el cobro, Payment Intent ofrece la posibilidad de guardar la información de la tarjeta para futuros pagos mediante el parámetro 'setup_future_usage' establecido en 'off_session'. Esto es especialmente útil para negocios que buscan equilibrar transacciones inmediatas con la posibilidad de retener clientes para futuras compras.
Más allá de estas diferencias básicas, es importante considerar el flujo de trabajo de cada uno. Por ejemplo, el Setup Intent requiere una interacción inicial con el cliente para obtener su consentimiento y almacenar sus detalles de pago de manera segura. Esto se alinea con las normativas de seguridad de datos y PCI Compliance, asegurando que la información del cliente se maneje de manera segura y confidencial.
En contraste, el Payment Intent se puede utilizar en un entorno más dinámico y directo. Por ejemplo, en un e-commerce tradicional donde el cliente selecciona productos y procede al pago inmediato. Aquí, la simplicidad y rapidez son clave, y Payment Intent permite una transacción fluida sin pasos adicionales para la configuración de pagos futuros.
Payment Element por defecto
De lo que queríamos hablar se da al utilizar el Payment Element con su configuración por defecto, en España algo como así:
Las pestañas de arriba son configurables en función de los métodos de pago que tengamos habilitados y el tipo de cobro que vayamos a hacer (podemos hacer un intent en modo suscripción, y no tendríamos disponibles métodos de pago que no sirvan para suscripciones, por ejemplo).
En la documentación hay bastante detalle de cómo cambiar el aspecto, especialmente puedes cambiar de pestañas a acordeón cómo salen los métodos de pago, y luego temas estéticos para adaptarlo a la página en la que vayas a utilizarlo.
Personalizar Element y quitar country
El problema viene cuando en España en general nadie pide el país a la hora de pagar, en el campo de tarjeta. Sobre todo porque es un campo que sueles solicitar en otro momento del ecommerce, o porque has registrado al usuario, o porque vas a hacerle un envío. Este campo en el caso de Stripe es parte de un objeto que se llama billing_details y sería algo así como los detalles de facturación.
const elements = stripe.elements(options);
const optionsPayment = {
defaultValues: {
billingDetails: {
address: {
country: 'ES'
}
}
},
fields: {
billingDetails: {
address: {
country: 'never',
postalCode: 'auto'
}
}
},
layout: {
type: 'accordion', // or tabs
defaultCollapsed: true,
radios: false
},
};
// Create and mount the Payment Element
const paymentElement = elements.create('payment', optionsPayment);
paymentElement.mount('#payment-element');Aquí creamos unas opciones para el PaymentElement en las que definimos que el country no tiene que pedirlo nunca y que el postalcode será automático.
También en este caso hay unas opciones para mostrar los métodos de pago en acordeón.
Una vez hecho esto, a la hora de confirmar el pago, habrá que pasarle el país (en este caso le estamos pasando siempre España, pero podríamos leerlo de otro campo del usuario, como el envío).
En caso de no pasar el country o no tener el postalcode como automático, podemos recibir un error:
Uncaught (in promise) IntegrationError: You specified "never" for fields.billing_details.address.country when creating the payment Element, but did not pass confirmParams.payment_method_data.billing_details.address.country when calling stripe.confirmPayment(). If you opt out of collecting data via the payment Element using the fields option, the data must be passed in when calling stripe.confirmPayment()
Que básicamente viene a decir que le hemos dicho que no pregunte por el país ni el código postal, porque ya los teníamos de otro sitio, pero no se los estamos pasando en la confirmación del pago, y es necesario hacerlo, tal y como mostramos aquí abajo.
const {error} = await stripe.confirmPayment({
elements,
clientSecret,
confirmParams: {
return_url: URLTORETURN,
payment_method_data: {
billing_details: {
address: {
country: 'ES',
}
}
},
},
});