Arquitectura recomendada

Una integración con SPIDI tiene seis piezas. Conocerlas evita los dos errores clásicos: crear sesiones desde el navegador y confiar en la redirección como prueba de pago.

Arquitectura recomendada: las seis piezasGuion: .docx · .yaml

Las Seis Piezas

1. Frontend — pide "quiero recibir un pago de X". Nunca guarda tu token ni crea sesiones.
2. Backend — guarda el token (secreto), crea la sesión y recibe los webhooks.
3. SPIDI API — crea la sesión y devuelve la payment_url.
4. Página de pago — la pantalla de SPIDI donde paga la persona; al terminar vuelve a tu success_url.
5. Webhook (push) — te avisamos a tu backend cuando hay paid/accredited. La vía fiable.
6. Status (pull) — tu backend consulta GET status para confirmar/reconciliar.

Reglas de Oro

Dos reglas que evitan el 90% de los bugs

1. El token y la creación de sesiones viven en tu backend, nunca en el navegador.
2. La redirección a success_url no es prueba de pago. Confirma con webhook + GET status. → Verificar status.

Webhook + Status, Juntos

• Webhook = te enteras al instante (push). Verifica la firma, deduplica, responde 2xx.
• Status = respaldo y reconciliación (pull), por si perdiste un aviso.

→ Conceptos base · Manejar notificaciones · Recibe tu primer pago