一篇文章了解跨境收單生態版圖

出海企業的日常工作中，跨境支付是一項不可或缺的環節。如果您在工作中遇到文章中的這6個問題，本文將是您尋找答案的起點。

01 什么是收單，什么是收款

收款（Payout）：指接受或獲得支付的過程。

收款通常是指商家或個人實際收到款項的行為，而不涉及具體的支付處理過程。

具體的場景是發生在平臺類比如 Wish，Ebay，Amazon，商戶需要提供一個虛擬銀行賬戶去接受平臺的結算款——這個過程就叫做收款。

收款的公司：易寶、連連支付、pingpong、空中云匯、payoneer（P卡）、尋匯等，他們持有國內人民幣牌照或者和持有人民幣牌照的金融機構合作，將商戶的海外收入合規的結換匯到國內。

卡收單（Acquiring）：是指商家或機構通過與銀行或支付機構簽訂協議，接受持卡人支付的過程。在收單過程中，商家通過收單機構（也稱為收單銀行或收單服務提供商）與持卡人進行交易，收單機構負責處理交易流程并將款項結算給商家。收單通常涉及到卡組織、銀行、商家和持卡人之間的復雜交互，以確保支付交易的安全和順利進行。

本地支付（Local Payment methods)：收單里面除了卡支付之外，還有本地支付方式指的是在特定國家或地區流行的支付方式，通常是人們習慣使用的支付方式。

這些支付方式可以是特定的網銀轉賬、本地電子錢包、現金支付、便利店支付等。通過提供本地支付方式，商家能夠更好地滿足消費者的需求，提高交易成功率，并減少因匯率轉換或外幣交易而產生的費用。

02 收單的行業主要參與者

持卡人 Card Holder
Merchant 商戶
Merchant Service Provider 商家服務提供商
3.1: 獨立銷售組織 ISOs
3.2: 支付網關 Payment Gateway
3.3: 支付服務提供商 Payment Service Provider
3.3.1: Payment Aggregator
3.3.2: 支付服務商 PayFacilitators
3.4: 傳統商戶服務提供商 Traditional Merchant Service Provider
3.5: Mobile Payment Processors
3.6: 高風險商家服務提供商High Risk Merchant Services Providers
Acquiring Bank 收單行
Payment Processor 支付處理商
Card Scheme/Network 卡組織

針對上述的各個角色我們展開講一下，雖然這些概念看起來太過于專業，但是這個是為了之后我們在選擇支付公司的時候需要考慮的因素需要先理解這些底層的定義。

主要參與者

1. 持卡人

是指持有信用卡、借記卡或其他支付卡的個人或實體。

除了普通的信用卡和借記卡外，還存在一些特殊類型的卡片，例如商務卡、預付卡、禮品卡（Gift Card）、旅行卡（Travel Card）。

2. 商戶 Merchant

在信用卡方案（如Visa和Mastercard）的背景下，“商家”指的是任何接受客戶信用卡或借記卡支付的企業或實體，作為商品或服務的支付形式。商家包括各種類型的企業，包括零售店、餐廳、在線零售商、服務提供商、虛擬服務提供商等

運營知識分享MID：收單行分配的商家識別碼作為唯一標識符，這個MID有助于跟蹤和處理交易，由卡網絡、收單銀行和支付處理商 Payment Processor 使用，以識別和路由交易到正確的商家賬戶。還有值得提出的是拒付率也是根據 MID 來計算和統計的

3. Merchant Service Provider 商家服務提供商

商戶服務由商戶服務提供商（MSPs）或支付處理公司提供，它們充當企業、客戶和金融機構（如銀行和信用卡網絡）之間的中介關鍵組成部分。

包括：

支付處理 Payment Proessing
POS 系統
支付網關 Payment Gateaway
商戶賬戶 Merchant Account
防欺詐和安全措施
分析跟蹤和報告
客戶支持

市場上有幾種不同類型的商戶服務提供商，每種提供不同的服務，滿足各種業務需求。

