07月 5, 2013

最近有很多朋友在知乎上私信我询问有关支付系统账务功能实现方面的问题,但鉴于私信回复实在无法把实际问题进行很好的表述,所以我纠结了半天,还是决定在donews上单独开几篇博客,分享一下我的经验。整套博文将从业务和技术实现两个维度阐述当前主流支付系统假设过程中账务处理的方案,文中为方便理解将支付公司指定为支付宝,还请多多谅解。基本属于想到哪说到哪,如有谬误,还请各位专家多多指正。

直入正题,第三方支付从无到有发展到现在,其实就账务体系这块经历了三大阶段。

第一个阶段,我称为清算一体阶段。

早期支付公司的商户通过在线支付收取货款后,向支付公司发起结算时,支付公司根据数据库中交易流水关联的商户号查找到所有该商户的未结算资金明细,汇总无误后将资金结算给商户。这个过程中,支付公司将清分(clearing),结算(settlement)两个动作放到一个事物中先后进行。

在这里补充一个小知识点:所谓清分(Clearing)是清算过程中的数据准备阶段, 对支付公司而言,主要是将需要结算给商户的资金进行汇总,整理,分类;所谓结算(settlement)可以看做是完成交易双方价值转移的过程。

通俗一点说,有一大堆商户在淘宝开店,最后资金都落到了支付宝,他们都向支付宝发起提现要求。支付宝首先要算清楚扣除手续费后每个商户可以提现多少资金(清分),然后根据计算来的数据,把钱汇给这些商户(结算)。也就是说,清分就是算钱的过程,结算就是给钱的过程,不知这样说各位看官是否明白?

后来,随着支付公司商户的急剧增多以及交易量的暴涨,假如每次商户发起提现支付公司的清结算部门都一条一条数据汇总轧张后进行出款,不仅员工叫苦连天,效率也十分低下,服务很差。所以不知道哪个聪明人第一个想出来这个方案:针对每个商户开立一个虚拟账户,每次交易完成后咱们就在商户的账户上进行余额的加减,这样子每次商户发起提现时我们的清算人员只要看一眼商户的账户余额就可以进行出款,然后把商户的余额给调账就可以了。这个阶段我称之为虚拟账户阶段,顺带一提,据我所知目前仍然有很多支付公司的系统停留在这一阶段。

再后来,大家发现这种单式记账法进行记账,经常丢数据不说,追查起来还难得一比。于是又有高人将银行金融体系的基于系统科目的记账方案搬了出来,由此进入当前阶段:基于会计核算体系的账务阶段,这几篇博文的重点也是讲这个阶段。

聊完了这三个阶段,相信大家对支付系统账务模块的历史演变,应该有了一个相对清晰的认识,那么在说正题之前,我们先简单了解一些基本的财务知识。这些知识不一定会帮助你飞黄腾达,但如果想深耕支付系统的建设,最好还是掌握这些知识。以下只是我的抛砖引玉,希望通过了解这些内容读者可以没有障碍地读更后续的内容。

首先是一些术语:

会计科目:会计科目是指对各项会计要素按其反应的经济内容和管理要求不同所进行科学分类的项目。

不掉书袋的说法,会计科目就是记账的基础,所有的“帐”其实都是会计科目余额的一种展现。

会计科目通常会分为很多类,假设我们现在只建设最简单的支付系统,那么至少我们需要熟知以下三个科目大类:

资产类科目:通常余额反映在借方,银行存款、固定资产等通常记录在资产类科目下。

负债类科目:通常余额反映在贷方,客户负债,应付款等通常记录在负债类科目下。

共同类科目:根据实际业务不同,具体的科目余额既可以反映在借方也可以在贷方,通常来说待清算款项会记录在共同类科目中。

为了让会计科目既反映总体核算数据,又体现细节核算数据,所以一般会分层次设置。例如在资产类科目下,我们设立一个一级科目叫做银行存款(科目号110),在银行存款科目下设置二级科目叫做工商银行存款(科目号110 01),在工商银行存款科目下设置三级科目叫做工商银行XX支行银行账户(科目号为11001 01)。大家注意看括弧里的黑体字,下级科目号=上级科目号+自己本身独立分配的科目号,这样就能很轻松地通过一个下级科目号推断出其上级科目。

