Una pasarela de pago para una tienda de Andorra debe conectar la compra con el cobro y devolver un resultado que permita gestionar el pedido. El comprador necesita pagar sin perder el contexto; tu equipo necesita saber si puede preparar la entrega. Ese recorrido completo es lo que hay que integrar, aunque el punto más visible sea el botón de tarjeta.
En AndorPay conectamos el pago con la infraestructura bancaria y la tienda o aplicación que utiliza tu negocio. Esta guía explica cómo preparar una integración ecommerce: plataforma, checkout, datos, estados, incidencias y puesta en marcha. Si todavía estás definiendo cómo vender, puedes empezar por la guía general para cobrar online desde Andorra.
Qué debe resolver la pasarela en tu tienda
La pasarela participa en la autorización del pago y comunica su resultado. La integración conecta ese resultado con la compra. Cuando ambas partes están bien preparadas, un pago confirmado se relaciona con un pedido concreto y el comprador recibe una explicación coherente.
La tienda conserva otras responsabilidades: calcular lo que se compra, recoger los datos necesarios, gestionar existencias y entregar. Un cobro correcto no arregla una dirección incompleta ni decide qué producto debe enviarse. Por eso, la puesta en marcha debe recorrer la compra desde el carrito hasta la gestión del pedido.
El problema puede estar en cualquiera de esas conexiones. Un botón que no aparece, un pedido pendiente tras pagar y un correo de confirmación que no llega son síntomas distintos. Identificarlos por separado ayuda a intervenir en el punto adecuado sin rehacer toda la tienda.
Las piezas que intervienen en una compra
El comprador ve un único proceso, pero detrás se coordinan la tienda, la conexión de pago y la infraestructura bancaria. Tu sistema de gestión puede añadir otro paso para preparar envíos o activar un servicio.
| Pieza | Función en la venta | Dato que debe conservarse |
|---|---|---|
| Tienda o aplicación | Prepara la compra | Pedido, líneas, importe y cliente |
| Checkout | Presenta la acción de pago | Sesión vinculada a esa compra |
| Procesamiento | Obtiene el resultado de autorización | Operación y estado confirmado |
| Integración | Actualiza la venta | Relación entre pedido y pago |
| Entrega o acceso | Cumple lo comprado | Estado del servicio o envío |
No necesitas gestionar todas estas piezas manualmente. Sí necesitas que exista una relación clara entre ellas para que tu equipo pueda encontrar una venta sin reconstruirla a partir de mensajes dispersos.
Haz una revisión breve de tu tienda actual
Antes de elegir una integración, identifica la plataforma, el tipo de checkout y las personalizaciones que afectan al pedido. Incluye impuestos configurados en la tienda, envíos, cupones, variantes y cualquier herramienta que reciba las ventas después del pago.
Escoge un pedido representativo y síguelo de principio a fin. Anota dónde se calcula el total, cuándo se recoge la dirección y qué pantalla utiliza el equipo para preparar la entrega. Esta revisión describe lo que hay que conservar al conectar el cobro.
Si ya tienes una pasarela, añade qué funciona y qué quieres mejorar. Puede faltar un método, sobrar trabajo manual o existir una incidencia en la actualización del pedido. Una necesidad concreta permite delimitar la intervención y comprobar después si se ha resuelto.
El punto de partida cambia según la plataforma
WooCommerce
Nuestro plugin conecta WooCommerce con AndorPay. Los productos y los cálculos permanecen en la tienda; el plugin transmite las líneas y referencias necesarias para el pago. No necesitas recrear el catálogo en AndorPay para esta integración.
La documentación cubre checkout clásico, Checkout Blocks, HPOS y el recorrido de pago de un pedido existente. Antes de instalar o actualizar, identifica la versión de WooCommerce y del plugin, además de las extensiones que modifican el checkout. Utiliza la guía vigente de WooCommerce para preparar la configuración correspondiente.
Shopify u otra plataforma con un checkout controlado
La plataforma determina qué conexiones admite y cómo se presenta el pago. Un proveedor compatible con una herramienta no convierte automáticamente todos sus métodos o modelos recurrentes en utilizables dentro de ella.
Si utilizas Shopify, revisamos el recorrido disponible y la forma de venta antes de proponer una integración. Si esa plataforma no cubre el caso, valoramos el cambio necesario con su alcance: productos, pedidos, entrega y trabajo del equipo. La decisión debe partir de tu operación, no solo de la existencia de un logotipo en una lista.
Una aplicación propia
Tu servidor prepara la compra y crea una sesión mediante la API. El comprador abre la dirección de checkout recibida y tu aplicación procesa los eventos que comunican el resultado. La guía REST describe esa conexión.
Define desde el principio cómo relacionarás cliente, producto, pedido y pago. La API permite conectar sistemas; las reglas de entrega y acceso siguen formando parte de tu aplicación. Esa separación ayuda a mantener el recorrido cuando cambian las pantallas o el catálogo.
Checkout alojado y experiencia dentro de la tienda
Un checkout alojado utiliza una página de pago preparada por la plataforma. Tu aplicación crea la sesión y dirige al comprador a la dirección correspondiente. Después recibe la confirmación que necesita para continuar la venta.
En WooCommerce, nuestro plugin conecta el proceso habitual de compra con los métodos disponibles. El cliente mantiene el contexto del pedido mientras completa el paso de pago. La decisión sobre la experiencia debe considerar la plataforma, el mantenimiento y los datos que hay que recoger.
Una integración por API puede utilizar un checkout alojado; no son opciones excluyentes. La API describe cómo se comunican los sistemas y el checkout describe dónde paga la persona. La guía de checkout alojado e integración API desarrolla esa diferencia.
Prepara el TPV para las operaciones que vas a ofrecer
La conexión bancaria debe corresponder al recorrido de venta. Indica si necesitas pagos puntuales, wallets o recurrencia. Cada modalidad tiene requisitos y activación propios; no se deducen solo de tener un TPV virtual contratado.
En nuestra integración WooCommerce, tarjeta requiere Redsys inSite. Apple Pay y Google Pay requieren X-PAY y la configuración correspondiente del banco y de cada wallet. Se habilitan los métodos disponibles para ese comercio y para el entorno del comprador.
La información inicial útil incluye banco, situación del TPV y plataforma. Con ella concretamos la preparación y el alcance de la propuesta. La guía de bancos y TPV en Andorra ayuda a ordenar la conversación con tu entidad.
Conserva la relación entre el carrito y el pago
El importe que se autoriza debe corresponder a la compra preparada por el sistema. Incluye los productos, variantes, descuentos y entrega calculados para ese pedido. Si algo cambia antes del pago, el recorrido debe aplicar la actualización de forma coherente.
Por ejemplo, cambiar el país de envío puede alterar la entrega disponible. El comprador debe revisar el total correcto antes de autorizar. Una integración que utiliza un importe anterior genera una diferencia que después tendrá que resolver tu equipo.
Conserva una referencia común entre pedido y operación. También conviene registrar qué intento pertenece a qué compra cuando hay una cancelación o un rechazo. Así se puede recuperar la venta sin confundir el primer intento con el resultado del siguiente.
Los datos de entrega forman parte del checkout
Para un producto físico, define los campos necesarios para preparar el envío. Comprueba dirección, contacto y opción de entrega en el pedido final. Para un producto digital, identifica el correo o cuenta que recibirá el recurso.
Las wallets pueden simplificar la introducción de datos, pero no debes presuponer que aportarán toda la información en cualquier situación. El recorrido necesita recoger lo que falta. Incluye en las pruebas las personalizaciones de campos y las reglas que cambian al seleccionar una dirección.
La comprobación útil termina con una venta que se puede entregar. Si alguien tiene que contactar después para pedir un dato obligatorio, identifica en qué punto faltó. El pago puede estar correcto mientras esa otra parte del checkout necesita un ajuste.
Qué debe ocurrir durante la autorización
El cliente selecciona el método y completa la acción solicitada. Puede aparecer una autenticación adicional o un periodo de espera. La pantalla debe mantener el contexto y explicar qué está pasando sin invitar a repetir la compra antes de conocer el resultado.
Un rechazo debe tener una salida comprensible. Una cancelación voluntaria debe permitir volver al recorrido de compra. Una respuesta pendiente necesita su propio tratamiento, porque todavía no equivale a un resultado final.
La documentación del ciclo de pago describe los estados de AndorPay. El equipo que integra la tienda debe utilizarlos para decidir cuándo permite otro intento y cuándo continúa esperando la operación existente.
El retorno del navegador y la confirmación son cosas distintas
Llegar a una página de agradecimiento orienta al comprador, pero no sustituye el resultado confirmado en el servidor. El navegador puede cerrarse antes de volver y una notificación puede llegar después. La integración tiene que contemplar ambos casos.
En AndorPay, los eventos permiten comunicar el resultado a tu aplicación. Tu sistema verifica la notificación y aplica la actualización correspondiente. La guía de webhooks explica la conexión y la verificación de firma.
Si la misma notificación llega otra vez, no debe generar una segunda entrega. La aplicación reconoce la operación ya procesada. Esta protección se comprueba con una repetición del mismo evento; no hace falta provocar un nuevo cobro para probarla.
Traduce el resultado de pago al estado del pedido
Tu equipo utiliza estados comerciales para trabajar: pendiente, listo para preparar, enviado o completado. Esos estados deben seguir reglas relacionadas con el pago, pero también con el tipo de producto y la entrega.
| Resultado del pago | Qué necesita la tienda |
|---|---|
| Confirmado | Relacionarlo con el pedido y aplicar la regla de preparación |
| Pendiente | Conservar la referencia y esperar o consultar el resultado |
| Acción requerida | Permitir que el comprador complete el paso necesario |
| Fallido | Mantener el pedido sin pagar y ofrecer recuperación adecuada |
No marques un pedido como entregado solo porque se haya cobrado. Tampoco pidas otro pago porque la pantalla de preparación no se haya actualizado. Primero identifica qué etapa ha terminado y cuál falta por sincronizar.
Preparación concreta en WooCommerce
Instala la versión del plugin correspondiente y abre su configuración en los ajustes de pagos. La guía documenta la conexión de API y checkout, la clave del entorno de pruebas y la activación de los métodos disponibles. Sigue esa secuencia para mantener todos los componentes en el mismo entorno.
El plugin prepara su identidad y registro de notificaciones al guardar la conexión. La ruta de comunicación debe ser accesible y las tareas programadas deben poder ejecutarse. Si un firewall bloquea esa ruta, corrige el acceso concreto que necesita la integración.
La documentación explica cómo revisar las acciones programadas y cómo sincronizar un pedido con AndorPay. Utiliza esas herramientas para recuperar coherencia con un pago existente. Completar manualmente un pedido o repetir el cobro sin consultar su operación puede ocultar el problema inicial.
Diseña cómo responder a una incidencia
Si el cliente dice «he pagado y la web sigue esperando», busca primero pedido y operación. Comprueba el resultado confirmado antes de decidir si necesita otro intento. La prioridad es explicar qué ha ocurrido con esa compra.
Si el pago está confirmado y falta actualizar el pedido, revisa la comunicación entre sistemas. Si el pedido está correcto y falta un correo, la incidencia está en la notificación al cliente. Separar estos casos evita cambios innecesarios en el proceso de autorización.
Conserva referencias, momento y resultado observado. No pidas el número completo de tarjeta para investigar. Tu equipo necesita información que permita localizar el recorrido, junto con una forma clara de comunicar el estado y el siguiente paso al comprador.
Devoluciones y cancelaciones deben tener un procedimiento
Cancelar una compra antes de pagar, anular un servicio y devolver un cobro son acciones distintas. Define qué puede solicitar el cliente y qué proceso seguirá el equipo para cada caso. La tienda debe reflejar la operación que realmente se ha ejecutado.
Nuestra documentación indica que el adaptador Redsys actual no admite reembolsos por esta API. Por ello, el procedimiento de devolución se concreta para la conexión del comercio antes de ofrecer una automatización. No debe mostrarse una devolución como completada si solo se ha registrado la solicitud interna.
Relaciona siempre la gestión con el pedido y pago originales. Así puedes atender una consulta posterior y distinguir una devolución solicitada de una realizada. La política comercial y la acción de pago deben permanecer coherentes durante ese seguimiento.
Si tu tienda vende suscripciones
Una integración recurrente añade el ciclo posterior a la primera compra. Necesitas definir periodo, renovación, cambio y baja, además del acceso o entrega asociados. Un pago inicial correcto no demuestra que todo ese ciclo esté preparado.
En AndorPay, la recurrencia requiere la capacidad de suscripciones y una conexión apta. La aplicación debe utilizar los eventos y operaciones disponibles conforme a sus reglas de servicio. La guía de recurrencia con Redsys desarrolla la preparación específica.
Si migras suscripciones, aclara la gestión de los medios guardados y del siguiente cobro. No presupongas portabilidad ni dejes dos sistemas programando el mismo periodo. La transición debe identificar qué sistema gestiona cada relación y desde cuándo.
Prepara una prueba que represente tus ventas
Selecciona pedidos habituales: un producto con envío, una variante, un descuento si lo utilizas y un producto digital si existe. Comprueba el total antes de autorizar y los datos finales después. No necesitas probar combinaciones que tu tienda no ofrece.
Añade éxito, rechazo, cancelación y cierre de navegador. Incluye una notificación repetida y una confirmación tardía. Para cada caso, define de antemano qué verá el cliente y qué estado necesita el equipo. Así la revisión compara un resultado con una expectativa concreta.
| Escenario | Resultado a revisar |
|---|---|
| Compra habitual | Pedido, importe y confirmación coinciden |
| Cambio de entrega | Se utiliza el total revisado por el comprador |
| Cancelación | La compra conserva un estado comprensible |
| Respuesta tardía | La tienda recupera el resultado existente |
| Evento repetido | No duplica entrega ni activación |
| Wallet compatible | Autoriza y conserva los datos necesarios |
La guía de pruebas detalla los entornos y escenarios. Registra las referencias de tus casos para que una incidencia pueda reproducirse sin involucrar un cobro nuevo al cliente.
Publica con la configuración del entorno real
Antes de abrir el nuevo recorrido, comprueba dominio, credenciales y métodos de producción. Si has probado en una dirección provisional, revisa la configuración que cambia al pasar al dominio definitivo. Mantén identificable qué versión e integración están activas.
Prepara también qué hará el equipo si aparece una incidencia al abrir. Puede ser detener nuevas solicitudes por el método afectado mientras se revisan operaciones pendientes, conservando la información existente. La respuesta debe evitar que el comprador termine con dos intentos sin saber cuál corresponde a su compra.
Una puesta en marcha termina cuando se ha revisado el recorrido publicado y su gestión, de acuerdo con las comprobaciones previstas. Un despliegue de archivos, una configuración guardada o un botón visible son pasos intermedios de ese trabajo.
Observa ventas y trabajo operativo después del cambio
Mira pagos confirmados, pedidos pendientes y consultas de clientes por método y dispositivo. Si una campaña cambia al mismo tiempo, sepárala al interpretar el resultado. La diferencia en tráfico puede influir en el comportamiento de compra.
Revisa también cuánto trabajo necesita una venta para quedar lista. Un checkout puede completar la autorización y aun así generar preguntas sobre entrega o confirmación. Esas consultas ayudan a localizar el siguiente ajuste útil.
Utiliza las referencias compartidas para revisar casos concretos. La mejora debe verse en una compra clara y en un pedido gestionable, además de en la apariencia de la pantalla. Esa es la base para ampliar métodos o automatizaciones cuando el negocio lo necesite.
Preguntas frecuentes
¿Tengo que cambiar mi tienda para usar AndorPay?
Revisamos la plataforma y el recorrido actual antes de plantear cambios. WooCommerce cuenta con una integración documentada; otras plataformas requieren estudiar sus posibilidades y el alcance necesario para tu venta.
¿Puedo conservar el catálogo de WooCommerce?
Sí. Nuestro plugin utiliza las líneas y referencias calculadas por la tienda. No necesitas duplicar ese catálogo en AndorPay para esta conexión.
¿Qué ocurre si un cliente cierra la página después de pagar?
El resultado debe recuperarse mediante la comunicación del servidor y relacionarse con el pedido. El regreso del navegador no es la única vía para conocer la confirmación.
¿Cuándo conviene añadir más métodos?
Cuando aportan una opción útil a tus compradores y la conexión está preparada. Comprueba el recorrido completo de cada método, incluidos los datos de entrega y el estado final del pedido.
Conecta tu tienda con el cobro y la gestión del pedido
Cuéntanos qué plataforma utilizas, con qué banco trabajas y qué necesitas mejorar. Revisaremos la compra completa y te presentaremos una propuesta concreta para integrar AndorPay.
Consulta nuestro TPV virtual en Andorra y solicita la revisión de tu tienda. Las condiciones y el alcance se presentan de forma privada.