一些常見類型的MSP包括以下：

3.1. 獨立銷售組織 ISOs (Independent Sales Organization)

ISOs 是一家被授權向商戶銷售或租賃支付處理服務的第三方公司或者個人。ISO是商戶與提供支付處理服務的金融機構之間的中介。ISO提供一系列服務，包括建立商戶賬戶、提供支付處理硬件和軟件、與支付處理器密切合作，并根據企業的具體需求提供定制解決方案。ISO通常通過為帶來的客戶向支付處理器或銀行支付傭金或費用來獲得報酬。

運營知識分享ISOs：只會負責介紹客戶，幫客戶開設商戶賬號，但是不會實際處理交易，實際的交易處理和結算的動作都不是由 ISO來負責。你可以單純理解為他們是外包的銷售團隊給銀行和支付處理商來找商戶線索，解決銷售策的問題。

3.2. 支付網關 Payment Gateway

支付網關是一種技術或服務，在消費者、商戶和支付處理商 Payment Processor 之間安全傳輸支付信息。它充當交易各方之間的橋梁。可以理解為實體零售店的銷售終端 POS，支付網關相當于線上的 POS 角色。使用支付網關可確保敏感的支付信息被安全處理。這是因為支付網關遵循嚴格的安全標準和加密協議，如支付卡行業數據安全標準（PCI DSS）

支付網關主要服務于商戶，幫助商戶安全完成線上交易的環節，是商戶和消費者之間傳遞交易批準Approve或拒絕Decline的技術提供商。

3.3. 支付服務提供商 Payment Service Provider

3.3.1. Payment Aggregator

支付聚合商是一種服務提供商，允許企業處理信用卡支付和移動交易，而無需在銀行或信用卡網絡中設立自己商戶賬戶Merchant Account。相反，聚合商只管理一個商戶賬戶，并將所有客戶都納入這一個商戶賬戶下。

運營小知識Payment Aggregator 主要適用于一些小中型企業，和 Payment Aggregator 對商戶審核沒有那么嚴格而且開戶上線速度也是很快，但是風險就在于你的交易和其他的子商戶都在一個 MID 下面。如果這個 PA 因為某一些子商戶的交易風險問題會直接影響他們整個 MID 的賬號正常交易。另外就是結算延遲的風險在這邊也是屬于一個較大的現金流風險

3.3.2. 支付服務商 PayFacilitators

Payfac 簡化了商戶賬戶注冊流程。Payfac 是支付聚合商的一種類型，但通常提供更全面的服務套件比如支付網關集成、面對面支付的硬件、防欺詐保護、交易報告和客戶支持。Payfac 是由收單銀行贊助注冊的獨立銷售組織（ISO）。它們維護一個主商戶賬戶，并允許子商戶submerchant 使用該賬戶來處理交易。每一個子商戶都可以有自己的獨立的 MID 以及MCC code, 取決于Payfac與收單行的合作關系，是否每一個子商戶都需要提交所有的 KYC 資料以及MCC給收單行審核。

下面這個圖主要展示了 Payment Aggregator和 Payfac 的主要區別：

3.4. 傳統商戶服務提供商 Traditional Merchant Service Provider

主要專注于為實體店提供支付處理服務。它們通常提供POS系統和硬件，如刷卡機和終端，以促進面對面交易。

3.5. Mobile Payment Processors

專注于為需要隨時接受支付的企業提供支付處理解決方案，例如食品車、市場攤位或移動服務提供商。它們通常提供可與智能手機或平板電腦配合使用的移動刷卡機或移動POS系統

3.6. 高風險商家服務提供商High Risk Merchant Services Providers

致力于與由于其產品、服務或行業性質而被視為高風險的企業合作。高風險企業可能面臨更高比率的退款（爭議交易）和欺詐。傳統的商戶服務提供商可能不愿意與它們合作。高風險商戶服務提供商為這些企業提供定制的支付處理解決方案和風險管理工具，通常費用更高。

