What are the limits on the batch file itself?
A CSV will not upload, whatever your spreadsheet tool suggests. Save as
.xlsx.
An empty file — a template with no data rows — is also rejected and cancels the batch, so a batch
that vanishes immediately after upload is usually a file whose rows did not sit where the template
expects them.
What do Batch name and Batch description do? Does the payee see them?
Neither is shown to any payee. Both are labels on your own batch record:
The description exists to tell a colleague approving the batch what it is for. What the payee
actually sees on their statement is the per-row description from the file, not either of these.
A row failed validation. Can I just send the good rows?
No. Validation is all-or-nothing: a single failed row cancels the whole batch, and there is no way to submit the rows that passed. Fix the file and upload it again. You do get told exactly what was wrong with each row. After validation the batch record carries a Checked file — the same rows you uploaded, with a failure-reason column filled in on the rows that failed, carrying the error code and its message. Work from that file rather than guessing: the reasons are per-row and specific, covering field format problems, a row whose country or currencies differ from the rest of the batch, a payee account the receiving side rejected, and rows that fell past the available balance.What statuses can a batch have?
Exactly two, from your side:
There is no third value. The filter on the batch list offers these two and
nothing else.
Two things follow from that, and both surprise people:
- In Progress covers several distinct internal stages. A batch can sit in In Progress for a while and still be moving. Do not read a long In Progress as a stall.
- Completed means “all rows finalised”, not “all rows succeeded”. A batch in which every row failed is still Completed. Always read the row statuses, never the batch status, to know whether money moved.
Why can’t I see a batch I know I created?
Because a batch only appears on your list once it has been submitted. Before that, and if it never gets there, it is not in the merchant view at all — the batch list query itself filters to In Progress and Completed rather than merely hiding other values in the UI. The case to watch for: a batch that is abandoned before processing — for example because the available balance was insufficient at submission, or because it sat unsubmitted past its validity — drops out of the list rather than appearing as failed or cancelled. If a batch you expected has vanished, do not assume it silently went through. Re-check your balance at the time of submission and create the batch again.What statuses can an individual row have?
Three, and these are the ones that tell you what actually happened:
Each row also carries a status timeline. The batch-level timeline is coarser —
it shows the submission, the processing start and the completion — so use the
row timeline when you need to explain a specific payee’s delay.
If a row shows no status at all, it is a row that never got as far as being
routed — typically one that failed file validation. Treat a blank row status as
a failure to resubmit, not as a pending payout.
What does the batch status timeline show?
Three points: Submitted, when the batch passed verification and was accepted — before any money moved; In Progress, when the funds were debited and processing began; and Completed, when every row finalised. Intermediate internal stages are not exposed as timeline nodes, so the timeline is a progress indicator rather than an audit trail. For reconciliation use the source, checked and result files attached to the batch record.Why are only some countries offered when I download a batch template?
Because templates are issued per contracted country. The list you see is derived from your signed payout agreements: one template per country covered by an agreement that is currently active and inside its validity window.- No active agreement means no templates at all — an empty list here is a contracting question, not a bug.
- The restriction is enforced on the download, not only in the UI. Asking for a country you are not contracted for is rejected rather than served.
- The country you are contracted for also determines which columns the template asks for, which is why you cannot reuse one country’s file for another.
Is there a second confirmation step before a batch goes out?
Yes — an explicit confirmation in the Portal after the preview. You see the available settlement balance, the total payout amount, the recipient total and the fee total, and you have to confirm before anything is debited. Insufficient balance rejects the submission at that point rather than part-processing the batch. That confirmation is an in-Portal step. Do not build a runbook that expects a verification code to arrive by email at this stage.I uploaded a batch but did not submit it. Can I cancel it?
You do not need to. A batch that has been uploaded but not submitted is closed automatically around four hours after it was created, and closing it costs nothing — the debit happens at submission, so an unsubmitted batch has never touched your balance. Two consequences worth planning around:- There is no cancel action, because there is nothing to cancel. If you uploaded the wrong file, upload the right one as a new batch and leave the old one to lapse.
- Do not prepare a batch well ahead of when you intend to send it. A batch reviewed on one day and submitted the next will not be there — it will have lapsed, and lapsed batches drop off the list rather than showing as cancelled, as described above. Upload and submit in one sitting.
Do batch payouts send webhooks?
No. The payout webhook is pushed only for payouts created through the API; a payout that originated as a row in a batch upload produces no notification, whatever its outcome. Track batch results from the batch record and its result file, or inquire each row’spayoutOrderId through
the payout API. See
Payout statuses, notifications & reports.
Where does the money for a payout come from?
From your acquiring settlement proceeds. Every balance check and every debit on the batch payout path is taken against your settlement account for the relevant currency — the preview you approve reads that same balance, so what you see at preview is the account that will be charged. Two consequences:- Money credited to you anywhere other than the settlement account for the funding currency is not reachable by a payout batch. The payout path does not offer an account picker, and it will not fall back to another account if the settlement balance is short — it rejects the submission instead.
- Payout is therefore downstream of settlement. If you need to increase payout capacity, the lever is settlement timing, not a separate top-up flow. See Settlement cycle for what governs when proceeds land.
Which of my settlement accounts can fund a payout? Can I choose?
You cannot choose — it is determined by currency, and the currency comes from your payout agreement.- The payout agreement for a country records the funding currency alongside the payee currency. That funding currency is the sole selector of which settlement account is debited.
- The funding currencies available when your agreement is set up are themselves limited to currencies in which you actually hold a settlement account, so an agreement cannot be written against an account you do not have.
- Because the batch’s funding currency is resolved per row from your agreements and then rolled up, all rows in one batch must share the same funding currency, payee currency and country — which is the underlying reason batch validation is all-or-nothing on those three fields.
Why must every row in one batch share the same country and currencies?
Because a batch is funded as a unit. The funding currency is resolved from your agreements per row and then rolled up to one value for the batch, and that single value selects the one settlement account to debit. A batch mixing corridors would need to debit more than one account, which the path does not do. That is why validation is all-or-nothing on country, funding currency and payee currency, and why a single bad row cancels the whole file rather than being dropped. Split multi-corridor payment runs into one batch per corridor and submit them separately; there is no partial submission.A batch has been In Progress for a long time. What should I check?
In Progress spans several stages, so duration alone tells you nothing. Work through this instead:
Do not resubmit the file to force progress. A second batch is a second debit
and a second set of payouts, so raise a stuck batch with your Waffo contact
rather than re-uploading it.
How do I reconcile a batch once it is Completed?
Work from the files on the batch record rather than from the screen:
Row-level failures return their amount to the settlement account they were
debited from; check your Account History for the returned amounts rather than
inferring them from the batch total. See
Balance & Account History for
how those entries are described.