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, Update a payment page, Get payment page details, and Get all payment page details.
v2 refunds support split funding
The v2 refund endpoints now support refunding split-funded transactions. Refund a settled transaction and Partially 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 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 and for an organization.
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:
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. 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 endpoint with split instructions in the request body. This replaces the legacy Refund a settled transaction with split instructions endpoint.
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 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 for the full workflow, balance requirements, and lifecycle differences from ACH.
New endpoint for depositing funds
We’ve added the 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 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 and Authorize payout endpoints return when a risk policy acts on a transaction. Both previously returned 400, which incorrectly implied the request itself was invalid.
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 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 and Manage payouts.
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 (
POST /Vendor/enrich/schedule_call/{entry}) schedules a call to a vendor. - Get outreach call status (
GET /Vendor/{vendorId}/enrichment/call-status) returns the latest call activity for a vendor.
The 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 for behavior and Enrich vendors with the API for integration details.
Pay Out responses now include vendorId
We’ve added a vendorId field to the responseData on the Pay Out Authorize, Capture, and Cancel 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.