Introduction

This article explains how to diagnose and resolve server errors and transaction errors that occur specifically when using Secure Acceptance, a CyberSource hosted payment form solution. It covers Hypertext Transfer Protocol (HTTP) server error codes returned by the Secure Acceptance gateway as well as numeric reason codes returned in the Secure Acceptance response body.

This article is intended for merchants and developers who are actively integrated with Secure Acceptance and are encountering errors during payment processing. If you are not using Secure Acceptance, refer to the applicable articles below:

Not using Secure Acceptance?

For general HTTP status codes, refer to: Connectivity - Common Hypertext Transfer Protocol (HTTP) Status Codes

For general REST API response codes, refer to: Connectivity - REST Application Programming Interface (API) Response Codes

When using Secure Acceptance, you may encounter either of the following error types:

Server errors — HTTP status codes such as HTTP 403, 400, or 500 returned by the Secure Acceptance gateway.
Transaction errors — Secure Acceptance responses that contain a numeric reason_code explaining why a request failed.

One of the most common server-side messages is:

"You are not authorized to view this page. The transaction has not been processed."

This message is always accompanied by an HTTP 403 Unauthorized status and indicates that the request was rejected before it reached transaction processing.

Another server-side message you may encounter is:

"The server encountered an error and could not complete your request. If the problem persists please report your problem and quote the following Error Reference Number: <error number>"

This message generally indicates a temporary server-side problem (HTTP 5xx) where the Secure Acceptance gateway cannot complete processing. The Error Reference Number is useful for Client Services to locate the event in server logs.

Overview of Error Types

Server errors
- HTTP 4xx: Input or authentication issues (for example, HTTP 403 Unauthorized).
- HTTP 5xx: Temporary service issues, including internal gateway errors.
Transaction errors: Returned in the Secure Acceptance response body with a reason_code and descriptive text.

Common Server Error Messages — Quick Reference

Error Message	Likely HTTP Code	Meaning	Recommended Action
"You are not authorized to view this page. The transaction has not been processed."	403 Unauthorized	Authentication or data validation failed before transaction processing.	Check API keys, required fields, timestamp accuracy, and key formatting.
"The server encountered an error and could not complete your request... Error Reference Number: <error number>"	500 Internal Server Error (or other HTTP 5xx)	Temporary server-side issue preventing the gateway from completing processing.	Record the Error Reference Number, check if the transaction was logged, then provide the Transaction Unique Identifier (UUID) and Error Reference Number to Client Services. Avoid immediate retries.
Generic HTTP 400 response	400 Bad Request	The request could not be understood due to malformed syntax or invalid parameters.	Validate and correct the request payload before resubmitting.
Generic HTTP 500 response without specific text	500 Internal Server Error	Unspecified server-side problem.	Retry later. If the issue persists, contact Client Services with the UUID and timestamp.

HTTP 403 — "You Are Not Authorized to View This Page"

The gateway rejected your request because required authentication or data validation failed.

Common causes include:

Incorrect or invalid Access Key or Secret Key
Missing required fields in the request payload
An out-of-sync signed_date_time value
Truncated or word-wrapped key strings

Procedure: Resolving Server Errors

Resolving an HTTP 403 Unauthorized Error

Verify that the Access Key and Secret Key match your Secure Acceptance profile.
Ensure all required fields are present and properly formatted in the request payload.
Confirm that signed_date_time is current and that your server clock is synchronized.
Check that key values are not truncated or word-wrapped.

Resolving an HTTP 5xx Server Error

Note the Error Reference Number exactly as displayed on screen.
Navigate to the Business Center, select Transaction Search, then select Secure Acceptance Search to check whether the transaction was logged.
Provide the Error Reference Number, Transaction UUID, and timestamp to Client Services if the transaction cannot be located.
Wait before retrying to avoid creating duplicate transactions.

Resolving an HTTP 400 Bad Request Error

