Trabaja con el agente
Ya sabes qué hace y lo tienes instalado. Esta página es lo que pasa entre las dos cosas: cómo es una sesión de verdad.
Lo único que tienes que darle
El lenguaje y dónde vive tu código. Nada más.
Haz una app en Node/Express que reciba pagos con SPIDI y verifique los webhooks.
No le des credenciales. No las necesita: se registra solo en el simulador y se entrega a sí mismo las tres piezas que hacen falta. Si le pasas credenciales de producción, te las va a rechazar — y ese rechazo es la funcionalidad, no un estorbo.
Y no le des la documentación. La descarga él, de esta misma web, cada vez. Pegarle un fragmento en el mensaje es la forma más rápida de que trabaje con una versión vieja.
Qué hace por su cuenta
Va por este orden, y conviene conocerlo porque es donde vas a mirar si algo sale raro:
- Se consigue credenciales en el simulador.
- Lee la documentación que necesita — no toda: elige por título y descripción.
- Escribe la aplicación, incluido el receptor de avisos.
- Cierra el ciclo: crea una sesión, la lleva a pagada, provoca la acreditación.
- Comprueba que tu receptor recibió el aviso y verificó la firma.
- Te enseña la traza de todo lo anterior.
El paso 5 es el que lo separa de un asistente cualquiera. Escribir el código es la parte fácil; lo que cuesta tiempo real es descubrir tres días después que los avisos nunca llegaron.
Dónde se para a preguntarte
Cuando algo depende de ti y no de SPIDI. Dónde vive tu servidor, qué lenguaje, qué hace tu negocio cuando un pago falla.
Y cuando la documentación no responde. Ahí se planta y te lo dice, en vez de inventar un endpoint. Si te ha pasado que un agente se saca un /refunds de la manga y lo descubres en producción, esa parada es justo lo que estás comprando.
«Eso no está documentado» es una respuesta correcta y a veces es la única honesta. Si te la da, la pregunta va a SPIDI, no al agente. Y si crees que sí está documentado, dile dónde: leerá esa página.
Las tres cosas que conviene comprobarle
Un agente que trabaja bien y uno que se equivoca con aplomo se parecen mucho por fuera. Estas tres separan uno de otro, y se miran en un minuto:
1 · ¿Enseñó la traza del ciclo, o solo dijo que funciona?
Tiene que haber una sesión que pasó a pagada y un aviso que llegó a tu receptor. Si lo que ves es «la integración está lista» y un 200, no has visto nada: el simulador trae receptores de prueba que responden 200 siempre y no ejecutan una sola línea de tu código.
2 · ¿Verificó la firma de verdad?
Es el error que más caro sale porque no se nota: un receptor que responde 200 sin comprobar la firma funciona perfectamente hasta el día que alguien le manda un aviso falso. → Manejar notificaciones
3 · ¿De dónde sacó los números? Si te da una cifra —un tope, un mínimo, un porcentaje— pídele el documento. La skill está hecha para citarlo. Un dato sin fuente puede ser memoria del modelo, y la memoria repite lo de antes con el mismo aplomo el día que SPIDI cambia algo.
Lo que no va a hacer
No pasa a producción por ti. Hay una reunión de certificación con SPIDI de por medio, y eso no lo automatiza nadie. → Pasar a producción
No decide tu negocio. Si entregas el producto en cuanto el pago llega o esperas a la acreditación es una decisión de riesgo tuya. Te explicará las dos fases y las consecuencias de cada opción; elegir es tuyo. → Transacción a dos fases
Y no sabe nada que esta documentación no diga. Si algo no está aquí, tampoco lo sabe él. Esa es exactamente la garantía: no hay una segunda fuente donde pueda haber leído algo que tú no puedes comprobar.
→ Recibe tu primer pago si quieres recorrer a mano lo que él hace solo.