Update the split of a paid transaction
Replace the split_marketplace of a transaction that is already paid, before the provider settles it
When an update is accepted
- The transaction is a
PURCHASEwith statusSUCCEEDED. - The provider still allows it: before settlement, and while the provider’s limit of split changes per transaction is not reached (each update uses that allowance once per leg). Both conditions belong to the provider; when one fails you get a
409withSPLIT_UPDATE_WINDOW_CLOSEDorSPLIT_UPDATE_LIMIT_REACHED, and the split is not changed. Yuno counts the changes already made and refuses an update that would pass the limit before it reaches the provider. - The payment has no refund (partial, total, or one waiting to be retried), no chargeback and no transfer reversal. Otherwise you get a
409withSPLIT_UPDATE_NOT_ALLOWED. - The provider of the transaction supports it. Availability is enabled per connection; contact Yuno to enable it for yours.
recipient_id or provider_recipient_id, never both) and its amount. The amounts must not add up to more than the transaction amount, in the currency of the payment.
Idempotency
X-Idempotency-Key is required. A timeout is not a failure: the update may have been applied at the provider even if you did not get the answer. Repeat the request with the same key and the same body and you get the outcome of the first attempt, without a second change at the provider: the same status, and the payment as it is at that moment (after a later update, the split shown is the current one). The same key with a different body is refused with SPLIT_UPDATE_IDEMPOTENCY_CONFLICT. If you repeat the request while the first attempt is still running (for example right after your own timeout), the answer is 400 OPERATION_IN_PROCESS and nothing changes: wait a few seconds and repeat it again with the same key. Use a new key only for a new change.
Where to read the split
The answer is the payment, in the same shape as Retrieve payment by ID. Read the split ontransactions.split_marketplace; the payment-level split_marketplace array does not carry it. The same is true of every later GET /payments/{payment_id}.
When the provider does not confirm
If the provider does not confirm the outcome (a timeout at the provider, or a failure while it replaced the rules), the answer is a502 with PROVIDER_ERROR and the update stays under review by Yuno. Do not send a new update for that transaction: it is refused with 409 SPLIT_UPDATE_NOT_ALLOWED until the review is complete. A retry with the same key returns the same 502. Refunds of that payment are refused until the review is complete too (next section).
Refunds while an update is open
While an update of a payment is in progress or under review, refunds of that payment (including cancel-or-refund) are refused with400 OPERATION_IN_PROCESS, the same answer as for any other operation running on the payment. Under review, the message says so. Nothing is recorded for the refused refund: repeat it with the same idempotency key once the update finishes. Refunds requested in bulk are not retried automatically; request them again.
Response codes
Authorizations
Headers
Required. Unique identifier of this update (MAX 64). A request that times out is not a failure: repeat it with the same key and you get the outcome of the first attempt. The same key with a different body is refused with SPLIT_UPDATE_IDEMPOTENCY_CONFLICT. A repeat sent while the first attempt is still running is answered 400 OPERATION_IN_PROCESS and changes nothing: wait a few seconds and repeat it again with the same key.
Path Parameters
The unique identifier of the payment (MAX 64; MIN 36).
The unique identifier of the purchase transaction whose split is replaced (MAX 64; MIN 36).
Body
Response
The split was replaced. The answer is the payment, in the same shape as Retrieve payment by ID; read the new split on transactions.split_marketplace.
The payment object. See The payment object.