Error Handling

Payment failures happen. Cards get declined. Networks timeout. Prism gives you structured error information that tells you exactly what went wrong and how to fix it, regardless of which payment processor generated the error.

The Error Object

Every error follows the same structure:

{
    error: {
        code: "PAYMENT_DECLINED",
        message: "Your card was declined.",
        category: "PAYMENT_ERROR",
        connector_code: "card_declined",
        connector_message: "Your card was declined.",
        request_id: "req_8f3a2b1c",
        retryable: false,
        suggested_action: "Ask customer to use different payment method"
    }
}
Field
Purpose

code

Unified error code you handle in your code

message

Human-readable explanation

category

Error type (PAYMENT_ERROR, NETWORK_ERROR, CONFIGURATION_ERROR)

connector_code

Original error from the payment processor

connector_message

Original message from the payment processor

request_id

Unique ID for support/debugging

retryable

Whether retrying might succeed

suggested_action

Recommended next step

Error Categories

Errors fall into four categories based on root cause:

Category
Description
Example
Retryable?

PAYMENT_ERROR

Customer's payment method failed

Declined card, expired card

No

NETWORK_ERROR

Connectivity issues

Timeout, connection refused

Yes

CONFIGURATION_ERROR

Setup problems

Invalid API key, wrong credentials

No

VALIDATION_ERROR

Request issues

Invalid amount, missing field

No

Handling Errors in Code

Real Error Examples

Declined Card (Stripe)

Stripe's raw response:

Prism unified error:

Invalid API Key (Adyen)

Adyen's raw response:

Prism unified error:

Network Timeout

Retry Strategies

Some errors warrant retry. Prism tells you which:

Retryable errors:

  • NETWORK_TIMEOUT

  • RATE_LIMIT_EXCEEDED

  • SERVICE_UNAVAILABLE

Non-retryable errors:

  • PAYMENT_DECLINED

  • EXPIRED_CARD

  • INVALID_API_KEY

  • VALIDATION_ERROR

Logging and Debugging

Always log the request_id for support:

Support teams can use request_id to trace the exact request in logs and diagnose issues.

Best Practices

  1. Handle specific error codes before falling back to generic handling

  2. Show customer-friendly messages, not raw error codes

  3. Log full error details for debugging

  4. Only retry retryable errors with exponential backoff

  5. Use request_id in customer-facing error messages for support

  6. Monitor error rates by category to detect issues early

Error Monitoring

Track errors to catch problems:

Configuration errors hitting production indicate a deployment or credential issue that needs immediate attention.

Last updated

Was this helpful?