Pagination and Sorting

/Partners/{id}/payments, /Merchants/{id}/payments, and /Terminals/{id}/payments all use the same paging, sorting, and filtering contract.

Every call is a GET request with parameters supplied in the query-string; no request body is required.

Query parameters

Name	Type	Default	Notes
page	integer	0	Zero-based index of the page to return.
pageSize	integer	50	Number of records per page (max = 100*).
sortBy	string	created	Field to sort on (created, updated, etc.).
sortDirection	string	desc	asc or desc.
fromDate	ISO-8601	—	Inclusive start timestamp.
toDate	ISO-8601	—	Inclusive end timestamp.
status	string	—	Filter by payment status (completed, underpaid, overpaid, refunded, …).

*Adjust the maximum if your implementation differs.

Request example

GET /Terminals/abc123/payments
  ?page=0&pageSize=50
  &sortBy=created&sortDirection=desc
  &fromDate=2025-04-01T00:00:00Z
  &toDate=2025-04-24T23:59:59Z

cURL

curl "https://api.test.devs.beadpay.io/Terminals/abc123/payments?page=0&pageSize=50&sortBy=created&sortDirection=desc&fromDate=2025-04-01T00:00:00Z&toDate=2025-04-24T23:59:59Z"

(No -X flag—curl defaults to GET.)

Response example (trimmed)

{
  "data": [
    {
      "id": "pay_5d3a9e",
      "created": "2025-04-18T14:22:31Z",
      "updated": "2025-04-18T14:22:31Z",
      "terminalId": "abc123",
      "statusCode": "completed",
      "amounts": { ... }
    }
  ],
  "total": 27,
  "page": 0
}

pageSize is supplied in the query but is not echoed in the response; your client should track the value it requested.

Best practices

• Always include page and pageSize to keep response times predictable.

• For infinite scroll, advance the fromDate window once you reach the last page instead of incrementing page indefinitely.

• Cache the total sparingly—refresh only when you need an updated count.