Skip to main content
Most “do you support X in Y?” questions can be answered without asking anyone, because the catalogue is published: 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:

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

On Payment Methods. The table has three filters — Type, Country/Region and Subscription — and these columns: 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:

​
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, 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: 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.
  • 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: 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 and Google Pay. The same logic applies to any other method: one contract per catalogue entry, enrolled through the process in Payment Method Enrollment.

​
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: 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 and on the published 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: 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 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”: 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?