Skip to main content
When a Payment API request fails, Quidkey returns a consistent JSON envelope and a meaningful HTTP status code. Use the status code and code for programmatic handling, and message for logging.

Error Envelope

Every error response has success: false and an error object:
Always branch on error.code, never on error.message. Messages may be reworded over time; codes are stable.

HTTP Status Codes

Validation Errors (400)

A 400 indicates the request body or parameters failed validation. The error.metadata.errors array pinpoints each offending field, so you can surface precise feedback.
Amounts are integer minor units: 1999 means £19.99, not £1,999. Sending a decimal or a major-unit value is a common source of 400 validation errors. See Amounts & Currencies.

Cross-Tenant Access Returns 404

If you request a resource that exists but belongs to another merchant, Quidkey returns 404, not 403.
This is deliberate. A 403 would confirm the resource exists, leaking information across tenants. Quidkey returns 404 so a resource you cannot access is indistinguishable from one that does not exist. Do not treat a 404 as proof a payment was never created.

Authentication & Permission Errors

Error Codes

Branch on these stable error.code values:

Handling Errors

Body abbreviated. See the Redirect guide for the full required payload.
Retry guidance: retry 409, 503, and 500 with exponential backoff. Do not blindly retry 400, 401, 403, 404, or 410; fix the request or credentials first.

Next Steps

Idempotency

Safe retries for create requests

Authentication

Resolve 401 errors with token refresh

Amounts & Currencies

Avoid the most common validation error

API Reference

Response format and conventions