另外顺带一提,假如一个会计科目不存在子科目,那么我们就认为其是底层科目,所有反应实际业务活动的账务必须记录在底层科目中。

资金平衡关系:

学过会计恒等式的同学都知道,资产=负债+所有者权益。对我们上述假定的支付系统而言,由于没有所有者权益,所以恒等式变更为资产+共同类借方余额=负债+共同类贷方余额。整体而言,无论什么业务状况下,我们必须保证系统内所有借方余额正好等于贷方余额,否则系统可以判定为有BUG。

记账规则:

既然设置了科目用来进行账务的记录,那么接下来咱们就必须明确在不同业务活动中我们如何记账。

在会计学中,我们至少用一组会计分录来进行账务变动的记录(因为要保持账务的平衡,有借必有贷,借贷必相等)。

例如:

有个支付宝用户通过网银向自己的支付宝账户充值100元,交易完成后支付宝内部账务可能会这样记录(以一级科目为例):

借:401 待清算充值款  100元

贷:201 客户负债账户  100元

tips:由于网银收单获取的资金,银行通常是T+1日结算给支付宝,所以这笔钱还没落地到支付宝的银行账户,故记录在待清算充值科目中。

日终时,银行发来对账文件,确认该笔交易,对账成功,支付宝系统会进行以下记账:

借:110 银行存款  100元

贷:401 待清算充值款 100元

大家可以看到,支付宝系统在确认对账成功,银行资金入账后,将原本的待清算账户中借方的100元挪动到了银行存款中。

在实际业务过程中,记账的规则不会如此简单,会在一个业务过程中同时发生好几笔会计分录变动,例如:

用户小明(系统代号001)向商户小红(系统代号002)购买商品,使用支付宝账户支付,价格100元,支付宝向小红收取手续费1元。交易完成后支付宝会进行如下记账:

借:201 001 小明支付宝账户  100元

贷:201 002 小红支付宝账户 100元

借:201 002 小红支付宝账户 1元

贷:401 001 支付宝收益账户 1元

这组记账,对支付系统来说,是一个不可分割的事物。要不然同时成功,要不然同时失败,绝对不会出现前一组分录记账成功,后一组失败的情况。那么这样的针对具体业务情况的记账逻辑,我们就称之为记账规则。

今天暂时分享到此,等有空了再更新。

05月 11, 2013

如果记得没错,第一次听说阿里有意入股新浪微博,应当是在12年的10至11月间,当时坊间传得沸沸扬扬,后来压了下去,官方有出面回应,答复很暧昧,没有说成也没有说不成。当时我就想写一篇文章聊聊这个事情,但每次都是写一开头,又匆匆擦掉,未能成文,原因有二:

一、市面上关于此事的相关评论已经十分多,许多分析也相当靠谱,没必要重新发明轮子。

二、对于微博这个产品以及她的管理团队,我一直拿捏不准他们的想法和思路,收购这事没敲定前,我姑且认为他们还有什么大动作没做,不敢随便乱说。诚然,今日新浪微博发展到这般地步,有功有过。在产品及用户运营层面,早期的新浪微博无疑是非常出色的,但在商业化进程中,新浪微博又相当步履蹒跚。

新浪老板曹国伟曾经在多个场合表达过所谓微博货币化的概念和想法,我们也看到新浪的确做了很多动作。从新浪旗下支付公司新付通到开放新浪会员收费服务,从小米2新浪售罄到Smart开卖,新浪一直在进行商业模式的探索和尝试。然而一直到目前为止,无论是广告、平台还是电商,都没有办法给新浪带来可观的收入以及利润,连续的亏损也让市场渐渐冷静下来——新浪股价从2011年147美元的最高点一直滑落到如今50到60美元之间。股价造成如此波动,其中有微信的一份功劳,但与其说是微信抢占了微博的市场,还不如说微信的崛起戳破了微博的泡沫。

