Retry schemes

Retrying failed exchanges

When PAY. calls your Exchange URL after a status update, our system will wait no more than five seconds for a response. However, it is possible that your server is not available just then or that a number of taxing processes are running that keep the server from responding in time. In that case, we will terminate the exchange call and view the request as failed. This may mean that your server has not processed the status update (correctly) and that the order status listed in your own back office does not match the one in PAY.’s Admin Panel.

To resolve this issue, you can use a so-called “retry scheme.” This ensures that the exchange call is repeated (a number of times) at a later time until we have received a correct response. When setting up a retry scheme, you can select the maximum number of times to repeat the call. If your script has not sent the correct response yet once this number has been reached, we will notify you via email. PAY. advises all merchants to use Retry Scheme. Here is how to set it up:

Select the Sales Locations tab in the Global Management System and click on “edit” next to the sales location for which you want to set up a retry scheme.

Specify how many times you want the call to be repeated with the “Repeat call” field. For most merchants, “six times within a two-hour period” is the recommended setting. Remember to save your changes.

📘

An email on latest retry option

If you do not activate a retry scheme and the exchange fails or if you do have a retry scheme and the last attempt fails, we will send an e-mail. You set the people via merchant -> users-> edit and then activate the 'technical problems' option.

Intervals

The table below shows the time between the various repeat calls.

Triggering the Retry Scheme

GET & POST Exchanges (Legacy)

When using standard GET and POST methods we will mark an exchange as "success" if your server's response begins with the word "TRUE". Any response that does not start with "TRUE" will be marked as "failed" and will kick in the Retry Scheme when turned on in the Global Management System.

Valid response:

TRUE

Valid response when using the exchange seperator:

TRUE|YOUR COMMENT

📘

Update the Seperator

If you like to use another Seperator, update the settings in the GMS

Valid but failed response, this will trigger the Retry Scheme:

FALSE|YOUR COMMENT

Invalid response, this will trigger the Retry Scheme:

ANYTHING OTHER THAN: TRUE

JSON Exchanges

When exchanging with JSON we'll expect the response to be in JSON format. Herein on the main level the "result" key is used to determine a "success" or "failed" exchange.

Valid response:

{
  "result": true
}

Valid result with custom data:

{
  "result": true,
  "description": "Exchange is marked as successful"
}

Valid but failed response, this will trigger the Retry Scheme:

{
  "result": false,
  "description": "Exchange is marked as failed"
}

Invalid response, this will trigger the Retry Scheme

{
  "description": "Exchange is marked as failed"
}