The error codes below are for illustrative purpose only. Please refer to the API specifications for the full list of error codes.
HTTP Status Code | Meaning | Definition | Best Practices |
---|
400 | Bad Request | This error code indicates that the request from the partner is a bad request. | - Client should log the error codes and error responses for each transaction.
- As a process workflow, the partner can then open a ticket with Blackhawk Network or if possible (where applicable)
|
409 | Error - No Further Processing Possible | This error code indicates that there is no further processing possible unless the situation causing the error is resolved. | - Client should log the error codes and error responses for each transaction.
- As a process workflow, the partner can then open a ticket with Blackhawk or if possible (where applicable)
|
502 | Timeout | This error code indicates that there is a timeout when sending response from the API Services to the client. | - Client should set the timeout setting to be 30 secs on their end.
- In case of a 502 error the client should issue a reverse Transaction call for the attempted request Id. This will help to cancel or rollback that transaction and assures no funds are collected from the partner as part of the original failed transaction.
- Based on the partner workflow, the timeout request can be retried as a new request.
- The retry attempt should be limited to X times to avoid any inventory implications. The X times can be determined based on the partner use case and needs to be determined during implementation.
|
503 | Service Unavailable | This error code indicates that the service is unavailable. This error can occur when the underlying API services are also unavailable. | - Client should set the timeout setting to be 30 secs on their end.
- In case of a 503 error the client should issue a reverse Transaction call for the attempted request Id. This will help to cancel or rollback that transaction and assures no funds are collected from the partner as part of the original failed transaction.
- Based on the partner workflow, the timeout request can be retried as a new request.
- The retry attempt should be limited to X times to avoid any inventory implications. The X times can be determined based on the partner use case and needs to be determined during implementation.
|
504 | Timeout | This error code indicates that there is a timeout between the API services and the provider. | - Client should set the timeout setting to be 30 secs on their end.
- In case of a 502 error the client should issue a reverse Transaction call for the attempted request Id. This will help to cancel or rollback that transaction and assures no funds are collected from the partner as part of the original failed transaction.
- Based on the partner workflow, the timeout request can be retried as a new request.
- The retry attempt should be limited to X times to avoid any inventory implications. The X times can be determined based on the partner use case and needs to be determined during implementation.
|