Before going live there are a number of scenarios that must be considered in order to provide a complete integration. Some of these are items within your own codebase that Zip do not revise explicitly and are expected to be completed by the time you provide access for [Certification](🔗) .
## Edge cases
Ensure you thoroughly test your integration, including scenarios with:
Duplicate data (e.g., retry the same request to see what happens)
## Timeouts and repeat transactions
There will inevitably be times when no response is received due to connection issues or similar. When this occurs, Zip expect transactions to be re-attempted until a valid response is received or until a timeout period expires.
### Transactional API calls
Other API calls require retry attempts to be identified to prevent double charges and also to avoid duplicate reference errors for the order reference being passed.
Any _Transactional_ API calls to the /charges or /tokens endpoints for example will need to use the same 'Idempotency-key' in the header as the original request to flag this.
The timings of these retries is reccomended as follows:
|**Attempt Number**||**Delay before attempt (seconds)**||**Timeout period (seconds)**||**Total Time elapsed (seconds)**|
If this total 60 seconds has elapsed without a valid response, queue asynchronously and present “Order is still being processed, you will receive an email once complete” message if possible.
Otherwise – if outside your overall page timeout set status of Order in your system to “Charge Error” and manually reconcile later.
## Review your logging
We recommend that you log all important data on your end. Your own logs will be a extremely valuable if your server has a problem contacting Zip or there's an issue with your API keys—both cases would prevent us from logging your request.
Regularly examine your logs to ensure they're storing all the information you may need and they aren't storing anything of a sensitive nature. Check if you identify any recurrent error which may require some adjustment in your integration.
## Change and secure your API keys
Make sure you keep your API credentials private.
## Error codes
The API uses consistent error responses and follows REST status code conventions where appropriate.
In order to provide more information or a sub-division of status codes an Error object is returned for all non 2xx status codes. The Error object contains a more specific code and error message.
The status codes that may be returned from the API are detailed below:
|2xx||OK Everything worked correctly.|
|400||Bad Request There is an error in the request object.|
|401||Unauthorized No valid API key provided.|
|402||Request Failed Request could not be processed, see error code for more information.|
|403||Forbidden Operation is not allowed (customer did not authorise action).|
|404||Not Found The resource does not exist.|
|409||Conflict The request is a duplicate of a previous request|
|429||Too Many Requests Requests are rate limited - you are making too many requests.|
|5xx||Server Error An error has occurred on zipMoney's end.|
Specific error codes for each endpoint are detailed on the appropriate endpoint page.
For BadRequest responses you can find the specific error detail in the details section of the Error object.
Once you are confident you have completed your integration, it's time to complete [certification](🔗)