Review the request payload for syntax and formatting errors.
Correct any invalid or missing parameters before resubmitting the request.

Checking Whether the Transaction Reached the Gateway

If no record exists, authentication or data errors — often causing the HTTP 403 message — prevented the transaction from being logged.
If the transaction is found but failed:
- Select the magnifier icon in the Log column and note the reason_code and error text.
- Use the Transaction Reason Codes table in this article to determine the appropriate next steps.
If the transaction cannot be located:
- Locate the Transaction Unique Identifier (UUID) captured by your system.
- Send the UUID to Client Services so the Application Programming Interface (API) gateway logs can be searched.
- See the Providing the Transaction UUID section below for details.

Providing the Transaction UUID

Why the Transaction UUID Matters

Locates detailed API gateway logs for the specific transaction.
Allows review of the full request payload and server-side response.
Identifies authentication, validation, or system issues not visible in standard Business Center searches.

How to Provide the Transaction UUID

Locate the UUID in your application logs or the original API request.
Share the UUID with Client Services along with the timestamp, error text, and any relevant request or response snippets.

Tip: Transactions created on the same day are easiest to locate. Provide the UUID to Client Services as soon as possible after the error occurs.

Transaction Reason Codes

The following table lists the reason codes returned in the Secure Acceptance response body, along with their descriptions and recommended actions. Use this table to identify the cause of a failed transaction and determine the appropriate next steps.

Reason Code	Description	Possible Action
100	Successful transaction.	No action required.
101	Request is missing one or more required fields.	Review the response fields `missingField_0` through `missingField_N` to identify which fields are missing. Resend the request with all required fields included.
102	One or more fields in the request contain invalid data.	Review the response field `invalid_fields` to identify which fields are invalid. Resend the request with the correct information.
104	The `access_key` and `transaction_uuid` fields for this authorization request match those of another authorization request submitted within the past 15 minutes. A duplicate transaction may have already been processed.	Before resubmitting, use the single transaction query or search for the transaction in the Business Center to confirm it has not already been processed. If confirmed as a duplicate, resend the request with unique `access_key` and `transaction_uuid` fields.
110	Only a partial amount was approved.	Review the partial approval and determine whether to proceed or request an alternative payment method.
150	General system failure.	To avoid duplicating the transaction, do not resend the request until you have reviewed the transaction status in the Business Center or programmatically through the single transaction query.
151	The request was received but a server timeout occurred. This error does not include timeouts between the client and the server.	To avoid duplicating the transaction, do not resend the request until you have reviewed the transaction status in the Business Center or programmatically through the single transaction query.
152	The request was received but a service timeout occurred.	To avoid duplicating the transaction, do not resend the request until you have reviewed the transaction status in the Business Center or programmatically through the single transaction query.
200	The authorization request was approved by the issuing bank but declined because it did not pass the Address Verification System (AVS) check.	You can capture the authorization, but consider reviewing the order for potential fraud before proceeding.
201	The issuing bank has questions about the request. An authorization code is not received programmatically but may be available verbally by calling the processor.	Call your processor to potentially receive a verbal authorization. For contact phone numbers, refer to your merchant bank information.
202	Expired card. This value may also be returned if the expiration date provided does not match the date on file with the issuing bank.	Request a different card or an alternative form of payment.
203	General decline of the card. No additional information was provided by the issuing bank.	Request a different card or an alternative form of payment.
204	Insufficient funds in the account.	Request a different card or an alternative form of payment.
205	Stolen or lost card.	Review this transaction manually to ensure that the correct information was submitted.
207	Issuing bank unavailable.	To avoid duplicating the transaction, do not resend the request until you have reviewed the transaction status in the Business Center or programmatically through the single transaction query.
208	Inactive card or card not authorized for card-not-present transactions.	Request a different card or an alternative form of payment.
210	The card has reached the credit limit.	Request a different card or an alternative form of payment.
211	Invalid Card Verification Number (CVN).	Request a different card or an alternative form of payment.
221	The customer matched an entry on the processor's negative file.	Review the order and contact the payment processor.
222	Account frozen.	Request a different card or an alternative form of payment.
230	The authorization request was approved by the issuing bank but declined because it did not pass the CVN check.	You can capture the authorization, but consider reviewing the order for the possibility of fraud before proceeding.
231	Invalid account number.	Request a different card or an alternative form of payment.
232	The card type is not accepted by the payment processor.	Contact your merchant bank to confirm that your account is set up to accept the card type in question.
233	General decline by the processor.	Request a different card or an alternative form of payment.
234	There is a problem with the information in your CyberSource account.	Do not resend the request. Contact Client Services to correct the information in your account.
236	Processor failure.	To avoid duplicating the transaction, do not resend the request until you have reviewed the transaction status in the Business Center or programmatically through the single transaction query.
240	The card type sent is invalid or does not correlate with the payment card number.	Confirm that the card type correlates with the payment card number specified in the request, then resend the request.
475	The cardholder is enrolled for payer authentication.	Authenticate the cardholder before proceeding with the transaction.
476	Payer authentication could not be completed.	Review the payer authentication setup and retry. If the issue persists, contact Client Services.
478	Strong Customer Authentication (SCA) is required for this transaction.	Ensure that your integration supports SCA and that the appropriate authentication flow is triggered before resubmitting the transaction.
481	Transaction declined based on your payment settings for the profile.	Review the risk score settings configured for your Secure Acceptance profile.
520	The authorization request was approved by the issuing bank but declined based on your Decision Manager settings.	Review the authorization request and your Decision Manager configuration.

