20180112-296号文解读

Posted by PaymentGroup on January 15, 2018

一、主题分享

1.1 开展条码业务所需资质

一、严格遵循业务资质及清算管理要求
非银行支付机构(以下简称支付机构)向客户提供基于条码技术的付款服务的,应当取得网络支付业务许可;支付机构为实体特约商户和网络特约商户提供条码支付收单服务的,应当分别取得银行卡收单业务许可和网络支付业务许可。
银行业金融机构(以下简称银行)、支付机构开展条码支付业务涉及跨行交易时,应当通过人民银行跨行清算系统或者具备合法资质的清算机构处理。自本通知发布之日起,银行、支付机构不得新增不同法人机构间直连处理条码支付业务;存量业务应按照人民银行有关规定加快迁移到合法清算机构处理。

这里面首先主要规范里面讲支付机构和银行进行分开,强调支付机构必须获得相应领域支付许可方能开展支付业务

  • 对于线上商户的条码支付,例如在电脑显示器上主扫完成线上商城订单支付,这个只需要互联网支付牌照
  • 而当我们一旦需要涉及线下实体门店的时候,无论主扫和被扫都需要银行卡收单牌照

从中我们可以看出人行很明确,线下实体收单属于银行卡收单管理范畴,线上商城支付属于互联网支付的范畴,也恰恰符合人民银行2010 2号令的规定

以下来自《非金融机构支付服务管理办法》(中国人民银行令[2010]第2号)

20180111_200151
20180111_200251

1.2 银行条码支付的规定

一、严格遵循业务资质及清算管理要求

支付业务涉及跨行交易时,应当通过人民银行跨行清算系统或者具备合法资质的清算机构处理

  • 首先人民银行强调对于跨行支付必须使用银联或者网联的二维码标准进行支付,对于本行银行卡支付,人民银行并没有强制规定
    所以对于银行本代本业务是允许使用银行自有标准进行支付

自本通知发布之日起,银行、支付机构不得新增不同法人机构间直连处理条码支付业务;存量业务应按照人民银行有关规定加快迁移到合法清算机构处理。

人民银行在296文中又在此强调银行不准在新增条码聚合支付业务
从该规范的目的也非常明确,将收单备付金划分界限,明确各自收单范畴,避免交叉收单,引起备付金监管的盲区

二、规范条码支付收单业务管理
银行和支付机构在为特约商户提供条码支付收单服务时,应执行《银行卡收单业务管理办法》(中国人民银行公告〔2013〕第9号公布)、《中国人民银行关于加强银行卡收单业务外包管理的通知》(银发〔2015〕199号)等规定。

这里人民银行把条码支付归类为银行卡收单的管理办法,因此相关的技术安全标准需要符合银行卡收单管理办法。

因此顺利成章
为实体特约商户提供收单服务,应履行本地化经营、商户定期巡检责任;为网络特约商户提供收单服务,应强化对网络支付接口的使用管理和交易监测,采取有效的检查措施和技术手段对其经营内容和交易情况进行检查

强调了对于线下实体商户的本地化经营和定期巡检的责任
本地化指的是地区性,例如我是一个上海的商户,在支付宝申请入网,我后来搬家去西安了,我这个终端也搬去西安了,此时支付宝应该拦截并暂停我的收单交易
对于支付宝发的静态二维码也是要如此,如果有西安的游客扫了我的静态二维码,就应该识别侦测出我在跨地区经营
这个相信做过POS收单的很多同事都清楚,叫做移机监控

四、加大监督检查力度
已开展条码支付业务的银行、支付机构应当全面梳理自身条码支付业务情况(含境内、跨境、境外业务)并形成报告,包括但不限于按年度统计的业务量、产品介绍、业务流程、技术方案、风险管理机制、境内外机构合作情况、资金清算模式、收费标准及利润分配机制、客户权益保护措施、外包服务机构信息及外包范围、以及根据本通知进行自查的情况及整改方案等。2018年1月31日前,全国性银行将报告报送人民银行总行,其他银行和支付机构将报告报送法人所在地人民银行分支机构。

该要求进一步收集了目前各支付机构、银行的支付业务,包含支付宝微信的境外收单业务,了解目前的业务模式以及整改方案,要求1-31完成上报
所以各位银行支付机构的同事务必要仔细逐条对应该管理办法,不要出现整改遗漏的地方

