Checkout alojado y API: cómo elegir la integración

Un checkout alojado y una integración por API pueden formar parte de la misma solución de pago. El checkout describe dónde paga el cliente; la API, cómo se comunican tu aplicación y el sistema de cobro. En AndorPay, tu servidor puede crear una sesión mediante API y enviar al comprador a la página alojada que devuelve la respuesta.

Si estás preparando pagos para una empresa de Andorra, la decisión útil es qué experiencia necesitas y qué parte del desarrollo mantendrá tu equipo. Esta guía compara esos trabajos y explica cómo elegir un recorrido sin asumir que usar una API obliga a construir toda la pantalla de pago.

Tres conceptos para tomar la decisión

Un checkout alojado es una página de pago preparada y servida por la plataforma. Tu negocio dirige al comprador hacia esa página con la compra ya identificada. Después utiliza la confirmación para continuar la venta.

Una API es el contrato de comunicación entre sistemas. Sirve, por ejemplo, para crear esa sesión o consultar recursos. La interfaz que ve el comprador y la comunicación del servidor son decisiones relacionadas, pero distintas.

Un plugin adapta la conexión a una plataforma concreta. Nuestro plugin WooCommerce relaciona el pedido con AndorPay y presenta los métodos disponibles en su recorrido habitual. Puede ahorrar trabajo específico de la tienda porque ya conoce sus datos y estados.

Qué hace tu aplicación con un checkout alojado

Primero identifica la compra y el cliente. Después solicita una sesión con los datos requeridos. La respuesta contiene la dirección que debe abrir el comprador. La guía REST de AndorPay documenta ese recorrido.

Tu aplicación conserva la relación entre la compra y la sesión. Cuando recibe un resultado confirmado, aplica la acción de negocio: preparar un pedido, entregar un recurso o activar el acceso correspondiente. La página de pago se ocupa de su paso dentro de esa venta.

Este reparto permite utilizar una pantalla preparada sin perder la conexión con la operación. Sigue habiendo desarrollo en tu servidor y en la gestión posterior. La ventaja es delimitar ese trabajo a la relación con tu producto, en lugar de asumir que debes construir cada componente de la autorización.

Qué trabajo conserva el comercio

El negocio decide qué se vende, quién compra, qué información necesita y qué entrega después. En una aplicación propia, esas reglas deben representarse en sus datos y procesos. La plataforma de cobro no puede deducir las condiciones de acceso de un servicio a partir de una redirección.

También necesitas comunicar el estado al comprador. Una confirmación clara incluye la compra reconocible y el siguiente paso. Si el pago está pendiente, la aplicación debe tratar esa espera de forma distinta a un rechazo o a una venta terminada.

Finalmente, alguien debe atender incidencias. Conserva referencias de pedido y pago para que la persona que recibe una consulta encuentre la operación. Esta necesidad existe con una página alojada y con una experiencia integrada en la tienda.

Si ya utilizas WooCommerce

Empieza por el plugin antes de plantear un desarrollo independiente. Nuestro recorrido mantiene productos y cálculos en WooCommerce y utiliza las líneas y referencias del pedido. No necesitas crear otro catálogo en AndorPay para esa integración.

Revisa las personalizaciones del checkout, envíos y campos. El plugin resuelve la conexión documentada, pero la prueba debe incluir los cambios particulares de tu tienda. Si otra herramienta recibe las ventas para preparar pedidos, incorpora ese paso al recorrido.

La guía de WooCommerce explica la configuración vigente. El objetivo de elegir un plugin es aprovechar una adaptación existente y comprobarla en tu instalación. No elimina la necesidad de mantenerlo actualizado ni de revisar la compra después de modificar extensiones relevantes.

Si tienes una aplicación propia

Elige el punto en el que se crea la compra y un servidor responsable de comunicarse con AndorPay. La clave de API permanece en ese servidor. El navegador recibe la dirección de checkout, no el secreto utilizado para crearla.

La aplicación abre la dirección devuelta por la API. No conviene construirla manualmente porque pertenece a una sesión concreta con sus datos y caducidad. El contrato documentado permite manejar esa respuesta sin depender del formato interno de la dirección.

Después integra la confirmación del pago. La guía de webhooks explica cómo verificar las notificaciones y relacionarlas con tu sistema. El SDK o lenguaje que utilices ayuda a implementar la conexión; el diseño del estado de tu producto sigue siendo responsabilidad de la aplicación.

Cómo cambia el reparto de mantenimiento

Con una página alojada, tu equipo mantiene la creación de sesiones, el paso hacia el pago, la recepción de eventos y la entrega. La plataforma mantiene la pantalla de pago correspondiente a ese recorrido. La integración debe continuar respetando el contrato utilizado.

Con un plugin, parte de esa adaptación está implementada para la tienda. Tu trabajo se concentra en la configuración, las versiones y la convivencia con otras extensiones. Las actualizaciones necesitan una comprobación del recorrido que utiliza tu negocio.

Una experiencia desarrollada más a medida puede aumentar la superficie que debe mantener tu equipo. Antes de asumirla, concreta qué diferencia necesita realmente el comprador y si está disponible en la conexión elegida. Personalizar más elementos solo aporta valor cuando resuelve una necesidad de la venta.

