Troubleshooting

“Test connection” fails

SIS0042 / signature error: the terminal key is wrong, belongs to the other mode, or the signature version does not match the terminal. Copy the key again from the Redsys portal (for HMAC_SHA256_V1 the older Base64 key).
SIS0026 / SIS0028: merchant code or terminal number wrong, or the terminal is not active.
SIS0027: the order currency is not enabled on the terminal.
Check the mode: test values only work in test mode and live values only in live mode.
Check for spaces before or after the merchant code and key.
The Log tab shows the answer (masked). The test sends a harmless refund request for an order that does not exist; “SIS0054 no operation exists for the refund” is the expected, good answer.
Your server must be able to reach sis.redsys.es (443) and, for tests, sis-t.redsys.es on port 25443, and have a current CA bundle.

The customer sees a Redsys error page

SIS0051 repeated order number: the add-on creates a new number for every attempt; this only happens when two stores share a terminal and collide, or the clock of an old backup repeats ids. Try again.
SIS0042 on the payment page: key, terminal or signature version wrong (see above).
SIS0430: the data could not be decoded. A proxy or filter changed the form; whitelist the checkout page.
The payment method does not show up at checkout: the add-on is disabled, unlicensed or the connection page is incomplete.

The order stays unpaid although the customer paid

Redsys must reach kv_redsys.webhook over HTTPS on the standard port. Check the Log for “Rejected” lines (bad signature, unknown order). Without a valid signed notification the add-on never marks an order paid.
Look at the operation in the Redsys portal (Consultas) and at its “Notificaciones” section.
A payment without any answer expires after 3 days (cron needed); a late notification still settles it.
“Notification amount or currency differs from the order”: the signed answer is for another amount; the order was not marked paid. Check the order for edits after checkout.

Nothing happens after an order changes status

Check Settings > General > Enable and the order status settings.
Check the license status bar on the add-on pages.
Open Jobs: queued jobs wait for cron. If the counts never change, the cron job is not running; run the command from the settings page by hand once.

A job is “Waiting to retry” or “Gave up”

The last error is shown in the list. Fix the cause (credentials, data, provider outage) and press Retry. Jobs are retried automatically after 5 minutes, 15 minutes, 1 hour, 3 hours and 12 hours before they give up.

Notifications are rejected

The terminal key and signature version on the Connection page must be the ones of the same mode.
The notification address must be reachable from the internet over HTTPS on the standard port, not behind a login, a firewall that only allows known IPs (Redsys does not publish its IP addresses) or a bot challenge.
Rejected notifications are listed in the log with the action “webhook”.

A refund shows “result unknown”

Redsys did not answer clearly (timeout, issuer unavailable). Look the operation up in the Redsys portal. If the refund is there press It was executed, otherwise It was not executed on the order tab. The add-on never repeats such a refund by itself because Redsys could refund twice.

The cron address answers “Forbidden”

The key in the address is wrong. Copy the address again from the settings page.

Still stuck

Contact us through https://cs-cart.kaviolabs.com with the add-on version, the CS-Cart version and the relevant log lines (secrets are masked automatically).