Errors

For more information, please see the documentation at here.

There are two base error formats that can be returned in card issuing: Bad Request and Internal. Below are the common elements of both types of errors. Depending on the endpoint more fields may be available.

Bad Request Errors

Bad request error are any errors that can be resolved by the requester. This includes but is not limited to:

Malformed request body or URL
Resource not found
Request violates configuration or status of entity

In most cases a bad request can only be resolved by changing the request or making a change to the entity. There are some conditions that will resolve on their own, mostly status and limit conditions.

HTTP Status Codes


HTTP Status	Description	When Used
400	Bad Request	The request is invalid given the current configuration of your program.
401	Unauthorised
404	Not Found	The requested resource was not found.
429	Too Many Requests	Too many requests have been received in a short time-frame.

Body Response Format:

{
    "error": {
        "code": "Error code that can be programmatically checked against",
        "message": "Human readable error message, subject to change"
    }
}

Internal Errors

Internal errors are errors that are encountered in fulfilling a request that cannot be resolved by a caller. In general, errors with HTTPS status codes 503 and 504 will resolve themselves after a period of time.

Internal errors are returned with a tracking code. This code is used to help investigate or reconcile issues that have occurred.

HTTP Status Codes


HTTP Status	Error Codes	Description	When Used
500	internal_error, internal_server_error	Internal Error	Internal error within card-issuing platform.
502	bad_gateway	Bad Gateway	Internal error, not recoverable. Please contact Berkeley if you encounter this error.
503	transitory_failure	Service Unavailable	The request cannot be processed at this time. Under most circumstances this error will resolve quickly and the request can be retried.
504	gateway_timeout	Gateway Timeout	A request has timed out, however may have completed successfully. Under most circumstances this error will resolve quickly. For requests that use an idempotency key the request can be retried with the same key. We do recommend that clients check the status of a request using the appropriate get/list method.

Body Response Format:

{
    "error": {
        "code": "Error code that can be programmatically checked against",
        "message": "Human readable error message, subject to change",
        "tracking_code": "41519fff-439c-4d3d-ab33-4b74c763d2de"
    }
}

Cardholders, Accounts and Cards

The actions that can be performed with a card or account are limited by their status. For actions taken through the API or through Berkeley’s portals only the account status is relevant.

Of special note is the status awaiting_processor. While accounts do not need to be active to load accounts in this temporary state will fail to load. It is possible to retry the load after this state has cleared.

Statuses


Status	Description	Notes
`awaiting_processor`	The processor has agreed to create an account but the account is not yet ready. This state usually resolves in less than an hour.	Temporary state. Card operations including loading cannot be performed.
`shipping`	Card is waiting to be shipped.
`shipped`	Card has been shipped.
`not_active`	The account or card is inactive. It can be activated via an IVR or by the Activate Card endpoint.	Value loads and transfers are possible. However, the cardholder will not be able to use the card for purchases.
`active`	The account or card is active.
`suspended`	The account or has been suspended.
`expired`	The account or card is expired.
`cancelled`	The account or card is cancelled.
`lost`	The account or card has been reported lost.
`stolen`	The account or card has been reported stolen.
`delinquent`
`closed`	The account or card has been closed.

Value Loads

Limit Based Errors

Value loads are subject to limits on the amount of funds and the number of load operations that can be completed. These limits are set up on a per program basis.

Below is a table of error codes associated with load limits:


Code	Description
`load_limit_exceded`	The amount of funds requested is more than the maximum amount or less than the minimum amount for a value load.
`velocity_check_failed`	A time based limit on value loads has been reached. This can either be the total amount or total number of loads in a given time period.
`insufficient_funds`	There are not enough funds in the Master Funding Account to complete the load.
`limit_exceded`	The value load would violate a limit that has not been classified as a load limit or a velocity limit.

Value Load Transaction Codes

Please contact support to see if the following codes are relevant/available on a per program basis.

The following transaction codes can be passed in the transaction_code field for both value load and unload.

transaction_code


transaction_code
cashback
atm_reimbursement_domestic
atm_reimbursement_intl

ACH

ACH is a batch process. This means that when an ACH transaction is created it is not yet completed. It’s status can be checked using the ACH Transaction History endpoint.

ACH Status Codes

These status codes shows the processors current progress in completing the ACH transfer.


Code	Description	Notes
`queued_for_transfer`	Transfer has been received and is waiting to be sent.
`sent`	Transfer has been sent.
`approved_after_limit_violation`	Transfer is approved.
`cancelled_after_limit_violation`	Transfer has been cancelled.	Terminal
`cancelled_due_to_violation_of_debit_limit`	Transfer has been cancelled.	Terminal
`cancelled_at_cardholders_request`	Transfer has been cancelled.	Terminal
`cancelled`	Transfer has been cancelled.	Terminal
`pending_for_approval_as_limit_exceeded`	Transfer is waiting special approval.
`deleted_by_cardholder`	Transfer has been deleted	Terminal
`bad_routing_number`	The routing number is incorrect.	Terminal
`on_hold`	The transfer is on hold with the processor.
`error`	The transfer has encountered an error and will not be completed.	Terminal

Card Issuing Certification and Onboarding
Secondary Authorizations
Simulate Authorization and Settlement