webUrl 和 deeplinkUrl 互斥——是什么规则决定我拿到哪一个？
必须依次满足两个条件。
第一，支付步骤本身必须是一次重定向。 只有当订单路由到的支付方式返回
以下某种 action 形式时，才会产生重定向字段：
App 推送流程完全不产生 URL——既没有
webUrl 也没有
deeplinkUrl。这不是出错了；只是没有什么需要你打开的。
第二，如果产生了重定向字段，由 URL 自身的类型决定这一对字段：
这就是为什么两者中永远只有一个存在：
actionType 和 URL
字段是在同一分支中一起设置的。
那我能要求返回 deeplink 而不是 web URL 吗？
不能。actionType 不是参数，也不是商户设置。它由
这笔具体交易实际路由到的支付方式所返回的重定向产物的形态决定。
实际上，这意味着你的两笔订单可能因为在创建时对你不可见的原因而
actionType 不同——顾客在收银台选择了不同的支付方式，或者同一支付方式
在不同的顾客设备上表现不同。你的集成必须容忍这一点。
那么读取重定向的正确方式是什么？
基于orderAction.actionType 分支。绝不要预判它。
- 把”没有
actionType也没有 URL”视为一种正常结果，而不是错误。 - 不要根据你认为订单使用的支付方式、顾客的设备，或同一支付方式 上周返回的内容来推断 URL 字段。
- 重定向回到你的页面不是支付成功的证明。 权威结果永远是支付通知（Webhook 通知）或订单查询。
actionType 和 userInfo.userTerminal 有关系吗？
它们是两个独立的维度。 actionType 描述重定向产物的
形态；userTerminal 描述顾客的设备类型。两者互不决定。
不过，确实存在一个间接联系，值得理解，
因为它是大多数混淆的来源：
- 有些支付方式用
userTerminal来决定到底打开哪种流程。 一种方式可能在顾客用 PC 时显示二维码，在顾客用手机时启动钱包 App。 - 这两种流程产生不同的产物。启动 App 会产生一个 scheme
URL，所以你得到
actionType = DEEPLINK。显示二维码根本不是重定向， 所以它不产生actionType也没有 URL——二维码会渲染在 Waffo 收银台页面上。
userTerminal 可以通过支付方式自身的行为影响你最终收到的内容。
它不能做到的是让你预判结果：
- 在相同的
userTerminal下，不同的支付方式返回不同的actionType值。 - 并非每个支付方式都会看
userTerminal。
userTerminal 是一个如实描述顾客的输入。
actionType 是一个你在运行时读取的输出。不要用前者去猜
后者。
那 userTerminal 实际上是做什么的？
它的主要、有文档记载的职责是资格判定：不是每个支付方式
都支持每种终端类型，所以该值用于检查某个
方式是否可以向这位顾客提供。不支持你所传终端的方式
不会出现在收银台上。
请传对该会话而言真实的值。对一个实际在钱包 App 内的顾客传
WEB
不会解锁任何东西；它只是给平台提供了错误的过滤信息。
顾客能自己在收银台切换国家吗？
可以，有两个条件。
选择器只存在于支付方式选择步骤。一旦
顾客选定了方式并进入下一步，就没有国家切换了。
切换国家会重新加载该国家的支付方式列表。任何
与之前选择绑定的内容——例如已输入的促销码——
都会被切换清除，所以顾客如果仍需要就要重新输入。
默认选中哪个国家？
按以下顺序解析：- 如果顾客在本次会话中已经切换过 Tab，则为该 Tab。
- 否则，为根据顾客 IP 推断出的国家——前提是该国家 是订单已解析的 Tab 之一。
- 否则，为 Global Tab（如果订单有的话）。
- 否则，为列表中的第一个 Tab。Tab 按字母顺序排列， Global 存在时排在最前，所以这里就是字母顺序第一的 国家。
对于一次性支付，我能通过参数固定国家和支付方式吗？
部分可以。在创建订单时：payMethodCountry 是一个过滤器，不是国家锁——传一个国家
并不会把页面缩减为只有该国家的方式，因为全球方式
按设计会通过过滤器。完整行为，包括国家 Tab 会怎样以及
过滤后没有任何方式剩下时会怎样，记载在
收银台支付方式展示规则中。
对于订阅，我能通过参数固定国家和支付方式吗？
可以——/api/v1/subscription/create 的 paymentInfo 下存在同样的三个过滤器，
行为方式与一次性订单相同：
订阅特有的两点：
- 你传的国家会存储在订阅上，并在 Waffo 每次 为其重新解析合格支付方式时重新应用——例如 顾客之后添加或更改支付方式时。因此，为某一国家创建的订阅 在其整个生命周期内都会持续提供该国家的本地方式（加上 全球方式）。
payMethodCountry是过滤器而不是锁，与一次性订单完全一样： 传一个国家并不会把页面缩减为只有该国家的方式， 因为全球方式按设计会通过过滤器。
payMethodCountry 收窄国家，
用 payMethodType / payMethodName 收窄方式，
用 cashierLanguage 设置语言。如果你想要一个严格
单一国家、不含全球方式的体验，请把它表达为方式
限制——指明你想提供的方式——因为仅靠国家过滤器
不会移除全球方式。
我的 Cashier Ranking 设置也适用于我的订阅收银台吗？
不适用。排序和展示配置按两个维度存储： 国家和产品类型。ONE_TIME_PAYMENT 和 SUBSCRIPTION 是
不同的产品类型，所以每个国家有一份一次性支付的配置
和一份单独的订阅配置。它们在任何方向上都不互相继承。
在收银台运行时，查找的是与订单的国家和订单的产品类型
都匹配的配置。如果该组合不存在配置，则对该组合应用平台默认排序
——自定义的一次性支付排序不会泄漏到订阅收银台，反之亦然。
需要提前规划的一个后果：配置一次性收银台并不等于
配置订阅收银台。 如果你两者都提供，请在商户 Portal 的
客制化收银台 → Cashier Ranking 下设置两次排序，每种产品类型一次。
当配置查找中完全未指定产品类型时，
默认为 ONE_TIME_PAYMENT——这也是订阅
收银台在你显式配置之前看起来未被改动的另一个原因。
我用一种币种创建了订单，顾客却被用另一种币种扣款，为什么？
因为在你的协议下，一个支付方式可以配置多个支付 币种，而收银台每个支付方式只显示一个条目， 而不是每个币种一个条目。必须有某种机制来选择该条目使用 哪个已配置的币种——而你作为订单币种传入的币种 并不自动是赢家。 你传的订单币种仍然是你订单和结算视图的币种； 变化的是顾客实际支付的币种， 换算会在收银台页面上展示给顾客。一个支付方式配置了多个币种时，哪个币种胜出？
该方式的候选币种逐级收窄。在每一级： 恰好一个匹配则流程结束；多个匹配则收窄候选池并继续； 没有匹配则候选池不变并继续。
一个实例，也是产生大部分此类工单的场景：
你创建了一个订单币种只在第 3 级决定结果——也就是说，只有当没有 候选匹配该方式自身的本地币种、也没有匹配顾客 IP 币种时。这是有意为之：对于本地支付方式，顾客自己账户所用的 币种比你恰好用来开单的币种是更好的结果。 这种收敛是平台行为，商户不可配置。currency = HKD的订单。顾客的 IP 解析为 中国。他们想用的电子钱包类方式属于中国，并且在你的协议下 同时配置了 USD 和 CNY。
- 第 1 级——该方式的所属国家是中国，其本地币种是 CNY。两个候选中恰好一个匹配。解析完成。
- 顾客以 CNY 支付，尽管你传的是 HKD。
我怎样才能完全避免这种意外？
两件事能让它变得可预测而非神秘：- 从订单中读取支付币种，不要假设它。 收银台 会显示顾客支付金额和换算明细，同样的值也在订单上——参见 收银台页面生命周期与收据。
- 如果特定支付币种是业务要求，请用
payMethodType/payMethodName收窄你提供的方式。限制方式就限制了 收敛所作用的候选集合。