HTTP Error codes
We follow industry standards for HTTP status codes and enrich them with detailed error information using the RFC 9457 Problem Details for HTTP APIs specification.Standard Status Codes
In general, codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided (e.g., a required parameter was omitted, etc.). Codes in the 5xx range indicate an error with our servers (these are rare).Problem Details
When an error occurs, we return a JSON response conforming to RFC 9457. For example, a typical error response might look like this:type: A URI identifier for the error type.title: A short, human-readable summary of the problem.status: The HTTP status code.detail: A human-readable explanation specific to the occurrence.instance: A unique identifier for the error occurrence (can be used in support/debugging).
Business unit errors
If your API key is linked to more than one business unit, every request must identify the target business unit with theMoment-Business-Unit header. A key linked to a single business unit can omit the header.
A
403 business_unit_access_denied does not mean the API key is invalid. The key authenticated successfully, so rotating it does not help. Check that the business unit is one the key is entitled to use.
Application Error Codes
In addition to HTTP status codes, we provide application-level error codes for granular insight into what went wrong during a payment operation.Error Object
When a payment attempt fails, the failure is recorded in the last_payment_error field of the response. This object is included in payment related responses and has the following structure:error_code: A general error code indicating the high-level reason for failure, (e.g.card_declined). See Error Codes.decline_code: A more specific code that explains why a card transaction was declined, typically provided by the issuing bank, payment processor, or credit card network. (e.g.insufficient_funds). See Decline Codes.message: A human-readable message describing the error.timestamp: An ISO 8601 timestamp indicating when the error occurred.
Error Codes
A general error code indicating the high-level reason for failure. The following are the possible values for thecode field, along with their descriptions:
Mandate Error Codes
When processing payment sessions, mandates enable recurring or series-based payments. A mandate is created during afirst_in_series payment by passing a mandate_options block, which defines the consent taken from the customer. This mandate is then associated with the customer’s payment method and enforced on subsequent next_in_series payments.
If a mandate validation fails during a next_in_series payment, the API returns a synchronous error response in the standard RFC 9457 format:
Decline Codes
A more specific code that explains why a card transaction was declined, typically provided by the issuing bank, payment processor, or credit card network. The following are the possible values for thedecline_code field, along with their descriptions and recommended rectification actions:
Best Practices for Clients
To ensure reliable and developer-friendly integrations, we recommend the following practices when handling errors from our API:- Always check the HTTP status code before attempting to parse the response body. Use it to determine the broad category of error (e.g., client-side vs. server-side).
- Use the
error_codefield for internal application logic. This field is stable and maps to general error categories (e.g., card_declined). It’s ideal for branching error-handling flows or conditional retry logic. - Use the
messagefield for human-readable error messages that can be logged or displayed in dashboards. This message is designed to be developer-friendly but not always end-user appropriate. - Use the
decline_codefield for additional context, especially for card-related failures. These codes represent issuer-specific reasons for declines and are useful for analytics, support tooling, or to tailor customer-facing messages when applicable. - Log the full
last_payment_errorobject on failed payment attempts for easier debugging and operational visibility. - Retry only when appropriate:
- Retry on
5xxerrors with backoff. - Do not retry on
4xxerrors unless explicitly documented as safe to do so (e.g. when rate limited).
- Retry on
- Monitor for
402 - Request Failederrors to detect cases where the request has been accepted but the state of the object may indicate a processing error, for example a payment has been created, but the payment processing may still have failed. - Monitor for
422 - Unprocessable Contenterrors to detect integration issues, such as invalid payment state or business rule violations.

