关于 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 。。。。

[gonglin]

我也来说说恶心的 Ping++吧，我申请了 2 个渠道，渠道选错了，没有办法更换，然后我要求退款，超过 24 小时还不给退款！

我打电话强硬要求退款，最后给我的办法是，在下一单。。。。然后把之前的钱退给我。。比流氓还流氓

我也真是恶心到了。。

[Moepo]

@gonglin 没有看出来 Ping++ 存在什么问题

[hrbwaxdoll]

@just4test
@bingx86

谢谢两位科普，但是实际上我还是觉得这件事如果如两位所说， ping++应该给出说明，我想不是我一个人有这种认知。

在这一点上， ping++并没有交代清楚

[Muninn]

感觉是想转嫁被攻击的概率吧
要是一直有人恶意调用你的支付接口
你要为此付出代价 而不是 ping++

[ggshily936]

带限制的收费模式相比传统按单收费的模式在大部分情况下更经济也更容易控制，当然超出套餐后的处理应该解释的更清楚明白。

[bingx86]

@hrbwaxdoll 同意 感觉可以 at 一下 @pingplsuplus

[bingx86]

好像写错了。。。 @pingplusplus

[hrbwaxdoll]

@bingx86 原来他们在坛子里啊~~~

嘿嘿，谢谢 at ，我总觉得一个好产品，应该有更好的变现渠道才是。

[hrbwaxdoll]

@ggshily936 如果解释的不清楚，就好像在天燃气瓶子上写好「会爆炸」，但是不说明什么情况下会爆炸，那还会有人敢买吗？