> This is Payabli documentation. For a complete page index, fetch https://docs.payabli.com/llms.txt — append .md to any page URL for lightweight markdown. For section-level indexes, query parameters, and other AI-optimized access methods, see https://docs.payabli.com/ai-agents.md

This entry covers the API changes released on June 15, 2026.

## Pay In

### Hide the save payment method checkbox on payment pages

We've added a `showSaveMethod` boolean to the `paymentMethods` section of a hosted payment page's content. Set it to `false` to hide the "Save payment details for future use" checkbox on the page. It defaults to `true`, so existing payment pages keep showing the checkbox unless you change it.

The field is available on the payment page endpoints: [Create a payment page](/developers/api-reference/hostedpaymentpages/create-a-payment-page), [Update a payment page](/developers/api-reference/hostedpaymentpages/update-a-payment-page), [Get payment page details](/developers/api-reference/hostedpaymentpages/get-payment-page-details), and [Get all payment page details](/developers/api-reference/hostedpaymentpages/get-all-payment-page-details).

### v2 refunds support split funding

The v2 refund endpoints now support refunding split-funded transactions. [Refund a settled transaction](/developers/api-reference/moneyinV2/refund-a-settled-transaction) and [Partially refund a settled transaction](/developers/api-reference/moneyinV2/partial-refund-a-settled-transaction) accept an optional request body with split instructions. Omit the body for a standard refund, or include `refundDetails.splitRefunding` to refund across the original split recipients. Split refunds now return the unified v2 response format, matching the legacy [Refund a settled transaction with instructions](/developers/api-reference/moneyin/refund-a-settled-transaction-with-instructions) endpoint.

### Settlement query responses include split transfer details

Settlement query responses now enrich each item in `splitFundingInstructions` with the batch and transfer that paid out the split. This applies to [Get list of settled transactions for an entrypoint](/developers/api-reference/query/get-list-of-settled-transactions-for-an-entrypoint) and [for an organization](/developers/api-reference/query/get-list-of-settled-transactions-for-an-org).

Each split instruction now carries three additional fields, alongside the existing `recipientEntryPoint`, `AccountId`, `Description`, and `Amount`. `batchNumber` and `transferId` are null when the batch or transfer isn't yet available:

| Field            | Type            | Description                                                                                |
| ---------------- | --------------- | ------------------------------------------------------------------------------------------ |
| `batchNumber`    | string or null  | The batch the split was paid out in. Null when the batch isn't available.                  |
| `transferId`     | integer or null | Identifier of the transfer that carried the split. Null when the transfer isn't available. |
| `transferAmount` | number          | The total amount of the transfer that carried the split.                                   |

### Legacy Pay In transaction endpoints are deprecated

We've deprecated the legacy Pay In transaction lifecycle endpoints. They still work for transactions originally created with the legacy endpoints, but new integrations should use the v2 endpoints, which return the [unified response format](/guides/pay-in-unified-response-codes-reference). Transactions created with a legacy endpoint must be managed with the legacy lifecycle endpoints, and transactions created with a v2 endpoint must be managed with the v2 endpoints. The two sets aren't interchangeable.

To refund a split-funded transaction, use the [Refund a settled transaction](/developers/api-reference/moneyinV2/refund-a-settled-transaction) endpoint with split instructions in the request body. This replaces the legacy [Refund a settled transaction with split instructions](/developers/api-reference/moneyin/refund-a-settled-transaction-with-instructions) endpoint.

| Deprecated endpoint                                                                                                                      | Use instead                                                                                                                                                                                                         |
| ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Make a transaction](/developers/api-reference/moneyin/make-a-transaction)                                                               | [Make a transaction](/developers/api-reference/moneyinV2/make-a-transaction)                                                                                                                                        |
| [Authorize a transaction](/developers/api-reference/moneyin/authorize-a-transaction)                                                     | [Authorize a transaction](/developers/api-reference/moneyinV2/authorize-a-transaction)                                                                                                                              |
| [Capture an authorized transaction](/developers/api-reference/moneyin/capture-an-authorized-transaction)                                 | [Capture an authorized transaction](/developers/api-reference/moneyinV2/capture-an-authorized-transaction)                                                                                                          |
| [Void a transaction](/developers/api-reference/moneyin/void-a-transaction)                                                               | [Void a transaction](/developers/api-reference/moneyinV2/void-a-transaction)                                                                                                                                        |
| [Refund a settled transaction](/developers/api-reference/moneyin/refund-a-settled-transaction)                                           | [Refund a settled transaction](/developers/api-reference/moneyinV2/refund-a-settled-transaction)                                                                                                                    |
| [Refund a settled transaction with split instructions](/developers/api-reference/moneyin/refund-a-settled-transaction-with-instructions) | [Refund a settled transaction](/developers/api-reference/moneyinV2/refund-a-settled-transaction) with split instructions                                                                                            |
| [Reverse a transaction](/developers/api-reference/moneyin/reverse-a-transaction)                                                         | No direct equivalent. Check the transaction's settlement status, then [Void](/developers/api-reference/moneyinV2/void-a-transaction) or [Refund](/developers/api-reference/moneyinV2/refund-a-settled-transaction). |

## Pay Out

### Instant payouts with wire and Real-Time Payments

We've added wire transfer and Real-Time Payments (RTP) as instant payout rails for vendor disbursements. Set `paymentMethod.method` to `"wire"` or `"rtp"` on the [Authorize payout](/developers/api-reference/moneyout/authorize-a-transaction-for-payout) endpoint, using the same `achHolder`, `achRouting`, `achAccount`, and `achAccountType` fields as ACH. Both rails are US domestic only and irrevocable: once captured, a wire or RTP payout can't be cancelled or reissued.