插句题外话,无论如何,我一直坚持认为,微信从来不是一个具有优良商业模式基因的产品。即便是在张小龙如日中天,被奉为神明的那段日子里,我依然顶着产品同僚们的嗤之以鼻,在商业模式上看衰微信。不可否认微信团队有情怀,有品位,有思想,但微信本身绝对不是一款值得腾讯投入如此多资源进行商业探索的产品。现在互联网上充斥着所谓“流量变现”、“用户变现”的理论,从诸位专家及评论员眼睛里看过去,一款产品或应用只要用户沟通,流量充沛,即便内容鸟不拉屎也一样可以创造出商业模式。我在此只能呵呵两声,建议专家一个用户100美元的价格收购墨迹天气。从去年下半年开始,微信团队在几大城市地推餐饮行业的“二维码优惠”以及微信企业账号服务,效果如何各位看官自己评价,反正就我身边的情况看来,微信的O2O活动仿佛一阵风吹过,现在大家再也想不起使用它打折了。

微信的看法点到为止,毕竟唱戏的主角是阿里和微博。在2011年FaceBook高调无比进行IPO准备的同时,几乎所有的投资人都在唱多新浪微博,在当时看来这个抄袭Twitter并成功获取2亿注册用户的产品,实在太值得投资了。按照业界流传的FB估值方式,彼时的新浪微博就已经市值200亿美元(一个用户值100美元的算法我姑且保留意见,脱离整体业务模式和市盈率去衡量企业价值是有违常理的,即便对象是FB),最重要的是,这个庞然大物丝毫没有用户增速放缓的迹象,这实在是太酷了。总之,新浪吸引到了足够的目光,从股市里也获取了足够多的资金支持。2011年,新浪微博的管理者们,脑子里第一思考的估计还是如何运营用户、留住用户以及增长用户,但问题很快来了。

从公开获取的数据来看,新浪在2012年前,已经在微博这个产品上投入了接近2个亿,再加上2012年曹国伟公开的1.6亿投入,新浪微博已经大约花去了3.6个亿,而带来的回报是2012年全年营收6600万美元。这个数据实在是谈不上光彩,大洋彼岸的Twitter时不时传出“收支平衡,或已盈利”的传闻相信也让微博人苦恼不已。无论如何,新浪微博从2011年开始大力推动商业化进程,除老本行广告业务外,电商和应用平台也风风火火进行开展,却始终没有能够让应收跟上用户增长的节奏。就现在来看,尽管微博的想象空间非常大,但所谓“商业闭环”,所谓“货币化”进程,都只是浅尝辄止,未能真正形成稳定有效的可持续商业模式,这时的新浪微博,既需要钱,更需要一个实现断奶,甚至实现盈利的出路,电商资源丰富,坐拥大量产业布局的阿里无疑是一个很好的合作对象。

再看阿里,最近几年没有停止过各大产业的布局。电子商务,云服务,支付结算,金融,投资,IT服务,广告营销,域名服务……等等等等,阿里从来没停止过产业扩张的步伐。但只有一件事情,阿里一直做得不够好,那便是用户关系以及媒体平台。淘江湖的失败估计让阿里的高层更加狠下决心在这块集中发力,这才有促成了与新浪微博的合作。

通过阿里的入驻,新浪可以直接摒弃一些不成熟的业务和部门(支付,电子商务),间接拥有中国最大的电子商务资源(理论上所有的阿里商户都可以在新浪平台上进行营销推广及广告投放),获取到足量的运营资金支持,最最重要的是得到了一个举足轻重的阵营盟友。

通过对新浪的投资和合作,阿里可以接触到基于用户关系的海量数据模型,直接为其集团板块下所有的企业带来媒体营销平台,获得中国互联网行业最大的用户入口之一,节省了此方面的投入。

四个字,各取所需。

新浪微博未来的想象空间是巨大的,它完全有可能达到如今腾讯的高度,建立起一个微博帝国。在这之前,让我们拭目以待,看看这次的强强联手,能给中国的互联网行业带来什么。

以上文章均为作者原创,仅在DoNews发表。

本人擅长胡诌,文章谬误颇多,为保声誉,拒绝转载。不识抬举,请媒体朋友海涵。

03月 6, 2013

最近几年,在电商、互联网相关的行业圈子里,有一个词非常热,那就是“第三方支付”。这个词热到什么程度?热到很多不涉及我们行业的朋友,见到我开口就问:你们公司拿到支付牌照没?

关于第三方支付,我在知乎回答了一些,但最近由于对知乎的小小失望,决定暂时不在那边码字了。但平时写惯的人,一下子停了又不习惯。恰逢不少朋友仍然在知乎上向我提问关于第三方支付的问题,那我干脆借Donews宝地,一点一点分享我对于这个行业的认识和看法。文中涉及的具体公司和业务情况,均为我自己的认知,如果有错误还请各位看官提醒指点。

