关于 Ping++的收费模式

[hrbwaxdoll]

之前一直在用 Ping++ 然后前几天发现它收费了，而最核心的限制条件是：每秒并发数。

试问一个以支付为核心服务的产品，将并发数做为收费的条件是正确的姿势吗？ 难道支付最该保证的不是支付成功，而是能否支付？

也是一个奇怪的逻辑，毕竟一个产品没有办法预估它的每秒并发数的，万一超出自己购买的套餐，是不是就会提示用户「您使用的产品由于没有购买足够的支付并发数所以您的支付失败了，请您稍后再试」？

用户体验咋办？支付失败可能是电商最致命的问题了，然而……

又或者直接就逼着用户购买最高的套餐？

btw ，我们已经弃用了，打算直接自己写了……

[yeyeye]

不适合你 或许适合别人……

收费模式估计也是从统计数据中分析得出的结论

[hrbwaxdoll]

@yeyeye 呵呵


所以，我是想讨论一下这种模式，至于是不是适合我，我自己当然有判断

[hrbwaxdoll]

当然，如果某个产品就是希望用户「支付失败，慢一点支付更好」，那……也只能是你开心就好了。

[crazyxin1988]

每秒并发数 作为限制不太合适吧
一般支付网关收费 有的是由固定费率 还有按照每笔收费
这种方式还是第一次听说

[freez]

并不会直接导致支付失败，这只是你的猜测罢了。

实际情况是，如果不购买套餐，会对超出免费上限的部分在次月额外付费。

下面是定价方案下面看到的说明：
接口调用次数包括付款、查询、退款等所有接口调用的请求。若商户当月接口调⽤次数超出所在方案的约定次数， Ping++ 会在次月根据上月调⽤次数的超出部分，按照每一千次 5 元的价格出具账单。商户需在收到账单的 30 天 内完成付款，以免影响后续服务的正常使用。

[hrbwaxdoll]

@crazyxin1988 是，所以这个挺奇怪的。

不知道 Ping++的市场是咋制订的策略，当时在朋友圈儿吐槽，也受到了一些朋友的支持，毕竟支付成功才是支付平台的关键业务。

而收费的前提如果是会影响到支付成功，那可能用户是会相当慎重，除非如 1 楼的朋友所说，刚好这种收费模式适合对方的业务「就是不在乎支付的成功率」，那就无所谓了。

否则用免费的，和付 2000 元的，基本上是一样的风险。

[yeyeye]

@hrbwaxdoll 我觉得吧 人家要收费 肯定要分析一下自己目前的数据 分析完后下定论 这个方案很好！

毕竟可以选择的收费模式就那么几种 不管选哪种 总有其道理 也总有其适用范围。这种不限制额度限制频率的，显然适合大额一点 单少一点的 还有限制金钱的额度的 这种对于小订单就很划算

而且频率限制了 你还可以调整程序做队列控制频率 或者激励会员尽量充值大额的 如果限制的是金额数量 那就调都没法调 只能交钱。

总之还是得看你的项目类型。当然啦，你说自己可以写那当然是最好的。

我想主要还是项目要生存，要不然没办法养活 ping++啊。

[hrbwaxdoll]

@freez 商户需在收到账单的 30 天 内完成付款，以免影响后续服务的正常使用。

所以，用户在支付了套餐后，还要继续支付「额外」的费用是吗？

另外，你说的这条我知道，我想讨论的是这样的付费方式是否合理，虽然有点瞎操心的感觉……

做产品是为了让用户省心，而不是操更多的心不是吗？

[yeyeye]

@hrbwaxdoll 不管哪种方式限制免费用户 /套餐。在额度用完后，那肯定是要扣费或者停用的。你的思想是没错的，支付网关要尽量支付成功，但是你不能让他不收费啊……

[hrbwaxdoll]

@yeyeye 可能和我们的产品特点有关系，所以我是相对更关心支付并发的，因为我们的产品每次报名的时候都是超大并发的，所以按这个逻辑，我可能即使买了最大的套餐，也不能满足需求。

使用成本太高，毕竟阿里、腾讯已经收了一定的费率，如果再通过一个支付平台扒一层，真心不如自己开发了，长远看成本更低此。

[hrbwaxdoll]

@yeyeye 我没有让它不收费啊， Ping++是个好产品，减少了极大的开发工作量，但是收费也要合理才成啊。

[hrbwaxdoll]

发完了看了下自己上边这句的语病~我醉了。

[crazyxin1988]

说实话，现在的支付，你只要接入支付宝和微信 基本就能满足绝大数人的支付需求了
现在微信支付和支付宝支付 的接入难度也不是很大
可以考虑 自己接入了

[casparchen]

支付部分写个排队系统，参考 LOL

[hrbwaxdoll]

@freez 仔细看了下，这段话其实说的是支付总调用次数，但是并没有提「每秒并发数」，所以其实还是不确定成功率的。

[yeyeye]

@hrbwaxdoll

这就是我最开始说的，很显然这种方式不符合你的项目。但是对于别人来说或许刚好合适，可以省很多钱。

我觉得你所认为的不合理，是没有针对你的情况有优化的套餐，我认为你应该和官方联系一下。或许下一期就有这样的套餐了。

[hrbwaxdoll]

@crazyxin1988 对的，我们也是这样考虑的，之前也就是使用了支付宝和微信，所以现在打算自己做了，而且还有一些支付平台也在做类似的业务，还在免费中。

但是看来这东西可能的话还是要自己来做，虽然维护成本增加，但是可用性和稳定性有所保障啊。

[hrbwaxdoll]

@yeyeye 但是从实际的业务出发来看，哪个涉及到收钱的产品希望用户排队呢，或是希望用户支付失败呢？

抛开我的项目，从所有的支付场景来说，没有任何一个商家希望用户付款环节存在任何的风险。是的，可以写排队系统，但这并不是最佳的解决方案。

[just4test]

“若商户当月接口调⽤次数超出所在方案的约定次数， Ping++ 会在次月根据上月调⽤次数的超出部分，按照每一千次 5 元的价格出具账单。商户需在收到账单的 30 天 内完成付款，以免影响后续服务的正常使用。”
怎么超都不会当时停机的。
qps 其实是个软限制，首先 ping++不会那么蠢超了 qps 就给你断流；其次 qps 这个很难开增值账单。每月调用次数两边都能对的上， qps 这账单没法对，还真翻 log 去啊。顶多说是，你超了太多 ping++的售后部门会联系你问要不要换套餐。

不知道你的生意有多大，我是觉得这个定价策略很良心了。一个核心功能保证 500qps 的系统，每月才收你 1w 块，服务器成本得多少？

反过来人家不按服务器压力收费，按流水收费， ping++每千次请求 5 块钱，就算百分之 10 是支付，每次客单价 10 快，也才合千分之 5 的手续费，而且没单次最低手续费，客单价越高手续费越低，你还想怎样……

[bingx86]

其实大多数人都高估了自己的 支付 QPS/TPS ，如果你知道国内某大型支付渠道全国的日常 QPS 在 5000 左右，还有一个前几的在线支付是 500 ，我这里说的是支付渠道，不是单指某一家商户；当然举商户的例子也可以，国内某家叉叉店的支付是 500/s 左右。以上数据都是说的 2015 年。。。

太多人不清楚自己的 QPS 了，而且很多人真的以为秒杀的 QPS 就是支付的 QPS 。。。。