4. 收單行 Acquiring Bank

這些客戶通常是高交易量的銀行和金融機構可以直接與卡組合作進行產品開發和營銷。雖然有一些必須支付的服務費用，但收單行在能夠管理的功能方面擁有最大的靈活性，并完全負責與分配的BIN相關的所有活動。

收單行在卡組那邊認證的全稱是 ‘’Principal Members/Clients 主要成員‘’

查詢鏈接：

https://b2b.mastercard.com/move/partner-program/find-a-partner/

https://partner.visa.com/site/partner-directory.html

運營小知識評估一個支付公司是否是收單行要以下幾個緯度1. 地區 Regions：每一個國家都需要單獨申請2. Visa/Mastercard/JCB/Discover 每一個卡組也是單獨申請的3. Capabilities 能力范圍，比如BNPL，發卡，Gateway，Merchant acquirer，processor 等4. 商業模式比如 Gaming & Gambling游戲和在線賭博，Ecommerce, Marketplace 商城

5. Payment Processor 支付處理商

支付處理商是消費者發卡行和商戶的銀行之間的技術中介。它們處理交易過程需要驗證客戶的付款信息，檢查欺詐行為，確保符合相關法規。最終，授權或拒絕交易。一般情況下，收單行和發卡行都是要和自己對應的支付處理商合作。

當然，在某些情況下，收單行/發卡行都可能自己本身同時為支付處理商。

支付處理商是在消費者發卡行與商戶收單行之間專注于支付處理 Processing 和授權 Authorize 的后端技術提供商。主要保證資金安全地從消費者賬戶轉移到商戶賬戶。

6. 卡組織

定義：支付網絡的例子包括Visa、Mastercard、American Express和Discover。這些支付網絡提供了基于卡的交易發生的基礎設施。它們位于收單機構和發卡機構之間，并來回傳遞消息以完成交易。

支付網絡還制定了收單機構和發卡機構需要遵循的通信規則和標準。

國際卡組和本地卡組是指信用卡或借記卡上所標示的支付網絡，其區別主要在于該卡組在國際范圍內的接受度和使用范圍。

以下是一些常見的國際卡組和本地卡組：

1. 國際卡組：Visa、Mastercard、American Express、Discover、UnionPay、JCB2. 本地卡組：China UnionPay（中國銀聯）、RuPay（印度）、Interac（加拿大）、Troy（土耳其）、Mada（中東）、Knet（科威特）等。

運營知識：重點卡組是有規定商戶合作主體所在國家只能和相同國家的收單機構或者三方支付機構合作。比如你如果使用香港主體，那你只能使用香港收單機構來合作處理全球的交易。這個是最合規的做法。當然目前的一些支付公司可以跳過這個規則，有兩種可能一種是合規的 MOR 模式，這種模式需要幫你代扣代繳消費稅，一般在虛擬行業這種三方支付機構比較多。比如 Xsolla, Terminal3, Paddle, Lemonsqeeze 等另外一種就是支付公司自己充當了商戶在歐洲注冊主體，以商戶的方式報備給收單行，之后把自己的通道下放給商戶用。

兩種模式其實都有一個大的弊端就是 MCC是固定的，基本上沒有辦法做到靈活適用于每一個商戶的商業模式直接會影響到成功率優化，所以這種方式比較適用于剛剛起步中小型的商家，追求的是跑通。

本文由 @是自由少女Lin呀原創發布于人人都是產品經理。未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務

吐槽一下。上個破班，閑嘛閑得要死，人都要爛掉。又加上等著過年，不知未來在何方哈哈。如今不缺糧草，又不愁冷暖。只是要滿足自己對美好品質生活的渴望，最終用自己的方式來真正創造實現人生價值。

不負能量了。最近有在使用 electron + react 自己開發一個客戶端應用。首先整個項目是通過 electron-boilerplate 模板來創建的，using Electron, React and Typescript。地址：https://github.com/sindresorhus/electron-boilerplate

