Resolución de problemas
1. Introduction
As soon as you start working with our platform, sooner or later it happens: You get stuck. You receive cryptic error messages and our platform rejects your transaction requests.
But fear not: We have the tools that will help you. We have designed our platform to give you the greatest autonomy in your daily online transaction business, even when confronted with errors.
Have a look at our best practices, our troubleshooting tools and explanations of the most common error messages. They will help you greatly to prevent and solve transaction trouble!
2. Follow Best Practices
The best way to tackle down errors is – of course – to avoid them in the first place. Although this is not possible in all cases, we have created a list of best practices. Following them will help go live faster by dodging the most common obstacles:
- Always use our Entorno de prueba first before going live or adding a new feature to your live shop. Both our Entorno de prueba / nav.aside.title.get-started.live-environment treat transaction request in the same way. As the expected behaviour and error messages are the same, it is an ideal way to test for any imponderables or stage scenarios
- Read the dedicated guide for the respective product carefully. Make sure to know the correct endpoint URL and all accepted parameters. Start sending requests with the absolute minimum of mandatory parameters to learn the basics of the respective product. This is especially helpful when dealing with alternative payment methods that require a lot of parameters.
- Check that the payment method you want to use is activated in your Back Office (Configuration > Payment Methods) and targeted in your request with parameters PM/BRAND
- Confirm that the option you want to use is activated in your Back Office (Configuration > Account > Your options)
- Be aware that we offer different ways to integrate with our platform. All of them require an individual approach
- Use the shopping cart plugins we natively support. As they come from certified providers, they have been thoroughly tested to create requests correctly
- Understand the meaning of transaction status codes and the transaction error codes. They help you find the cause of failed requests.
- Distinguish failed requests from unsuccessful payments
-
- A failed request is the result of an unsuccessful pre-payment check by our platform. In most cases, impacted transactions do not have any status at all. They often appear in our secure payment page with a generic error message. These are invalid requests containing technical errors that prevent our platform to process the transaction altogether. Our system adds them to our Back Office error logs with more detailed information. Have a look at the most typical ones and how to treat them.
The image shows a typical generic error message on our secure payment page.
An unsuccessful payment is a transaction with either status 0/1/2. This is the result of a technically valid request, albeit rejected by a third party (by the acquirer or issuer). To learn about the rejection reason, look up the transaction in the Back Office (Operations > View transactions). The acquirer ticket and the 8-digit error message in the transaction overview contains more information.
The images shows the acquirer ticket and the 8-digit error message in the transaction overview
However, failures like these can still be caused by an error on our platform in specific situations. Make sure to contact us if your transaction decline rate is above average.
- Allow free traffic between your server and our platform by following our Firewall documentation.
3. Use troubleshooting tools
Apart from our best practices, we offer you various diagnostic tools. In many cases, they will help you get to the root cause and amend the error completely on your own!
- Every error analysis requires you to understand during which step exactly the error occurs. Have a look at this decision tree to learn where you need to fix your transaction flow:
The flow chart shows the different scenarios of erroneous transactions and how to deal with them
If our platform rejects a transaction, we create a log entry in the Back Office of the PSPID the transaction was sent to. Go to Configuration > Error logs to check them. The table provides valuable information to understand what went wrong and what you can do to fix the error
Column | Description |
---|---|
Date time |
Timestamp of the request |
Mode |
Integration mode trigram. Possible values: DPR: DirectLink AFU: Batch (advanced) THP: FlexCheckout
|
Requestor’s IP address |
The IP the request was sent from |
PAYID |
Unique reference of the transaction in our system. Is only created if the mandatory parameters are sent correctly |
Description |
Detailed description of the error. Check our list for the most common error messages |
- We offer pages in our Back Office you can use to simulate different integration modes. Go to Support > Integration and user manuals > Test pages. Choose one of the available modes by clicking on “.asp” in the respective line. In the subsequent screen, fill in the first set of parameters (which are the mandatory parameters for each integration). Click then on “Submit” to send the request.
- We constantly monitor our platform to react quickly for any unforeseen events that may impact your online business – something you can do, too! Enrol with our status page to be always up to date for outages and planned maintenance. This will help you distinguish problems on our platform from errors on your end.
The image shows the Ingenico status page displaying a notification about a service interruption for one our acquirers.
4. Understand error messages
An important part of amending errors is to know exactly what they mean. We have collected the most common ones with some detailed explanation. All these error messages appear either in the
- Customers’ browser during the payment process
- Back Office (Configuration > Error logs)
- XML response you receive for DirectLink / FlexCheckout requests
Find more errors and how to deal with them in our Códigos de error de transacciones overview.
-
Show Hide
Unknown order/1/s/
Why do I get this?
The value you send along with the transaction for parameter SHASIGN does not match with what we expected.
For which integration modes can this happen?What can I do to solve this?
Make sure to calculate SHASIGN as explained in our documentation.
-
Show Hide
Unknown order/0/s/
Why do I get this?
You do not send the mandatory parameter SHASIGN in your transaction request.
For which integration modes can this happen?What can I do to solve this?
Make sure to send SHASIGN with your transaction request as explained in our documentation.
-
Show Hide
unknown order/1/r/
Why do I get this?
- Our platform does not recognise the referrer you have configured in Configuration > Technical information > Data and origin verification > Checks for e-Commerce & Alias Gateway > URL of the merchant page containing the payment form that will call the page: orderstandard.asp
For which integration modes can this happen?
What can I do to solve this?
- Enter the correct value for the deferrer in the Back Office. The deferrer is the URL sending requests to classic.urltestorderstandard_utf8.asp / classic.urlprodorderstandard_utf8.asp
- As this is not an obligatory check, leave the field empty. Our platform will not perform this check altogether
-
Show Hide
unknown order/0/r/
Why do I get this?
- Our platform does not receive the referrer you have configured in Configuration > Technical information > Data and origin verification > Checks for e-Commerce & Alias Gateway > URL of the merchant page containing the payment form that will call the page: orderstandard.asp.
For which integration modes can this happen?
What can I do to solve this?
- Make sure that your system does not block the transfer of the referrer information when making transaction requests to our platform. In some cases, your customers’ browser blocks the transfer as well. In a scenario like this, we will skip this check if the SHASIGN value is correct
- Enter the correct value for the deferrer in the Back Office. The deferrer is the URL sending requests to classic.urltestorderstandard_utf8.asp / classic.urlprodorderstandard_utf8.asp
- As this is not an obligatory check, leave the field empty. Our platform will not perform this check altogether
-
Show Hide
unknown order/1/i/
Why do I get this?
- Our platform does not recognise the IP address you have configured in Configuration > Technical information > Data and origin verification > Checks for DirectLink and Batch (Automatic) > When using these transaction submission modes, login details have to be transmitted in the HTTP parameters.
For which integration modes can this happen?
What can I do to solve this?
- Enter the correct IP address(es) in the Back Office from which requests are sent to our endpoints for DirectLink / Worldline Fichero de Lote (avanzado)
- As this is not an obligatory check, leave the field empty. Our platform will not perform this check altogether
-
Show Hide
50001111
Why do I get this?
- This is a generic error message for data validation errors. It will appear in one of the following scenarios
- You send wrong data in parameters USERID / PSWD
- Your transaction request is missing one or more mandatory parameters
- Parameters sent to our platform contain no values or invalid values
For which integration modes can this happen?
What can I do to solve this?
- Configure your API user and API password in both your system and in the Back Office
- Make sure to send all mandatory parameters correctly as described in our documentation for the respective integration mode.
-
Show Hide
50001184 - SHA signature mismatch
Why do I get this?
- The value you send along with the transaction for parameter SHASIGNATURE.SHASIGN does not match with what we expected.
For which integration modes can this happen?
What can I do to solve this?
- Make sure to calculate SHASIGNATURE.SHASIGN as explained in our documentation.
-
Show Hide
55555555 - <parameter> missing or incorrect format
Why do I get this?
- One of the mandatory FlexCheckout parameters is missing in your transaction request. “<parameter>” acts as a placeholder for this error message. If you do not send Account.PSPID, the error message will be “55555555 – Account.PSPID missing or incorrect format”
For which integration modes can this happen?
What can I do to solve this?
- Make sure to send all mandatory parameters correctly as described in our documentation
-
Show Hide
Connection to API feature not allowed for this user
Why do I get this?
- You send credentials of a non-API user in parameters USERID / PSWD.
For which integration modes can this happen?
What can I do to solve this?
- Make sure you have an API user and send its credentials in your requests.
-
Show Hide
PSPID not found or not active
Why do I get this?
- The name of the account you send in parameter PSPID does not exist or is not active yet.
For which integration modes can this happen?
What can I do to solve this?
- Check the name of your account and that is sent correctly in parameter PSPID
- Mind that we have both a Entorno de prueba / Entorno de producción. The name of your accounts may differ per environment
- Check your account’s activation status in the Back Office via Home > Informative steps. Contact us if you need help identifying / activating your PSPID
-
Show Hide
no <parameter>
Why do I get this?
- One of the mandatory parameters is missing in your transaction request. “<parameter>” acts as a placeholder for this error message. If you do not send PSPID, the error message will be “no PSPID”
For which integration modes can this happen?
What can I do to solve this?
- Check the documentation of the respective integration mode for the mandatory parameters.
-
Show Hide
<parameter> too long
Why do I get this?
- The value sent for a specific parameter exceeds the maximum length. “<parameter>” acts as a placeholder for this error message. If PSPID is impacted, the error message will be “no PSPID”
For which integration modes can this happen?
What can I do to solve this?
- Look up the parameter in our Parameter Cookbook. Define the value as described in columns “Format” / “Max length”
-
Show Hide
amount too long or not numeric: … / Amount not a number
Why do I get this?
- The value sent for parameter AMOUNT exceeds the maximum length and / or contains invalid characters.
For which integration modes can this happen?
What can I do to solve this?
- Look up parameter AMOUNT in our Parameter Cookbook. Define the value as described in columns “Format” / “Max length”.
-
Show Hide
not a valid currency : …
Why do I get this?
- The value sent for parameter CURRENCY is invalid.
For which integration modes can this happen?
What can I do to solve this?
- Look up parameter CURRENCY in our Parameter Cookbook. Define the value as described in columns “Format” / “Max length”.
-
Show Hide
The currency is not accepted by the merchant
Why do I get this?
- The value sent for parameter CURRENCY has not been added to your PSPID.
For which integration modes can this happen?
What can I do to solve this?
Log on to the Back Office and go to Configuration > Account > Currency. Select the missing currency from the drop down menu and click on “Add”
-
Show Hide
ERROR, PAYMENT METHOD NOT FOUND FOR
Why do I get this?
- The payment method you want to target with parameter PM and / or BRAND has not been added / activated in your PSPID.
For which integration modes can this happen?
What can I do to solve this?
- Log on to the Back Office and go to Configuration > Payment methods. Check whether the payment method is “Active” in column “Status”.
- In our Entorno de prueba, you can activate any inactive payment method on your own by accessing the payment method via the green pen symbol > PM activation. You can also add any new payment method via Configuration > Payment methods > Choose new payment method
Contact us to add / activate payment methods in our Entorno de producción.
-
Show Hide
Overflow in refund requests/x/xxx
Why do I get this?
- The transaction you want to refund cannot be refunded for one of these reasons:
- You have accidentally clicked the “Refund” button twice in the Back Office or a refund was already being processed when you clicked this button
- Your tried to refund an already refunded transaction or try to refund more than the original amount via a DirectLink / Worldline Fichero de Lote (avanzado) maintenance request.
For which integration modes can this happen?
- nav.aside.title.get-started.payment-platform-user-guides.maintain-your-transactions
- DirectLink maintenance
- Worldline Fichero de Lote (avanzado) maintenance
What can I do to solve this?
- Before you send your refund request, doublecheck the status of the transactions in the Back Office or via a DirectLink Query / Worldline Fichero de Lote (avanzado) download request.
-
Show Hide
Overflow in data capture
Why do I get this?
- You have tried to capture an amount that is bigger than the originally authorised amount.
For which integration modes can this happen?
What can I do to solve this?
- Before you send your capture request, make sure to send for parameter AMOUNT only what has been originally authorised.
- If a transaction has been partially captured before, send for parameter AMOUNT only the remaining amount to be captured
- You have tried to capture an amount that is bigger than the originally authorised amount.
-
Show Hide
This order is not authorized / This order has already been captured / This order is not settled
Why do I get this?
- You have tried to capture or refund a transaction that has not reached status 5 / 9 respectively
For which integration modes can this happen?
What can I do to solve this?
- Before you send your refund request, doublecheck the status of the transactions in the Back Office or via a DirectLink Query / Worldline Fichero de Lote (avanzado) download request.
- You have tried to capture or refund a transaction that has not reached status 5 / 9 respectively
5. Códigos de error de transacción
Puede encontrar más información sobre errores y estados de transacción aquí.
Si ha iniciado sesión en su cuenta de Worldline, encontrará todos los posibles errores y estados en la sección Guías del usuario del menú Asistencia.
Preguntas más frecuentes
Existen tres motivos por los que no puede reembolsarse una transacción. Debe tener en cuenta lo siguiente (con la condición de que la opción Reembolso esté activada en su cuenta):
- La transacción está en un estado "incompleto", por ejemplo, en estado pendiente o erróneo (91, 92, etc.) que no permiten la operación de reembolso.
- Si la transacción está autorizada (estado 5), en cuyo momento no se ha realizado todavía el pago, tiene que cancelar la autorización en lugar de solicitar el reembolso.
- El método de pago usado no admite la funcionalidad de reembolso, caso de determinadas tarjetas de débito, métodos de banca web y métodos de pago "fuera de línea", como la transferencia bancaria.
El mensaje "Se ha producido un error, vuelva a intentarlo más tarde. Si es el dueño o el integrador de este sitio web, inicie una sesión en el área de administración de Worldline para ver los detalles del error." es un mensaje de error genérico que aparece si se produce un problema técnico específico al solicitar la página de pago. No mostramos el error real en la página de pago, principalmente por motivos de seguridad, pero también para no confundir a los clientes.
En su cuenta de Worldline, en "Configuración" > "Registros de errores", puede buscar fácilmente los errores que se han producido cuando aparece el mensaje de error genérico. El significado real de estos errores se describe en la página Posibles errores.