首先,不管大家知不知道,反正我一定要强调一下:何为第三方支付?

为什么我要强调这个问题呢?因为即便在知乎这个相对“高质量用户”的地方,我仍然经常见到诸如“为什么京东不建立自己的第三方支付”、“第三方支付会成为银行吗”此类问题,因此我觉得,在谈历史、谈现状、谈发展之前,至关重要的一点,是先把第三方支付的本质搞清楚。

第三方支付,往大白话里说,主营业务就是代收,代付,所有第三方支付业务都是在这个基础上进行的。A要给B钱,C帮A收了钱,再付给B99%的款项,收1%手续费,这就是最简单的第三方支付业务。
第三方支付公司只开手续费对应的发票,销项税的基数也是以此为准。

在这个过程中大家可以观察到,实际上A和B的经营活动,C一点都不参与,C在这个业务过程中是完全独立的个体,是真正意义上的第三方。C的盈利点在于手续费之间的差价,至于B卖了什么给A,B赚了A多少钱,C一概不关心。

以上是对于第三方支付的基本概念,所有市面上的第三方支付企业,最最基础的实体业务都是代收代付。在这个代收代付业务的基础上,最近几年各支付企业也进行了功能上的改进和创新。例如基于电商诚信需求的“担保交易”、利益实时分配的“分账产品”、为运营进行支撑服务的“会员账户产品”等等等等……

讲完了第三方支付的基本业务,我们来看看目前市场上,第三方支付有哪些山头,分别是如何运作的。

首先当仁不让的肯定是最有名的线上支付老大支付宝为首的电子商务派系,同派系的的有腾讯的财付通,盛大旗下的盛付通等。之前我看网上有前辈将他们分得更细,什么电商派系,游戏派系,互联网派系(当时网易、百度和新浪搞支付也闹得沸沸扬扬,至今仍然在全力支持的并不多),我觉得没有太大必要。这类支付公司的特点很鲜明:在做第三方支付之前,其母公司或者关联公司就已经有庞大的线上支付需求,仅仅为承载其业务,就已经有相对庞大的支付结算部门进行日常运营,久而久之,自然而然发展成为第三方支付。

这类支付公司的优势和劣势都非常明显,优势在于获取线上用户的相对低成本(淘宝和支付宝用户几乎就完全重叠了),拥有大量用户运营经验,技术实力强大,创新性强。劣势的话,早期合适人才相对稀缺(当然用钱就填平了),线下业务开展相对乏力(游戏公司略好一些,因为有积累点卡渠道),企业发展过块,产品线铺得过多,导致内部资源争抢以及效率的折损(互联网公司发展到后期的通病)。

第二大山头是我很敬佩的一类企业,我管他们叫做独立第三方支付公司。这类公司的代表当然就是业界大名鼎鼎的快钱、汇付天下这两家。在之前几年的产品化过程中,快钱、支付宝、汇付天下是被抄袭得最多的企业。支付宝被抄袭,因为他站在电子商务的最前沿,有不得不去优化和解决的电商需求;而那两家公司,后面没有关联的贸易公司给交易量撑腰,前面要面对其他支付公司的竞争,可谓夹缝中求生存,不得不去迎合市场做产品创新。航空业务出票窗产品、机票保理业务、特定行业现金管理解决方案等等,我在初入行业的那段时间,向这两家公司,尤其是快钱学了不少。这类公司的优势是人才,尤其是高端人才较多,从业人员经验丰富(不管你承认不承认……反正快钱是我见过的向外输送人才最多的公司了),研发能力较强,团队效率较高。劣势当然也很明显:没有自有业务撑腰,C端用户获取困难。

第三类是过去十几年沉淀下来的预付卡公司,其实游戏点卡也可以算是一种预付卡。这类公司通常都有很强的地域性,预付卡公司在牌照出来前,可是非常能挣钱的。预存款资金沉淀、废卡残值,预付卡公司只要规模做起来,利润都是杠杠的。既然国家要对通用性预付卡公司进行管理,一并算进支付牌照,那么这类公司也变成了第三方支付公司中的一股势力。

