Reconcile sales and withdrawals

What the API can match

The public API has no field that links a withdrawal to the sales inside it. get-withdrawals returns totals, and get-transactions has no withdrawal code. You can estimate which transactions a withdrawal covers from their release dates, but the result is an estimate.

There is one exception. When a partial withdrawal is requested with transaction_ids on withdraw-balance, the response lists the transactions involved. Store that list if you need a direct link.

If the card companies pay a seller directly, also compare against those companies' statements.

Before you start: catch missed callbacks

Compare against PayMe's records, not only your own database. A callback is dropped after three failed delivery attempts, so an order your system shows as unpaid may be paid.

On a schedule, call get-sales for the sales you still treat as open and apply the sale_status it returns. get-sales leaves out initial sales unless you ask for them, so include that status when you need them:

{
  "seller_payme_id": "MPLDEMO-MPLDEMO-MPLDEMO-1234567",
  "sale_status": ["initial", "authorized"],
  "sale_created_min": "2026-11-03 00:00:00",
  "page_size": 500,
  "page": 1
}

Step 1: List the withdrawals

Call get-withdrawals for the period and keep withdrawal_payme_code, withdrawal_created, withdrawal_currency and withdrawal_total. Also keep withdrawal_source and withdrawal_card_brand, which tell apart split withdrawals on the same date. Sort by date with items_order_by_column.

{
  "seller_payme_id": "MPLDEMO-MPLDEMO-MPLDEMO-1234567",
  "withdrawal_currency": "ILS",
  "withdrawal_created_min": "2026-10-01 00:00:00",
  "withdrawal_created_max": "2026-10-31 23:59:59",
  "items_order_by_column": "withdrawal_created",
  "items_order_by_direction": "asc",
  "page_size": 500,
  "page": 1
}

withdrawal_payme_code is the same number as withdrawal_id in the withdraw-balance response and tran_payme_code in the withdrawal-complete callback.

Step 2: List the money movements

Call get-transactions for the same seller and currency. It filters on the creation date only, so start well before the first withdrawal you are checking: a transaction can be released long after it was created.

{
  "seller_payme_id": "MPLDEMO-MPLDEMO-MPLDEMO-1234567",
  "sale_currency": "ILS",
  "transaction_status": ["validated", "refunded", "p-refund", "chargeback", "partial-chargeback", "chargeback-refund", "partial-chargeback-refund"],
  "transaction_created_min": "2026-07-01 00:00:00",
  "transaction_created_max": "2026-10-31 23:59:59",
  "page_size": 500,
  "page": 1
}

Keep requesting pages until items_count is lower than page_size.

Step 3: Group by release date

For each withdrawal, take the transactions whose transaction_release_date falls after the previous withdrawal's withdrawal_created and no later than this one's. Then add them up, using transaction_price_after_fees on validated rows and transaction_price on the others, with the sign from this table:

`transaction_status`	Effect on the seller's balance
`validated`	Add
`refunded`, `p-refund`	Subtract
`chargeback`, `partial-chargeback`	Subtract
`chargeback-refund`, `partial-chargeback-refund`	Add

Amounts on these rows are positive, so apply the sign yourself. All amounts are in minor units, and timestamps are Asia/Jerusalem local time.

Step 4: Expect some differences

The sum can differ from withdrawal_total for these reasons:

Installments: a sale paid in installments can be released in parts, while transaction_release_date is a single date.
Other charges: a withdrawal also reflects charges that are not transaction fees and do not appear in get-transactions.
Split withdrawals: one seller can have several withdrawals on the same date, split by source and card brand (withdrawal_source and withdrawal_card_brand on get-withdrawals).
Partial withdrawals: these take specific transactions out of the date order.
Returned fees: a refund's effect also depends on the fees returned to the seller.
Settlement timing: transaction_price_after_fees holds its final value once the transaction is settled. Until then it can equal transaction_price.

If a difference remains, contact PayMe with the withdrawal_payme_code.

Fees

On validated rows, use transaction_price_after_fees as the net amount. The fee detail in sale_fees explains the charge, but adding up its *_total values won't reproduce the net amount, because sale_processing_fee_total, sale_discount_fee_total and sale_rapid_settlement_fee_total exclude VAT.

Field in `sale_fees`	Meaning
`sale_processing_fee`, `sale_processing_fee_total`	Processing rate, and its total in minor units
`sale_processing_charge`	Fixed processing charge, in major units
`sale_discount_fee`, `sale_discount_fee_total`	Discount rate, and its total
`sale_rapid_settlement_fee`, `sale_rapid_settlement_fee_total`	Rapid settlement rate, and its total
`sale_annual_interest_rate`	Annual interest rate (percent) behind the discount and rapid settlement fees
`sale_market_fee`, `sale_market_fee_fixed`, `sale_market_fee_total`	Platform fee percent, fixed platform fee in major units, and the total in minor units. On get-transactions, the total covers the percent part plus the fixed part, worked out on the row's `transaction_price`. See Platform fees

Refunds and chargebacks

Sale status: get-sales keeps one row per order and shows refunded, partial-refund, chargeback or partial-chargeback in sale_status. Use get-transactions for the amount and date of each event.
Refunds in parts: each partial refund is its own transaction row with its own payme_transaction_id. A sale refunded in parts stays partial-refund, even after the whole amount is returned, so add up the refund rows to know the refunded total.
Notifications: the sale-chargeback and sale-chargeback-refund callbacks tell you when a chargeback arrives or is reverted.