Antes de tocar dinero real
En el resto de este portal, quien aprueba tu integración es el simulador: fuerzas el desenlace que quieras, sin dinero real, tantas veces como haga falta.
Con el SDK no existe esa pieza. Se desarrolla contra el sandbox —que sí protege tu dinero y el de tu cliente— pero ahí no se fuerza nada: los desenlaces ocurren o no ocurren. Y llega un momento, el primer pago real, en el que equivocarse le cuesta dinero a otra persona.
Esta página es para llegar a ese momento con las cuatro cosas sabidas.
Las tres que tienen consecuencias sobre dinero real
1 · Se prueba contra el sandbox, y ahí no puedes forzar nada
El SDK se desarrolla y se prueba contra el sandbox de SPIDI, que tiene su propia información y sus propias credenciales — te las entrega tu asesor, no se registran solas. Es el entorno donde vive tu integración hasta que la certifiques.
Lo que no hay es un simulador del débito. En el resto del portal el simulador te deja provocar un pago fallido, una sesión vencida o una acreditación caída cuando quieras; aquí no. En el sandbox las cosas ocurren, no se fuerzan. Esa es la red que pierdes, y por eso los desenlaces malos hay que preverlos en el código en vez de ensayarlos.
Es de dónde salió la sesión. Una sesión creada en producción debita de verdad aunque tu aplicación apunte a sandbox. Mezclar orígenes es la forma de mover dinero real creyendo que estás probando — y un débito no tiene reverso técnico.
En varias plataformas el cliente apunta a producción si no indicas otra cosa. Un ambiente asumido, en un flujo que mueve dinero real, es la equivocación más cara de esta integración.
2 · La confirmación del débito no se reintenta. Nunca
La API no admite claves de idempotencia en esta operación: un segundo intento puede debitarle dos veces al pagador.
Si pierdes la respuesta, no repitas. Consulta el estado de la transacción, que es una lectura y puedes repetirla sin riesgo.
En tu interfaz, deshabilita el botón de confirmar mientras la petición está en vuelo. Un doble toque es un doble débito. Es la regla más importante de todo el SDK, y la única cuyo incumplimiento le cuesta dinero al pagador.
3 · Una sesión de pago sirve una sola vez
No la reutilices para un segundo intento ni para otra transacción. Si el pagador quiere volver a intentarlo, tu backend genera una sesión nueva.
La lista del primer pago real, ya en producción
Cuando el sandbox está cerrado y la certificación pasada, queda un último ensayo que sí mueve dinero: el primero de verdad. Para eso hay una lista, y no es de configuración: es de operación. Cada punto corresponde a algo que ya salió mal en alguna integración.
- Tienes autorización escrita: ambiente, método, monto máximo y ventana de tiempo.
- La sesión es nueva, por el monto mínimo y sin vencer.
- Una persona opera y otra observa, con ruta de escalamiento acordada.
- Sin captura de tráfico, sin registros del cuerpo de las peticiones, sin telemetría que copie datos sensibles.
- La clave del SMS se teclea con entrada oculta: nunca en código, variables de ambiente, historial ni tickets.
- La confirmación se envía una sola vez y el botón se bloquea mientras está en vuelo.
- Ante una respuesta ambigua: consulta el estado, registra hora e identificadores, y detente.
- La evidencia guarda hora, identificador de sesión y de comprobante. Nada más.
- Las credenciales del comercio están únicamente en tu servidor.
- La liberación del servicio depende del estado consultado en tu servidor, no de la pantalla.
- El comprobante le llega al pagador y la leyenda de atribución está en la pantalla.
Del documento de integración del SDK que entrega SPIDI, de agosto de 2026. No está verificada contra el simulador, porque el débito del SDK no se puede simular — a diferencia del resto de este portal. → El contrato