Capture, Refund, Void

Reference pages: Capture Sale, Refund Sale, Void Authorization, the capture guide, Idempotency and Retries.

Send seller_payme_id on all three. A partner also sends payme_client_key, and that seller must belong to it: otherwise refund-sale fails with error 303.

Authorize now, capture later

generate-sale with sale_type: "authorize", the buyer pays, the sale is authorized, then capture-sale moves it to completed.

Rule	What happens otherwise
Capture within 7 days of the authorization	Error 516
Capture once	A second capture fails with error 305 in the sandbox, with `completed` as the additional information
Capture only after the buyer paid	A sale still `initial` fails with error 305 in the sandbox

Alert before the limit, for example at 144 hours, counted from the authorization. Your own business decides what happens then.
Send language: "en", or errors arrive in Hebrew.
A partner's market_fee is set when the sale is created, not at capture: see Platform Fees.

Partial capture

PayMe accepts sale_price on capture-sale, within the account's capture limit. What happens to the rest of the hold is unconfirmed, and the query check fails by design because no row matches the full order amount. Don't offer partial capture until PayMe answers (see What to Ask PayMe First).

Refund

Leave out sale_refund_amount for the full amount. To refund part, send it in minor units, within the allowed range.
Partial refunds can repeat while the total stays within the sale. Refunding when nothing is left failed with error 352 in the sandbox, and a refund above the sale's price failed with error 517.
After a partial refund, a refund with no amount returned exactly the rest in the sandbox: a 2000 sale refunded 1000, then 1000.
The sale then stays partial-refund. It never moves to refunded. Add each response's payme_transaction_total to your own refunded total, and block further refunds when it equals the price.
If a refund's outcome is unknown, re-read the rows. A refund row settles it: count it once. No row doesn't prove there was no refund, so keep further refunds blocked until a person records the true total (TRN-04).

Void

There's no separate call: refund-sale with no amount on an uncaptured authorization releases the hold, and the status becomes voided. This worked for a partner and for a direct seller in the sandbox.

Show it as "Void" for authorized sales and "Refund" for completed ones.
A void's refund callback isn't refunded money. Skip it when the status is voided.
A void adds no refund row. To confirm one, read get-sales, or get-transactions with transaction_type: 40: its row shows sale_status voided. A default query returned no rows for a voided sale in the sandbox. Add transaction_status: ["validated", "voided"] to see the Void row too.

Reading the rows

Each get-transactions row has a transaction_action, and PayMe's values are:

`transaction_action`	What the row is
`Debit`	A charge. Seen in the sandbox
`Authorize`, `Capture`	A hold, and taking it
`Refund`, `Partial Refund`	Money back to the buyer. Seen in the sandbox
`Void`, `Partial Void`	A hold released, not refunded money. `Void` seen in the sandbox
`Chargeback`, `Partial Chargeback`	The card company took the money back
`Chargeback Refund`, `Partial Chargeback Refund`	A chargeback reversed. Not a refund to the buyer
`Tokenize`, `Detokenize`	Token work, with no money moved

To add up refunds:

Count a row only if transaction_action is exactly Refund or Partial Refund, and transaction_status is refunded or p-refund. Don't match the word "refund", which also finds Chargeback Refund, and don't count a row whose status is failed.
Its transaction_price is the positive amount refunded. The charge row keeps the sale's full price.
Count each row once, by payme_transaction_id. A refund-sale response gives that same ID, so a response and a row can't add the amount twice.
A signed callback is only a reason to re-read. Never add from its body (CB-01).