Pruebas y simulador

El simulador de esta documentación

Cada página de la referencia incluye un playground que emula la API con JavaScript puro en tu navegador — no toca ningún servidor. Replica:

• Las validaciones y mensajes de error exactos de producción (auth, campos requeridos, 404s).
• Las formas de respuesta reales de cada endpoint.
• El estado compartido: lo que haces en una página se ve en las demás mientras no recargues. Un init aparece en /payment/pending y en /status; una tarjeta guardada con save_card: true aparece en GET /cards y sirve para charge-saved y suscripciones.

Reglas del sandbox simulado

Datos sembrados al cargar: una tarjeta demo (key: C8F0D2A1B3E4F5A6B7C8D9E0, [email protected]) y una transacción pendiente.

Flujo completo guiado (5 minutos)

1. POST /payment/init → copia la reference.
2. POST /payment/auth-setup con esa reference.
3. POST /payment/process con save_card: true → copia saved_card.key.
4. GET /status/:reference → verás APROBADO.
5. GET /cards → tu tarjeta está ahí.
6. POST /payment/charge-saved con tu card_key.
7. POST /subscriptions/create con el mismo card_key.

O pruébalo aquí mismo:

curl -X POST "https://api.wizpay.app/payment/init" \
  -H "x-wpay-key: wpk_sandbox_demo" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Mi primera prueba", "amount": 10, "id_currency": 1 }'

Ambiente de pruebas real (sandbox)

En la fase Sandbox tu sistema apunta a https://api-test.wizpay.app con tu API key de prueba (wtest_…, se genera desde el panel): dinero de mentira, flujo real. Es el primer paso del Pase a Producción.

Tarjetas de prueba (sandbox)

La lista completa y vigente vive en tu panel → Tarjetas de Prueba (sección Fase Sandbox). Las tarjetas registradas se validan como un emisor real:

• El CVV y la fecha de expiración deben coincidir exactamente con la tarjeta de prueba — si no, el cobro se rechaza (CVV incorrecto, Fecha de expiración incorrecta).
• Una fecha vencida rechaza con Tarjeta vencida, tenga o no tarjeta registrada.
• Las tarjetas con saldo se rechazan por Saldo insuficiente si el monto lo supera; saldo Ilimitado siempre aprueba.
• Las tarjetas con 3-D Secure devuelven PENDING_3DS: tu integración abre el step_up_url como popup (igual que en producción) y aparece el banco simulado de WizPay — el código del reto es 1234. Al completarlo, la transacción pasa a APROBADO.

Para el QR de sandbox, el código generado es escaneable de verdad: se paga con la billetera de prueba (o con POST /qr/simulate-pay/{reference}), y tu integración recibe la confirmación por el mismo stream de eventos que en producción.

Tarjetas de la fase Implementación

Cuando tu sistema pasa a Implementación, el sandbox queda atrás: pruebas contra https://api.wizpay.app con credenciales de TEST del procesador y las tarjetas oficiales de CyberSource (matriz 3-D Secure). Están en tu panel → Tarjetas de Prueba, sección Fase Implementación, organizadas por escenario: Frictionless (aprueba directo), Attempts (aprueba con intento) y Step-Up (abre el challenge real del banco).

Checklist antes de salir a producción

• La x-wpay-key de producción vive solo en variables de entorno del backend.
• return_url apunta a tu dominio real (o frontend_url configurado en el sistema).
• Manejas los 3 resultados de /payment/process (APROBADO, RECHAZADO, PENDING_3DS).
• El popup del Step-Up funciona (probado con una tarjeta enrolada en 3DS).
• Confirmas pagos por webhook o GET /status desde el backend — no solo por la redirección del navegador.
• Manejas 429 con Retry-After.
• Tu receptor de webhooks valida Authorization: Bearer y es idempotente por reference.