Error Handling

HTTP Status Codes?

See Error and Status Codes for a list of HTTP Status Codes that might be returned.

A 400 Series Error is usually something that you can fix by changing something in your request. A 500 Series Error is usually something that you need to contact us ([email protected]) to look at. If we determine that a 500 Series Error can be fixed by you, we will try to change this error situation to a 400 Series Error in a future code release.

PCI does require us to be cryptic in the Error Messages that we return back; but for certain 400 Series Errors, we may return back something in the Error Message (EM) field of the JSON Response that indicates what might be wrong.

You should never get a HTTP Status Code of 400 on Production

If you are getting a HTTP Status Code of 400 on the Production Environment, that usually means you are not handling these errors correctly on your end. We strongly recommend completing the Production Certification Test in its entirety, specifically the portion where we recommend integrating your application with our API calls.

Use of HTTP Status Code 207?

You might get HTTP Status Code 207, when there is an Error while processing your Transaction due to some Upstream Process.
Everything on our end processed successfully:

  • Your request passed all our checks
  • Configuration is available to process your request
  • A record is created for your request (Transaction)

But an Error occurred in some Upstream Processing.

Customer Facing Error Messages?

We are a Server-to-Server Web Services (API) and we are not Customer Facing, so:

  • We do not provide User Friendly Error Messages.
  • We do not provide Error Details (because of PCI).
  • We do not recommend showing your Customers our Error Messages or Error Codes.
    Your Application should catch as many errors as possible before sending the Request to us. You should not use us (API Request) to check the Customer's Data Errors. Therefore, if your Application is catching the obvious errors and you are not exposing Error Details from your Application or from our API, then there shouldn't be a lot of unique Error Messages back to the Customer.