ps: 當想在 github 搜學習資源時，可以檢索 awesome + [theme] 比如 awesome JavaScript, awesome Vue, etc.

基于這個模板創建的項目,其中 react 的 webpack 配置文件是 webpack/react.webpack.js ，最初好像都沒配置 css-loader，更別提什么 css 模塊化了…幸好有點 webpack 基礎和之前也比較系統地了解學習了 react。

css 模塊化：隨著 react、vue 等基于模塊化框架的普及，我們通常會將頁面拆分為多個小組件，然后將多個組件拼接組成最終程序呈現的頁面。但是如果頁面中兩個組件使用了相同的類名，后者的樣式會把前者的覆蓋掉，造成樣式的命名沖突。所以就出現了 css 模塊化的概念。vue 是我們在組件中寫樣式的時候加上 scoped 就好了，但是 react 通常要自己進行配置。CSS 模塊化使得我們可以向 import js 一樣來引用我們的 css 代碼，代碼中的每一個類名都是引入對象的一個屬性。通過這種方式，在使用時明確指定所引用的 css 樣式。在打包的時候自動地將類名轉換為 hash 值，完全杜絕 css 類名沖突的問題。

css 命名規范 BEM：BEM，塊 block，元素 element，修飾符 modifier。由 Yandex 團隊提出的一種前端命名方法論，使得 css 類對其他開發者來說更加透明且更有意義。

/* 塊通常是指 Web 應用開發中的組件或模塊.每個塊在邏輯和功能上都是相互獨立的*/

.block{}

/* 元素是塊中的組成部分.元素不能離開塊使用,且 BEM 不推薦在元素中嵌套其他元素*/

.block__element{}

/* 修飾符是用來定義塊或元素的外觀和行為.同樣的塊在應用不同的修飾符之后,會有不同的外觀*/

.block--modifier{}

餓了么團隊開源的 element-ui 組件庫的 css 類命名采用的就是此規范。而螞蟻金服的 ant-design 好像并沒有哈哈。之后自己也將一直遵守這樣的規范，逐漸養成自己的一整套規范！開發就是要規范化，爭取不寫垃圾代碼。

配置 css 模塊化：

