Skip to main content
Some top-level API resources support retrieval with search API methods. You can use the search APIs to retrieve your PayNext objects in a flexible manner. Using search is a faster alternative to paginating through all resources with individual filter parameters. Search is available on the list endpoints — GET /payments, GET /customers, GET /subscriptions, and GET /plans — when you set the X-API-Version: 2.0.0 header. With this header, the endpoint parses the DSL from the query parameter, ignores the legacy filter query parameters, and returns the search envelope (object, url, has_more, next_page, total_count, data). Without the header, the endpoints keep their v1.x behavior and response shape. See Parameters and Response format below. To create a search query, review the search query language and reference the query fields of the resource:
Field names use dotted paths (for example payment_status, customer.email, payment_method.details.last4). Short aliases such as status, email, or card_last4 are not accepted and return an error. Always use the exact field names listed in the tables below.

Examples

Here are some examples of what you can do with the search APIs. Look up payments matching a custom metadata value.
curl

Payments by status and amount

Look up settled payments over a specific amount.
curl
Look up customers matching an email substring.
curl

Negation filter

Look up payments not in USD currency.
curl

Numeric filter

Filter payments with an amount greater than 10000.
curl

Combining multiple filters

Look up payments matching a combination of metadata and currency.
curl

Search query language

Query structure and terminology

A query clause consists of a field followed by an operator followed by a value: You can combine up to 10 query clauses in a search by either separating them with a space, or using the AND or OR keywords (case insensitive). You cannot combine AND and OR in the same query. There is no option to use parentheses to give priority to certain logic operators. By default, the API combines clauses with AND logic. On the Payments and Customers endpoints, all clauses in an OR query must target the same field; the Subscriptions and Plans endpoints allow OR across different fields. The example query customer.email:"alice@example.com" metadata["tier"]:"premium" matches records where both the customer email is alice@example.com and the metadata includes tier with a value of premium.

Negation

You can negate query clauses using a - character. For example, the following search returns records that don’t match the currency USD: -currency_code:"USD"

Field types, substring matching, and numeric comparators

Each field has a type that defines the operations you can use on it. For a full list of available fields and their types, see supported query fields for each resource. Using an unsupported operator — such as specifying greater than (>) on a token field — returns an error.

Quotes

You must use quotation marks around string values. Quotation marks are optional for numeric values. For example:
  • currency_code:"USD" — quotes are required
  • amount:1000 — quotes are optional
You can escape quotes inside of quotes with a backslash (\): statement_descriptor:"the descriptor called \"My Store\""

Metadata

You can perform searches on metadata that you’ve added to objects that support it. Use either bracket or dotted syntax to construct a clause for a metadata search: metadata["<field>"]:"<value>" or metadata.<field>:"<value>". The metadata key must consist of [a-zA-Z0-9_] characters. The following clause demonstrates how to query for records with an order ID of ord_abc123: metadata["order_id"]:"ord_abc123" You can query for the presence of a metadata key on an object. The following clause matches all records where order_id is a metadata key: -metadata["order_id"]:null Some resources also expose scoped metadata fields for related objects — for example customer.metadata["<key>"] on payments and subscriptions, or plan.metadata["<key>"] on subscriptions. These are listed in each resource’s field tables.

Null operator

The null keyword checks for field presence or absence: :null is supported on token, string, and date fields. It is not supported on numeric fields.

Search syntax

The following table lists the syntax that you can use to construct a query.

Supported query fields for each resource

Query fields for Payments

Core

Customer

Subscription

Processor

Payment method and card

Network token

PayPal payer info

Processor customer

Refund

Tax

3-D Secure

Decline information

AVS / CVC checks

Processor identifiers

Fraud prevention

Metadata

The payment_status field accepts the following values: PENDING, FAILED, AUTHORIZED, SETTLING, SETTLED, DECLINED, BLOCKED, CANCELLED.
The payment_method.type field accepts values like CARD, PIX, PAYPAL, CASHAPP, APPLEPAY, GOOGLEPAY, VENMO, AMAZONPAY.
The payment_token_type field accepts: CARD_PAN, NETWORK_TOKEN, PROCESSOR_TOKEN.
payment_method.details.bin_data.brand is the card network (for example visa, mastercard). payment_details.network_payment_id is the scheme-side network transaction identifier returned by the processor (for example, the Mastercard trace id or Visa transaction id) — they are different fields.
customer.email and customer.external_id on payments match against the customer associated with the payment.

Query fields for Customers

Core

Address

Payment methods

Subscriptions

Subscription plan

Metadata

The subscriptions.status field accepts values like ACTIVE, CANCELLED, PAST_DUE, PAUSED, TRIAL, SCHEDULED_FOR_CANCELLATION.

Query fields for Subscriptions

Core

Customer

Plan

Metadata

The status field accepts values like ACTIVE, CANCELLED, PAST_DUE, PAUSED, TRIAL, SCHEDULED_FOR_CANCELLATION.

Query fields for Plans

The interval and trial_interval fields accept days, months, years. The type field accepts recurring, one-off.

Parameters

All search endpoints accept the same parameters:
string
required
The search query string. See the search query language and the list of supported query fields for each resource.
integer
default:"10"
A limit on the number of objects to return. Limit can range between 1 and 100, and the default is 10.
string
A cursor for pagination across multiple pages of results. Don’t include this parameter on the first call. Use the next_page value returned in a previous response to request subsequent pages.

Response format

A dictionary with a data property that contains an array of up to limit results. If no objects match the query, the resulting array will be empty.
string
required
The resource collection name — one of payments, customers, subscriptions, or plans.
string
required
The URL of the search endpoint that was called.
boolean
required
Whether there are more results available beyond this page.
string
A cursor to use as the page parameter for the next request. null if there are no more results.
integer
required
The total number of objects matching the query.
array
required
An array of result objects matching the query. Each entry is a full resource object (the same shape returned by the corresponding GET /{resource}/{id} endpoint).

Limitations

Rate limits

Search endpoints are rate-limited to 20 requests per second per API key. For workloads requiring analytics or bulk data export, consider using webhooks or scheduled data pulls.

Data freshness

Don’t use search for read-after-write flows (for example, searching immediately after a payment is created) because the data may not be immediately available to search. Under normal operating conditions, data is searchable in under 1 minute. For read-after-write flows that require immediate data availability, use the standard list APIs with individual filter parameters.

Query constraints

  • Maximum 10 clauses per query
  • You cannot combine AND and OR in the same query
  • On Payments and Customers, all OR clauses must target the same field (Subscriptions and Plans allow OR across different fields)
  • No parentheses for operator precedence
  • Substring matching (~) requires a minimum of 3 characters
  • Space-separated clauses default to AND logic
In some cases, the data you use to find search results might not match the results that you receive. This can happen because the search index is slightly behind the latest state of the object.