Error Code Reference

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.

Did this page help you?