关于支付的几点注意
2015-10-28 10:38
232 查看
无意中看到BeeCloud创始人讲到做支付的经验,感觉特别贴切,尤其在本人对接过几家支付或托管业务相关的公司时,感触更深,好一点的提供完整的仿真产线环境,对接很顺畅,eg:汇付天下,有的虽然无仿产线环境,但是可以临时搭建环境使用真钱做测试,同时运营支持到位,可以直接对接解决问题,eg:联动优势、连连支付;最差的要数19支付了,毫无可用的对接API,文档无参考价值、最让人受不了的是上产线后,无法解决线上问题,客户推运维、运维推客户、技术不管、打电话让用QQ联系,QQ发消息不回,简直……不说了,说多了都是泪。
以下是原话(后期做支付可以有适当的借鉴思考):
一方面,如果你是第一次做支付开发,项目需要同时接几个支付方式,那前期要分别向每个第三方支付(就是支付宝,微信这些),各银行申请账号,通道,或进行商务洽谈,每个渠道都要一两周左右的沟通审核期,加上后面研读每家的文档,分别coding、调试,非常费时费力,可能一两月都搞不定。而且下次你在做另外一个项目的支付接入时,还要几乎做同样重复费力的工作。
另一方面,就是支付流程的风险承担。因为涉及到资金交易,所以本身支付开发就比较敏感,每个环节要都要推敲。支付功能上,会涉及到支持退款,对账和差错处理的运营工作以及风险控制; 另外对不少创业团队来讲,服务器是否能支持支持高频次,高并发的支付请求也是一个挑战 (比如项目做营销活动时你的交易量可能突然暴涨);此外你还要防止中间人攻击导致支付数据泄露、订单被黑客恶意篡改等外在风险。
还有防止 薅羊毛 个人经验
最后一方面就是支付体验的优化。比如客户下单时,发起支付响应时间过长会直接导致订单流失。现在支付场景的很多样化,应用内支付,网页支付,微信公众号支付,线下扫码支付,项目选择什么样的入口可以提高下单成功率、体验上更加流畅,这些可能是立项时就要考虑的。
还有与支付配套的数据统计分析服务,订单,退款,对账管理服务等SaaS服务,也都是必须的。
以下是原话(后期做支付可以有适当的借鉴思考):
一方面,如果你是第一次做支付开发,项目需要同时接几个支付方式,那前期要分别向每个第三方支付(就是支付宝,微信这些),各银行申请账号,通道,或进行商务洽谈,每个渠道都要一两周左右的沟通审核期,加上后面研读每家的文档,分别coding、调试,非常费时费力,可能一两月都搞不定。而且下次你在做另外一个项目的支付接入时,还要几乎做同样重复费力的工作。
另一方面,就是支付流程的风险承担。因为涉及到资金交易,所以本身支付开发就比较敏感,每个环节要都要推敲。支付功能上,会涉及到支持退款,对账和差错处理的运营工作以及风险控制; 另外对不少创业团队来讲,服务器是否能支持支持高频次,高并发的支付请求也是一个挑战 (比如项目做营销活动时你的交易量可能突然暴涨);此外你还要防止中间人攻击导致支付数据泄露、订单被黑客恶意篡改等外在风险。
还有防止 薅羊毛 个人经验
最后一方面就是支付体验的优化。比如客户下单时,发起支付响应时间过长会直接导致订单流失。现在支付场景的很多样化,应用内支付,网页支付,微信公众号支付,线下扫码支付,项目选择什么样的入口可以提高下单成功率、体验上更加流畅,这些可能是立项时就要考虑的。
还有与支付配套的数据统计分析服务,订单,退款,对账管理服务等SaaS服务,也都是必须的。
相关文章推荐
- mysql输出的错误提示是法语
- matlab程序移植到C(输出比较)
- 输出1000-2000是闰年的年份
- TBS调试手机QQ浏览器
- 【Qt多线程之信号量】Qsemaphore
- 第七讲流程图
- 解决maven与eclipse中@override出现must override a superclass method错误
- python文件的整体结构
- LeetCode Serialize and Deserialize Binary Tree
- GCD多线程
- 自动归档autoArchive By H.l
- HiHo Coder字典树 TrieTree
- AugularJS学习笔记
- jquery qrcode二维码生成插件
- NSURLSession
- 第 四 十 三 天:mysql 的 相 关 问 题
- Android 属性动画Interpolator和ViewPropertyAnimator的用法
- [2000]:ASCII码排序(三个数排序、考虑scanf函数)
- listView添加动画
- Python 列表删除元素