整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

一篇文章了解跨境收单生态版图

出海企业的日常工作中,跨境支付是一项不可或缺的环节。如果您在工作中遇到文章中的这6个问题,本文将是您寻找答案的起点。

01 什么是收单,什么是收款

收款(Payout):指接受或获得支付的过程。

收款通常是指商家或个人实际收到款项的行为,而不涉及具体的支付处理过程。

具体的场景是发生在平台类比如 Wish,Ebay,Amazon,商户需要提供一个虚拟银行账户去接受平台的结算款——这个过程就叫做收款。

收款的公司:易宝、连连支付、pingpong、空中云汇、payoneer(P卡)、寻汇等,他们持有国内人民币牌照或者和持有人民币牌照的金融机构合作,将商户的海外收入合规的结换汇到国内。

卡收单(Acquiring):是指商家或机构通过与银行或支付机构签订协议,接受持卡人支付的过程。在收单过程中,商家通过收单机构(也称为收单银行或收单服务提供商)与持卡人进行交易,收单机构负责处理交易流程并将款项结算给商家。收单通常涉及到卡组织、银行、商家和持卡人之间的复杂交互,以确保支付交易的安全和顺利进行。

本地支付(Local Payment methods):收单里面除了卡支付之外,还有本地支付方式指的是在特定国家或地区流行的支付方式,通常是人们习惯使用的支付方式。

这些支付方式可以是特定的网银转账、本地电子钱包、现金支付、便利店支付等。通过提供本地支付方式,商家能够更好地满足消费者的需求,提高交易成功率,并减少因汇率转换或外币交易而产生的费用。

02 收单的行业主要参与者

目录

  1. 持卡人 Card Holder
  2. Merchant 商户
  3. 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
  4. Acquiring Bank 收单行
  5. Payment Processor 支付处理商
  6. 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 模块化:

  1. 首先 npm install –save-dev style-loader css-loaderstyle-loader 是通过 JS 脚本创建一个 style 标签,里面包含样式。但是并不能单独使用,因为它不负责解析 css 之前的依赖关系,所以还需安装 css-loader。webpack 使用 js 写的,运行在 node 环境下,打包的时候只会处理 js 之间的依赖关系。所以处理 css 文件需要引入 css-loader 来识别,通过特定的语法规则进行内容转换最后导出。
  2. 修改 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'),
   },
   ]
   }
   
  1. 定义 css 文件。
   .className {
   color: green;
   }
   /_ 编写全局样式 _/
   :global(.className) {
   color: red;
   }
   
  1. 当然还可以引入 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组件间通信:

  1. 父子组件通信props / $emit$parent / $children
  2. 隔代组件通信$attrs / $listenersprovide / inject
  3. 通用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/