第四类,是过去主营线下业务的支付公司,也就是POS业务。这类公司多半和银联、银行有较深的背景关系,同时也和预付卡公司进行业务合作,形成预付卡POS收单的清分网络。最具代表性的自然就是银联商务。

其实经过2010年到2011年的牌照申请,大多数支付公司都开始渐渐丰富自己的产品线,许多互联网支付公司也开始做起了预付卡和POS(像快钱这类公司产品线非常丰富,基本上要什么有什么),而据我所知很多原本一心做POS和预付卡的公司也开始整合自己的互联网支付渠道产品。这是一个好现象,有竞争才有发展。

今天就先扯到这里。

11月 29, 2012

本文源自我在知乎上的一个回答,最近在微博上被分享了好多次,就贴在这儿分享给大家。

为了可以更好地解释支付结算系统对账过程,我们先把业务从头到尾串起来描述一下场景,帮助大家理解:
一个可能得不能再可能的场景,请大家深刻理解里面每个角色做了什么,获取了哪些信息:
某日阳光灿烂,支付宝用户小明在淘宝上看中了暖脚器一只,价格100元。犹豫再三后小明使用支付宝网银完成了支付,支付宝显示支付成功,淘宝卖家通知他已发货,最近几日注意查收。

我们来看看这个过程中有几个相关方,分别做了什么。我语文不好,写得饶口,如果看不懂请多看几次:
小明:持卡人,消费者,淘宝和支付宝的注册会员,完成了支付动作,自己的银行账户资金减少,交易成功。
银行:收单银行,接受来自支付宝的名为“支付宝BBB”的100元订单,并引导持卡人小明支付成功,扣除小明银行卡账户余额后返回给支付宝成功通知,并告诉支付宝这笔交易在银行流水号为“银行CCC”
支付宝:支付公司,接收到淘宝发来的订单号为“淘宝AAA”的商户订单号,并形成支付系统唯一流水号:“支付宝BBB”发往银行系统。然后获得银行回复的支付成功信息,顺带银行流水号“银行CCC”
淘宝:我们支付公司称淘宝这类电商为商户,是支付系统的客户。淘宝向支付系统发送了一笔交易收单请求,金额为100,订单号为:“淘宝AAA”,支付系统最后反馈给淘宝这笔支付流水号为“支付BBB”

以上流程貌似大家都达到了预期效果,但实际上仍然还有一个问题:
对支付公司(支付宝)而言,虽然银行通知了它支付成功,但资金实际还要T+1后结算到它银行账户,所以目前只是一个信息流,资金流还没过来。

Tips:插一句话,对支付系统内部账务来说,由于资金没有能够实时到账,所以此时小明的这笔100元交易资金并没有直接记入到系统资产类科目下的“银行存款”科目中,而是挂在“应收账款”或者“待清算科目”中。大白话就是,这100元虽然答应给我了,我也记下来了,但还没收到,我挂在那里。

对商户(淘宝)而言,虽然支付公司通知了它支付成功,他也发货了,但资金按照合同也是T+1到账。如果不对账确认一下,恐怕也会不安。

倒是对消费者(小明)而言:反正钱付了,你们也显示成功了,等暖脚器呀等暖脚器~

基于支付公司和商户的困惑,我们的支付结算系统需要进行两件事情:一是资金渠道对账,通称对银行帐;二是商户对账,俗称对客户帐。对客户帐又分为对公客户和对私客户,通常对公客户会对对账文件格式、对账周期、系统对接方案有特殊需求,而对私客户也就是我们一般的消费者只需要可以后台查询交易记录和支付历史流水就可以了。
我们先聊银行资金渠道对账,由于支付公司的资金真正落地在商业银行,所以资金渠道的对账显得尤为重要。
在一个银行会计日结束后,银行系统会先进行自己内部扎帐,完成无误后进行数据的清分和资金的结算,将支付公司当日应入账的资金结算到支付公司账户中。于此同时,目前多数银行已经支持直接系统对接的方式发送对账文件。
于是,在某日临晨4点,支付宝系统收到来自银行发来的前一会计日对账文件。根据数据格式解析正确后和前日支付宝的所有交易数据进行匹配,理想情况是一一匹配成功无误,然后将这些交易的对账状态勾对为“已对账”。

