Refunds & Cancellations

Split payments are refunded and cancelled with the core payment endpoints — there is no separate marketplace refund API. You call POST /payments/{id}/refund (full or partial) or POST /payments/{id}/void on the payment id, exactly as described in Refunds and Pre-authorization, Capture & Void. This page covers what that means for a payment that carries seller legs.

⚠️

Amounts are minor units (kuruş): "amount": 5000 = ₺50.00.

How it works

Pick the right operation

Void releases an authorization that has not been captured (no partial). Refund returns money on a captured/settled payment — full or partial, cumulative across multiple calls.

Call the core endpoint

Both are Step-Up endpoints and settle against the original provider and credential used by the payment — they never re-route.

Reconcile the seller side

The refund is processed at the transaction level; the seller breakdown remains tracked on the transaction record. Use it to drive your own seller-facing adjustments before the next payout.

Request

# Partial refund of ₺50.00 on a split payment
curl -X POST https://api-gateway.lunixi.com/api/v1/payments/pay_01HV3K9X7QWE.../refund \
  -H "Authorization: Bearer <access-token>" \
  -H "X-Key-Id: <key-id>" \
  -H "X-Date: <iso-timestamp>" \
  -H "X-Nonce: <nonce>" \
  -H "X-Signature: <ed25519-signature>" \
  -H "Idempotency-Key: 9d2f4c81-6a3e-4b7d-8c5f-0e1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{ "amount": 5000, "reason": "buyer returned one item" }'
 
# Void an uncaptured authorization
curl -X POST https://api-gateway.lunixi.com/api/v1/payments/pay_01HV3K9X7QWE.../void \
  -H "Authorization: Bearer <access-token>" \
  -H "X-Key-Id: <key-id>" \
  -H "X-Date: <iso-timestamp>" \
  -H "X-Nonce: <nonce>" \
  -H "X-Signature: <ed25519-signature>" \
  -H "Idempotency-Key: 1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d"

Omit amount for a full refund. The payment's status moves to REFUNDED, PARTIALLY_REFUNDED or VOIDED — the full status model and cumulative-partial rules live in the core Refunds guide.

What happens to the seller legs

The refund or void executes against the payment as a whole — the buyer is made whole in a single operation, regardless of how many sellers the charge was split across.
Once the payment's status is REFUNDED, PARTIALLY_REFUNDED or VOIDED, every seller leg of that transaction reads legStatus: "REVERSED" in GET /marketplace/transactions — the leg status follows the transaction, it is not prorated per seller.
The transaction record keeps its seller breakdown (per-leg net, commission, hold), so you can always see which sellers a refunded payment had been split across. Internally, Lunixi's settlement accounting reverses the refund across the seller legs in proportion to each leg's share of the charge.
How a partial refund is allocated to individual sellers is a business decision on your side (which seller's item was returned?). Use the recorded breakdown to compute the adjustment and reflect it in the seller's payout — for example with a manual entry in the payout ledger.

Practical rule of thumb: refund the buyer first (core endpoint), then reconcile the affected seller's balance before the next payout run. The audit log records both sides.

Errors

Status	Meaning	What to do
`400`	Amount exceeds the refundable balance, or void attempted after capture	Check the payment's current status and captured/refunded amounts
`401` / `403`	Step-Up auth failed	Re-sign — see Authentication
`404`	Payment not found	Verify the payment id

Webhooks

payment.refunded / payment.partially_refunded — after a successful refund
payment.voided — after a successful void

See the webhook reference for payload shape and delivery semantics.

Next steps

Refunds (core) — partial/cumulative rules, statuses, edge cases
Pre-authorization, Capture & Void — the authorization lifecycle
Transactions & Payouts — seller breakdown and payout adjustments

3D Secure Payment Transactions & Payouts