HTTP response codes

HTTP code	Description
`200`	Request executed correctly
`400`	Incorrect request, invalid request payload
`401`	Unauthorised access. Requesting a resource that requires authentication. Please ensure you are providing the correct authorisation token.
`403`	No authority to execute the request
`404`	Unknown resource. You can find information on how to handle this error below.
`406`	The request is valid, but contains values that cannot currently be accepted. This error will be returned if a payment method or channel is used that is inactive in the shop, or if its availability is temporarily restricted globally. You can find information on how to handle this error below.
`422`	The request does not contain the required parameters, contains unacceptable parameters, or the values sent in them do not meet the requirements. You can find information on how to handle this error below.
`500`	An error has occurred with the payment method provider's server or the imoje server. You can find information on how to handle this error below.
`503`	System unavailable. You can find information on how to handle this error below.
`504`	Gateway timeout. You can find information on how to handle this error below.

Handling response codes

404

Error code 404 means that you are sending a request to an endpoint that we have not defined. Check the Endpoints section or refer to the RESTful API Methods and ensure that the endpoint you are using exists and has been formulated correctly.

406

You may encounter this error if you try to create a transaction for a payment method or channel that is inactive in your shop, or if we have temporarily disabled it globally due to a system failure or scheduled maintenance.

You can avoid this error entirely by checking the availability of payment methods and channels. You can do this by using the request for available payment methods or the request for shop details. Both solutions return the key parameter isOnline, which you can use to display or, for example, grey out individual payment methods and channels.

See error example

422

Please ensure that all parameters and values sent in the request comply with our requirements. Pay particular attention to the data types and characters allowed for each parameter you wish to use. You will find the allowed character sets in the Body section of each request.

See example error

500

This is an error that can occur suddenly, so it's worth being well prepared for it to ensure that payment processing isn't disrupted too much and that users don't encounter any problems completing their orders. This error usually occurs when you attempt to create a transaction for a payment method and channel where there is a communication issue with various payment systems, e.g. due to a system failure, and our system has not yet had time to apply the appropriate availability limit.

How best to handle error 500?

In such situations, we recommend disabling the relevant payment channel in your system for a few minutes to prevent users from encountering further errors. You can then take one of the following actions:

Allow users to retry the payment by selecting a different method or channel.
Do not display the error to users, or customise the message accordingly and, as soon as it appears, generate a payment link and redirect them directly to it. To ensure that the user does not select the same method/channel again on our gateway, use the visibleMethod and specify there all the payment methods you want, excluding the method where the error occurred.

If we detect an excessive number of 500 errors, we will endeavour to impose a limit on the relevant payment method/channel as soon as possible. Any attempt to create a transaction in such a situation will result in a 406 error. Please ensure that you are also aware of how to handle this error.

See example error

503 and 504

These errors indicate that there are issues with the availability of our system. If you encounter any of them, it is best to temporarily disable the imoje payment option in your application and check the status of the situation after, say, 5 minutes by sending a single GET request.