Tips:此时,对账完成的交易,会将该笔资金从“应收账款”或者“待清算账款”科目中移动到“银行存款”科目中,以示该交易真正资金到账。

以上太理想了,都那么理想就不要对账了。所以通常都会出一些差错,那么我总结了一下常见的差错情况:
1.支付时提交到银行后没有反馈,但对账时该交易状态为支付成功
这种情况很正常,因为我们在信息传输过程中,难免会出现掉包和信息不通畅。消费者在银行端完成了支付行为,银行的通知信息却被堵塞了,如此支付公司也不知道结果,商户也不知道结果。如果信息一直没法通知到支付公司这边,那么这条支付结果就只能在日终对账文件中体现了。这时支付公司系统需要对这笔交易进行补单操作,将交易置为成功并完成记账规则,有必要还要通知到商户。

此时的小明:估计急的跳起来了……付了钱怎么不给说支付成功呢!坑爹!

TIPS:通常银行系统会开放一个支付结果查询接口。支付公司会对提交到银行但没有回复结果的交易进行间隔查询,以确保支付结果信息的实时传达。所以以上情况出现的概率已经很少了。

2.我方支付系统记录银行反馈支付成功,金额为100,银行对账金额不为100
这种情况已经不太常见了,差错不管是长款和短款都不是我们想要的结果。通常双方系统通讯都是可作为纠纷凭证的,如果银行在支付结果返回时确认是100元,对账时金额不一致,可以要求银行进行协调处理。而这笔账在支付系统中通常也会做对应的挂账处理,直到纠纷解决。

3.我方支付系统记录银行反馈支付成功,但对账文件中压根不存在
这种情况也经常见到,因为跨交易会计日的系统时间不同,所以会出现我们认为交易是23点59分完成的,银行认为是第二天凌晨0点1分完成。对于这种情况我们通常会继续挂账,直到再下一日的对账文件送达后进行对账匹配。
如果这笔交易一直没有找到,那么就和第二种情况一样,是一种短款,需要和银行追究。

以上情况针对的是一家银行资金渠道所作的流程,实际情况中,支付公司会在不同银行开立不同银行账户,用以收单结算(成本会降低),所以真实情况极有可能是:
临晨1点,工行对账文件丢过来(支行A)
临晨1点01分,工行又丢一个文件过来(支行B)
临晨1点15分,农行对账文件丢过来
。 。 。
临晨5点,兴业银行文件丢过来
。。。
不管什么时候,中国银行都必须通过我方业务员下载对账文件再上传的方式进行对账,所以系统接收到中行文件一般都是早上9点05分……

对系统来说,每天都要处理大量并发的对账数据,如果在交易高峰时段进行,会引起客户交互的延迟和交易的失败,这是万万行不得的

所以通常支付公司不会用那么傻的方式处理数据,而是在一个会计日结束后,通常也是临晨时段,将前一日交易增量备份到专用对账服务器中,在物理隔绝环境下进行统一的对账行为,杜绝硬件资源的抢占。

以上是银行资金渠道入款的对账,出款基本原理一致,不过出款渠道在实际业务过程中还有一些特别之处,由于大家不是要建设系统,我就不赘述了。

谈完了资金渠道的对账,我们再来看看对客户帐。

前面提到了,由于资金落在银行,所以对支付公司来说,对银行帐非常重要。那么同理,由于资金落在支付公司,所以对商户来说,对支付公司账也一样重要。能否提供高品质甚至定制化的服务,是目前支付公司走差异化路线的一个主要竞争点。
就流程而言@詹世波已经说的差不多了,我就不赘述了……

—————————————————没经过排版的小知识点——————————————–
之前说过,银行与支付公司之间的通讯都是可以作为纠纷凭证的。原理是对支付报文的关键信息进行密钥加签+md5处理,以确保往来报文“不可篡改,不可抵赖”。
同理,支付公司和商户之间也会有类似机制保证报文的可追溯性,由此我们可以知道,一旦我方支付系统通知商户支付结果,那么我们就要为此承担责任。由此我们再推断一个结论:
即便某支付订单银行方面出错导致资金未能到账,一旦我们支付系统通知商户该笔交易成功,那么根据协议该结算的资金还是要结算给这个商户。自然,我们回去追究银行的问题,把账款追回。
—————————————————没经过排版的小知识点——————————————–