1.3 具体条款中的重点关注点解读

第四条支付机构开展条码支付业务,应按规定取得相应的业务许可,并按相应管理办法规范开展业务。

明确支付继续开展条码支付业务必须取得相应许可,如果没有银行卡收单牌照, 则必须关停目前线下实体的入网商户业务

第五条支付机构不得基于条码技术,从事或变相从事证券、保险、信贷、融资、理财、担保、信托、货币兑换、现金存取等业务。

明确支付机构条码支付不能用于证券、保险、信贷、融资、理财等业务
具体实际的例子吧,保险公司有一笔保单要支付,在PAD生成一个二维码,支付宝去扫描二维码支付,新的吧办法不允许
在基金公司网站,选择支付宝支付,在pc显示器上扫支付宝二维码支付,新的管理办法不允许
扫描二维码完成消费贷、信贷分析业务,即二维码使用花呗,新的办法不允许

预付卡支付不得使用条码支付方式,如果预付卡一定需要使用,可以考虑绑定在支付账户上使用
这里再次强调人行仅仅针对支付机构,对于银行条码支付仍然可以用于上述场景

第六条银行、支付机构开展条码支付业务应遵守客户实名制管理规定;遵守反洗钱法律法规要求,履行反洗钱和反恐怖融资义务;依法维护客户及相关主体的合法权益。

条码支付需要符合反洗钱管理办法,即需要对用户可疑交易和大额交易进行上报,如果用户单笔支付金额超过1万元,或者月累计超过5万元,需要补充验证用户身份证影像文件验证,否则可能会面临违反反洗钱规定收到罚款

第九条银行、支付机构开展条码支付业务,应将客户用于生成条码的银行账户或支付账户、身份证件号码、手机号码进行关联管理。

这条规定,条码支付生成的要素为银行卡或者支付账户ID、身份证、手机号
也就是说实际并不是基于支付账户绑定卡生成条码,而是基于支付账户id生成

**必须强调把支付账户作为一个整体进行看待 **

第十条银行、支付机构开展条码支付业务,可以组合选用下列三种要素,对客户条码支付交易进行验证:
(一)仅客户本人知悉的要素,如静态密码等;
(二)仅客户本人持有并特有的,不可复制或者不可重复利用的要素,如经过安全认证的数字证书、电子签名,以及通过安全渠道生成和传输的一次性密码等;
(三)客户本人生物特征要素,如指纹等。

该描述与非银支付机构网络支付管理办法描述一致,一共分为3类

  • A 静态密码
  • B 数字证书或短信验证码
  • C 生物特征

采用客户本人生物特征作为验证要素的,应当符合国家、金融行业标准和相关信息安全管理要求,防止被非法存储、复制或重放。

目前针对生物特征,刷脸支付目前尚未符合金融行业标准,暂时不可认为是验证要素之一

第十二条 银行、支付机构应根据《条码支付安全技术规范(试行)》(银办发〔2017〕242号)关于风险防范能力的分级,对个人客户的条码支付业务进行限额管理:
(一)风险防范能力达到A级,即采用包括数字证书或电子签名在内的两类(含)以上有效要素对交易进行验证的,可与客户通过协议自主约定单日累计限额

A级=数字证书+静态密码或者生物特征

(二)风险防范能力达到B级,即采用不包括数字证书、电子签名在内的两类(含)以上有效要素对交易进行验证的,同一客户单个银行账户或所有支付账户单日累计交易金额应不超过5000元;

B级=支付密码+短信验证码或者指纹

(三)风险防范能力达到C级,即采用不足两类要素对交易进行验证的,同一客户单个银行账户或所有支付账户单日累计交易金额应不超过1000元;

C级=支付密码或者短信验证码或者指纹

第十三条支付机构向客户开户银行发送支付指令,扣划客户银行账户资金的,同一客户全部银行账户合计日累计交易限额执行第十二条的规定。

这里注意,支付机构在累计支付限额的时候为该同一个客户(身份证号)下的所有支付账户的所有绑定卡消费合计+所有余额支付合计
再次强调是同一个自然人,而不是同一个支付账户

第十四条银行、支付机构提供付款扫码服务的,应具备差异化的风控措施和完善的客户权益受损解决机制,在条码生成、识读、支付等核心业务流程中明确提示客户支付风险,切实防范不法分子通过在条码中植入木马、病毒等方式造成客户信息泄露和资金损失。

