Skip to main content
PCI Booking API responses use standard HTTP status codes combined with application-specific return codes. Error responses include a numeric code and human-readable message and moreInfo fields.

Success Codes

Error Response Format

Error responses are returned as an ErrorBlock, in the same format as the request. For JSON requests:
For XML requests:

Application Error Codes

Common Causes for Frequently Misread Codes

Two codes are consistently misread because their generic text doesn’t match their most common real-world cause:
The message “Unauthorized” or “Not authorized to access this resource” reads like an auth/permissions bug, but on a token-related call it most often means:
  • The token was deleted or never existed. By far the most common cause - check whether the token was deleted (deletions are permanent) or whether a prior tokenization actually succeeded.
  • The token belongs to a different environment. A sandbox-created token cannot be accessed from a production account, or vice versa.
  • The account is blocked or terminated. Check account status before assuming it’s a credentials issue.
  • Actual authentication failure (invalid API key, expired session token) is possible but less common than the above for this code.
“Internal server error” sounds like a PCI Booking-side bug, but it most often means:
  • The request body is malformed - commonly an invalid credential structure (wrong field names for the gateway) rather than an actual server fault.
  • A tokenization attempt failed upstream. If a tokenization silently failed, any later action on the token you expected to exist will surface as -1003 rather than repeating -150.

HTTP Status Code Mapping

PCI Booking maps application errors to standard HTTP status codes: