> ## 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.

# Which Payment Methods and Markets Can I Accept?

> How to answer coverage questions yourself from the published payment method catalogue: which markets are listed, how the table aggregates rows, why one payment method appears under two names, how to tell whether a method does subscriptions or refunds, and how your own contracted list differs from the catalogue.

Most "do you support X in Y?" questions can be answered without asking anyone,
because the catalogue is published: **[Payment Methods](/docs/en/essentials/payment-methods)**
carries a filterable table of every payment method in the Waffo catalogue with
its type, markets, payment currencies, subscription support and refund rules.

This page is about **reading that table** — what a row means, what the filters
do, and which questions the table cannot answer. Three neighbouring pages cover
adjacent ground and are not repeated here:

* [Reading Your Payment Method Configuration](/docs/en/support/payment-method-config-and-limits-faq) —
  the same information for **your own account**, from the API.
* [Payin Agreements & Transaction Limits](/docs/en/support/payin-agreements-and-limits-faq) —
  the same information for your own account, as the Portal renders it.
* [Payment Method Enrollment](/docs/en/support/payment-enrollment-faq) — getting a
  method added to your account.

## Where is the list of supported payment methods and markets?

On [Payment Methods](/docs/en/essentials/payment-methods). The table has three
filters — **Type**, **Country/Region** and **Subscription** — and these columns:

| Column | What it holds |
| - | - |
| Type | The `payMethodType` category — [the full list is below](#what-are-the-paymethodtype-categories) |
| Payment method | The method's catalogue name, in the same spelling you send as `payMethodName` |
| Country/Region | Every market the method is catalogued for, as ISO 3166-1 alpha-3 codes |
| Payment currency | Every currency the method is catalogued in |
| Subscription | Whether the method appears under the subscription product |
| Refundable | Whether refunds are possible at all on the method |
| Partial refund | Which refund shapes the method permits |
| Refund period | How long after payment a refund stays possible |

The **Country/Region filter is the authoritative answer to "which markets do you
cover?"** — read the current option list there rather than from any prose list,
including this page's.

Two market codes are not countries:

| Code | Meaning |
| - | - |
| `EU_LIST` | A group of European markets treated as one catalogue entry |
| `GLB` | Global — not tied to a market at all. Stablecoin acceptance is catalogued this way, so it is never filtered by the shopper's country |

## Is India, Morocco, Pakistan or Russia covered?

None of those four markets appears in the published catalogue. Neither do any
other markets absent from the Country/Region filter — if a market is not in that
filter, there is nothing catalogued for it, and the answer does not change based
on who asks.

The same test settles the reverse question. A market **is** covered if it is in
the filter; whether *your* account is contracted for anything in it is a
separate question, answered by
[your own configuration](/docs/en/support/payment-method-config-and-limits-faq), not
by the catalogue.

## Why does one row cover several countries and currencies?

Because the table aggregates before it displays. Rows in the underlying
catalogue are per market, currency and product; the table groups them by
**payment method name + type** and merges the group into one row:

| Column | How the group is merged |
| - | - |
| Country/Region | Every market in the group, de-duplicated and sorted |
| Payment currency | Every currency in the group, de-duplicated and sorted |
| Subscription | *Yes* if **any** row in the group is under the subscription product |
| Refundable | *Yes* if **any** row in the group is refundable |
| Partial refund | The **most permissive** shape in the group |
| Refund period | The **longest** period in the group |

The consequence matters: a row showing three countries and *Refundable: Yes* does
**not** promise refunds in all three. The optimistic merge means the table
answers *"is this ever true?"*, not *"is this true for my market?"*. For a
per-market, per-currency answer, use the configuration endpoint on your own
account, where each contract is a separate entry.

## Why do I see two names that look like the same payment method?

Because market variants of a wallet are separate catalogue entries with separate
names and separate contracts — for example `ALIPAY` and `ALIPAYHK`, or
`WECHATPAY` and `WECHATPAYHK`. They differ in market, in payment currency, and
in which entry your account is contracted for.

Practical rules:

* **`payMethodName` is what you send, verbatim.** Take it from the catalogue or
  from your own configuration response, not from the name a shopper would
  recognise. A method's checkout-facing display name and its `payMethodName` are
  not always the same string.
* **Being contracted for one variant does not contract you for the other.** If
  you send a variant you are not contracted for, order creation fails with
  `A0018` — see [Common Errors Troubleshooting](/docs/en/support/errors-troubleshooting-guide).
* The same applies across markets for a single name: one method name catalogued
  in several markets is still one contract per market.

## What are the `payMethodType` categories?

`payMethodType` is the coarse category, and it is a fixed enumeration. You can
send it on order creation instead of an exact `payMethodName` to let the shopper
pick within a category, and you can send several comma-separated:

| Value | Category |
| - | - |
| `EWALLET` | e-Wallet |
| `CREDITCARD` | Credit card |
| `DEBITCARD` | Debit card |
| `APPLEPAY` | Apple Pay |
| `GOOGLEPAY` | Google Pay |
| `ONLINE_BANKING` | Online banking |
| `DIGITAL_BANKING` | Digital banking |
| `VA` | Virtual account |
| `OTC` | Over-the-counter |
| `OTCBANK` | Over-the-counter at a bank |
| `BNPL` | Buy now, pay later |
| `QR` | QR code payment |
| `QRIS` | QRIS |
| `USSD` | USSD |
| `NAPASCARD` | NAPAS card |
| `KOREANCARDS` | Korean domestic cards |
| `PREPAIDCARD` | Prepaid card |
| `UNIONPAY` | UnionPay |
| `CRYPTO` | Stablecoin — see [Stablecoin Payments](/docs/en/support/stablecoin-payments-faq) |

Note the spelling: the card categories are `CREDITCARD` and `DEBITCARD`, one
word, and Korean domestic cards are `KOREANCARDS`. There is no `CARD`,
`BANK_ACCOUNT` or `WALLET` value.

Four of these categories — `VA`, `OTC`, `CREDITCARD` and `DEBITCARD` — do not
require you to also name a specific method, because the shopper chooses the
concrete option at the checkout. For every other category, order creation still
expects a `payMethodName` unless you are deliberately sending the shopper to the
Waffo checkout to choose.

## Do Apple Pay and Google Pay need enrolling separately?

Yes. They are their own catalogue categories (`APPLEPAY` and `GOOGLEPAY`) with
their own catalogue entries per market, so each is its own contract — being live
on cards does not make either of them live. Both also carry integration work
beyond the contract, which is why they have their own published guides:
[Apple Pay](/docs/en/developer-docs/integration/apple-pay/overview) and
[Google Pay](/docs/en/developer-docs/integration/google-pay/google-pay).

The same logic applies to any other method: one contract per catalogue entry,
enrolled through the process in
[Payment Method Enrollment](/docs/en/support/payment-enrollment-faq).

## How do I tell whether a payment method can do recurring billing?

There is no "supports subscription" flag on a single contract. Subscription
support is expressed as a **separate product**: `productName` on the catalogue
row. The four payin products are:

| `productName` | What it is |
| - | - |
| `ONE_TIME_PAYMENT` | A single payment |
| `DIRECT_PAYMENT` | A payment taken without sending the shopper to the Waffo checkout |
| `SUBSCRIPTION` | Recurring billing |
| `MINI_PROGRAM_PAYMENT` | Payment inside a wallet's mini program — see [Mini Program Payments](/docs/en/support/mini-program-payments-faq) |

So a method is available for recurring billing when there is a catalogue entry
for it under `SUBSCRIPTION`. On the published table this is the **Subscription**
column; on your own account it is a `payMethodDetails` entry whose `productName`
is `SUBSCRIPTION`.

Two consequences merchants regularly hit:

* **One-time and subscription are enrolled separately.** Having a method live
  for one-time payments does not make it available for recurring billing on your
  account; that is a second contract.
* Remember the aggregation rule above — on the published table, *Subscription:
  Yes* means at least one market/currency combination for that method is under
  the subscription product, not all of them.

Which methods behave well under retries, and what a wallet-based subscription
can and cannot do, is in
[Subscription Payment Methods & Retries](/docs/en/support/subscription-retry-and-payment-methods-faq)
and on the published
[Subscription payment methods](/docs/en/developer-docs/tools-and-references/references/subscription-payment-methods)
page.

## Does the payment method depend on whether the shopper is on web or in an app?

It can, and you declare the context with `userInfo.userTerminal`:

| Value | The shopper is |
| - | - |
| `WEB` | On a desktop browser |
| `APP` | On a mobile phone |
| `IN_WALLET_APP` | Inside a payment method's own wallet app |
| `IN_MINI_PROGRAM` | Inside a payment method's mini program |

`WEB` is the default when you send nothing. Not every payment method supports
every terminal, so the value can change which methods are usable for an order —
and for the two in-wallet values it is not optional context but the thing that
makes the payment possible at all.

The catalogue does not carry a per-method terminal matrix. The reliable way to
find out is the order-creation response: send the terminal your shopper is
actually on, and let the response tell you whether the method is usable. Do not
infer a terminal restriction from a method's absence in one context and presence
in another.

## What is `payOption`, and do I enroll each option separately?

`payOption` is the sub-choice *within* a payment method — paying from a wallet
balance, from a debit card, from a credit card, and so on. Two things to know:

* **On order creation and inquiry it is read-only.** It reports what the shopper
  actually chose, and it comes back empty on methods that offer no choice.
* **On your contract it can be priced per option.** Where it is, your
  [Payin agreement page](/docs/en/support/payin-agreements-and-limits-faq) shows one
  fee line per option instead of one per method, and a method with no meaningful
  per-option distinction renders as `-`.

So you do not enroll options one by one as if they were payment methods — they
come with the method's contract. What you may see is the same method priced
differently depending on which option the shopper picks.

## How do the catalogue and my own contracted list differ?

They answer different questions, and mixing them up is the most common cause of
"it works in the docs but not on my account":

| Question | Where the answer is |
| - | - |
| Does Waffo have this method at all? | The published catalogue |
| Am I contracted for it? | `/api/v1/paymethodconfig/inquiry`, or **Service → Payin** in the Portal |
| Can it take a payment right now? | `currentStatus` on that same response, and ultimately the order-creation response |
| What are my amount limits for it? | `orderAmountMin` / `orderAmountMax` on that same response, per contract |

Your own list is always the narrower one, and it is the only one your
integration should branch on. Treat the published catalogue as a planning
document for "which markets should we ask to be enrolled in", never as a runtime
source of truth.

## Where do I look next?

* [Reading Your Payment Method Configuration](/docs/en/support/payment-method-config-and-limits-faq) —
  every field of your own configuration response, and the errors it produces
* [Payment Method Enrollment](/docs/en/support/payment-enrollment-faq) — how a method
  gets added, and what each enrollment status means
* [Payment Method Refunds & Limits](/docs/en/support/payment-method-refund-limits-faq) —
  refund shapes, refund windows and refund minimums per method
* [Checkout Display Rules](/docs/en/support/cashier-display-rules-faq) — how the
  methods you are contracted for are ordered and grouped on the checkout
* [Payment Methods](/docs/en/essentials/payment-methods) — the catalogue itself


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