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 para integrar SPIDI

Las seis piezas

1. Tu frontend ──(pide un pago)──► 2. Tu backend ──(crea sesión)──► 3. SPIDI API
                                        ▲                                │
                                        │                                ▼
6. status (pull) ◄──────────────────────┤                    4. Página de pago (payment_url)
5. webhook (push) ◄─────────────────────┘◄───────────(aviso firmado)────┘

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) — SPIDI avisa 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