Pagination and Sorting
Purpose
All three payment-history endpoints—/Partners/{id}/payments
, /Merchants/{id}/payments
, and /Terminals/{id}/payments
—share the same paging and filtering contract.
Each call is a POST request with pagination, sorting, and filter values supplied as query-string parameters. No request body is required.
Query parameters
page
integer
no
0
0-based page index. page=2&pageSize=50
returns the third block of 50 records.
pageSize
integer
no
50 • max 200*
Number of rows per page.
sortBy
string
no
created
Field to sort on (created
, amount
, statusCode
, …).
sortDirection
string
no
desc
asc
or desc
.
fromDate
ISO-8601 string
no
–
Payments created ≥ this timestamp. 2025-04-01T00:00:00Z
toDate
ISO-8601 string
no
–
Payments created ≤ this timestamp.
status
string
no
–
One of: created
, processing
, completed
, underpaid
, overpaid
, fullyRefunded
, partiallyRefunded
, expired
, invalid
, cancelled
* Adjust the maximum if your implementation differs.
Request example
Curl
(No JSON body—everything is passed in the query string.)
Response example (trimmed)
data
Array of payment objects for this page.
total
Total number of payments that match the filters.
page
Page index you requested.
pageSize
is supplied in the query but is not echoed in the response; your client should keep track of the size it requested.
Best practices
Always include
page
andpageSize
to keep response times predictable.For infinite scroll, advance the
fromDate
window instead of incrementingpage
after you reach the last page.Cache
total
sparingly—refresh only when you need an updated count.
Last updated