这条人行明确要求在条码生成、读取、支付过程中,都需要明确提示用户支付风险,需要进行页面改造

第十六条银行、支付机构开展条码支付业务所涉及的业务系统、客户端软件、受理终端(网络支付接口)等,应当持续符合监管部门及行业标准要求,确保条码生成和识读过程的安全性、真实性和完整性。

此处再次强调是业务系统、客户端软件都需要符合监管部门及行业标准,举个例子,我们做个插件植入商户自主研发的收银台客户端中,该商户收银台客户端并没有通过安全认证,该业务就是存在严重问题

第十七条银行、支付机构应按照中国人民银行相关规定强化支付敏感信息内控管理和安全防护,强化交易密码保护机制;通过支付标记化技术应用等手段,从源头控制信息泄露和欺诈交易风险。

这条属于技术技术规范,这里不做展开,脱敏问题各位务必重视,支付采用TOKEN支付方式,直接传输卡号方式需要整改

第十八条 银行、支付机构应指定专人操作与维护条码生成相关系统。条码信息仅限包含当次支付相关信息,不应包含任何与客户及其账户相关的支付敏感信息。
特约商户展示的条码,仅限包含与当次支付有关的特约商户、商品(服务)或商品(服务)订单等信息。移动终端展示的条码,不得包含未经加密处理的客户本人账户信息。

这里强调条码支付展现时不得展现具体信息,持卡人账户信息需要使用

第二十条银行、支付机构应根据条码支付的真实场景,按规定正确选用交易类型,准确标识交易信息并完整发送,确保交易信息的完整性、真实性和可追溯性。

对于PC端显示器扫码支付和线下门店扫码支付虽然都是主动扫码支付,但是前者为互联网支付,后者为银行卡收单类型,交易类型不同,不可混为一谈

银行、支付机构应在支付交易报文中通过特定域标识该交易为条码支付交易,以供报文接收方正确识别并进行授权处理

条款中,明确说明了交易报文中必须明确识别条码支付为特定交易类型,不得与移动快捷支付混为一套,分立而治

第二十一条支付交易完成后,特约商户受理终端和移动终端应显示支付结果;支付失败的,特约商户受理终端和移动终端还应显示失败原因。

这个注意点为商户终端必须显示失败原因,目前大量的商户终端并不显示,需要进行全面整改

第二十三条中国支付清算协会、清算机构应将条码支付特约商户纳入特约商户信息管理系统及黑名单管理机制。银行、支付机构拓展特约商户时,应进行查询确认,如商户及其法定代表人或负责人在特约商户信息管理系统中存在不良信息记录的,应谨慎为该商户提供条码支付服务;不得将已纳入黑名单的单位和个人,以及由纳入黑名单个人担任法定代表人或者负责人的单位拓展为特约商户,已经拓展为特约商户的,应当自该特约商户被列入黑名单之日起10日内予以清退。

强调了准入机制,不能再像以前来者不拒,谁都可以来进行收单,需要定期查询黑名单系统,并且在整改期间进行限期清退处理

第二十四条对依据法律法规和相关监管规定免于办理工商注册登记的实体特约商户(小微商户),收单机构在遵循“了解你的客户”原则的前提下,可以通过审核商户主要负责人身份证明文件和辅助证明材料为其提供条码支付收单服务。

该条款与前期火热的支付宝的收款码而言,明确了收款码需要(个体经营户)需要办理条码收单,必须审核其辅助材料,证实其从事的相关经营范围

以同一个身份证件在同一家收单机构办理的全部小微商户基于信用卡的条码支付收款金额日累计不超过1000元、月累计不超过1万元。银行、支付机构应当结合小微商户风险等级动态调整交易卡种、交易限额、结算周期等,强化对小微商户的交易监测。

这个更明确了小微商户信用卡收款不得日累计超过1000元,月累计不得超过一万元,如果发现存在信用卡套现,进一步降低其限额甚至关闭

第二十七条银行、支付机构应按规定向中国支付清算协会和清算机构特约商户信息管理系统报送特约商户基本信息。

这条更加明确,想玩虚假商户?基本不太可能,银行的结算账户姓名和入网商户名称进行一个比对,很快就能发现收单机构入网中的问题,所以老老实实审核商户真实性,不要玩虚的了

