> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Checkout Payment Method Display Rules

> How the Waffo checkout decides which payment methods to show and in what order: merchant-defined ranking, newly signed methods, folding, unavailable methods, country grouping, and display-mode options.

This page explains the rules the Waffo checkout uses to decide which payment
methods your users see, how they are grouped, and in what order.

## Can I control the order payment methods appear in?

Yes. In the Merchant Portal, go to **Cashier Customization → Cashier Ranking**.
There you can:

* Configure ranking **per country**, at either MID or SubMID level.
* **Drag and drop** payment methods (and sub-methods within a type) to reorder
  them, or use the **pin** action to move an item to the first position.
* Preview the resulting checkout layout in real time before saving.
* Click **Reset to Default Setting** to remove your customization for the
  selected country and fall back to the platform default ranking.

The list only contains payment methods available under your active agreements.
If you have never customized a country, the platform default ranking applies.

## Where do newly signed payment methods appear?

If you have already customized the ranking, a newly activated payment method
never disrupts your existing order:

* Your configured items keep their exact positions.
* New payment methods are **appended to the end** of the list, in the
  platform's default relative order.
* A new sub-method (for example a new wallet under eWallet) is appended to the
  end of its own type group.

There is no visual "new" marker on the ranking page, so a newly signed method
appears silently at the bottom of its group. If ordering matters to you, check
the ranking page after signing a new payment method. If you are still on the
default configuration, the list simply refreshes with the new method in its
default position.

## Why are some wallets only visible after clicking "See more"?

When a payment type contains more than three sub-methods, the checkout shows
the first three (by ranking) and folds the rest behind a **See more (X more)**
button. Clicking it expands the full list instantly; **Show less** folds it
back. This keeps the page compact — your top-ranked methods get the visibility.
The same folding applies in the Portal's live preview.

## Why is a payment method grayed out on the checkout?

When a payment method is temporarily unavailable (for example, during channel
or provider maintenance), the checkout **grays it out instead of hiding it**:

* Graying out does not change the configured ranking, so the layout stays
  stable.
* If every sub-method under a type is unavailable, the whole type icon is
  grayed out and cannot be selected.
* The default selection automatically falls on the first *available* payment
  method.

Availability is restored automatically once the maintenance ends.

## How are the country tabs organized? Why is a wallet listed under a country I did not expect?

Checkout tabs group payment methods by **Payment Method Country** — the
country a payment method itself belongs to (a local wallet belongs to its home
country; card schemes are Global). This mapping is defined by the platform and
cannot be changed per merchant.

* Methods with global support appear both under their home-country tab and
  under the **Global** tab.
* The tab selector only appears when the order resolves to two or more tabs.
* The default tab is inferred from the user's IP; if no tab matches, the
  Global tab is selected, then alphabetical order as a final fallback.

## Can I narrow what a user sees on a specific order?

Partly, and the exact behavior surprises people.

Pass the optional `payMethodCountry` field when creating the order and the
checkout hides **local** payment methods that belong to other countries.
**Globally available methods — card schemes and similar — are always kept**,
because they are not tied to any single country. So passing
`payMethodCountry=IDN` does not reduce the page to Indonesian methods only;
you will still see the global ones. That is expected behavior, not a bug.

Two more effects worth knowing:

* If you have at least one local method in the country you passed, the
  checkout stops showing country tabs and presents a single list.
* If you have no local method for that country, the methods keep their own
  country grouping, so tabs can still appear.

If none of your contracted methods survive the filter, order creation is
rejected rather than showing an empty page.

Omit the field and the checkout shows all payment methods under your
agreements, grouped into tabs as described above.

## Can I remove country tabs, or pull one wallet out of its group?

Two additional display options exist for merchants with specific layout needs:

* **Flat display** — all payment methods across countries are shown on a
  single page with no country tabs. If the flattened list would be too long,
  the checkout automatically falls back to country grouping for that order.
* **Standalone display** — a single payment method is pulled out of its type
  group and ranked as an independent top-level item (card types cannot be
  pulled out).

Both are off by default. Contact your Waffo account manager if you want either
display form enabled for your account.

## This wallet returned only a checkout URL — what does the user do on the checkout page?

Not every payment method has a deeplink. Several Southeast Asian wallet and
QR-code methods return a **Waffo checkout URL**, and the step that actually
authorizes the payment happens on that page:

* **QR-code methods** render the QR code on the Waffo checkout. The user scans
  it with their own bank or wallet app.
* **Some wallets** first collect the user's phone number on the checkout
  page. After the user submits it, the wallet app pushes an
  authorization request to that user's phone, and the user approves it there.

Two integration consequences:

* Your app and WebView must be able to open the checkout page — if you only
  handle deeplinks, these methods dead-end.
* Users need to be able to **scan, save or copy the QR code**, so do not render
  the checkout in a container that blocks long-press or screenshots.

Which URL field to read (`webUrl` versus `deeplinkUrl`, driven by
`orderAction.actionType`) is covered in the
[integration FAQ](/docs/en/developer-docs/tools-and-references/references/faq).

## A payment method I expected is not on the checkout at all. How do I work out why?

Missing is different from grayed out. Grayed out means temporarily
unavailable — see above. Missing means the method never entered the list for
that order. Work down this list, in order; each step is something you can check
yourself:

| Check | How |
| - | - |
| Is the method active under your agreements **in this environment**? | `POST /api/v1/paymethodconfig/inquiry` — sandbox and production answer separately |
| Does it support the order's currency? | The same response lists the currencies per method |
| Is the order amount inside the method's accepted range? | The same response carries the amount range — check it before creating the order |
| Did you filter it out? | `payMethodType` / `payMethodName` / `payMethodCountry` on the order narrow the list |
| Does it support the terminal you sent? | A method that does not support your `userInfo.userTerminal` is not offered |
| Is it folded? | With more than three sub-methods under a type, the rest sit behind **See more** |

