- 读懂你的支付方式配置—— 同样的信息，针对你自己的账户，来自 API。
- Payin 协议与交易限额—— 同样的信息，针对你自己的账户，以 Portal 呈现的形式。
- 支付方式开通——如何把一个 方式添加到你的账户。
支持的支付方式和市场列表在哪里？
在支付方式。表格有三个 筛选项——Type、Country/Region 和 Subscription——以及以下列：
Country/Region 筛选项是”你们覆盖哪些市场？“的权威答案
——请从那里读取当前的选项列表，而不是从任何文字列表，
包括本页的。
有两个市场代码不是国家：
印度、摩洛哥、巴基斯坦或俄罗斯覆盖了吗？
这四个市场都没有出现在已发布的目录中。Country/Region 筛选项中缺失的任何 其他市场也一样——如果一个市场不在那个 筛选项里，就说明目录中没有为它登记任何内容，而且答案不会因为 谁在问而改变。 同样的测试也解决了反向的问题。一个市场如果在筛选项里， 就是被覆盖的；至于你的账户是否在该市场签约了任何内容，则是 另一个问题，由 你自己的配置而不是 目录来回答。为什么一行会覆盖多个国家和币种？
因为表格在显示之前做了聚合。底层目录中的行是 按市场、币种和产品划分的；表格按 支付方式名称 + 类型分组，并把该组合并为一行：
这个后果很重要：一行显示三个国家且 Refundable: Yes
并不承诺在这三个国家都能退款。这种乐观合并意味着表格
回答的是*“这是否曾经为真？“，而不是”这对我的市场是否为真？”*。要获得
按市场、按币种的答案，请在你自己的账户上使用配置端点，
那里每个合同是一个单独的条目。
为什么我看到两个看起来像同一个支付方式的名字？
因为一个钱包的市场变体是单独的目录条目，有单独的 名称和单独的合同——例如ALIPAY 和 ALIPAYHK，或者
WECHATPAY 和 WECHATPAYHK。它们在市场、支付币种、
以及你的账户签约了哪个条目上都不同。
实用规则：
payMethodName就是你要原样发送的内容。 从目录或 你自己的配置响应中获取它，而不是从购物者 会认出的名字。一个方式面向收银台的展示名称和它的payMethodName不一定是同一个字符串。- 签约了一个变体不代表签约了另一个。 如果
你发送了一个未签约的变体，订单创建会以
A0018失败——参见常见错误排障。 - 同一个名称跨市场也是如此：一个方式名称在多个市场 登记，仍然是每个市场一个合同。
payMethodType 有哪些类别？
payMethodType 是粗粒度类别，是一个固定的枚举。你可以
在创建订单时发送它而不是精确的 payMethodName，让购物者
在类别内选择，也可以用逗号分隔发送多个：
注意拼写：卡类别是
CREDITCARD 和 DEBITCARD，一个
单词，韩国本地卡是 KOREANCARDS。没有 CARD、
BANK_ACCOUNT 或 WALLET 这样的值。
其中四个类别——VA、OTC、CREDITCARD 和 DEBITCARD——不
要求你同时指定具体方式，因为购物者在收银台选择
具体选项。对于其他所有类别，订单创建仍然
期望有 payMethodName，除非你是有意把购物者送到
Waffo 收银台去选择。
Apple Pay 和 Google Pay 需要单独开通吗？
需要。它们是各自独立的目录类别（APPLEPAY 和 GOOGLEPAY），
每个市场有自己的目录条目，所以每个都是独立的合同——卡已上线
不会使它们中的任何一个上线。两者在合同之外还有集成工作，
这也是它们有自己已发布指南的原因：
Apple Pay 和
Google Pay。
同样的逻辑适用于其他任何方式：每个目录条目一个合同，
通过
支付方式开通中的流程开通。
我如何判断一个支付方式能否做周期性扣款？
单个合同上没有”支持订阅”的标志。订阅 支持表现为一个单独的产品：目录行上的productName。
四个 Payin 产品是：
所以当一个方式在
SUBSCRIPTION 下有目录条目时，它就可用于周期性扣款。
在已发布的表格上这是 Subscription
列；在你自己的账户上则是 productName
为 SUBSCRIPTION 的 payMethodDetails 条目。
商户经常遇到的两个后果：
- 一次性和订阅是分别开通的。 一个方式在一次性支付上已上线 不代表它在你账户上可用于周期性扣款； 那是第二份合同。
- 记住上面的聚合规则——在已发布的表格上，Subscription: Yes 表示该方式至少有一个市场/币种组合在 订阅产品下，而不是全部。
支付方式是否取决于购物者在网页上还是在 App 内？
可能取决于，你通过userInfo.userTerminal 声明上下文：
你什么都不传时默认为
WEB。并非每个支付方式都支持
每种终端，所以该值可能改变哪些方式可用于某个订单——
而对于两个钱包内的值，它不是可选的上下文，而是
让支付成为可能的关键。
目录不携带按方式划分的终端矩阵。可靠的
了解方式是订单创建响应：发送购物者
实际所在的终端，让响应告诉你该方式是否可用。不要
从一个方式在某个上下文中缺失、在另一个上下文中存在
来推断终端限制。
payOption 是什么，我需要逐个开通每个选项吗？
payOption 是支付方式内部的子选择——从钱包
余额支付、从借记卡支付、从信用卡支付等等。两点须知：
- 在订单创建和查询上它是只读的。 它报告购物者 实际选择了什么，在没有选择的方式上返回为空。
- 在你的合同上它可以按选项定价。 在有此情况的地方，你的
Payin 协议页面会按选项显示一行
费用而不是按方式显示一行，而没有实质性
按选项区分的方式则显示为
-。
目录和我自己签约的列表有何不同？
它们回答不同的问题，把两者混淆是 “文档里能用但我的账户上不行”最常见的原因：
你自己的列表永远是更窄的那个，也是你的
集成唯一应该依据的。把已发布的目录当作
“我们应该申请开通哪些市场”的规划文档，绝不要当作运行时
的事实来源。
接下来我该看哪里？
- 读懂你的支付方式配置—— 你自己配置响应的每个字段，以及它产生的错误
- 支付方式开通——一个方式 如何被添加，以及每种开通状态的含义
- 支付方式退款与限额—— 按方式划分的退款形式、退款窗口和退款最小金额
- 收银台展示规则——你签约的 方式在收银台上如何排序和分组
- 支付方式——目录本身