标签：默认 服务 bin 举例 strong 一般来说 时间 退款 实现
收单场景多币种支付概述:在跨境收单的场景下,一笔支付交易会涉及以下几个币种:
支付交易币种: 发起支付订单客户实际支付的币种
渠道交易币种: 渠道可以接受的支付币种.
渠道结算币种: 渠道给支付平台对账单中交易的结算币种. 一般来说，渠道支持的结算币种是交易币种的一个子集, 所以选择渠道的时候我可以只考虑渠道的结算币种是否支持支付交易币种.
MERCHANT结算币种: 支付平台结算给MERCHANT的币种
对于每个支付渠道, 一般会有以下几个配置:
渠道支持的交易币种列表
渠道支持的结算币种列表
渠道默认的结算币种
实际情况可能比这个更加复杂: 比如微信, 在不同区域支持的交易币种和结算币种不同, 还和使用API的版本也有关系.
由于这三个币种可能不同, 所以需要进行汇率转化，根据不同的情况, 汇率转化可能发生在发卡行也可能发生在支付平台. (信用卡正向支付交易扣款途径: MERCHANT 交易系统 -> 支付平台 -> 下游渠道收单行(ACQUIRER BANK) -> 卡组织 -> 发卡行)
综上所述，一笔订单结算给MERCHANT的时候可能会经过一次或多次汇率转换，这是我们希望竭力避免的，因为每一次汇率转换意味着可能出现因汇率波动出现损失，另外渠道换汇可能还有额外的手续费. 在支付单路由到下游渠道的时候需要考虑这种情况. Like for like，顾名思义，就是以交易原币种做结算，再细分又有两层含义. 渠道like for like: 渠道不进行汇率转化，直接以交易币种结算给支付平台. 支付平台like for like: 支付平台不进行汇率转化, 直接以渠道结算币种结算给商家.
如果支付单交易币种和MERCHANT结算币种一致，那理论上我们应该可以避免任何汇率转化，前提是对接的支付渠道中存在一个能交易币种结算的渠道. 如果这样的渠道不存在，那就需要进行两次汇率转化. 渠道将交易币种C转化为渠道结算币种C‘给支付平台,汇率为R1, 支付平台将渠道结算币种C‘再换回C给MERCHANT,汇率为R2. 那支付平台获利或损失为 (R2- R1) * 交易金额.
如果支付单交易币种和MERCHANT结算币种不一致, 那理论上至少需要一次汇率转换, 假设交易币种为C1， MERCHANT结算币种为C2. 这里有两种选择: 1. 选择一个能以C1结算的渠道，渠道以C1结算给支付平台，支付平台负责进行C1 -> C2的换汇再结算给MERCHANT. 2. 选择一个能以C2结算的渠道, 渠道负责C1 -> C2的换汇，支付平台直接俄以C2结算给MERCHANT. 对于支付平台来说, 如果有换汇能力, 显然方案1更加有优势, 具有可控性 (参见后文关于MCP的描述). 方案2的汇率由渠道决定不受控制.
在跨境支付的电商领域比较适用. 支付平台提供给电商平台的商户一个汇率报价用于让他以指定的币种展示商品价格, 此币种一般和商家期望的结算币种不同. 电商平台的买家可以以展示的币种支付订单. 支付平台提供一个汇率锁定的能力确保实际换汇的汇率和报价汇率一致, 从而保证商户收到的支付款金额和原始的商品金额相同. 因为用户下单完成支付到实际下游渠道结算给商家时间差为N天, 中间汇率会发生波动，在平台不提供锁汇能力的情况下，商家实际收到的支付款金额可能和产品本身价格不符. 同时也为买家提供了方便，他可以选择合适的币种支付. 当然支付平台为了对冲风险，报价的汇率一般会比市场高一些.
服务对象: 电商平台的卖家 (merchant)
场景举例: 某美国电商平台原本商品都以美金标价，为了吸引海外客户, 他也同时支持以RMB或者EUR展示商品价格和进行支付. 电商平台每天会定时向支付平台获取USD->RMB和USD->EUR的汇率报价和报价的有效时间 (一般为一天，GMT 8:00 - 第二天 8:00). 同时需要关注的还有报价的实际生效时间范围, 即预期换汇交易发生的时间，一般是2天后实际结算时. 如果一个中国的买家选择以RMB支付, 商品原始价格为USD: 100, 支付平台提供的报价汇率为6.8, 支付平台收到的支付单为RMB 680. 那支付平台在实际支付交易成功时会发起一笔FXBOOKING (换汇预订)的操作, 即以之前的报价的汇率在执行一笔两天后交割的RMB 680 -> USD100换汇交易. 两天后当收到结算的RMB 680的时候可以之间以锁定的汇率转换为USD100结算给电商平台.
主要影响结算: 商户可以选择用交易币种结算或者指定的其他币种结算
实现问题:
在临界点上,实际支付的时间可能刚好超过报价汇率的有效时间. 这时需要电商平台重新获取汇率计算支付金额
上述场景有一个很重要的假设: 有渠道支持以交易币种结算给支付平台, 即渠道不能发生换汇 如果渠道不支持以交易币种结算，那支付平台实际需要执行换汇的币种和之前报价,锁汇交易的币种不同. 这无疑会增加额外的风险,并且无法保证以原本商品的价格结算给MERCHANT.
锁汇时间的范围控制. 由于支付平台给商家报价的生效时间范围是固定的, 而下游渠道给支付平台的结算时间只有在支付交易发生后选择支付渠道时才能确定. 支付平台需要承担这两者时间差产生的汇率风险.
从广义上来说只要支付币种和结算币种不同发生换汇就算一种DCC,只要支付服务提供者能有进行实时汇率转换的能力. 在交易链路上，DCC服务可以由支付平台，收单行，卡组织或者发卡行提供，这里主要讨论的是支付平台提供的DCC能力. 在信用卡支付中,DCC会在支付订单币种和信用卡本身的币种间做转换.
服务对象: 电商平台的买家 + 持卡人
场景举例: 某电商平台产品以美金标价(USD 100)，持卡人用一张人民币VISA卡支付，一般情况下一般持卡人会发起一笔美金交易，然后在信用卡还款日再以当天的美金汇率购汇还款, 如果电商平台使用了支付平台提供的DCC服务，那么支付平台会在确认支付时由信用卡的卡BIN检测到信用卡本身的币种(RMB)，如果平台支持在美金和人民币之间进行汇率转换，那平台会提供一个额外的人民币支付的选项和对应的汇率给MERCHANT并展示给持卡人 (FXRATE = 7.0)，持卡人可以选择依然用美金支付或者用人民币支付，如果持卡人选择用人民币支付，那么支付平台会直接传人民币(RMB 700)给渠道, 并且发起一笔FXBOOKING (换汇预订)的操作: 以之前提供的DCC汇率卖出RMB 700, 购入USD 100, T+N日当渠道结算RMB 700给交易平台时，那之前预订人民币到美金的换汇交易可以保证以USD100结算给MERCHANT，正好等同于商品的原始价格.
DCC服务的价值: 对于MERCHANT可以规避交易币种到结算币种的汇率风险. 对持卡人可以以卡本身币种支付，一定程度规免了汇率在支付日到信用卡还款日之前的波动风险. 当然这个汇率本身会略高于当日市场汇率，用于覆盖支付平台和MERCHANT承担的汇率风险.持卡人需要作出权衡
实现问题:
渠道路由选择，因为DCC服务会变更到支付平台发给渠道的币种,而渠道交易币种是路由逻辑的重要因素(渠道必须支持以)所以路由逻辑要在DCC服务确定了渠道交易币种之后重新
上述场景式一个VERY HAPPY CASE, 其中有两个特别重要的前提. 1: 渠道结算币种和支付币种相同. 2. 支付订单币种和MERCHANT结算币种相同. 我们需要考虑更多复杂的场景. 1. 如果支付平台给渠道的交易币种和渠道给支付平台的结算币种不同怎么办？在这种场景下由于渠道本身做了一次换汇, 而这个汇率本身存在一定的波动风险, 导致渠道给支付平台的结算金额不可预估. 支付平台应对的方式是在计算DCC汇率时提高一定的比例，确保从付款者收到的钱足够覆盖汇率波动的风险. 这种场景下在获取DCC汇率的时候除了传入支付交易币种和持卡人卡币种还需传入渠道结算币种，这样计算汇率时能充分考虑到渠道交易币种(即持卡人卡币种)到渠道结算币种间可能的汇率变化. 另外这种场景下DCC服务本身应该仅仅提供一个报价汇率，而不进行对应的换汇交易. 比如商品展示价格是USD, 卡币种是RMB, 渠道结算币种是AUD, MERCHANT结算币种是USD，实际发生换汇应该是在AUD->USD之间. 如果支付平台发起一笔从RMB->USD的FXBOOKING是完全没有意义的.
另外之前的简化模型没有考虑到渠道收取支付平台的费用. 给渠道发送100RMB可能只能收到98RMB. DCC汇率计算也需要考虑此因素. 总而言之，DCC汇率需要考虑:
对于MERCHANT来说DCC和MCP一样能减少汇率波动的风险确保收单金额. 但是关注点不同, DCC关注点是在交易发生时, 其币种转换发生在支付单币种到渠道交易币种之间 MCP关注点是在结算发生时, 其币种转换发生在渠道结算币种和MERCHANT结算币种之间.
另外支付平台会对MCP服务收取一个服务费用，这个费用会由MERCHANT承担，而DCC服务本身不会收取MERCHANT额外的费用，平台收取的服务费用会提现在DCC汇率本身，简单说就是会从支付者多收钱，多收的这部分钱用作为支付平台的利润.
标签：默认 服务 bin 举例 strong 一般来说 时间 退款 实现
原文地址：https://blog.51cto.com/shadowisper/2541467
