Environments, testing and local development
16.1 Testing without risking money
Creating a payment charges nothing: it stays pending until someone pays it. To test safely
against production: a minimal amount (L 1.00) and a near-term expires_at, and do not pay it. The
link expires on its own. Triggering 401 / 404 / 422 errors is equally harmless.
16.2 Sandbox test cards
Use these only with sk_test_ / pk_test_ keys. Any future expiry date; name and email can be
test values.
| Brand | PAN | CVV |
|---|---|---|
| Visa | 4012000000020071 |
3 digits |
| Visa | 4333333333332222 |
3 digits |
| Amex | 343333333333335 |
4 digits |
Prefer the two Visa numbers. No forced-decline or 3-D Secure scenario cards are published, so declines and authentication challenges still cannot be simulated deliberately - handle those states defensively even though you cannot exercise them on demand.
16.3 If sandbox rejects every creation
An sk_test_ key can authenticate correctly and still fail to create payments with:
422 "El entorno sandbox no esta configurado para enlaces de pago.
Contacte a soporte ROKI o use su clave API live."
That is not the key's fault and not the code's, and regenerating the key does not fix it: the sandbox terminal is not provisioned for that merchant. Ask ROKI to enable sandbox for the account.
16.4 Receiving webhooks in local development
ROKI must reach a public HTTPS URL, so localhost will not work. Options:
- A tunnel (ngrok, Cloudflare Tunnel), registering the generated URL in the portal under the sandbox environment.
- To only inspect events without writing code, a temporary public receiver (webhook.site and similar), useful for seeing the real payload and headers.
Remember to register the final URL before going to production: tunnel URLs change.