Documentación para desarrolladores
Pasar a producción
La producción usa otra cuenta Redsys y una API key distinta. Completa el cambio de forma controlada y verifica los tres sistemas.
Confirmar las capacidades del TPV
Pide al banco que confirme por escrito el FUC, terminal, secreto y métodos activos en producción. Tarjeta alojada requiere Redsys inSite. Las suscripciones requieren tokenización o credenciales almacenadas y pagos recurrentes iniciados por el comercio, también llamados MIT.
| Capacidad | Cuándo se necesita |
|---|---|
| Redsys inSite | Campos de tarjeta alojados y tokenización sin que tu aplicación reciba PAN o CVV. |
| Tokenización / COF | Guardar una referencia reutilizable del método para suscripciones y recuperación de cobro. |
| Recurrencia / MIT | Cobros posteriores iniciados por AndorPay sin interacción del comprador. |
| Redirección Redsys | Sólo cuando el comercio utilice un flujo o continuidad que dependa de esa modalidad. |
| Bizum RTP | Pago Bizum sin abrir el formulario clásico de Redsys. |
| Apple Pay / Google Pay X-PAY | Wallets habilitadas para ese FUC y terminal, con su certificación correspondiente. |
Cerrar la configuración de seguridad
| Control | Comprobación |
|---|---|
| HTTPS | Checkout, URLs de retorno y webhook usan certificados válidos. Localhost sólo se admite durante desarrollo. |
| API key | ap_live_ existe sólo en secretos de servidor y no aparece en bundles, HTML, logs ni analítica. |
| Webhook | El endpoint verifica Andorpay-Signature sobre el cuerpo sin procesar y aplica una tolerancia de 5 minutos. |
| Dominio | El origen productivo exacto está autorizado en Redsys inSite y, si corresponde, Apple Pay. |
| Datos de tarjeta | Tu aplicación no captura, persiste ni registra PAN, caducidad o CVV. |
| Correlación | Los logs guardan request_id, event.id y referencias internas sin secretos. |
Cambiar de sandbox a producción
- 1
Guarda la cuenta Redsys productiva
En Configuración de Redsys, selecciona producción y guarda las credenciales reales.
- 2
Genera una clave ap_live_
No transformes ni reutilices la clave ap_test_. El entorno de una API key no puede cambiar después de emitirla. - 3
Actualiza el secreto de servidor
Sustituye ANDORPAY_API_KEY en el entorno productivo y despliega sin exponer su valor en logs o revisiones de código. - 4
Comprueba el webhook
Mantén la URL HTTPS accesible, confirma el secreto activo y revisa que los eventos necesarios estén seleccionados. - 5
Invalida sesiones abiertas
Recarga cualquier checkout preparado antes del cambio. No reutilices una sesión creada con la clave de sandbox.
Verificar una operación real
Crea un pago real de importe reducido. Comprueba el mismo resultado en Redsys, AndorPay y tu aplicación antes de abrir el checkout a todo el tráfico. La entrega payment.succeeded debe producir una sola vez el efecto de negocio esperado.
Prueba además un rechazo controlado y confirma que no entrega producto. Si utilizas suscripciones, valida el alta, el método reutilizable y la capacidad MIT con el banco; no esperes al primer ciclo real para descubrir que el TPV carece de recurrencia.
Preparar operación y recuperación
| Situación | Respuesta operativa |
|---|---|
| Webhook degradado | Revisa estado HTTP, timeout, DNS, TLS y WAF. Reintenta la entrega desde el dashboard después de corregir la causa. |
| Resultado incierto | No repitas el cobro. Consulta pagos y Redsys con las referencias correlacionadas. |
| Clave expuesta | Genera una clave nueva, valida la conexión y desactiva la anterior. |
| Secreto webhook expuesto | Rota el secreto, actualiza el servidor y valida una entrega firmada nueva. |
| Redsys no permite reembolso | La API responde 501 payment_rail_refund_unsupported. Define el proceso operativo con el banco antes del lanzamiento. |