收單場景多币種支付小結

收單場景多币種支付概述:

在跨境收單的場景下,一筆支付交易會涉及以下幾個币種:

支付交易币種: 發起支付訂單客戶實際支付的币種

管道交易币種: 管道可以接受的支付币種.

管道結算币種: 管道給支付平台對賬單中交易的結算币種. 一般來說，管道支援的結算币種是交易币種的一個子集, 是以選擇管道的時候我可以隻考慮管道的結算币種是否支援支付交易币種.

MERCHANT結算币種: 支付平台結算給MERCHANT的币種

對于每個支付管道, 一般會有以下幾個配置:

管道支援的交易币種清單

管道支援的結算币種清單

管道預設的結算币種

實際情況可能比這個更加複雜: 比如微信, 在不同區域支援的交易币種和結算币種不同, 還和使用API的版本也有關系.

由于這三個币種可能不同, 是以需要進行匯率轉化，根據不同的情況, 匯率轉化可能發生在發夾行也可能發生在支付平台. (信用卡正向支付交易扣款途徑: MERCHANT 交易系統 -> 支付平台 -> 下遊管道收單行(ACQUIRER BANK) -> 卡組織 -> 發夾行)

Like for like

綜上所述，一筆訂單結算給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的匯率由管道決定不受控制.

多币種詢價 (MCP -- muti currency pricing)

在跨境支付的電商領域比較适用. 支付平台提供給電商平台的商戶一個匯率報價用于讓他以指定的币種展示商品價格, 此币種一般和商家期望的結算币種不同. 電商平台的買家可以以展示的币種支付訂單. 支付平台提供一個匯率鎖定的能力確定實際換彙的匯率和報價匯率一緻, 進而保證商戶收到的支付款金額和原始的商品金額相同. 因為使用者下單完成支付到實際下遊管道結算給商家時間差為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 -- dynamic currency conversion)

從廣義上來說隻要支付币種和結算币種不同發生換彙就算一種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是完全沒有意義的.

• 支付平台收取的利潤
• 支付管道收取支付平台的交易費用
• 從支付訂單币種到持卡人卡币種轉換的匯率波動
• 從支付币種到管道結算币種的匯率波動

比較MCP和DCC

資費計算 (COST & FEE)

結算

退款