Decisiones abiertas
Puntos que dependen de acuerdos con cada proveedor o de decisiones del equipo. Cada uno trae una propuesta por defecto.
| # | Tema | Estado | Propuesta |
|---|---|---|---|
| 1 | Dónde vuelve el pagador tras pagar | Cerrada: no vuelve; la app del proveedor da el feedback. La página de pago abierta muestra la conclusión | — |
| 2 | Crear el pago al iniciar (como PSE) en vez de al llegar el primer evento. Hoy, hasta el primer evento no hay pago y, si el evento no trae reference, el pago queda con la referencia vacía | Abierta | Crear el pago en in_review con el medio correcto y la referencia del link |
| 3 | Vencimiento: qué pasa si el proveedor nunca confirma | Abierta | Evento expired del proveedor (o barrido de la pasarela) → pago failed con motivo EXPIRED |
| 4 | Firma del webhook de confirmación | Abierta | Mantener el secreto compartido y añadir timestamp; HMAC si el proveedor puede |
| 5 | Vocabulario de estados y motivos (rechazo, fondos insuficientes, expirado) | Abierta | Acordar una tabla con cada proveedor y reflejarla en el evento al comercio |
| 6 | Plantillas reales del enlace (esquema, parámetros) y del QR/llave de Bre-B; quitar el texto de demostración de la UI | Abierta — depende del proveedor | — |
| 7 | amount obligatorio en todos los eventos | Abierta | Exigirlo (hoy es opcional y se usa el del link) |
| 8 | Alias neutro del endpoint (/webhooks/crezcamos/payments) | Opcional | Añadirlo sin quitar el actual |
Limitación conocida: el estado es por link
La página de pago y el resultado se apoyan en el estado del link, no en el del pagador. En un link de varios usos, el primer pago cambia el estado para todos. Se resolvería con la decisión 2.