首先 npm install –save-dev style-loader css-loaderstyle-loader 是通過 JS 腳本創建一個 style 標簽，里面包含樣式。但是并不能單獨使用，因為它不負責解析 css 之前的依賴關系，所以還需安裝 css-loader。webpack 使用 js 寫的，運行在 node 環境下，打包的時候只會處理 js 之間的依賴關系。所以處理 css 文件需要引入 css-loader 來識別，通過特定的語法規則進行內容轉換最后導出。
修改 webpack 配置項，這里的 webpack 版本是 4.42.1。

   module.exports = {
   module: {
   rules: [
    {
    test: /\.css$/,
    use: [
    'style-loader',
    // 開啟模塊化并自定義 hash 名稱
    {loader:'css-loader',options:{modules:{localIdentName:'[path][name]\_\_[local]--[hash:base64:5]'}}},
    ],
    // 排除 node_modules 文件夾
    exclude: path.resolve(rootPath,'node_modules'),
   },
   ]
   }

定義 css 文件。

   .className {
   color: green;
   }
   /_ 編寫全局樣式 _/
   :global(.className) {
   color: red;
   }

當然還可以引入 less-loader 等 css 預處理器，同樣開啟模塊化。這邊給出我在項目中的配置。

   module.exports = {
   module: {
   rules: [
    {
    // CSS 全局處理
    test: /\.css$/,
    use: [
    'style-loader',
    'css-loader'
    ],
    exclude: path.resolve(rootPath,'node_modules'),

   },
   {
    // less 模塊化處理
    test: /\.less$/,
    exclude: path.resolve(rootPath,'node_modules'),
    use: [
    'style-loader',
    {loader:'css-loader',options:{modules:{localIdentName:'[local]-[hash:5]'}}},
    'less-loader'
    ]
   }
   ]
   }

最后引入 AntDesign。項目地址https://ant-design.gitee.io/docs/react/introduce-cn。

首先 npm i antd -S 安裝，然后在項目入口文件中引入 antd 樣式 import ‘~antd/dist/antd.css’。當然前提是你的 webpack 支持解析 css 文件。

如果優雅地使用該組件庫并結合 ts 寫 react 項目，可以參考https://github.com/ant-design/ant-design-pro

css 的發展也應該進行到了可以使用 js 語言寫 css，同樣可以實現 css 模塊化，比較好的方案是 styled-components。不過我暫時沒法接受這樣的寫法，，感覺開發效率也不高。

本篇博客想記錄的就是這些吧，寫得有點匆忙。不過通過寫博客，對自己學習的幫助真的很大！同時要強迫自己繼續堅持和養成寫博客的好習慣。

原文地址：https://zzfd.github.io/2021/02/02/reactCSS 模塊化和引入 AntDesign

參考資料：如有侵權，請告知，將第一時間刪除部分內容。

https://zhuanlan.zhihu.com/p/100133524

https://blog.csdn.net/wu_xianqiang/article/details/104560613

https://github.com/ant-design/ant-design-pro

https://github.com/sindresorhus/electron-boilerplate

ue也用這么久了，原理之類的文章也看了不少。今天又精讀了一篇頭條上的文章，自己也總結記錄一下。雖然吧，該學vue3了，不過想轉React了哈哈。不扯了，還是先總結下Vue這個框架吧。

官方介紹： Vue是一套用于構建用戶界面的漸進式框架。與其它大型框架不同的是，Vue 被設計為可以自底向上逐層應用。其架構模式為MVVM。

漸進式框架：主張最少，可以將其他模塊逐步接入。其核心庫只關注視圖層（聲明式渲染和組件系統），可以在項目中只引入vue.js就可開發。同時你也可以引入vue-router作為客戶端路由管理，vuex作為全局的狀態管理等。

自底向上逐層應用：將基礎做好，打牢再逐層往上添加效果和功能的設計。

vue

架構模式MVC：Model-View-Controller。MVC的流程大概就是，html（View）操作，告知js（Controller）要更新數據（Model），js（Controller）更新了數據（Model），然后再更新html(View)。

MVC

架構模式MVP：Model-View-Presenter。Presenter層既能將頁面操作告知Model進行數據更新，又能在數據更新時負責通知View進行更新視圖，使的View層與Model層解耦。（React）

MVP

架構模式MVVM：Model-View-View-Model，實現了數據綁定的MVP，使得Model狀態的改變會直接導致視圖的更新（數據驅動視圖）。（Vue）

MVVM

Vue模板渲染：vue的核心之一聲明式渲染，具有自身的模板語法，允許在html中嵌入js代碼，并可結合強大的指定機制。實現聲明式地將數據渲染出視圖。
實現模板渲染的前提是進行模板編譯。模板編譯分為三個階段，parse、optimize、generate最終生成render函數。

模板編譯

parse階段：使用正則表達式對template內容進行字符串解析，得到指令、class、style等數據，生成抽象語法樹AST(Abstract Syntax Tree)。
optimize階段：尋找AST中的靜態節點進行標記，為后面VNode的patch過程中對比做優化。被標記為static的節點在之后的diff算法中會被直接忽略。
generate階段：根據AST結構拼接生成render函數的字符串。
在項目開發中，可以通過預編譯進行一定的優化。即將template轉化為render function，可在項目的構建中完成，無需等到runtime階段。比如webpack中vue-loader依賴的vue-template-compiler模塊。當然也可以直接在vue組建中編寫render函數（可結合jsx）。

聲明式渲染：只告訴程序想要什么結果，如何達成由程序保證，開發者不用關心。（不直接操作dom，結合模板語法）
命令式渲染：一步一步告訴程序如何去做，能否達成結果取決于開發者的設計。（找到這個元素，直接操作dom。）

組件機制：Vue的組件擁有自己的狀態（data），外部傳入的屬性（prop）和事件，通過數據和狀態計算出來的計算屬性（computed），監聽屬性（watch），自身方法（methods）及生命周期函數等，各個維度組合起來決定組件最終呈現的樣子與交互的邏輯。

Vue組件間通信：

父子組件通信props / $emit$parent / $children
隔代組件通信$attrs / $listenersprovide / inject
通用EventBus（$emit / $on / $once / $off），中央事件總線系統。Vuex

Vue插槽slot：組件的一塊HTML模塊，由父組件決定。分默認插槽（name=default）和具名插槽。

slot實現原理：當子組件vm實例化時，獲取父組件傳入的slot標簽內容，存放在vm.$slot中，當組件執行渲染函數時，遇到標簽，則使用$slot中的內容進行替換，此時也可以向插槽傳遞數據，稱之為作用域插槽。

<!-- 作用域插槽 -->
<template>
    <!-- parent.vue -->
    <div class="parent">
        <h1>這是父組件</h1>
        <current-user>
            <template slot="default" slot-scope="slotProps">
                
            </template>
        </current-user>
    </div>
</template>

<!-- 作用域插槽 -->
<template>
    <!-- child.vue -->
    <div class="child">
        <h1>這是子組件</h1>
        <slot :user="user"></slot>
    </div>
</template>
<script>
export default {
    data() {
        return {
            user: {
                name: '小趙'
            }
        }
    }
}
</script>

父子組件

組件：對特定功能和樣式進行獨立的封裝，使得HTML元素得到擴展，代碼得到復用。開發靈活，高效。
模塊：對特定功能進行抽離封裝，提高程序耦合度，結構更加清晰，便于維護擴展。

響應式系統：Vue.js是一款MVVM的JS框架，當對數據模型data進行修改時，視圖會自動得到更新。

響應式原理：響應式的核心機制是觀察者模式，三個重要概念，Observer，Dep，Wathcher。

發布者-Observer：主要作用是在組件vm初始化時，調用defineReactive函數，使用Object.defineProperty方法對對象的每個子屬性進行數據劫持/監聽，為每個屬性添加getter和setter，對應的屬性值變成響應式。在組件初始化時，調用initState函數，執行initState、initProps、initComputed方法，分別對data、prop、computed進行初始化。

調度中心-Dep：主要作用是對觀察者進行管理，收集觀察者dep.depend和通知觀察者更新dep.notify。

觀察者-Watcher：主要作用是為觀察屬性提供回調函數以及收集依賴，接收調度中心的通知。分為normal-watcher、computed-watcher（只有當其他地方需要讀取計算屬性時才會重新計算）、render-watcher。執行順序computed–>normal–>render。

響應式系統

虛擬DOM：為了解決頻繁更新DOM產生的性能問題。使用JS對象對瀏覽器的DOM進行抽象。Virtual DOM的每個節點被定義為VNode。視圖更新時，會將更新前后的VNode進行Diff對比，實現最小DOM更新操作。

render: function (createElement) {
    // 使用 this.$createElement 創建 VNode
    return createElement('div', 'hellow world');
}

Diff：實現最小單位地修改視圖。Vue內部的diff成為patch。通過同層的樹節點進行比較，時間復雜度為O(n)

當然，這只是總結了其中的一部分，其他生命周期函數、指令、過濾器、全局API等尚待總結。

原文地址：https://zzfd.github.io/2021/01/22/vue總結01

參考資料：如有侵權，請告知，將第一時間刪除部分內容。

https://www.jianshu.com/p/63b55a3ee81b

https://blog.csdn.net/sinolover/article/details/101682289

https://m.toutiao.com/is/J7G2wEn/

https://m.toutiao.com/is/J7GR5Pd/

在線咨詢

上一篇：CSS自定義屬性
下一篇：2019廣州國際燈光、音響展覽會絕不容錯過的民族音響燈光產品

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商