September 8, 2026

API changes for September 8, 2026

Add an endpoint to authorize and capture a payout in one call

We’ve added POST /MoneyOut/payout, which authorizes a payout and captures it in the same request and returns the capture result. Use it when you need the capture outcome synchronously, instead of calling Authorize payout and then Capture payout separately.

A failed capture doesn’t undo the authorization: it returns the capture error and leaves the payout authorized, so retry the capture with GET /MoneyOut/capture/{referenceId} rather than resubmitting. The endpoint ignores autoCapture in the request body, because it always captures inline.

See Authorize and capture a payout and the Manage payouts guide.

Wire and RTP balance error codes split

The balance check that runs at authorize time for wire and RTP payouts now returns two distinct error codes instead of one. Error 3729 (Transaction amount exceeds available payout balance.) still covers a requested amount greater than the available balance. The new error 3730 (Payout balance information is unavailable for this paypoint.) covers a paypoint without balance data, or balance data that can’t be read. Before this change, that case also returned 3729. Both codes return HTTP 400 Bad Request.

See Send instant payouts and the API response codes reference.

Filter chargebacks and returns by amount

The chargebacks and returns query (GET /Query/chargebacks/{entry} and the /org/{orgId} variant) has two new amount filters. amount filters by the record’s own amount (the top-level netAmount in the response), which differs from the existing netAmount filter (the original transaction’s net) for partial disputes and reversals. totalAmount filters by the original transaction’s gross, including service and pending fees (transaction.totalAmount in the response). Both accept the conditions (gt, ge, lt, le, eq, ne), and you can sort by them with sortBy=asc(amount) or desc(totalAmount).

We’ve also registered replyBy as an alias for the replyDate filter. The response exposes the reply deadline as replyBy, but only replyDate worked as a filter name, so a replyBy filter used to return zero records with a 200 instead of matching. See the Filters and Conditions Reference for filter syntax.

Filter payouts by `orderId`

The payouts query endpoints now accept an orderId filter, matching the filter already available on GET /Query/transactions/{entry}. Use it to look up a payout by the orderId you supplied on the original MoneyOut authorize request — for example, for an idempotency check after an idempotencyKey error.

orderId accepts the eq and ne conditions and matches case-insensitively. The payout query response also now includes orderId, which is null for payouts that don’t have one.

This change affects the following endpoints:

Partial payouts for bills (managed payables)

You can now partially pay a bill through managed payables. On the Authorize payout request, set totalAmount below the outstanding balance of the single bill you’re paying. The partial amount lives on the payout, not on the bill. The bill moves to the new Partially Paid status (75) and stays selectable for further payment until it’s fully paid.

Bill responses, queries, and reports now include paidAmount and outstandingBalance (outstanding = netAmount − paidAmount). You can filter for partially paid bills with ?status=75, and you can subscribe to a new BillPartiallyPaid webhook that fires on each partial payout. Paying more than the outstanding balance returns error 3448, a request with more than one bill returns 3451, and paying a bill that’s already fully paid returns 3411.

Partial payouts are available on request for managed payables only — on-demand payout methods stay full-payment-only. Contact the Payabli team to turn on partial payouts for your account.

See Manage bills and the API response codes reference.

Documentation updates

As part of an ongoing effort to better align the documentation with the API, we’ve corrected a field name in the response reference. The API itself was already returning this data. This change affects the documentation only.

`Summary.pageIdentifier` corrected to `pageidentifier`

The reference documented the Summary object’s pagination-token field as pageIdentifier, but the API has always returned it as pageidentifier. We’ve corrected the schema and examples to match.

This affects the response reference for the following endpoints:

Server SDKs keep their existing PageIdentifier / page_identifier member name for this field, so there’s no breaking change for SDK consumers. The casing mismatch made the field always deserialize to null. It now decodes correctly.