Cómo se integra con SPIDI
Integrar SPIDI son dos decisiones, no una, y conviene no mezclarlas.
Primero: ¿Dónde Paga Tu Cliente?
En la página de SPIDI. Tu backend crea la sesión y le entregas un enlace o un botón; el pago ocurre en una página de SPIDI y tu cliente vuelve. Es lo que documenta casi todo este portal, y es el camino más corto.
Dentro de tu propia aplicación. Tu cliente no sale: pone sus datos y confirma en tu pantalla, que diseñas tú. Eso es el SDK, y existe para Kotlin, React, Swift y Go.
Se desarrolla contra el sandbox, no contra el simulador — y ahí los desenlaces no se fuerzan: ocurren o no ocurren. Así que los casos malos se prevén en el código en vez de ensayarse. Si vas por ahí, la primera parada no es el código. → El SDK
Y no son excluyentes. Quien usa el SDK sigue necesitando su backend contra la API de Productos —autenticarse, crear el acuerdo, crear cada sesión—: el SDK solo cubre el tramo del pagador.
Después: ¿Quién Escribe el Código?
Esta segunda decisión vale para los dos casos de arriba. Cambia quién teclea y cuánto tardas, no lo que construyes.
Lo que no cambia es el final: tu integración se da por buena cuando cierra un ciclo completo contra el simulador. No cuando compila. (Salvo en el débito del SDK, que no se puede simular.)
Camino 1 — Con el Agente
Si trabajas con Claude Code, instalas la skill spidi y le pides la integración en tu propio idioma. El agente escribe el código, lo corre contra el simulador, fuerza los desenlaces y te dice qué falló.
Haz una app en Node que reciba pagos con SPIDI y verifique los webhooks.
Lo que lo hace distinto de pedírselo a un agente cualquiera es lo que la skill le prohíbe: no sabe la API de memoria —consulta esta misma documentación en cada respuesta— y no puede darse por aprobado a sí mismo. Un 200 no le vale; tiene que enseñar la traza del ciclo cerrado.
→ Qué hace · Cómo se instala · Trabaja con él
La mitad del valor no es que integre: es que le preguntes. «¿Cuánto dura una sesión?», «¿con qué campo concilio contra el banco?» — y responde citando el documento del que sale, o dice que no está documentado. Eso vale aunque escribas tú el código.
Camino 2 — A Pie, con el Simulador
Si no usas un agente, o prefieres tener el código en la cabeza antes que en la pantalla, el camino es el mismo que sigue la skill: el simulador y estas guías.
El simulador es una copia de SPIDI donde tú decides qué pasa. Fuerzas que un pago salga bien, que falle, que expire, que la acreditación se caiga — sin dinero real y sin esperar a que ocurra.
→ Recibe tu primer pago, que es el camino más corto de punta a punta.
Cuál Elegir
| Si… | Camino |
|---|---|
| Usas Claude Code y quieres estar integrado hoy | Con el agente |
| Quieres entender cada pieza antes de escribirla | A pie |
| Tu organización no permite instalar plugins de terceros | A pie |
| Estás depurando algo que ya está en producción | Con el agente — es donde más tiempo ahorra |
| Solo tienes una duda | Pregúntale al agente, o busca aquí arriba |
No es una decisión que cierres. El agente sigue estas guías; las guías explican lo que el agente hace. Puedes empezar con uno y terminar con el otro sin rehacer nada.
Lo que No Cambia, Elijas el que Elijas
El simulador es quien aprueba. Ni el código que se ve bien ni un 200 demuestran una integración. Lo demuestra un ciclo cerrado: creas la sesión, la llevas a pagada, la acreditación ocurre, y tu servidor recibe el aviso y lo verifica. → Conducir el ciclo
El pago ocurre en dos fases y las dos importan. Es el concepto que más caro sale ignorar, y no lo salva ninguna herramienta. → Transacción a dos fases
Y a producción no se pasa solo. Hay una reunión de certificación de por medio. → Pasar a producción
Esta página es sobre cómo integrar. Si aún no sabes qué —un botón, una solicitud con fecha, una dirección permanente, un reparto entre varios— eso se decide antes. → ¿Cuál solución necesito?