一、对支付系统而言,最基本的对账功能是供商户在其后台查询下载某一时间段内的支付数据文件,以供商户自己进行对账。
这个功能应该是个支付公司就有,如果没有就别混了。
二、对大多数支付系统而言,目前已经可以做到对账文件的主动投送功能。
这个功能方便了商户系统和支付系统的对接,商户的结算人员无须登录支付平台后台下载文件进行对账,省去了人工操作的麻烦和风险。

对大型支付系统而言,商户如果跨时间区域很大,反复查询该区域内的数据并下载,会对服务器造成比较大的压力。各位看官别笑,觉得查个数据怎么就有压力了。实际上为了这个查询,我最早就职的一家支付公司重新优化了所有SQL语句,并且因为查询压力过大服务器瘫痪过好几次。
现在比较主流的做法是把商户短期内查询过、或者经常要查询的数据做缓存。实在不行就干脆实时备份,两分钟同步一次数据到专用数据库供商户查询,以避免硬件资源占用。甚至……大多数支付公司都会对查询范围跨度和历史事件进行限制,比如最多只能查一个月跨度内,不超过24个月前的数据……以避免服务嗝屁。

对账这块大致就这样了,再往细的说就说不完了,大家有什么想问的可以单M我或者回复答案。
稍后给大家讲一下风控。
———————————————–风控的分割线——————————————-
风险控制,在各行各业都尤其重要。
金融即风险,控制好风险,才有利润。
虽然第三方支付严格意义上说并非属于金融行业,但由于涉及资金的清分和结算,业务主体又是资金的收付,所以风险控制一样非常重要。

对支付公司来说,风控主要分为合规政策风控以及交易风控两种。
前者主要针对特定业务开展,特定产品形态进行法规层面的风险规避,通常由公司法务和风控部门一起合作进行。例如,一家公司要开展第三方支付业务,现在要获得由人民银行颁发的“支付业务许可证”。遵守中国对于金融管制的所有条规,帮助人行监控洗钱行为……这些法规合规风险,虽然条条框框,甚至显得文绉绉,但如果没人解读没人公关,业务都会无法开展。
当然,这块也不是本题所关注的重点,提问者关注的,应当是业务进行过程中的交易风控环节。

现在随着各支付公司风险控制意识的加强,风控系统渐渐被重视起来。除了上述提到的合规风控相关功能,风控系统最讲技术含量,最讲业务水平,最考究数据分析的业务就是交易风控环节。

对一笔支付交易而言,在它发生之前、发生过程中及发生过程后,都会被风控系统严密监控,以确保支付及客户资产安全。而所有的所有秘密,都归结到一个词头上:规则。风控系统是一系列规则的集合,任何再智能的风控方案,都绕不开规则二字。

我们先看看,哪些情况是交易风控需要监控处理的:
1.钓鱼网站
什么是钓鱼呢?
用我的说法,就是利用技术手段蒙蔽消费者,当消费者想付款给A的时候,替换掉A的支付页面,将钱付给B,以达成非法占用资金的目的。
还有更低级的,直接就是发小广告,里面带一个类似http://tiaobao.com的网址,打开后和淘宝页面一摸一样,上当客户直接付款给假冒网站主。

第一种情况风控系统是可以通过规则进行简单判定的,虽然有误杀,但不会多。
通常使用的规则是判断提交订单的IP地址和银行实际支付完成的IP地址是否一致,如果不一致,则判断为钓鱼网站风险交易,进入待确认订单。

但第二种情况,亲爹亲娘了,支付公司真的没办法。当然遇到客户投诉后可能会事后补救,但交易是无法阻止了。

2.盗卡组织利用盗卡进行交易
大家都知道,信用卡信息是不能随便公布给别人的,国内大多信用卡虽然都设置了密码,但银行仍然会开放无磁无密支付接口给到商户进行快速支付之用。
所谓无磁无密,就是不需要磁道信息,不需要密码就可以进行支付的通道。只需要获取到客户的CVV,有效期,卡号三个核心信息,而这三个信息是在卡上直接有的,所以大家不要随便把卡交给别人哦~