Best Practices

Always check response fields for specific error messages and reason codes before taking action.
Verify transaction status in the Business Center before resubmitting to avoid creating duplicate transactions.
Double-check all API request parameters for completeness and accuracy before submission.
Ensure your system clock is synchronized to prevent timestamp-related errors.
Provide the Transaction UUID when contacting Client Services to expedite log retrieval and investigation.

Potential Client Questions

I received an HTTP 403 error but I am not using Secure Acceptance — does this article apply to me?
- No. This article applies specifically to merchants using Secure Acceptance. If you are not using Secure Acceptance and are encountering HTTP errors, refer to Connectivity - Common Hypertext Transfer Protocol (HTTP) Status Codes for general HTTP error guidance.
I received a reason code that is not in this table — where can I find more information?
- If you are using a REST API integration rather than Secure Acceptance, refer to Connectivity - REST API Response Codes for a broader list of API response codes. If the code still cannot be located, contact Client Services for assistance.
My transaction is not showing up in the Business Center — what should I do?
- If the transaction cannot be located in the Business Center, locate the Transaction UUID captured by your system and submit it to Client Services. The internal team will use the UUID to search the API gateway logs and identify the issue. Transactions created on the same day are easiest to locate, so provide the UUID as soon as possible.
Is it safe to retry a transaction after receiving an HTTP 5xx error?
- Not immediately. Before retrying, check the transaction status in the Business Center under Transaction Search and then Secure Acceptance Search to confirm whether the transaction was logged. Retrying without checking first may result in duplicate transactions.
What is the Error Reference Number and how do I use it?
- The Error Reference Number is a unique identifier displayed in the HTTP 5xx error message returned by the Secure Acceptance gateway. It allows Client Services to locate the specific event in server logs. Record this number exactly as displayed and include it along with the Transaction UUID and timestamp when contacting Client Services.
My transaction was declined with reason code 104 — does that mean it was already processed?
- Reason code 104 indicates that a duplicate transaction was detected based on matching access_key and transaction_uuid fields from a request submitted within the past 15 minutes. Before resubmitting, verify the transaction

Was this article helpful?

Articles Recommended for You

Secure Acceptance - Error Troubleshooting