The two that catch people most often are the amount range and the environment.
An amount just outside a method's range silently removes it rather than
producing an error, and a method that is live in production is not necessarily
enabled in a test environment.

The mechanics of each check are in
[Payment method configuration and limits](/docs/en/support/payment-method-config-and-limits-faq).
If the method survives all six checks and is still absent,
[contact support](mailto:support@waffo.com) with the order ID, the amount, the
currency and the terminal you sent.

## Does every payment always involve a redirect? Can I remove that step?

No, and no. The number of hops is a property of the payment method, not
something the checkout adds or you can configure away:

| Payment method behaviour | Hops the customer sees |
| - | - |
| Card | Stays on the checkout. The card issuer may insert an authentication step |
| QR code | Stays on the checkout — the code is rendered there, and the customer scans it with another app |
| Codes and bank details | Stays on the checkout — the details are shown there, and the customer pays elsewhere |
| Wallets that authorize on their own surface | One hop out to the wallet, then back |
| Wallets that push an authorization to the customer's phone | No hop — the checkout collects an identifier and waits |

So a redirect only exists where the payment method requires the customer to
authorize somewhere Waffo does not control. There is no setting that removes it,
and building your own page does not remove it either — you receive the redirect
instead of the checkout doing it for you.

What you *can* remove is Waffo's own selection page: pin the payment method on
the order and the customer goes straight into that method's flow. And you can
remove the Waffo result page at the end if the bypass is enabled for your
account — see
[Checkout page lifecycle](/docs/en/support/cashier-order-lifecycle-faq).

## What does the amount breakdown show? Can price and tax be listed separately?

They already are. Where the order carries the relevant values, the checkout
itemizes the amount rather than showing one total:

| Line | When it appears |
| - | - |
| Price | The order amount, before any discount |
| Discount | A promotion code or coupon is applied to the order |
| Subtotal | Shown as order amount → customer amount, with the exchange rate underneath, for a cross-currency order |
| Customer fee | The order carries a fee charged to the customer |
| Tax | The order is taxable. The line is labelled with the applicable tax's own name, so customers see the local term rather than the word "tax" |
| Total | Always |

Two behaviours worth knowing:

* Where the tax cannot be computed until the customer supplies an address, the
  tax line is shown with a prompt to enter the address, and it resolves once
  they do — so the customer always sees that tax exists before they commit.
* On a subscription, the total line reads as the amount due today, which for a
  trial or a delayed start is not the recurring amount.

Which currency leads the display, and the font sizes of the amounts, are part
of the customization surface — see
[Customizing the checkout page](/docs/en/support/cashier-customization-faq).

## Can I change the payment-method icons or brand names, or add my own text and links?

No. The customization surface covers your own branding — logo, merchant name,
colors, radii, base font size, header layout and amount display — and nothing
beyond it. Specifically, there is no control for:

* Payment-method icons or brand names. These are rendered from
  platform-supplied assets so that customers recognise the method, and there is
  no download of them in the Portal either. If you need a brand's mark for your
  own pages, take it from that brand's own brand guidelines, where its usage
  rules also live.
* Free text of your own anywhere on the page.
* Your own links — a payment guide, help centre or T\&Cs link.

If your checkout needs merchant-authored copy or links next to the payment
methods, the route is a merchant-built page, not a setting — see
[Building my own checkout page](/docs/en/support/merchant-built-checkout-faq).

The full list of what *is* configurable is in
[Customizing the checkout page](/docs/en/support/cashier-customization-faq).

## Is the default ranking a recommendation for my market?

It is the **platform default** — the order applied when you have not
customized a country. It is not derived from your traffic, it is not tuned per
merchant, and it is not advice about your market. Treat it as a sensible
starting point, not as a recommendation you should be reluctant to change.

If ranking matters commercially to you, the useful move is to customize the
countries you care about and compare conversion yourself; the ranking page is
per country, so you can change one market without touching the others. For
input on which methods to lead with in a given market, ask your Waffo contact
rather than inferring intent from the default order.

## The country switcher is easy to miss. How do I get customers to the right list?

Do not rely on the customer finding it. Two things reduce the problem, and the
first is much stronger than the second:

* **Pin the country on the order.** If you know where the customer is — from
  their account, their shipping address, the storefront they are on — pass
  `payMethodCountry` on `/api/v1/order/create`. The checkout then presents one
  list with no tabs to find, while global methods such as card schemes stay
  available. This also fixes the case where the customer's IP resolves to the
  wrong country because they are on a VPN or a corporate network.
* **Pin the payment method.** If your own page already asked which method they
  want, pass `payMethodType` and `payMethodName` and the customer skips the
  selection page entirely.

The parameter behaviour, including what `payMethodCountry` does and does not
filter, is in the question above and in
[Checkout customization](/docs/en/developer-docs/integration/checkout/customization#when-to-pass-paymethodcountry).

## If I price in a local currency, can customers still pay by card?

The country tabs group by the **payment method's** country, not by the order
currency, so pricing in a local currency does not remove card methods. Card
schemes are global: they sit under the Global tab and stay there whichever
local tab a customer opens. A customer who switches to a local tab is seeing
that country's local methods — the cards have not gone away, they are one tab
over.

What can genuinely make a card method unavailable is the currency itself not
being enabled for your card agreement. That is visible to you before you create
the order: the currencies each method accepts are listed in the
`paymethodconfig/inquiry` response — see
[Payment method configuration and limits](/docs/en/support/payment-method-config-and-limits-faq).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.