第二十八条银行、支付机构应建立特约商户检查制度,明确检查频率、检查内容、检查记录等管理要求,落实检查责任。

定期检查,无论线上和线下,必须要进行留存管理,年审认证的时候没有就会被毙掉

第二十九条银行、支付机构应当对实体特约商户条码收单业务进行本地化经营和管理,通过在特约商户及其分支机构所在省(区、市)辖内的收单机构或其分支机构提供收单服务,不得跨省(区、市)开展条码收单业务。

这里不再展开,就是规范了条码支付的属地化经营,如果为集团连锁的,那么一个分店入网一个商户号,没商量

第三十一条银行、支付机构应尊重特约商户的自主选择权,不得干涉或变相干涉特约商户与其他机构的合作。

这里再次强调,和与特约商户的合同中,不得有明显的的排他性的语句,需要注意措辞和表述

第三十二条银行、支付机构开展条码支付业务应参照银行卡刷卡手续费定价标准科学合理定价,不得采用交叉补贴、低于成本价格倾销等不正当手段排挤竞争对手,扰乱市场秩序。

这条明确了条码支付需要符合银行卡刷卡的手续费,不能再以千一、千2的价格对外进行收单,且不能进行返佣、补贴形式,如果一旦发现可以实名举报

第三十五条银行、支付机构应建立特约商户风险评级制度,综合考虑特约商户的区域和行业特征、经营规模、财务和资信状况等因素,对特约商户进行风险评级

没有客户风险评级,必须尽快启动开发,再怎么简单也要做一套

第四十条银行、支付机构应能够有效识别本机构发行的客户端程序和特约商户受理终端,能够确保条码生成和识读过程的安全性。

客户端程序和商户终端必须体现支付机构,而不能像收钱吧那种,只体现自己,而不体现具体的支付宝、微信、银行,反正聚合支付也只能说聚合支付,只能默默服务

第四十五条银行、支付机构应充分披露条码支付业务产品类型、办理流程、操作规程、收费标准等信息,明确业务风险点及相关责任承担机制、风险损失赔付方式及操作方式。

充分披露一般是在官方网站上进行明确,公示收费标准,注意对外宣传口径


二、Q&A

Q1:客户端程序和商户终端必须体现支付机构,而不能像收钱吧那种,只体现自己,而不体现具体的支付宝、微信、银行,反正聚合支付也只能说聚合支付,只能默默服务,可以延展一下,收钱吧,哆啦宝这种以后还能干吗?

我觉得是不行了,只能来回切换程序了;就是一个机器可以有多个终端程序,但是每个终端程序必须是有各自的支付机构或者银行发行的程序。我举个很简单的例子,万一收钱吧变造交易,明明是A商户,变造成为B商户,这个人民银行是非常反感的。

Q2:”(二)风险防范能力达到B级,即采用不包括数字证书、电子签名在内的两类(含)以上有效要素对交易进行验证的,同一客户单个银行账户或所有支付账户单日累计交易金额应不超过5000元;”,所有支付账户的交易金额怎么统计呢?由谁来统计?

支付机构在累计支付限额的时候为该同一个客户(身份证号)下的所有支付账户的所有绑定卡消费合计+所有余额支付合计;支付机构自己风控系统统计,指的是同一个支付机构下同一个自然人的所有支付账户。

Q3:威富通的业务有影响吗?

我觉得会的

Q4:我记得以前是招行还是哪个银行做过,二维码取现?

兰州银行,第二天就被叫停了

Q5:Ping ++业务受影响吗?

会的,具体聚合支付如何显示处理,可能还要等人行细则;但是从目前来看聚合支付的空间很有限。

Q6:线下实体商户商户二位码收单需要银行卡收单牌照,是不是意味着有牌照的支付公司只能做银行发的二维码?这部分的清算会送到银联还是网联?

对的,没有牌照,只能做银联二维码;目前应该是银联,网联还没用起来

Q7:现有银行模式微信支付宝是玩完了吗?

对!多次发文明确了

Q8:如果有收单牌照,是不是也不能做支付宝和微信了?

对的,只能做自己;商户是谁的就是谁的;没有银行卡收单牌照,基本线下就做不了了;有银行卡收单牌照的也不好做,成本很高,做全国人力成本都不够

