Developer documentation
Redsys test cards and sandbox guide
Validate your integration with Redsys test cards and your own sandbox credentials. Check the bank result, order and delivery as well as the buyer’s experience.
Redsys test cards: number, expiry date and CVV
| Scenario | Card | Expiry | CVV |
|---|---|---|---|
| Generic VISA · EMV3DS 2.2 | 4548810000000003 | 12/49 | 123 |
| Frictionless authorisation · EMV3DS 2.1 | 4548814479727229 | 12/49 | 123 |
| Challenge authorisation · EMV3DS 2.1 | 4548817212493017 | 12/49 | 123 |
| Decline · authenticate successfully in the simulator | 4548810000000003 | 12/49 | 999 |
12/49 is an example expiry date; Redsys accepts a future date. CVV 999 simulates a decline with the generic card. Complete authentication successfully in the simulator to check that decline.
Official Redsys test cards and environments
Also test challenge abandonment, browser reloads and late returns. When the result is uncertain, check the existing transaction before requesting another charge.
Prepare the test environment
- 1
Configure your Redsys test account
Save the FUC, terminal and sandbox secret supplied for your virtual POS. Production credentials are different. The generic Redsys demo account does not replace inSite activation for your merchant account. - 2
Generate an ap_test_ key
The API key fixes each checkout’s environment when it is created. Do not reuse an ap_live_ key during testing. - 3
Authorise the domain
Redsys inSite must allow the exact HTTPS origin where the card form loads. - 4
Configure the webhook
Use a public HTTPS URL and keep the sandbox signing secret on the server.
Test Bizum
In the sandbox used by our integration, use mobile number 700 000 000 (+34700000000). Amounts below €5 are authorised, amounts between €5 and €10 are declined, and amounts above €10 are not supported for testing. Confirm the conditions of the environment assigned to your terminal.
Check authorisation in the banking app, declines, abandonment and late callbacks. Bizum requires the bank to enable RTP; AndorPay does not automatically switch to a classic redirect flow when RTP is unavailable.
Test Apple Pay and Google Pay
Apple Pay
Apple Sandbox lets you check the payment sheet, eligibility and merchant session in Safari on a compatible device. The standard Redsys sandbox may decline X-PAY. Full authorisation requires the certification environment agreed with Redsys or your bank.
Google Pay
Under Settings → Rails → Redsys, select Test, enable Google Pay and save. The setting is stored per environment: enabling it in test does not enable it in production.
The integration uses Google TEST and gateway=redsys. The sheet can open without a production merchant ID, but authorisation requires X-PAY on the terminal and a card compatible with CRYPTOGRAM_3DS.
Test webhooks and prevent duplicate effects
| Case | Expected result |
|---|---|
| Valid signature | The endpoint accepts the exact body and returns 2xx. |
| Modified signature | Returns 400 before interpreting or applying the event. |
| Old timestamp | Rejects a difference greater than 5 minutes. |
| 500 response | AndorPay retains event.id and schedules redelivery. |
| Repeated event | Recognises event.id without repeating the business effect. |
| Out-of-order events | Decides from content and state, not just arrival order. |
Test recurring Redsys payments
A successful first payment does not validate an entire subscription. With tokenisation and recurring payments enabled on the test terminal, also check these scenarios:
| Case | Expected result |
|---|---|
| Sign-up and first transaction | Link the customer, consent, payment reference and subscription. |
| Later renewal | Verify a MIT transaction and its service period without repeating the initial purchase. |
| Declined or pending renewal | Do not extend access as though payment were confirmed; resolve the state before another charge. |
| Repeated notification | One payment must not extend the period twice or duplicate delivery. |
| Cancellation | Check its effective date and that no charge remains scheduled after cancellation takes effect. |
Criteria for completing testing
An authorisation and a decline must produce consistent states in Redsys, AndorPay and your application. A valid webhook triggers the intended effect once; an invalid signature does not trigger it; a pending payment does not cause a blind second charge.
Repeat the journey on desktop and mobile. Retain request_id, event.id and the internal order reference without logging API keys, secrets, PANs, expiry dates or CVVs.
Next steps
Additional technical documentation in Spanish: Webhook signatures and retries · Going live