Pasar a producción
Cuando tu integración ya funciona, el paso a producción no es un cambio de URL. Hay una reunión de certificación por medio, y se valida contra el sandbox — no contra el simulador donde aprendiste.
Los tres entornos se recorren en orden: aprendes y ensayas en el simulador, repites el recorrido en el sandbox, y ahí es donde se certifica. → Entornos y URLs
Merece leerse ahora y no al final: lo que se certifica condiciona cómo construyes, y enterarse el día de la reunión es la forma cara de descubrirlo.
Los cuatro elementos obligatorios de tu pantalla de pago
Se validan en la reunión, y frenan certificaciones. No son de estilo: los cuatro se pueden comprobar mirando la pantalla y el código.
| Qué tiene que haber | |
|---|---|
| La leyenda de atribución | «Desarrollado por SPIDI», con el logotipo |
| El comprobante | Cada pago exitoso genera uno verificable, y tiene que llegarle al pagador: en pantalla, por correo, o guardado en su historial dentro de tu aplicación |
| La identificación del pago | Quién pagó, cuánto y con qué referencia bancaria — para que una consulta posterior se resuelva sin buscar capturas |
| El botón bloqueado mientras la petición está en vuelo | No es diseño: es la defensa contra el doble débito |
Es la misma regla del SDK, y la razón por la que aparece aquí es que se certifica: no basta con hacerlo, hay que poder enseñarlo. → Antes de tocar dinero real
El Kit de Marca completo —banners, piezas para redes, cintillos, plantillas— es otra cosa y no hace falta para la integración técnica: eso lo trabaja tu equipo de mercadeo. Pídeselo a tu asesor de SPIDI cuando lo necesites.
Los cuatro pasos
- Solicitas la reunión de certificación.
- Se valida tu implementación. Participan dos equipos: el técnico, que revisa que la integración esté bien hecha, y el de marca, que revisa que cumpla los lineamientos.
- Entregas los datos formales de tu empresa, una vez aprobada la validación.
- Recibes tus credenciales de producción. Se crea tu usuario en el ambiente productivo y se te envían.
Lo que sorprende, y por eso va aquí arriba
La marca también se certifica. No es solo una revisión técnica. Lo que enseñas al pagador —el botón, cómo lo nombras, qué respaldo muestras— entra en la validación.
Si dejaste el copy del botón para el final, es el momento de mirarlo: → Qué texto poner en el botón
Qué conviene llevar resuelto
No es una lista oficial: es lo que un integrador querría tener demostrado antes de sentarse.
| Por qué se mira | |
|---|---|
| Confirmas el estado desde tu servidor | La redirección a tu URL de éxito no es prueba de pago |
| Verificas la firma de los avisos | Y sobre todo: que rechazas una firma que no cuadra |
Deduplicas por idempotency-key | El mismo aviso puede llegarte más de una vez |
| Manejas los desenlaces malos | Pago fallido, sesión vencida, acreditación fallida |
| La configuración no está incrustada | El mismo código tiene que correr en pruebas y en producción; lo único que cambia es el entorno |
Los cinco se ensayan en el simulador, que es donde puedes forzar los desenlaces malos, y se repiten en el sandbox, que es contra lo que se valida. → Conducir el ciclo
La precertificación, antes de pedir la reunión
Pídele al agente que precertifique tu integración. Recorre lo que la reunión va a validar, lo comprueba con hechos en vez de a ojo, y te deja el resultado por escrito — lo que pasó, lo que falta y lo que no se puede comprobar sin mover dinero.
Precertifica mi integración de SPIDI antes de pedir la reunión.
Para qué sirve, en una frase: que la reunión no sea el sitio donde te enteras.
Cubre lo funcional y lo de pantalla: los cinco hechos de arriba y los cuatro elementos obligatorios, que también se validan.
Y lo que no hace, dicho ahora: no sustituye la reunión, no aprueba nada, y no ejecuta un débito — ni en el SDK ni en producción. Lo que no se puede comprobar sin mover dinero real te lo dice, no lo intenta. → Trabaja con el agente
Lo que cambia el día que pasas
Las credenciales. Las de producción son otras y llegan por el paso 4. Las de pruebas no sirven, y no hay una forma de "promover" una cuenta.
Nada más debería cambiar. Si tu configuración vive en el entorno y no en el código, pasar a producción es cambiar unas variables. Si tienes que tocar código, es señal de que había algo incrustado que no debía estar.
Antes de pedir la reunión
Un repaso corto:
- ¿Tu endpoint de avisos es público y alcanzable desde fuera? Un endpoint que solo responde en tu máquina funciona en pruebas y no en producción.
- ¿Ensayaste los desenlaces que no son el pago exitoso?
- ¿El copy y el aspecto del botón siguen los lineamientos?
- ¿Tienes los datos formales de la empresa a mano para el paso 3?