Instant payouts draw against the paypoint's available payout balance, which Payabli validates at authorize time for wire and RTP. Two balance-specific errors return error code `3729` with HTTP `400 Bad Request`: one when Payabli can't read the balance, and one when the amount exceeds the available balance.

See [Send instant payouts](/guides/pay-out-developer-instant-payouts) for the full workflow, balance requirements, and lifecycle differences from ACH.

### New endpoint for depositing funds

We've added the [Deposit funds](/developers/api-reference/funding/deposit-funds) endpoint (`POST /Funding/depositFunds`) for adding funds to a paypoint's available payout balance. Deposited funds enter a pending state and become available for instant payouts once confirmed through FBO reconciliation.

### New wire and Real-Time Payments payout statistics

The [Get basic statistics](/developers/api-reference/get-basic-statistics-for-a-paypoint-or-organization) endpoint (`GET /Statistic/basic`) now returns four fields that break out outbound RTP and wire activity: `outRTPTransactions`, `outRTPVolume`, `outWireTransactions`, and `outWireVolume`. Each follows the existing per-rail count and volume pattern and returns `0` when there's no activity on that rail.

### Capture and authorize return 202 or 422 on risk policy outcomes

We've updated the HTTP status codes the [Capture payout](/developers/api-reference/moneyout/capture-an-authorized-payout-transaction) and [Authorize payout](/developers/api-reference/moneyout/authorize-a-transaction-for-payout) endpoints return when a risk policy acts on a transaction. Both previously returned `400`, which incorrectly implied the request itself was invalid.

| Risk outcome    | Status | Response code | Meaning                                                                                   |
| --------------- | ------ | ------------- | ----------------------------------------------------------------------------------------- |
| Held for review | `202`  | `9051`        | Velocity fraud alert. The transaction is accepted and held for risk review, not rejected. |
| Blocked         | `422`  | `9005`        | A risk policy blocked the transaction. Terminal rejection.                                |

In both cases the body still carries `isSuccess: false` and the `responseData` detail block. `400` is now reserved for structurally invalid requests. Update any integration that treats a `400` on these endpoints as an outright failure, so a held transaction isn't mistaken for a rejected one. See [Manage payouts](/guides/pay-out-developer-payouts-manage#capture-a-payout-transaction) for details.

### New `Capturing` payout status

Payouts now report a transient `Capturing` status (`12`) while a capture is in progress, between `Authorized` (`11`) and `Captured` (`1`). See [Pay Out statuses](/guides/pay-out-status-reference#payout-transaction-statuses) and [Manage payouts](/guides/pay-out-developer-payouts-manage#capture-a-payout-transaction).

### Pay Out transaction webhooks now include `RefundAmount`

We've added a `RefundAmount` field to all Pay Out transaction webhooks.
If a vendor partially refunds a transaction, this field contains the amount left of the original transaction after the refund.
Example: If the original transaction was for \$100.00, and the vendor issues a partial refund of \$30.00, this field has a value of \$70.00.

### AI vendor outreach calling (beta)

Vendor enrichment now includes an AI outreach call as a third stage. When invoice scanning and web search can't determine how a vendor wants to be paid, Payabli can schedule an AI agent to call the vendor and collect their preferred payment method and contact email.

We've added two endpoints:

* [Schedule outreach call](/developers/api-reference/vendor/schedule-enrichment-call) (`POST /Vendor/enrich/schedule_call/{entry}`) schedules a call to a vendor.
* [Get outreach call status](/developers/api-reference/vendor/get-enrichment-call-status) (`GET /Vendor/{vendorId}/enrichment/call-status`) returns the latest call activity for a vendor.

The [enrich vendor](/developers/api-reference/vendor/enrich-vendor) endpoint also accepts a new `scheduleCallIfNeeded` parameter that triggers the call automatically when the earlier stages return insufficient data.

Outreach calling is in beta and is opt-in. Contact your Payabli representative to enable it, provision a phone number, and discuss pricing. See [Vendor enrichment](/guides/pay-out-vendor-enrichment-overview) for behavior and [Enrich vendors with the API](/guides/pay-out-developer-vendor-enrichment-integrate) for integration details.

### Pay Out responses now include `vendorId`

We've added a `vendorId` field to the `responseData` on the Pay Out [Authorize](/developers/api-reference/moneyout/authorize-a-transaction-for-payout), [Capture](/developers/api-reference/moneyout/capture-an-authorized-payout-transaction), and [Cancel](/developers/api-reference/moneyout/cancel-a-payout-transaction) payout responses. `vendorId` returns the Payabli vendor ID for the payout, the same value as the existing `customerId` field, which is unchanged and continues to work. Use `vendorId` for clearer Pay Out semantics.

### Transfer report adds `type` and `method`

We've added `type` and `method` fields to the Pay Out transfer report, returned by [Get list of outbound transfers for a paypoint](/developers/api-reference/query/get-list-of-transfers-out-for-entrypoint) and [for an organization](/developers/api-reference/query/get-list-of-transfers-out-for-organization).

| Field    | Type           | Description                                             |
| -------- | -------------- | ------------------------------------------------------- |
| `type`   | string or null | The transfer type: `debit`, `credit`, or `billing`.     |
| `method` | string or null | The payment method, such as `ach`, `vcard`, or `check`. |

You can also filter the report by these values with two new filters, `detailType` and `detailMethod`. Both support the `eq`, `ne`, `in`, `nin`, `ct`, and `nct` operators. See the [reporting engine reference](/developers/developer-guides/pay-ops-reporting-engine-overview#filters-and-conditions-reference) for filter syntax.