On This Page

Transaction Search Performance Update

We are aware of an intermittent issue that impacts transaction search performance. The search functions in our APIs and Business Center are served from a shared search platform that is used by all Transaction Management module customers. An issue can occur when there is an unusually high search activity, which places a heavy load on the shared search service. We applied traffic controls to reduce the impact and are rolling out additional safeguards to prevent recurrence.

This issue does not impact payment processing transactions.

To improve transaction search performance and provide more consistent response times, transaction search platform is being updated for requests that use multiple search identifiers. As part of this enhancement, searches that include multiple identifiers will support up to 15 identifiers per request. Merchants whose integrations currently submit larger batches should update their systems to divide searches into smaller requests.

Merchant Impact

You might occasionally experience slower response times or timeouts.

For API integrators, an HTTP

429

response, often indicates that there are too many request responses on Transaction Search, Case Search, or the Find Similar Transactions feature, particularly for large, broad, or long-date-range searches.

Recommended Actions

Keep multi-value lookups to 15 identifiers or less per search.

Use the narrowest date range that answers your question. A period of 7 days or less is recommended for interactive transaction searches.

Break large bulk lookups into smaller batches instead of using one large combined search.

Avoid broad wildcard searches, especially searches that use a short prefix and an asterisk (*).

If a search is slow or times out, wait a moment before retrying instead of retrying immediately.

For API integrators:

Limit each request to 15 or fewer identifiers.

Use the narrowest date range your job needs.

Implement back off on timeouts or errors instead of not tight-loop retries.

If you receive a

429

response, honor any Retry-After value and reduce your request rate and batch size rather than immediately retrying.

If your workflow requires a large multi-identifier or long-date-range search on a recurring basis, contact your support or account team so it can be reviewed for the batch and export path or an appropriate exception.

Recommended Next Step

Review your search and integration patterns and adhere to the guidance provided in the Transaction Management Best Practices
section below.

Best Practices for Implementing Searches

These best practices apply to searches you implement using the Transaction Search API, Case Search, API and the Business Center. Following the practices below will help keep your searches and detail lookups fast and reliable.

General Guidance: Keep multi-value lookups to 15 identifiers or less per search. For example, reference numbers, request IDs, or account numbers. For larger lookups, use another method instead of one very large interactive request.
Use the narrowest date range that answers your question. Use 7 days or less for interactive transaction searches.
Break large bulk lookups into smaller batches. For example, implement several searches of less than or equal to 15 identifiers and less than or equal to 7 days instead of implementing one combined search that spans many identifiers and a long date range.
Retry failed or slow searches manually, using a short pause, instead of immediately re-running the identical search in an automated loop.
Practices to Avoid: Do not implement broad wildacard searches. These searches scan a large portion of the search index and are the most resource-intensive type of search.
The following wildcard validation rules now apply:
Leading wildcard searches are no longer accepted.
Wildcard searches must contain a minimum of three characters preceding the wildcard character (*).
The following examples demonstrate the accepted and unsupported wildcard formats.
Unsupported Wildcard Formats:
*ABC
A*
AB*
12*
Accepted Wildcard Formats:
ABC*
ABCD*
123*

Avoid combining a large number of identifiers with a long date range in the same search. Cost increases roughly with identifiers multiplied by a date range, so a search that is fine on its own can be expensive when both are large together.
Avoid automated rapid-retry on a timeout. An identical search that timed out will typically time out again if re-run immediately, which adds load on the service without improving results.
API Searches: Request Shape: Cap each request to 15 or fewer identifiers when using multi-value lookups. If your integration currently sends larger batches, split them into multiple smaller requests.
Use an end-of-day reconciliation or bulk report instead of paging through many large interactive search calls.
Use the narrowest date range your job actually needs. Recurring jobs that request a wide window are a common source of avoidable load.
Avoid wildcard or short-prefix values in identifier fields. Search for an exact full value when it is available.
API Searches: Retry and Error Handling: Implement a back off retry instead of tight-loop retry. If a request times out or errors, wait before retrying, and increase the wait time on repeated failures (exponential back off).
If you receive a
429
(rate limited) response, treat it as a signal to slow down, not a bug to route around. Honor any Retry-After value if present, and reduce your request rate/batch size rather than retrying immediately or in parallel.
Cap your retry attempts for a given request. For example, 3 to 5 attempts with increasing back off retries and alert/log instead of retrying indefinitely.
Watch for repeated identical requests from your own systems. A scheduled job that re-issues the exact same search on every run because a prior run did not complete can create a sustained load without your team realizing it. Add job-level locking or de-duplication search so a stopped run does not stack up.
Business Center Searches: Transaction Search:
search on a specific field (order number, request ID, reference number) instead of a broad free-text and keyword term when possible. Keep the date range to 7 days or less.
Quick Search:
use a reasonably narrow date range rather than the widest default. If you manage multiple sub-accounts under a parent account, searching from the specific sub-account instead of searching from the top-level parent view when you know what account from which the transaction belongs.
Bulk Export and Reporting:
if you need a large number of transactions or cases, use the Business Center report feature to pull the full set at once instead of repeatedly re-running and paging through search results. If a search is slow or times out, wait a moment and retry once instead of repeatedly clicking search or refresh in quick succession.