Entornos, pruebas y desarrollo local

16.1 Probar sin arriesgar dinero

Crear un pago no cobra nada: queda en pending hasta que alguien lo pague. Para probar sin riesgo contra producción: un monto mínimo (L 1.00) y un expires_at cercano, y no lo pagues. El enlace vence solo. Provocar errores 401 / 404 / 422 es igual de inofensivo.

16.2 Tarjetas de prueba de sandbox

Usá estas solo con llaves sk_test_ / pk_test_. Cualquier fecha de vencimiento futura; el nombre y el correo pueden ser valores de prueba.

Preferí los dos números Visa. No hay publicadas tarjetas para escenarios de rechazo forzado ni de 3-D Secure, así que los rechazos y los desafíos de autenticación siguen sin poder simularse a propósito - manejá esos estados de forma defensiva aunque no los puedas ejercitar a demanda.

16.3 Si el sandbox rechaza toda creación

Una llave sk_test_ puede autenticar correctamente y aun así fallar al crear pagos con:

422 "El entorno sandbox no esta configurado para enlaces de pago.
     Contacte a soporte ROKI o use su clave API live."

Eso no es culpa de la llave ni del código, y regenerar la llave no lo arregla: la terminal de sandbox no está aprovisionada para ese comercio. Pedile a ROKI que habilite el sandbox para la cuenta.

16.4 Recibir webhooks en desarrollo local

ROKI tiene que poder alcanzar una URL HTTPS pública, así que localhost no va a funcionar. Opciones:

• Un túnel (ngrok, Cloudflare Tunnel), registrando la URL generada en el portal bajo el entorno sandbox.
• Para solo inspeccionar eventos sin escribir código, un receptor público temporal (webhook.site y similares), útil para ver el payload y los encabezados reales.

Acordate de registrar la URL final antes de pasar a producción: las URLs de los túneles cambian.