Qué comparar antes de elegir

El contexto que necesita el cliente

Comprueba que la persona reconoce el producto, el importe y la identidad del comercio al pagar. Mantén consistente la oferta entre la página de venta y el checkout. Un cambio de pantalla se entiende mejor cuando continúa el mismo contexto.

También revisa el regreso después de pagar o cancelar. El comprador debe saber si ha terminado, si debe esperar o si puede volver a intentarlo. La claridad de este paso depende de la integración y de sus mensajes, no únicamente del lugar donde aparece el formulario.

El trabajo disponible en tu equipo

Una aplicación con servidor y desarrollo propio puede integrar sesiones y eventos dentro de su arquitectura. Una tienda gestionada por una persona sin equipo técnico puede necesitar una conexión preparada y acompañamiento en la configuración.

Describe quién mantendrá el sistema después del lanzamiento. Esa respuesta ayuda a elegir un alcance sostenible y a definir el soporte necesario. Una demostración fácil de montar no explica por sí sola cómo se resolverá una incidencia meses después.

Las operaciones posteriores

Pregunta cómo se relacionarán los pagos con pedidos, suscripciones y entrega. Si necesitas renovaciones, define también qué ocurre tras la primera compra. Si necesitas una devolución, concreta el proceso disponible para la conexión.

Nuestra documentación indica que el adaptador Redsys actual no admite reembolsos por esta API. Define con nosotros cómo gestionar una devolución en tu conexión y quién se encargará de tramitarla. Ese proceso forma parte de la operativa posterior al cobro.

Tres escenarios para orientar el proyecto

Tienda WooCommerce con catálogo y envíos. Parte del plugin y revisa que los datos del pedido, entrega y confirmación queden conectados. La guía de integración ecommerce desarrolla el recorrido completo.

Aplicación de servicios digitales. El servidor crea la sesión y la confirmación activa la regla de acceso correspondiente. El checkout alojado puede formar parte de esta integración por API. Define quién recibe el servicio y qué pasa con intentos pendientes.

Servicio vendido después de una propuesta. Puede bastar con un enlace y una entrega gestionada después del pago. Antes de desarrollar una conexión propia, revisa la guía de enlaces sin programar. El alcance técnico debe seguir la venta que necesitas realizar.

Un ejemplo de compra en una aplicación

Imagina un servicio digital que ofrece una compra puntual. La persona identifica el producto y accede con su cuenta. El servidor relaciona esa compra con el cliente, crea la sesión y entrega la dirección de pago al navegador.

El comprador completa la autorización. La aplicación recibe el resultado confirmado y activa el acceso para aquella cuenta. Si cierra la pestaña antes de volver, la confirmación del servidor permite conocer el resultado y continuar según las reglas preparadas.

La misma aplicación puede mostrar después el estado de la compra. Si recibe una notificación repetida, reconoce la operación y no entrega dos veces. Este ejemplo utiliza una API y una página alojada de forma complementaria, con un reparto claro entre pago y producto.

Qué comprobar antes de abrir el recorrido

Realiza una autorización correcta, un rechazo y una cancelación en el entorno de pruebas. Comprueba la relación entre compra y pago y el estado final de tu aplicación. Añade un cierre de navegador y una confirmación que llegue después del retorno.

Repite una notificación para verificar que no duplica el efecto de negocio. Para una tienda, revisa el pedido; para un servicio, el acceso. La guía de pruebas de integración detalla los escenarios y resultados que conviene registrar.

Comprueba también el entorno publicado: dominio, credenciales y métodos activados. Una conexión preparada en pruebas no demuestra que la configuración de producción sea idéntica. La puesta en marcha requiere revisar ambas según el alcance acordado.

Preguntas frecuentes

¿Usar la API significa construir un formulario de tarjeta?

No. La integración documentada permite crear una sesión y utilizar la página alojada devuelta. Tu aplicación mantiene la relación con la compra y procesa el resultado confirmado.

¿Un checkout alojado evita desarrollar cualquier integración?

Depende del recorrido. Una aplicación propia necesita crear sesiones y gestionar confirmaciones. Un enlace preparado desde el panel puede resolver una venta manual sin construir ese servidor específico.

¿Puedo cambiar la experiencia más adelante?

La evolución debe conservar pedidos, referencias y reglas de confirmación. Define el nuevo recorrido y prueba cómo convive o sustituye al anterior antes de enviar tráfico hacia él.

¿Qué papel tiene un SDK?

Facilita trabajar con una API desde un entorno concreto. No determina por sí mismo dónde verá el comprador la pantalla. La guía de SDK e integración TPV explica su alcance.

Define el recorrido y el trabajo que necesitas asumir

Cuéntanos qué plataforma tienes, cómo compra el cliente y quién mantendrá la integración. Prepararemos una propuesta de AndorPay que concrete la experiencia, la conexión y el acompañamiento.

Consulta nuestro TPV virtual en Andorra y solicita una propuesta para tu integración. Recibirás el alcance y las condiciones de forma privada.