碰到类似的这种交易,风控系统就不会像钓鱼网站这样简单判断了。
过去我们所有的历史交易,都会存库,不仅会存支付相关信息,更会利用网页上的控件(对,恶心的activex或者目前用的比较多的flash控件)抓取支付者的硬件信息,存储在数据库中。
当一笔交易信息带着能够搜集到的硬件信息一同提交给风控系统时,风控系统会进行多种规则判定。
例如:当天该卡是否交易超过3次
当天该IP是否交易超过3次
该主机CPU的序列号是否在黑名单之列

等等等等,一批规则跑完后,风控系统会给该交易进行加权评分,标示其风险系数,然后根据评分给出处理结果。

通过硬件信息采集以及历史交易记录回溯,我们可以建立很多交易风控规则来进行监控。所以规则样式的好坏,规则系数的调整,就是非常重要的用以区别风控系统档次高低的标准。

例如,我听说著名的风控厂商RED,有一个“神经网络”机制,灰常牛逼。
其中有一个规则我到现在还记忆犹新:
某人早上八点在加利福尼亚进行了信用卡支付,到了下午一点,他在东亚某小国家发起了信用卡支付申请。系统判断两者距离过长,不是短短5小时内能够到达的,故判定交易无效,支付请求拒绝。

规则非常重要,当然,数据也一样重要。我们不仅需要从自己的历史记录中整合数据,同时还要联合卡组织、银行、风控机构,购买他们的数据和风控服务用来增加自己的风控实力。

SO,风控是一个不断积累数据、分析数据、运营数据、积累数据的循环过程。

好的风控规则和参数,需要经过无数次的规则修改和调整,是一个漫长的过程。
不知道大家做互联网,有没有利用GA做过AB测试,同样的,风控系统也需要反复地做类似AB测试的实验,以保证理论和实际的匹配。

最后给大家说一个小小的概念:
所谓风控,是指风险控制,不是风险杜绝。
风控的目标一定不是把所有风险全部杜绝。
合理的风控,目标一定是:利润最大化,而不是风险最小化
过于严格的风控规则,反而会伤害公司利益(看看销售和风控经常打架就知道了)

不光是交易的风控,我们日常制定规则,法规,公司流程,也一定要秉着这个出发点进行规划。

11月 13, 2012

文/DoNews新锐作者 天顺

所谓架构,在业务层面看来,无非就是归类、整合、统一、灵活运用。

从技术上对应,就是面向对象的继承、封装、多态。

面向对象的思想从来就不是一种软件开发思想,他完全可以用来指导我们在生活中思考问题的方式。

就好比我们的支付系统,每天会有各式各样不同银行渠道处理的交易,有各式各样商户的订单,有各式各样的异常,如果我们每个银行渠道、每个商户、每个异常都单独处理,那排列组合下来,这个数字太吓人了。

产品经理要做的是,把这些业务元素,归集,统一。

好比商户提交的订单信息,无非就是包含了订单号、订单金额、时间、订单备注、需要支付的银行、手续费由谁支付、交易状态等等信息,我们把这些信息整合,明确必填项和非必填项,统一称为订单。(架构师会建立模型,在代码层面应当就有一个类,这些元素就是类的属性)

那么订单他会遇到交易失败,申请退款等各种业务逻辑,这些逻辑由产品经理明确,由架构师将其整合,在类中增加了它对应的方法。

对于某些特殊订单,他既有普通订单的特性,又有自己独特的业务逻辑,那么产品经理会把共性和特性描述清楚,架构师会做继承。

总而言之,产品经理并不是一个将技术实现方案告知研发工程师的职位。实际上产品经理并不对产品的技术实现架构负责。产品经理只要能把业务逻辑描述清楚,告知技术,双方无歧义即可。

有架构设计能力的产品经理固然好,但这个能力实际上并非必须,甚至有时候还添乱(专业的人做专业的事情)。

过于专注如何交付技术的同学,实际上还是产品设计者,并不是统筹产品的人。

当你开始考虑你产品未来的走向,开始考虑盈利模式,开始思考竞争对手的策略时,你才算开始对自己的产品进行管理。

最后:好的架构师很重要。

======带个自私自利的小AD=========

只需你花一分钟,让业界听到你回声。如果你有更加丰满、独特的个性化点评视角,欢迎奔跑加入iDoNews点评团,私信@沸话小欧 即可。

转载请注明 DoNews新锐作者/天顺

Tags: ,,.

Welcome to DoNews Blog. This is your first post. Edit or delete it, then start blogging!