Introduction

This article explains how to locate transactions in the Cybersource Business Center using the Transaction by Phase search feature. This feature allows you to filter payments based on their position in the processing lifecycle, such as authorization, settlement, or exception states.

If a transaction cannot be located using standard Transaction Management searches, this article explains how to verify the search scope, locate Secure Acceptance transactions, investigate a possible API or integration-level failure, and troubleshoot an original transaction that cannot be located by the refund service.

Overview of Transaction Phases

Procedure: Search for Transactions by Phase

1. Sign in to the Business Center.
2. Select Transaction Management > Transaction by Phase.
3. Select the desired Phase from the dropdown list.
4. Select a date range and select Apply.
5. Review the transaction results.

If You Cannot Find a Transaction

If a transaction does not appear in Transaction Management, complete the following checks before concluding that the payment does not exist, failed to reach Cybersource, or should be replaced.

1. Confirm the Environment and Merchant Account

• Confirm that you are signed in to the same environment that processed the original payment.
• Confirm that you are searching under the same merchant account that processed the payment.
• If you have access to multiple environments or merchant accounts, verify the original integration or payment configuration before searching again.

2. Expand the Date Range

• Expand the search date range to account for differences between the transaction date, processing date, and settlement-related activity.
• Confirm that the selected date range includes the date on which the original payment was submitted.
• If the search could return more than 2,000 transactions, narrow the criteria or generate a report.

3. Use the Correct Identifier

Use an identifier associated with the original payment or capture. Do not assume that an identifier from a separate follow-on transaction will locate the original payment.

• Search with the original payment or capture ID when that identifier is required.
• Do not substitute a refund ID, merchant reference, processor reference, token ID, or unrelated follow-on transaction ID when the search requires the original payment or capture ID.
• If searching by merchant reference, confirm that it is the reference assigned to the original payment rather than a refund or another follow-on transaction.

4. Search the Applicable Transaction Phase

• Review the original transaction type and its expected position in the payment lifecycle.
• Search the applicable authorization, settlement, or exception phase.
• If the lifecycle state is uncertain, review the relevant phases rather than relying on a single search result.

5. Check the Payment Channel

A transaction may appear in a different Business Center area based on the payment channel through which it was submitted.

• Confirm which payment channel processed the original transaction.
• If the transaction was submitted through Secure Acceptance, search the Secure Acceptance area.
• Use any other applicable channel-specific search available for the product or integration.

6. Search for a Secure Acceptance Transaction

Secure Acceptance transactions do not appear in the standard Transaction Management views.

To search for Secure Acceptance transactions:

1. Select Transaction Management > Secure Acceptance.
2. Use the available filters, such as date, payment type, and amount, to locate the transaction.

7. Reconcile the API Response and Original Request

Not visible in search does not by itself prove that the payment failed, and visible does not by itself prove that it is refundable. First compare the API response with the original request and record the following information:

• HTTP status
• Transaction status
• Original request ID
• Merchant reference
• UTC timestamp
• Environment
• Merchant account

If the response indicated success or acceptance but the payment is still missing after the expected processing period, do not create a replacement payment solely because it is absent from search. Reconcile the original outcome first to avoid a duplicate charge.

8. Investigate a Possible API or Integration-Level Failure

If the transaction is not visible after checking the environment, merchant account, date range, identifier, transaction phase, payment channel, and original API response, an API or integration-level failure is one possible explanation.

Review the merchant application's API request and response records, including the exact HTTP status, transaction status, response body, original request ID, merchant reference, UTC timestamp, environment, merchant account, and available integration logs.

Do not conclude that the transaction failed to reach Cybersource solely because it was absent from a Business Center search. Successful or accepted processing can coexist with persistence, indexing, or lifecycle-data gaps.

For more information about reviewing and interpreting REST API responses, see:

• Connectivity – REST API Response Codes

If the Refund Service Cannot Locate the Original Transaction

This message means the refund service could not locate an eligible original transaction using the information and search scope provided. Confirm that you are searching in the same environment and merchant account that processed the payment.

Expand the date range and search with the original payment or capture ID—not a refund ID, merchant reference, processor reference, token ID, or unrelated follow-on transaction ID. If applicable, also search by transaction phase or payment channel.

A payment may appear in transaction search but still be unavailable to the refund service if the required original capture or lifecycle record cannot be found.

Transaction-Search Retention and Refund Eligibility

Transaction-search retention and refund eligibility are separate. The original transaction must be within the refund window supported by its payment method and processing platform, and the refund service must be able to retrieve the original authorization and capture data.

Refund windows vary. Do not assume that every searchable transaction can be refunded or that one universal time limit applies. A transaction can be searchable but outside the applicable refund window. A transaction may also be within the applicable refund window but unavailable to the refund service because the required historical linkage is missing.

If the payment is found but no refund action is available, confirm that it:

• Was successfully captured or settled.
• Has remaining refundable value.
• Is within the refund period applicable to its payment method and processing platform.
• Has the original authorization, capture, and lifecycle data required by the refund service.

Refund Search and Eligibility Checklist

1. Confirm that you are using the same environment that processed the payment.
2. Confirm that you are searching under the same merchant account that processed the payment.
3. Expand the date range.
4. Use the original payment or capture ID required by the refund service.
5. Do not substitute a refund ID, merchant reference, processor reference, token ID, or unrelated follow-on transaction ID.
6. If applicable, search by transaction phase or payment channel.
7. Confirm that the payment was successfully captured or settled.
8. Confirm that the transaction has remaining refundable value.
9. Confirm that the transaction is within the refund period applicable to its payment method and processing platform.
10. Confirm that the refund service can retrieve the required original authorization, capture, and lifecycle data.
11. Review the original payment, capture, and refund history.
12. Confirm that another refund has not already been submitted or accepted before retrying.

Additional Resources

• Cybersource Business Center
• Connectivity – REST API Response Codes