Un SDK puede simplificar la conexión con un TPV, pero la integración estará completa cuando el pago quede relacionado con el pedido y produzca el resultado correcto en tu aplicación. Para elegirlo, empieza por identificar qué parte vas a integrar: el procesamiento bancario, un checkout alojado o el sistema que gestiona tus cobros.
Si desarrollas una web o un servicio para una empresa de Andorra, esta guía te ayuda a separar el trabajo de la librería del trabajo de tu aplicación. Con AndorPay puedes preparar la conexión mediante API y utilizar los eventos de pago para continuar la venta, sin confundir una petición aceptada con un pedido ya pagado.
SDK, API y plugin: qué resuelve cada uno
Una API define cómo se comunican dos sistemas. Un SDK reúne herramientas para trabajar con un servicio desde un lenguaje o entorno concreto. Un plugin conecta ese servicio con una plataforma, como una tienda, y suele incluir decisiones sobre su funcionamiento.
No son alternativas intercambiables. Una aplicación propia puede utilizar una API mediante un SDK, mientras que una tienda instala un plugin que internamente realiza peticiones. El comercio necesita conocer el recorrido final; el equipo técnico necesita elegir el punto de conexión que puede mantener.
Las librerías oficiales de integración de Redsys ayudan con parámetros, peticiones y firma. Esa asistencia técnica tiene un alcance concreto: tu aplicación sigue teniendo que relacionar la operación con la compra y decidir cómo actualiza su estado.
Empieza por el problema de tu aplicación
Si ya utilizas WooCommerce, comprueba primero la integración disponible para tu instalación. Desarrollar una conexión desde cero puede introducir trabajo que el plugin ya resuelve. Nuestra guía de WooCommerce explica el recorrido de pago y pedido que prepara AndorPay.
Si tienes una aplicación propia, identifica quién crea la compra, qué servidor conserva su referencia y qué evento permite entregarla. Esa información sirve para decidir dónde usar una librería. Elegir un paquete únicamente porque su instalación es rápida no resuelve la relación entre esos sistemas.
Decide qué servicio quieres integrar
Integrar directamente con un procesador y conectar una plataforma que organiza los cobros son proyectos con responsabilidades distintas. Dibuja primero las partes: aplicación, servidor, pantalla de pago, confirmación y sistema que entrega el servicio.
En un recorrido con AndorPay, tu servidor puede crear una sesión de checkout y dirigir al comprador a la dirección devuelta. La aplicación recibe después las notificaciones pertinentes para continuar. La guía REST documenta ese contrato; no necesitas asumir que existe un SDK oficial para tu lenguaje.
Esta decisión debe quedar clara antes de mezclar ejemplos. Una clave, una firma o un campo de Redsys no tienen necesariamente el mismo formato ni la misma función en una petición a AndorPay. Usa la documentación del servicio al que estás llamando en cada tramo.
Qué trabajo puede ahorrar una librería
Una librería bien ajustada al contrato evita repetir código de comunicación y facilita utilizar los formatos esperados. También puede hacer más legible el punto de conexión: el equipo entiende dónde se construye una petición y cómo se interpreta una respuesta.
El beneficio se aprecia al mantener la integración. Si el formato de un servicio cambia, interesa localizar el código afectado y comprobar su actualización sin recorrer toda la aplicación. Para conseguirlo, concentra la conexión en un módulo y traduce sus resultados a los estados que utiliza tu negocio.
Por ejemplo, la pantalla de un pedido no debería necesitar conocer todos los parámetros bancarios. Puede mostrar si espera confirmación, si el pago se ha completado o si requiere una acción. El detalle técnico queda disponible para diagnóstico en el componente que gestiona la conexión.
Qué sigue siendo responsabilidad de tu servidor
El servidor debe relacionar la compra con su cliente, producto y condiciones. También debe controlar qué datos acepta del navegador. El comprador puede elegir una opción, pero la aplicación debe comprobar que esa elección corresponde a una oferta válida.
En la integración REST de AndorPay, la clave de API es un secreto del servidor. No se incluye en JavaScript público ni se devuelve al comprador. La respuesta que utiliza el navegador contiene la información necesaria para continuar, como la URL de checkout proporcionada por el servicio.
| Responsabilidad | Pregunta que debe responder tu implementación |
|---|---|
| Compra | ¿Qué se está contratando y con qué referencia? |
| Cliente | ¿A qué cuenta pertenece la operación? |
| Petición | ¿Qué servicio y entorno reciben los datos? |
| Confirmación | ¿Cómo se verifica el resultado recibido? |
| Entrega | ¿Qué acción corresponde a ese pago? |
| Seguimiento | ¿Dónde se consulta una operación pendiente? |
Revisa también los permisos de quien inicia cada acción. Que una llamada tenga el formato correcto no demuestra que deba ejecutarse para cualquier usuario o pedido. La aplicación conserva esa responsabilidad aunque una librería construya la petición.
La respuesta a una petición no termina la venta
Crear una sesión permite iniciar un recorrido de pago. No confirma que el cliente lo haya completado. Del mismo modo, una URL de retorno permite volver a tu web, pero no debe ser la única base para marcar el pedido como pagado.
El cliente puede cerrar la ventana después de autorizar, perder la conexión o volver mientras el resultado todavía se está actualizando. Tu sistema debe poder recibir la confirmación y asociarla a la compra independientemente de esa pantalla.
La documentación del ciclo de pago explica esta separación. Utilízala para definir los estados visibles en tu aplicación y evitar que un problema de navegación termine convertido en un segundo intento de cobro.
Prepara las notificaciones como parte de la integración
Los webhooks permiten que el servidor reciba eventos sobre lo ocurrido. Verifica el mensaje según el contrato documentado antes de aplicar su contenido. Conserva la relación entre evento, operación y pedido para que el efecto sea identificable.
Una notificación repetida debe poder reconocerse. Si el primer mensaje activó un periodo de servicio, recibirlo de nuevo no debería ampliar otro periodo. La aplicación necesita registrar qué efectos ya aplicó, aunque el servicio vuelva a entregar el mensaje.
Para AndorPay, consulta la guía de webhooks. Separa la verificación de la comunicación del trabajo comercial que viene después. Así puedes investigar un error de entrega sin volver a solicitar un pago que ya está confirmado.
Comprueba el contrato antes de automatizar reintentos
Los servicios pueden tener reglas diferentes para repetir peticiones. Una recomendación genérica sobre idempotencia no sustituye la documentación de cada operación. Comprueba qué cabeceras acepta y qué significa reenviar una solicitud.
En concreto, nuestra guía REST indica que POST /v1/checkouts rechaza la cabecera Idempotency-Key. No copies un ejemplo de otro proveedor que la añada por defecto. Para una respuesta incierta, conserva la referencia disponible y comprueba el estado antes de crear otra acción de cobro.
También conviene distinguir repetir una consulta, crear otra sesión y ejecutar un cargo. Son acciones con consecuencias distintas. El tratamiento de un error debe responder a la operación concreta, no a una regla que repite todo lo que devuelve un fallo.
Cómo evaluar una dependencia antes de incorporarla
Comprueba quién publica el paquete y qué documentación describe su alcance. Revisa el lenguaje y versiones compatibles, el tipo de integración y el procedimiento de actualización. Un nombre parecido al del proveedor no demuestra que sea un componente oficial.
Prepara una prueba pequeña con el entorno adecuado y registra la versión utilizada. Debe mostrar que puedes construir una petición válida, interpretar el resultado y resolver un error conocido. Después conecta ese resultado a una compra de prueba de tu aplicación.
Evita añadir una dependencia solo para ocultar una llamada sencilla. Si la API se puede integrar de forma clara con las herramientas existentes, valora el mantenimiento adicional del paquete. La decisión útil es la que deja una conexión comprensible para quien tendrá que resolver una incidencia meses después.
Pruebas que debería superar el recorrido completo
Comprueba un pago aceptado, uno rechazado y un abandono. Añade una notificación repetida y una confirmación que llegue después de cerrar el navegador. En todos los casos, compara el resultado del pago con el estado del pedido o del acceso.
Utiliza credenciales y medios de prueba del entorno correspondiente. No mezcles parámetros de producción para conseguir que una demostración funcione. La guía de pruebas de AndorPay describe escenarios y límites de los distintos métodos.
Antes de publicar, deja por escrito quién revisa las incidencias y qué referencias necesita. Una prueba correcta también debe permitir explicar un fallo sin buscar claves o datos completos de tarjeta en registros. El diagnóstico necesita contexto de la operación, no información que el equipo no debería almacenar.
Preguntas frecuentes
¿Un SDK elimina todo el trabajo de integración?
No. Puede simplificar la comunicación con un servicio, pero tu aplicación debe relacionar el pago con la compra, verificar los eventos y aplicar el resultado. El alcance exacto depende de la herramienta.
¿Necesito un SDK de AndorPay para mi lenguaje?
Puedes conectar un backend mediante la API REST documentada. Revisa el contrato y las capacidades necesarias antes de elegir una dependencia. Si utilizas una tienda compatible, estudia primero su integración disponible.
¿Qué necesitamos para revisar tu proyecto?
La plataforma, el lenguaje del servidor, el banco y un esquema de la compra. Añade si vendes productos, servicios o suscripciones y qué debe ocurrir después del pago. Cuéntanos qué integración necesitas y definimos contigo la conexión adecuada.