Skip to main content
Merchant Settlement describes the cycles we offer (T+1, T+10, weekly). This page covers the operational side: which transactions fall into a settlement, which calendar day the funds land on, and why a settlement date can pass with no money and no file. Report columns are defined in Reconciliation reports.

​
How is my settlement date calculated?

  1. Scope by transaction day. Settlement preparation runs after each natural day closes and picks up transactions whose success time falls in the previous day, 00:00:00–23:59:59 UTC+8.
  2. Add the contracted cycle, then land on a business day. For a T+N cycle the settlement date is the first business day at or after T+N — business days come from a holiday calendar, not a fixed weekday rule.
Date fields on the Portal’s Settlement Batch pages are labelled (UTC+8) for this reason.

​
Why does my transaction-day total differ from yours by one day?

This is the most common reconciliation gap, and three rules explain nearly all of it:

​
Why do transactions on the same day settle on different dates?

A settlement cycle is not a single merchant-level setting. Settlement agreements are configured per MID + payment method (and per contracted country), each carrying its own cycle type (day-based or week-based) and delay count N, its own settlement currency, and its own settlement target account. Two payment methods used on the same day — or the same method in two countries — can legitimately settle on different dates and in different currencies.

​
What settlement cycles can my agreement be on?

Five cycle types exist. Which one you are on, and the delay count N that goes with it, are set on your settlement agreement per MID and payment method — so different payment methods can be on different cycles. The cycle type decides two things at once: which transactions are grouped together, and which date the delay is counted from. Read together with the rule above: N is added to that date, and then the business-day rule moves the result out until it lands on a business day. So T+N on a DAY cycle means N days after the transaction day itself; the same N on a WEEK cycle means N days after the week has closed. Two points that cause most of the confusion:
  • MONTH_1X groups exactly the same transactions as MONTH. The difference is only where the delay starts: the end of the following month rather than the end of the transaction month, so with the same N it pays out roughly a month later.
  • On anything other than DAY, one settlement covers a range of days. That is why the calendar’s Transaction Period shows a range rather than a single date, and why your own daily totals will not line up one-for-one against a settlement.

​
Which holidays affect my settlement date?

Not one country’s calendar. The business-day calculation uses the merged, de-duplicated holiday calendar of all related countries configured on your acquiring contract for that contracted country, weekends included. If any related country is closed, the date is not a settlement day and the settlement defers. Clicking a non-settlement day in the Portal calendar lists the reasons one by one as Related Holidays (country + holiday name), rather than a bare “Non-settlement Day” label. Only confirmed holidays are shown.

​
How do I read and export the settlement calendar?

The calendar’s primary dimension is Country/Region — a single-select list of the countries covered by your active contracts, shown as ISO 3166-1 alpha-3 codes, first one selected by default. Everything follows that selection:
  • Regions of Holidays shows only the related countries of the selected country/region.
  • Transaction days and settlement dates (including deferred ones) are derived for that country/region only.
  • Rows show Transaction Period, Scheduled Settlement Date and Actual Settlement Date.
  • Export produces settlement_calendar_[Region]_[YYYYMM].xlsx with those same three columns, covering the selected country/region only.
The calendar is a schedule view and offers no per-date file download — reconciliation reports are attached to the settlement batch instead. Scheduled Settlement Date (Deferred) exists because a scheduled date is computed when transactions are packed, and can still move afterwards — the holiday calendar changes, or a negative period rolls forward. It carries the deferred result, so both the original and the currently expected date stay visible.

​
What exactly is one Settlement Batch?

A batch deliberately spans countries, payment methods and order currencies. So if one settlement date carries two settlement currencies, you get two batches, each with its own settlement details and summary reports. The Settlement Batch list defaults to the last 30 days; a batch’s detail page exposes its reconciliation reports and a transaction-level export. Inside a batch each transaction clears in a fixed four-step order — relevant if you recompute net amounts: fees and taxes billed in the order currency are deducted first, the remainder is converted to the settlement currency, fees and taxes billed in other currencies come next, and what remains is the Net Settlement Amount.

​
A settlement date passed with no money and no file. Why?

Usually the period’s net amount was negative — refunds and chargebacks exceeded payments. Then:
  • No funds move on that date and no settlement batch record is created, which is also why no settlement report is generated by default.
  • The negative balance is carried forward and merged with following periods until the cumulative net turns positive; that settlement is the one that pays out.
  • We do not draw on your reserve to cover a negative period, and refunds are not funded from the reserve either.
To tell “nothing to settle” apart from “file generation failed”, ask support to enable header-only placeholder files on every scheduled date — it is a per-merchant configuration.

​
Why did a settlement of refunds from my refund reserve arrangement ignore the holiday calendar?

Because that kind of settlement is deliberately kept off the business-day rule. Refunds that were funded from your refund reserve account — see Where Refund Money Comes From — are not netted into your ordinary settlements. They are cleared on their own, in their own settlement batch, and on their own date: The reason for the exception is that this settlement closes out an arrangement rather than paying out a trading period. Its date is fixed by the arrangement you agreed to, so letting each related market’s holidays push it around would make the close-out date unpredictable — the opposite of what the business-day rule is there to achieve for ordinary settlements. How to recognise one when you are reconciling:
  • It is a separate settlement batch, so a date can carry both an ordinary settlement and one of these.
  • Its transactions are refunds, not payments.
  • The Comments field on the settlement record, and in its settlement summary and detail files, is filled in to mark it as a refund reserve settlement. On an ordinary settlement that field is empty.
What the reserve account itself is, and how holds and releases on it are counted, is in Reserves — note that a rolling reserve’s release date is a different calculation, counted in business days or calendar days according to your contract.

​
An older settlement is still open. In what order do retries happen?

A settlement that could not be booked because the unsettled account lacked balance is retried on later settlement runs, in a fixed order: oldest settlement date first, then within the same date largest amount first, until even the smallest outstanding settlement cannot be covered. Later dates are not processed ahead of an unfinished earlier one — which is why a Portal record can show a settlement date earlier than today and still be open.
Still not matching? Contact support with the settlement batch id or the transaction day you are reconciling.