论坛首页 编程语言技术论坛

使用ROR处理电子支付和视频等方面怎么样?

浏览 10198 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2008-02-29  
gigix 写道
leondu 写道
yehs220 写道
电子支付:paypal的库已经有了,国内的什么支付宝啦等等自己写也不难
图片:imagemagic + rmagick (+ rails plugin - file_column, uploadcolumn...)
视频:编辑基本都是用现成的native的库,忘了是什么,搜搜吧,用ruby包装了一下,或者通过命令行;播放...网上一堆flv的播放器



补充一下,paypal的直接支付比较简单,但是订阅模式(subscription/recurring)就很难搞。

订阅也还可以啊,我感觉没有什么特别不好的地方
关键在于,如果你打算支持退款,那么你自己的网站就肯定要做虚拟货币,不管你是叫它积点也好积分也好,反正就是这样一种东西。如果你做虚拟货币,那么是零售还是订阅对于支付平台来说就没有区别了,用户都是以零售的方式从你这里购买一批虚拟货币,然后怎么用虚拟货币是你自己网站的规则。


你说的这种是自己做一个定期扣款的逻辑吧?
我有个问题就是在不保存用户信用卡信息的前提下,如何定期去扣取用户账户上的钱呢?


我说的难搞指的是使用paypal自己提供的subscription api。
现在还没做完,难搞的印象来源于这里:
http://talklikeaduck.denhaven2.com/articles/2007/09/02/how-to-cure-the-paypal-subscription-blues
引用

The PayPal protocol isn’t very well specified, at least when it comes to the sequence of notifications for subscriptions. It turns out that it’s not recommended to use payment notifications to track the validity of subscriptions on the merchant’s server. The intent is for PayPal to handle that state, and indicate state transitions with subscr_signup, and subscr_eot. Here are some of the problems which can arise when you try to track subscription state yourself:

1. The order of payment and signup notifications is not specified, I’ve seen the initial payment notification come after the signup notification, but it usually seems to come first. This can cause havoc if you don’t realize this.
2. Let’s say a subscriber signs up for a one-month subscription, then cancels it two weeks later. If you get the cancel notification and turn off the subscription right away, you have taken away two weeks that the subscriber already paid for, and your code might get confused when you get the eot notification at the end of the month. You are supposed to turn the subscription on when you get the signup notification, and turn it off when you get the eot.

There’s a slight complication to this scheme. If the user signs-up, cancels, and signs up again before the initial sign-up expires, you will still get an eot for the first signup, which means that, if you’re not careful, you can end up turning off the second subscription. My solution to this was to keep a counter of how many unmatched signups the user has, and only turn off the subscription when the counter reached zero.


还有就是ActiveMerchant对于subscription的修改也不支持,要自己hack(见上文)。

 

 

0 请登录后投票
   发表时间:2008-02-29  
引用
你说的这种是自己做一个定期扣款的逻辑吧?
我有个问题就是在不保存用户信用卡信息的前提下,如何定期去扣取用户账户上的钱呢?

你不扣钱啊。你让他自己往虚拟钱包里充值,看他虚拟钱包快空了就发邮件叫他再充。
保存信用卡做定期扣缴很麻烦的,再考虑到中国的在线支付有80%以上是借记卡那就更加麻烦。最好不要打这个主意。
0 请登录后投票
   发表时间:2008-02-29  
gigix 写道
引用
你说的这种是自己做一个定期扣款的逻辑吧?
我有个问题就是在不保存用户信用卡信息的前提下,如何定期去扣取用户账户上的钱呢?

你不扣钱啊。你让他自己往虚拟钱包里充值,看他虚拟钱包快空了就发邮件叫他再充。
保存信用卡做定期扣缴很麻烦的,再考虑到中国的在线支付有80%以上是借记卡那就更加麻烦。最好不要打这个主意。

哦,你说的没错。
不过我们说的是两码事了,我现在的客户是指定要实现基于paypal的subscription的。
0 请登录后投票
   发表时间:2008-02-29  
leondu 写道
gigix 写道
引用
你说的这种是自己做一个定期扣款的逻辑吧?
我有个问题就是在不保存用户信用卡信息的前提下,如何定期去扣取用户账户上的钱呢?

