Orders not confirmed after a Redsys payment

Do not mark the order as paid because the buyer returned to the shop. Confirmation must come from Redsys's server-to-server notification, validated by the application.

Find the notification first

1. Look up the transaction in the Redsys Administration Portal by order number, merchant and terminal.
2. Check the configured notification URL and its exact result. Note the time and any error.
3. Correlate that time with the website's access log and the payment module's log. A test from the hosting itself does not prove that Redsys could reach the URL.

Secure notification setup

Use a maintained version of the Redsys integration for PrestaShop, WooCommerce or the relevant application. Configure the notification URL with HTTPS and a valid certificate as a Hostsuar security measure; do not downgrade the callback to HTTP to hide a failure. If the notification does not arrive, check the URL, certificate, chain, DNS, firewall and logs from the same moment, from an external network.

The application must not mark an order as paid just because the customer visited the return URL. Before confirming the payment, the server callback must:

• Verify Redsys's cryptographic signature with the configured key and reject any invalid signature.
• Check that the order number, merchant, terminal, currency, transaction type and exact amount match the pending transaction stored locally.
• Interpret the Ds_Response code according to Redsys's table and the transaction type before changing the order status.
• Prevent replays: record the transaction identifier and process each notification idempotently, without charging or confirming the same order twice.

Place a test order after updating or changing the module and confirm in the logs that both the HTTPS notification and all these validations complete correctly.

If Redsys shows the charge but the shop does not confirm it

Do not ask the buyer to pay again without checking the transaction. First check its result in Redsys and the local status to avoid a second charge. An HTTP 200 from the callback only proves its web response; the module log must also confirm the validation and the status change.

If the portal lets you resend the notification, use that feature only after fixing the cause and confirming that the integration handles repeats without duplicating effects. Do not build a manual notification or mark the order based on parameters in the browser URL.

This URL keeps the historical reference to SNI certificates, but a current failure should not be attributed to SNI without a TLS error that proves it. See the Redsys integration documentation and keep the keys and the test and production environments separate; never include the signing key in a ticket or screenshot.