order_by on payment and dispute listings

What's new

GET /v1/payments renamed its field query parameter to order_by, and GET /v1/disputes gained an order_by parameter of its own. On both endpoints the named timestamp now does two jobs: it is the field start_at/end_at filter on, and it is the field the returned records are sorted by. Before, it only picked the filter field.

The accepted values differ per endpoint. Payments keep the existing RangeField enum (created_at, modified_at, status_updated_at). Disputes take a new DisputeOrderByField enum (created_at, updated_at), defaulting to created_at.

One other detail: order_by on payments no longer declares a default in the spec, where field documented created_at.

Impact

A time-windowed pull now comes back ordered by the same timestamp it was filtered on, so paging through with limit and offset walks the window in order instead of an unspecified one. On disputes, windowing by updated_at lets an incremental sync pick up cases that changed since the last run rather than only cases opened since then.

Changes

Resource	Change
get_payments	Renamed the field query parameter to order_by. It now sets the sort order as well as the filtered field, and no longer declares a created_at default
get_disputes	Added the optional order_by query parameter (created_at or updated_at, default created_at), which sets both the field start_at/end_at filter on and the sort order
Components	Added the DisputeOrderByField enum (created_at, updated_at)

Upgrade

• Callers of get_payments that pass field must send order_by instead. The old name is gone.
• Pass order_by explicitly on get_payments if you were relying on the documented created_at default.
• Check any code that assumes a fixed sort on either endpoint. The order now follows order_by.
• Nothing to change on get_disputes. Omitting order_by keeps the current created_at behavior.

Need help?
Contact our integration team at [email protected]