你不扣钱啊。你让他自己往虚拟钱包里充值,看他虚拟钱包快空了就发邮件叫他再充。
保存信用卡做定期扣缴很麻烦的,再考虑到中国的在线支付有80%以上是借记卡那就更加麻烦。最好不要打这个主意。

哦,你说的没错。
不过我们说的是两码事了,我现在的客户是指定要实现基于paypal的subscription的。

呵呵,看来不是中国的客户
0 请登录后投票
   发表时间:2008-02-29  
gigix 写道
leondu 写道
gigix 写道
引用
你说的这种是自己做一个定期扣款的逻辑吧?
我有个问题就是在不保存用户信用卡信息的前提下,如何定期去扣取用户账户上的钱呢?

你不扣钱啊。你让他自己往虚拟钱包里充值,看他虚拟钱包快空了就发邮件叫他再充。
保存信用卡做定期扣缴很麻烦的,再考虑到中国的在线支付有80%以上是借记卡那就更加麻烦。最好不要打这个主意。

哦,你说的没错。
不过我们说的是两码事了,我现在的客户是指定要实现基于paypal的subscription的。

呵呵,看来不是中国的客户

:)
you got it.
0 请登录后投票
   发表时间:2008-02-29  
gigix 写道
jollibee 写道
Active Merchant 可以实现国外支付,国内的,直接利用网银提供的接口即可。

用网银接口会累死的,每个银行都得做一遍
找个现成的支付平台,首信或者快钱之类的,所有的银行都支持了,开发也颇简单
视频,从我最近接触的一些行业分析来看,我看不出有什么理由去做又一个视频网站
视频网站开发成本高,运营成本大,营收途径不清晰
还不如直接把土豆mashup进来的好



计划的东西是一个和具体行业结合的,电子支付这一块我也觉得找个线程的支付平台比较好,这样成熟度高,也可以腾出更多的时间做业务上的事情
视频,也不是打算整一个像土豆一样的专业视频网站,加入视频的内容主要是对业务的一个辅助介绍,视频的规模不会很大,最主要还是图片和文字方面。
0 请登录后投票
   发表时间:2008-02-29  
langkins 写道
视频,也不是打算整一个像土豆一样的专业视频网站,加入视频的内容主要是对业务的一个辅助介绍,视频的规模不会很大,最主要还是图片和文字方面。

最简单的办法就是做成flash,因为你并不需要频繁更换播放的内容
0 请登录后投票
   发表时间:2008-02-29  
gigix 写道
langkins 写道
视频,也不是打算整一个像土豆一样的专业视频网站,加入视频的内容主要是对业务的一个辅助介绍,视频的规模不会很大,最主要还是图片和文字方面。

最简单的办法就是做成flash,因为你并不需要频繁更换播放的内容

可以考虑的一种方式

不过很多内容也许会由用户自己去上传,要求用户自己去做flash可能不太合适。

0 请登录后投票
   发表时间:2008-02-29  
langkins 写道
gigix 写道
langkins 写道
视频,也不是打算整一个像土豆一样的专业视频网站,加入视频的内容主要是对业务的一个辅助介绍,视频的规模不会很大,最主要还是图片和文字方面。

最简单的办法就是做成flash,因为你并不需要频繁更换播放的内容

可以考虑的一种方式

不过很多内容也许会由用户自己去上传,要求用户自己去做flash可能不太合适。


上ffmpeg阿,上传后转换 http://ffmpeg.mplayerhq.hu/
0 请登录后投票
   发表时间:2008-03-11  
leondu 写道
yehs220 写道
电子支付:paypal的库已经有了,国内的什么支付宝啦等等自己写也不难
图片:imagemagic + rmagick (+ rails plugin - file_column, uploadcolumn...)
视频:编辑基本都是用现成的native的库,忘了是什么,搜搜吧,用ruby包装了一下,或者通过命令行;播放...网上一堆flv的播放器



补充一下,paypal的直接支付比较简单,但是订阅模式(subscription/recurring)就很难搞。


严重同意这位任兄的说法,听楼主的意思支付不是你业务的重点,自己如果不投入大量精力是做不好的,每家银行的接口都不一样,千差万别,每个都要接一次,还要处理掉单对帐,一大堆问题,很麻烦的,不如找一个现成的支付平台,而且现在好多支付平台都有好多增值服务.
0 请登录后投票
论坛首页 编程语言技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics