Skip to main content
PUT
Update the split of a paid transaction
Marketplaces that redistribute an order after payment (a different seller delivers, an item is swapped) can replace the split of a paid transaction instead of refunding and charging again. The update replaces the whole split: the legs you send become the split, and legs you do not send are removed. The payment and the transaction keep their status, and no new transaction is created.

When an update is accepted

  • The transaction is a PURCHASE with status SUCCEEDED.
  • 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 409 with SPLIT_UPDATE_WINDOW_CLOSED or SPLIT_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 409 with SPLIT_UPDATE_NOT_ALLOWED.
  • The provider of the transaction supports it. Availability is enabled per connection; contact Yuno to enable it for yours.
Every leg must name its recipient (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 on transactions.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 a 502 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 with 400 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

public-api-key
string
header
default:<Your public-api-key>
required
private-secret-key
string
header
default:<Your private-secret-key>
required

Headers

X-Idempotency-Key
string
required

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

payment_id
string
required

The unique identifier of the payment (MAX 64; MIN 36).

transaction_id
string
required

The unique identifier of the purchase transaction whose split is replaced (MAX 64; MIN 36).

Body

application/json
split_marketplace
object[]
required

The new split: every leg the transaction must have after the update.

Minimum array length: 1
description
string

Description of the update (MAX 255; MIN 3).

metadata
object[]

Custom key-value pairs stored with the update.

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.