Q9-1:我测试收钱吧产品,我自己都没签署过自动提现服务,现在提示说开通了自动提现,而且要>100元才能提
20180111_211354

嗯,所以人行要管制啊,各种太乱了;自己留了资金池,又不受备付金管理;属于无牌机构从事支付业务。

Q9-2:收钱吧做二清啦? Q9-3:提不了钱,要不我再充点进去?提现看谁给我钱?

可以的,你可以看一下交易对手方是谁

A1:不用看了,九成的二清;银行模式的微信支付宝,一分钱都是自动清分的,根本没有手动,手动的都是单独调代付实现的。
A2:只有明天了,还是自动提现;反正之前我测试的时候是喔噻打给我的;估计是拉卡拉了现在,等明天看

Q10:看来收单机构只能做银联二维码了?

即使能做,也只能基于银行2,3类账户;不能说基于支付账户的绑定卡做银联二维码

Q11:想知道现有银行模式的微信支付宝有撒出路?

快刀斩乱麻吧,要么把商户卖给支付宝,做成直连,要么就只能等着关了

Q12-1:你觉得收钱吧怎么办?转型服务于银行自身和银联二维码?

技术服务商

A1:嗯,银行渠道商,刚搞了一些品牌商超

Q12-2:但商户端品牌还能显示收钱吧吗?收钱吧难道相当于pos机提供商了?

技术服务商的意思是,不涉及资金,只提供服务,商家需要在收单机构开户;相当于pos机软件开发商。

Q13:银行二维码是每个银行自己推自己的付款码和微信支付宝付款码一样吗?

不是的,只有本带本可以,其他跨行必须使用银联或者网联标准

A1:银行二维码 你就理解成本代本的pos其他都是银联二维码就类似于带银联的pos;线下二维码实际上在监管看来就是 幻化形态的pos。

对!甚至也管到了线上了;支付宝pc扫码支付也在这个管理办法里哦

Q14:本来以为会出一个二维码支付的牌照子项可以线下线上一起搞,结果还是安场景切分了监管

还是没有看4月份的条码支付业务管理办法征求意见稿,其实之前已经态度更明确了;《条码支付业务规范》(征求意见稿)全文

Q15-1:我还有个问题,那现在那些已经转清的支付机构商户,突然之间不能用支付宝和微信了,这个真空期咋整?

存量的逐步整改,提交人行人行整改方案;1月31日之前要提交的。

Q15-2:是啊,现在不少商户的二清都是依赖财付通或者支付宝解决的,他们怎么过?

一切回归理性吧,该是谁的就是谁的

Q16-1:如果我是商户,我现在要使用刷卡,微信支付宝,如何办理?

一个个入网,终端是一个还是多个就看服务商了; A1:但你不能从银行一个渠道就把所有的入网做完了,你需要分别称为支付宝和微信还有银行的服务商 然后分别帮商户入网

Q16-2:这种只能是智能POS来承载吧,那不是要切换三个收款工具?

没错!传统也行,就是切换起来有点难受 A1:那就一个商户弄三个POS
智能终端体验肯定更好,对于pos机厂商是重大利好

Q17:”扫描二维码完成消费贷、信贷分析业务,即二维码使用花呗,新的办法不允许”,扫码支付不能使用花呗?

对啊,通过条码支付完成信贷业务

Q18:网联会不会出一个像银联二维码那样的东西,扫微信支付宝和三方的?

肯定不会的啦,网联只会负责银行跨行清算,其他的不要多想了

Q19-1:我今天打电话给人行老师,他说他正在制定统一标准,用清算组织连接支付宝和微信,然后你有互联网支付牌照,可以用来收款,支付宝微信用来付款,参照银联的发卡行和收单行的,这个清算组织就是网联。

不要想的太美好,我之前也问过网联,还没规划

Q19-2:还说2号令大修,马上要发布新的2号令,还没到网联,老师还在制定标准

那就等吧,2号令还是周小川签署的;我觉得周小川这个节骨眼不太会这么做。

Q19-3:但我没骗大家,我今天才打的电话,我比较信任他;这也解除了我们小支付机构的困扰,因为我直接问,现在这么搞,直接造成微信支付宝垄断,我们没有活路;说明他们还是在准备统一标准,按照银联收单方和发卡方来弄,也确实符合他们的思路。。

