Saltar al contenido principal

Usar el simulador de pruebas

El simulador es un sandbox hosteado que emula el contrato de la API Productos de SPIDI: la máquina de estados de la sesión, la acreditación a dos tiempos y los webhooks firmados. Te registras, obtienes tus credenciales y trabajas en tu propio espacio aislado — nadie más ve ni afecta tus datos de prueba. Todo sin tocar producción ni mover dinero real.

¿Por qué un simulador?

El entorno de pruebas en vivo no deja forzar un paid o un failed (el pago es un formulario real) ni dispara webhooks de prueba. El simulador sí: provocas el desenlace que quieras y recibes el aviso firmado, de forma reproducible.

Usar el simulador de pruebas (sandbox hosteado)

Paso 1 — Regístrate​

Una llamada te da tu token (para autenticarte) y tu webhook_secret (para verificar tus avisos). Son tuyos: todo lo que crees queda aislado bajo tu cuenta.

curl -X POST https://sim-productos.abiertolab.com/register \
  -H "Content-Type: application/json" \
  -d '{"short_name":"mi-tienda","password":"demo"}'

Respuesta: { "account_id": "...", "token": "...", "webhook_secret": "whsec_..." }. Guárdalos. ¿Perdiste el token? Recupéralo con POST /api/spidipagos/login (mismas credenciales).

Paso 2 — El plano de control​

Lo que el entorno en vivo no permite: provocar el desenlace. Vive en /control/*, va autenticado con tu token y solo afecta tus datos.

# forzar el desenlace de una sesión
#    leg 1 = débito:        outcome = paid | failed | expired
#    leg 2 = acreditación:  outcome = accredited
curl -X POST https://sim-productos.abiertolab.com/control/sessions/<session_id>/outcome \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"leg":1,"outcome":"paid"}'

# limpiar TU estado entre pruebas (no toca a nadie más)
curl -X POST https://sim-productos.abiertolab.com/control/reset -H "Authorization: Bearer <token>"

También hay una pantalla /pay/:id con botones Pagar · Rechazar · Expirar para demostrarlo a mano en el navegador y redirigir a success_url / failure_url como en una integración real.

Para recibir webhooks

El simulador hosteado entrega el aviso a tu webhook_url por HTTP. Debe ser una URL accesible desde internet (por ejemplo, un túnel como ngrok, o tu servicio desplegado). Un localhost no es alcanzable desde el simulador hosteado.

Qué emula y qué no​

  • Sí: responde la API Productos validando contra la OpenAPI · fuerza paid/failed/expired y lo refleja en GET status · emite webhooks firmados (HMAC) con reintentos e idempotencia · acredita a dos tiempos · aísla por cuenta.
  • No: no mueve dinero real ni habla con bancos · no reproduce la lógica interna de SPIDI (solo el contrato) · aún no cubre la API Merchant/POS.

Siguiente paso​

¿Listo para integrarlo? → Recibe tu primer pago, que corre contra este simulador de punta a punta.

¿Contribuyes al simulador? También puede correrse localmente (MySQL 8.4 + npm run dev, o docker compose up) para desarrollo y CI. Eso vive en el repositorio del proyecto (simulador/, dev-services/), no es necesario para integrar contra el sandbox hosteado.