美文网首页互联网金融产品优质文章精选学点金融产品经理感悟
互联网金融平台知识介绍2::充值相关知识介绍

互联网金融平台知识介绍2::充值相关知识介绍

作者: 复盘随记 | 来源:发表于2015-10-11 23:20 被阅读847次

    互联网金融平台知识介绍文章列表http://www.jianshu.com/p/8443e4c53f37

    写在前面

    本人供职于互联网金融公司,将写一系列文章介绍互联网金融公司互联网端的产品、运营工作,本文是该系列中的一篇。此系列文章的目标是读者可复制、可执行,内容只有干货和细节,没有鸡汤和大道理


    互联网金融平台最看中的用户的magic monent是投资。充值作为投资的起点,其重要性不言而喻。
    本文将从充值的逻辑出发,全面介绍充值的产品流程和运营重点。(篇幅有限,暂不包含前端UI UE 部分)
    以下内容通用于电子商务等需要付款的产品。

    本文结构

    • 什么是充值
    • 如何选择付款方式
    • 如何选择第三方支付
    • 简化的充值流程
    • 第三方支付的特点
    • 产品经理的工作内容
    • 运营人员的工作内容
    • 数据统计及用途
    • 第三方支付常见问题、原因、解决办法
    • 提高体验
    • 充值管理后台的架构

    什么是充值


    简单来说,充值就是

    • 钱从用户的银行账户上转移到平台的银行账户上
    • 同时用户在平台的余额增加

    这就对平台提出了两项基本要求

    • 提供用户可用的付款方式
    • 用户付款后平台上的余额要尽快增加

    如何选择付款方式


    常见可用的付款方式有转账、pos刷卡、付现金、网关支付、快捷支付、代扣。每种都有自己的使用场景。

    我们如何从中选择呢?这要看我们的产品处于什么阶段。不同阶段有不同的打法。

    如果我们处于初创期,我们采取最简单、成本最小但满足用户最多的方式,让产品快速上线;如果在成熟期,我们增加不常用但是满足高端用户、意见领袖用户个性化需求的方式,扩大口碑。

    • 线上付款:网关支付、快捷支付。****对于互联网金融用户,用户充值的特点是高频、随时随地****,支付过程简单快速、支持移动端的快捷支付最适合不过,属于必须要支持的支付方式。但它的缺点是通常手续费较高和充值限额较小。网关支付的手续费通常较低,充值几乎没有限额。
    • 线下付款:转账、pos刷卡、付现金。都需要专门的财务人员手动处理订单,效率低下,而且增加了对账的复杂度,任何互联网金融平台都不必支持。虽然有人会说,还是存在用户比如老年人只会用线下方式付款,可是这样的用户数量太少了,而且他们是你的目标用户吗,他们会使用互联网进行投资吗?所以,不予考虑。
    • 其他:代扣。需要用户去银行签约,比较麻烦,用户太少,不予考虑。

    如果只有移动端,快捷支付必须上。如果PC端和移动端都有,哪种支付方式成本(手续费成本、开发成本)低并且可以快速上线,前期就上哪种支付方式,后期肯定都要支持。

    如何选择第三方支付


    确定付款方式为网关支付、快捷支付后,我们需要找到第三方支付合作,通过第三方支付完成支付。

    为什么不直连银行呢?因为你没有资历、没有背景、没有交易量,银行几乎不会和你合作,合作的话,手续费也会很高;常见银行十几家,一家银行一家银行洽谈的时间成本也无法承受;即使都谈成了,后续的技术开发成本、运行维护成本也非常高。

    而第三方支付作为独立于付款方和收款方的机构,专门为解决这类问题而生---只要和他们完成商务和技术对接,一次性就可以支持很多银行的充值了。

    市面上的第三方支付有上百家,该如何选择呢?判断一家第三方支付是否可以合作,可以从以下几个维度进行评估。


    第三方支付
    • 手续费。如果用户的充值手续费是平台垫付,则手续费是首要考虑的因素。用户充值10万元,有的第三方支付收取500元手续费,有的只收取N元,差别巨大。即使是用户自付手续费的平台,较低的手续费也是良好用户体验的一部分。(出于商业原因N值已经隐去)
    • 品牌形象。和支付宝、财付通、快钱这种大品牌取得合作,本身也是一种信用背书。对于理财平台,任何可以增信的信用背书都是多多益善。
    • 合作银行。第三方支付支持的银行越多,用户充值时可选择的余地就越大。
    • 充值限额。对于互联网金融来说,用户充值的特点是高频大额,如果一个第三方支付能给你的限额是单个用户每天最多5000元,该支付肯定是无法使用的。
    • 充值流程。一定要问清第三方支付的充值流程,是否满足你们的产品需求。比如,平台的方案是用户输入自己在平台设置的支付密码后,就可以充值成功,但是你洽谈的第三方支付要求必须输入他们向用户发送的短信验证码,才能充值成功。双方就有必要继续向下谈了。
    • 安全性。现在安全事故频发,第三支付在数据传输、保存上的加密方案是否足够有效也是需要考量的。最好对方采用几乎无法破解的非对称加密对数据进行加密。如果加密方式安全级别不够,比如还在使用md5加密,平台和第三方支付传输数据的链接可能会被黑客破解,黑客就可以伪造自己账号充值成功的数据包发送给平台,黑客的账号的余额就会增加,然后黑客立刻提现,则平台就会遭受损失。可见安全性不够,资金风险有多大。如果第三方支付安全性不够,必须要一票否决掉。
    • 稳定性。外部合作的通病就是对方随时随地就可能出问题影响自己的业务,几乎不给你调整准备的时间。所以,平台必须对对方的充值成功率和接口的响应时间做出要求。
    • 售后服务。自己是否可以成为对方的KA?第三方支付出问题的概率非常大,如果出了问题,对方是否有专员给予解决,响应能否及时?这些都应该提前了解清楚。经验来看,通常大的支付出问题少,出问题后解决问题慢;小支付出问题多,解决快。
    • 其他。还需要考虑财务提现到帐时间、提现手续费、是否支持子账户管理及子账户的权限分配这样的小问题。

    大家可以综合以上关键点,就可以找到满足自己需求的第三方支付。
    ps:平台可以和8家第三方支付签约,技术对接5家,实际使用3家。保持两三家作为备胎

    简化的充值流程


    和第三方支付合作后的简化充值流程如下,实际的流程要比这复杂。


    充值流程
    1. 用户发起充值,生成一笔充值订单,订单信息至少包含(user_id,order_id, money_amount, status )。
    2. 平台将(platform_id, order_id, money_amount)发送给第三方支付,进入第三方支付充值流程。
    3. 用户在前端使用第三方支付进行充值。用户使用网关支付和快捷支付的充值操作过程可以参考支付宝使用网银充值和快捷充值。此时第三方支付可能直连用户使用的银行,也可以和其他第三方支付合作,间接连接用户使用的银行。
    4. 第三支付返回给平台order_id对应订单的充值结果。
    5. 平台更新order_id对应订单的status,若充值成功则增加用户余额。

    流程中,平台可控的是向第三方支付发送充值请求和接受充值结果。而用户走第三方支付的充值流程,则几不可控。不可控的部分也是问题最常发生的地方

    第三方支付的特点


    第三方合作共有的特点是不可控,支付特有的特点是资金流转的流程和限制。两者结合,构成了第三方支付的特点。

    依靠对这些特点的了解和分析,我们制定相应的产品和运营机制,为用户提供更好的体验。

    • 有限额。处于风控的考虑,银行会根据第三方支付的实力给予第三方支付设置一定的限额,第三方支付也会评估平台的实力给予平台设置一定的限额。限额一般是针对单张银行卡,分为单笔限额,单日限额,单月限额。当用户付款超过限额则付款失败。举例而言,第三方支付给予平台的单笔限额是10万,单日限额50万,单月限额是1000万。用户使用一张银行卡某天分四次充值10万、10万、10万、9万后,第五次再充值10万,虽然符合单笔限额,但是触发了单日限额,还是会充值失败,这时该用户只能换张卡充值。如果该用户自己在银行柜台或者网银设置了单笔充值限额1万,则用户的第一笔10万充值也会因为触发他卡的限额而失败。综上,用户某笔充值的最大额度,受到第三方支付的单日、单笔、单月限额和自己在银行设置的限额的共同约束。

    用户在充值的时候,后端根据历史充值记录判断出用户此时可以充值多少钱,前端提示“您本次充值最多可以充值XX元”,给出详细的限额说明,接口层不接受超过该值的充值请求。避免用户开始充值到中途时遇到限额不够的提示的沮丧。

    • 收手续费。手续费是第三方支付重要的利润来源。对于免用户充值手续费的平台,手续费其实是平台垫付,此时手续费也就构成了平台的成本支出,减少手续费就是扩大公司利润。因为我们必须关注手续费。

    用户充值时,根据合同签订的计费方式,后端自动将充值请求分发到手续费最低的第三方支付。

    • 不稳定。所有第三方合作都会时不时出问题影响平台的正常运营和用户的使用,第三方支付尤其如此。原因1 第三方支付如果切换自己的合作机构(银行或者其他第三方支付),就需要重新做技术对接,对接初期必然存在bug;原因2 数据包在传输的过程中会发生遗失,也叫做掉单 。如果合作的第三方支付不是最顶级的那几个,肯定会问题频发而且防不上防,用户和相关运营产品技术叫苦不迭。其中最常见的问题是用户充值掉单,最严重的问题是整个支付无法使用。曾经,某平台仅对接了一家第三方支付,某天该平台遭遇了合作的第三方支付出bug导致全站用户无法充值的情况,损失巨大。

    签约多家第三方支付,后端自动切换到可用的第三方支付;和第三方支付建立事前沟通机制;统计各第三方支付充值成功率。

    • 用户急。用户理财时,往往充值金额较大,当发生掉单(银行卡扣款,用户余额没有增加),用户非常担心自己的资金是否收到了损失,会以很激动的态度联系平台。

    记录详细的用户行为日志(时间 IP 金额 第三方支付名称 充值进度 返回值)和终端设备日志(客户端版本 硬件信息),通过这些记录还原充值场景,有助于快速定位问题。设置自动多次向第三方支付查询充值订单结果的机制。安排专人为用户答疑,定位问题后,协调第三方支付补单或者退款。

    事前,如果犯罪分子想利用快捷充值盗卡,平台可以用限制资金同卡进出的方式来防范;而如果犯罪分子利用网关充值盗卡则没有有效办法。事中,如果没有实力建立专门的部门从技术手段识别该问题,可以和同盾这样的第三方反作弊反欺诈机构合作。事后,增强提现审核,发现用户多次充值后资金不投资直接提现,则暂不付款启动用户身份确认流程;和第三方支付协同配合,冻结犯罪分子账号,将资金返回给受害人。如果真的发生了盗卡问题且受害人资金无法追回,则根据双方合同约定,由负责赔偿的一方赔偿用户损失。

    产品经理的工作内容


    产品经理主要在系统建设的前期介入。后期工作较少,但是要持续盯紧充值成功率的变化。

    • 前期,围绕第三方支付的特点,设计用户端和后端的产品逻辑,和数据监控项。设计出一个用户体验流程,充值成功率达标,为公司最大限度地节省手续费,方便运营使用的充值系统。
    • 后期,帮助运营解决用户遇到的充值问题。
    • 协调技术修补bug。
    • 关注充值成功率,查找波动原因。

    运营人员的工作内容


    充值属重运营的工作,对于运营人员,他们的日常工作是

    • 操作后台。比如在后台修改银行限额和打开、关闭某第三方支付。
    • 解决充值失败问题。客服将充值用户的充值记录发给运营,运营协调产品、技术、第三方支付查找问题原因。如果是掉单,则协调第三方支付补单或者退款。
    • 与第三方支付沟通。第三方支付的任何变动都是直接通知负责的运营人员,运营再通知产品和客服。在节假日前,运营会询问第三方支付在假期是否有人值班,有问题和谁对接。

    数据统计及用途


    数据统计帮助我们发现问题,我们需要统计

    • 充值成功率。这个指标可以作为整个充值系统的KPI,引导产品经理优化用户端和后端的产品逻辑。通常,某支付的充值成功率突然降低,则预示着该支付出现问题,需要跟进了。
    • 充值失败原因。可以了解用户最常遇到的问题。找到某些失败原因的触发条件后,也可以在前端增加提示,引导用户规避失败条件。
    • 掉单情况。了解到哪些第三方支付最近不太稳定,不稳定就先关掉吧。

    第三方支付常见问题、原因、解决办法


    1. 掉单。充值过程涉及多方互相调用,所以数据包在传输的过程中容易遗失。造成了两种情况1、充值失败,用户没有扣款 2、用户已经扣款,但是平台没有收到第三方支付的扣款成功通知,用户的余额没有增加。问题1并不常见,影响也较小,解决方法是用户重试。问题2 的解决办法是第三方支付重新回调接口告知平台充值成功,或者给用户退款。

    2. 身份信息验证失败。快捷充值需要验证用户信息(姓名 身份证号 手机号 银行卡号)。同一家银行,不同第三方支付合作的分行也多不同,不同分行间的数据库优势有时会不同步。此时,就会发生同一张卡及相同的用户信息在A支付正常充值,B支付身份验证失败的情况。此时,我们可以做的事情并不多,只能是如果用户持续反馈同类事件,在后台调整该银行的充值不再走容易出问题的第三方支付。

    3. 短信延迟或收不到短信。大家进行快捷充值时可能会发现,收到的短信验证码,有时是第三方发送的,有时是银行发送的。原因是不同的第三方支付和银行的合作方式不同,这是他们之间合作模式决定的。有的第三方支付甚至可以要求商户方发短信及验证验证码是否填写正确。有的第三方支付自己发短信,但是特别不靠谱,延迟好几分钟才发给用户。解决方案:找到本次充值时,用户使用的第三方支付,将用户的个人信息(快捷卡手机号、银行卡号)发给第三方支付查询问题原因。

    4. 银行或第三方支付维护。当某支付下的某银行突然维护甚至第三方支付本身发生维护,如果没有备胎可以切换的话,就会对充值、投资业务造成较大影响,解决方案就是多个第三方支付自动切换。

    5. 限额调整。当某第三方支付在没有通知我们的情况下调了某银行的充值限额,出发新限额的用户就会充值失败。预防4 5 问题的方式,都是定期和第三方沟通。

    6. 触发风控系统。银行和第三方支付都有自己的反作弊、反欺诈、反洗钱系统,用户触发该系统的黑名单或者被评估为有风险也会充值失败。

    7. 盗卡盗刷。现象是持卡人表示没有在平台充值,但是用户的银行转账记录里显示有通过某第三方支付充值,并且该第三方支付表示充值是在我们发生的。解决方案:先判断影响范围,如果是个别人“倒霉”的话,运营人员会协调第三方支付进行处理。如果是某个银行在某种支付方式下的问题,则在相应的支付方式下关闭该银行。比如建设银行的网关支付因为自己的机制有漏洞,出现过被盗刷的情况,我们当时下掉了建设银行的网关支付。虽然我们利用同卡进出的机制,减少用户资金的损失,但是犯罪分子可以先申请解除绑定的银行卡再绑定自己的银行卡,进而提现来完成犯罪,所以务必慎重对待解卡申请。


      易宝要求用户解绑需要提交的材料
    8. 绑卡失败。现象是用户告知客服自己绑卡失败,可能会有绑卡失败时我们提示给用户的文案的截图,有可能没有任何信息。解决方案:在绑卡记录查询后台查询该用户的绑卡记录,然后将用户的完整的绑卡日志发送给提示用户遇到问题的第三方支付,找第三方支付查询问题原因。

    9. A支付充值成功,B支付充值失败。可能的原因是

    • A、B支付支持的银行卡类型不一致。比如A支付支持理财卡,B支付不支持,用户在A充值成功,当用B充值时会失败
    • A、B支付和不同的分支行合作,两者数据库不一致
    • A、B支付对用户银行卡的校验规则不一致
    • B支付或者B支付合作的银行出了Bug。联动优势出现过一次合作的招商银行出bug的案例
      前三种case的解决方案:后台支持设定某用户不使用某几个第三方支付,或者弃用规则不合群的支付。
      第四种case,只能关闭出现问题的支付下的银行,待对方解决后再打开。

    提高体验

    • 提供多种充值方式。如果成本OK,就尽量多提供些用户常用的充值方式,除了基本的网关支付、快捷支付,还可以有微信支付、支付宝支付。
    • 签约多家第三方支付。有三个目的:1.覆盖更多的主流银行,每家第三方支付支持的银行数量不同,多家支付才能覆盖更多银行。2.覆盖用户充值常见区间,各家第三方支付支持的限额不同,每家支付才能满足多样的充值金额需求。3.互为备份,必须保障每家银行至少有两个第三方支付可用,上面说过第三方支付不稳定,不能当某一家第三方支付出问题,就耽搁用户充值。
    • 自动路由系统。当某笔快捷充值的申请,被A支付拒绝或者超时的情况下,可以自动将该笔充值请求路由到B支付,B支付扔无法支持则继续路由,直到没有支付可用。路由系统的好处是1.减少了充值手续费,各支付路由的先后顺序是从该笔充值的手续费由低到高排列的。2.提高了充值成功率。
    • 主动查询。上面提到掉单是第三方支付的常见问题,当用户完成一笔充值后第三方支付迟迟没有返回给我们结果,我们可以设置一个超时自动查询脚本,主动去第三方支付那里查询该笔订单的状态,查到则更新用户充值结果,没有查到则报警通知运营人员介入。
    • 监控报警。监控报警是一种暴露问题的机制。资金流太重要了,任何不符合预期的地方都要能自动暴露出来,尤其这三种异常:
      1.掉单的报警。充值完成后,长时间没有返回结果,需要报警通知运营介入联系第三方支付人确认问题原因。
      2.路由的报警。某笔充值A支付不支持,路由到B支付却充值成功了,说明A支付出问题了,也要报警。
      3.对不上账的报警。内部对账不平,或者和第三方支付对账不平,需要报警。

    充值管理后台的架构

    综上所述,一个充值管理后台需要包含下面几部分:

    脑图
    • 第三方支付管理
    • 银行管理
    • 网关支付管理
    • 快捷支付管理
    • 充值订单管理
    • 监控报警系统
    • 路由系统
    • 订单补单系统
    • 内部对账
    • 与第三支付对账
    • 数据统计

    结束


    有的地方说的不是很细,期待大家的回复与讨论。

    长按二维码关注【复盘】,和博主一起在互联网金融从业中获得更多

    qrcode_for_gh_a4b1f46488c1_430.jpg

    相关文章

      网友评论

      • 王美丽_be94:海外充值找“帮你充”
      • gentleming:如果能把对账清算那部分也包括进来就完美了。
      • 李春旸:账务设计呢?
      • 083a27541adb:写的不错!如果有些好的优化用户体验的方案就很好了

      本文标题:互联网金融平台知识介绍2::充值相关知识介绍

      本文链接:https://www.haomeiwen.com/subject/wvubcttx.html