打好防范化解重大风险攻坚战,重点是防控金融风险,要服务于供给侧结构性改革这条主线,促进形成金融和实体经济、金融和房地产、金融体系内部的良性循环。中央经济工作会议的精神,但是存在小的支付公司跑路风险。支付公司注册资本很多很小,如果其中一家跑路了,互联互通的基础就打破了,会引发系统性风险的。除非备付金100%上收。

Q19-4:估计以后费率也会拆分,商户提供方和提供支付账户付款方;收支各自收费。。

A1:19大的主调就是扶持大的,中小的退出,或者做创新。

嗯,供给侧改革,现在支付公司太多了。人行之前也有想法合并到100家以内

A2:以上(19-1至19-3)消息我也是今天才知道,仅供大家参考了解。如果真的这么执行,这对互联网支付牌照应该算利好了;哪怕手续费大头支付宝微信拿走,作为收款方也能分到一点点,不至于做不了。

我觉得未来终端会是一块新的市场

Q19-5:估计以后费率也会拆分,商户提供方和提供支付账户付款方,这个就是受理方和支付账户持有方吧?

A1:恩,老师是这么跟我说的,参照银联的分配方式
A2:其实原来传统消费是以卡片为介质去占有了c,以后就是支付账户
A1:对
A2:银联是四方模式,网联是三方

也不能这么说,支付账户只能是一种补充,银行卡的体系还是非常重要的

Q19-6:不能否认卡存在的必要性,这是必要的底层

嗯。所以我觉得人行不会这么做,而且支付宝不是国企,过于庞大就不受掌控了

Q19-7:只是在移动互联网发展及移动支付背景下。发展成当前的模式了

嗯,所以恰逢其时进行了遏制

Q19-8:您是指保留支付宝的扫码转接,然后让网联再结算给支付宝的模式吗?上面的谈话是这个意思吗?

是的

Q19-9:本质上这个是「备付金到备付金」的模式,我认为会有

嗯,是的,从人行备付金管理办法也是一种冲击

Q19-10:只不过这个码不是支付宝的码,而是网联银联的码

我觉得不会,网联不负责商户入网。说白了网联又变成了通道。

Q19-11:所以2号令大修,是不是除了上次缴存比例外,还有其他

A1:网联只出标准,不是直接去铺受理方
A2:这点我没细问,但据说快发布了

即使改动我也觉得是从严

Q19-12:网联不是商户通道,受理商户是我们这样的小支付公司也可以参与,只要有互联网牌照;

A1:原来走支付宝扫码的,只从支付宝过。修改为网联标准,实际上就会并入网联,网联能看到所有的交易,之后再把这个结算资金给支付宝;所以296我认为真的是,重新给了第三方机会

网联这种属于大创新呢;同样的,风险也存在,信用机制的问题;小的支付机构存在重大隐患

Q19-13:但前提真的要按照人行老师说的实施,网联进度太慢,然后人行老师现在制度还没定

A1:网联就算出了,估计也不能在线下用,还是线上扫码;否则银联会叫的 也不符合线上线下分开的监管思路
A2:只要监管到位,我合规经营,不能我交易量小,就要把我掐死啊

Q19-14:小额支付一直是人行强调的

看网联设计,可能会调低授信额度;真要实现,不是那么简单,要通盘考虑的;嗯,这种有可能的;但是还是要看网联的进度,感觉网联这进度和你的预期有点距离

A1:恩,网联速度就不说了,一言难尽,之前协议支付我可以帮他们稍微分担点接入银行,现在的新接口,我已经对接完毕了,但我有心无力,说暂时还没支持我银行的验收标准。。。我猜测某大型机构没接入,没法出标准;我也希望网联的日程不要拖,6月底的大限很快就要到的;能尽早像文件要求的那样,其实对我们小支付公司也有好处的,就是通道不会朝不保夕了

Q19-15:铺条码需要有收单牌照吧?

嗯,需要有收单牌照


招聘

  • 今日头条老熊团队在招聘, 支付产品经理、研发工程师都需要,工作地点:北京、上海, 猛击这里查看
  • 有赞团队在招聘, 支付产品经理、架构师、研发工程师, 工作地点:北京、杭州, 猛击这里查看
  • 蚂蚁金服招聘互联网金融监管科技高级专家/资深专家(成都,北京), 猛击这里查看

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。