Where do I see which payment methods I am contracted for?
Service → Payin. One row per contracted combination, with these columns:Fees and Settlement cycle are not shown for every contract type — if they are absent from your
page, that is your contract shape, not a missing permission.
Anything the backend does not supply renders as - rather than being left blank, so a dash means
“nothing configured for this row”, not “zero”.
How do I read the Fees column?
The Fees cell is composed, not a single number. It is assembled from up to four parts:
Where the ceiling is expressed as a proportion rather than a fixed amount, the
max part appears as
a percentage instead.
Two further details:
- The column header carries the tooltip “Rounding up to 2 decimal places per transaction.” — rounding is applied per transaction, not once per settlement batch.
- Where a payment method prices differently per payment option, the row expands into one fee line
per option. A payment option with no meaningful per-option distinction renders as
-.
What is the User Fee column, and why can’t I see it?
User Fee is a fee borne by the payer, not by you, on payment methods that work that way. The
column is conditional: the Portal only renders it when at least one row on your page actually
carries a user fee. If none do, the column is absent — nothing is hidden from you.
Its header tooltip reads “Fees charged to end users.”
Where a user fee exists, the Refundable cell for that row gains a second line telling you what
happens to that fee on a refund:
This matters when you quote a refund total to a customer: the payer’s fee and your fee follow
separate rules. Your own fee behaviour on refunds is covered in
Refund FAQ.
What does a settlement cycle like T+3 mean?
The notation is a cycle letter, a+, and a count:
So
T+3 is a daily cycle with a delay of 3, W+1 a weekly cycle with a delay of 1, M+1 a monthly
one. A monthly variant also appears as M+1X.
Note the daily letter is T, not D — if you are mapping this into your own systems, do not
assume D. How the cycle turns into an actual payout is covered in
Settlement cycle.
What do the agreement statuses mean?
TheStatus column carries one of five values, colour-coded:
Read the colour as the practical signal: green is the settled, in-service state; yellow means the
row is still being brought up; red means it is not in service. A value the Portal does not
recognise is shown as-is rather than being hidden, and an empty one as
-.
If a row you expect to transact on is not green, raise it with your Waffo contact before debugging
your integration — the agreement state is set on Waffo’s side, not from the API.
What do the Refundable values mean?
Four values, and they are about shape, not about whether any individual order can be refunded right now:Refund Period next to it is the window after payment inside which a refund is still accepted.
Both feed the Portal’s per-order refund control — see
Why is the Refund button missing or greyed out?.
Which filters does this page give me, and can I export it?
Six filters:Payment Method Country, Payment method type, Payment method, Order Currency,
User Currency and Status. Product is a column, not a filter — to narrow by product, filter
on the other fields and read the Product column.
Export produces a CSV of the current view:
Queued, asynchronous exports elsewhere in the Portal behave differently; see
Exports & Report Downloads.
Why doesn’t the row order match the Payment Method Country column?
Rows are sorted country → payment method type → payment method name → product, ascending. The subtlety: the sort key is the agreement’s own country field, while the first column displays the payment method’s country. For most rows these coincide; where they differ, the visible order will not look strictly alphabetical by the column you are reading. Sorting is also applied per page of results, so paging does not re-sort the whole set.What does the Order Expiry Customization column actually tell me?
The range of order expiry you are allowed to ask for on that row — not a
single default. Where a payment method accepts a custom expiry, the cell shows a
time range; where it does not, the cell shows - and the expiry is whatever the
contract sets.
Two details that decide how you read it:
- The range shown is the intersection of what the row allows on a mobile app and what it allows on a desktop browser, so it is the window that is safe regardless of which terminal your shopper is on. A row can be more permissive for one terminal than the range implies.
- The whole column is hidden unless at least one row on your page has a customisable expiry. Its absence means “none of your rows support this”, not a missing permission.
Can I set the order expiry myself, and what wins if it conflicts?
SendorderExpiredAt on order/create. Omit it and the contract’s expiry
applies — that is the documented default.
What happens to a value you do send:
One code not to misread:
A0034 is returned when the expiry you provided
has already expired by the time the order is being acted on. It is not the
code for “your expiry was outside the allowed range”.
Order expiry, once set, is the shopper’s payment window — what happens when it
closes, and which order states are final, is in
Payment Timeouts & Finality.
What is the Mini Apps Info column?
The wallet mini-programs registered for that row. Each entry is a mini-app name;
hovering it shows the app’s ID and name. The column is pinned to the right of the
table and is only rendered when at least one row on your page has mini-app
entries — otherwise it is absent entirely, and a row with none shows -.
You need this when you are taking payments from inside a wallet’s mini program,
because the app ID is what identifies your mini program to the payment method.
The integration itself, including the product (MINI_PROGRAM_PAYMENT) and the
terminal value to send, is in
Mini Program Payments.
My order was rejected for exceeding a limit. Which limit?
There are three, and the message tells you which:
For
A0008, compare the order amount against the matching Service → Payin row. For A0020 and
A0021, the row is the wrong place to look: these limits are keyed by merchant ID + order
currency only, so switching the payer to a different payment method in the same currency does
not help, and raising one currency’s limit does nothing for another. For A0021 the order size is
not the problem — the day is. All three are returned at order creation, so no order is left
half-created.
Where no account-level limit is configured for that order currency, the A0020 / A0021 checks
do not run and neither error can occur. The account-level limits are not shown on Service → Payin;
if you need to know them, ask your Waffo contact.
How exactly is the daily limit counted, and when is headroom released?
Two practical consequences:
- An order created just before
00:00 UTC+8that succeeds after it still counts against the day it was created. - Abandoned checkouts consume headroom until they close. If you are batching high volume near the cap, that is usually what has eaten the difference — not the payments that succeeded.
Can my limits change without me doing anything?
Yes. Where the provider underlying a payment method revises its limits, Waffo recalculates the limits on your agreement, and the new range appears on Service → Payin. Two mechanics are worth knowing:- Where the provider’s limit is expressed in a different currency from your agreement, it is converted before being applied, so the resulting figure will rarely be a round number.
- Rounding is deliberately conservative: the minimum is rounded up and the maximum is rounded
down, so the resulting range is never wider than the underlying one. For currencies with no
minor unit —
JPY,KRW,VNDand similar — the minimum lands on a whole unit.
A payment method I use is being discontinued. How am I told?
When an agreement of yours is terminated, an email naming the payment method goes to the administrator and super-administrator users on your merchant account. Details:
After that, the row shows
Terminated in red on Service → Payin, and new orders on that
combination are refused. Existing orders and their refunds are unaffected by the status change
itself. If the method matters to your checkout, raise a replacement with your Waffo contact — the
Portal has no self-service path to re-enable a terminated row.
Which merchant name does my customer see at checkout?
The checkout page shows a display name, which is resolved in this order:
The important asymmetry: an unconfigured display name does not fall back to your legal entity name
on the main order-information line — it simply shows nothing. If customers report a blank or
unexpected merchant name at checkout, this resolution order is the first thing to check. Other parts
of the checkout page have their own fallbacks, so a name can be absent in one place and present in
another. See Cashier display rules for what else the page
shows.