当前位置

详细记录在Drupal的Ubercart中设置接受PayPal付款

James Qi 在 2011年8月17日 - 10:42 提交
内容摘要:6月份开始用Drupal系统的Ubercart搭建网上销售平台"Business Directory Sale Center",当时就觉得有两个难点需要克服:一个是自动支付、一个是......

  6月份开始用Drupal系统的Ubercart搭建网上销售平台"Business Directory Sale Center",当时就觉得有两个难点需要克服:一个是自动支付、一个是自助下载。

  自助下载的比较容易解决,就是Ubercart中设置商品的时候可以添加Feature,只要附加上可以下载的文件就OK了,购买了该商品的用户当时就可以看到下载链接、自行下载。剩下就是支付的问题。

  Ubercart的支付功能支持很多种支付方式,例如:2Checkout, alipay, Authorize.net, Credit Card, CyberSource, Google Checkout, Payment Method Pack, PayPal等,我们在英文销售网站中只设置了PayPal这种最流行的方式,本来准备还加上支付宝Alipay的,但实际测试中发现标价1美元通过支付宝就成了1人民币元,没有货币转换的机制,就去掉了。

  而PayPal在Ubercart中可以设置两种:

  • PayPal Express Checkout:快速结帐,需要收款方是商业账户
  • PayPal Website Payments Standard:网站标准支付,需要收款方是高级帐号或者商业账户

  我以前的个人用的PayPal帐号属于普通个人账户,只能付款购物或者直接转账(转入、转出都行),但无法支持上面的收款,我查了一下资料,把自己的普通个人账户升级为高级账户,这样就可以用上面的网站标准支付方式收款了。以前还设置了一个公司账户,属于商业账户,因为提现操作很麻烦,这次也没有用,所以还不能用快速结帐方式。

  需要说明的是,如果购买方没有PayPal帐号,也一样可以付款给我们,只要根据屏幕提示,输入信用卡信息,就可以通过PayPal支付,并当时注册一个PayPal帐号。

  PayPal的测试比较麻烦,只有一个专门的测试系统,Sandbox的网址是 http://developer.paypal.com ,需要注册正式PayPal以外的专门测试帐号,并设置销售方测试帐号、购买方测试帐号,获得API用户名、密码、签名信息,并设置到Ubercart对应的支付设置中。实际测试的时候也比较罗嗦,需要在销售网站、PayPal测试站之间切换,好几个帐号也容易搞混淆,不过最终还是测试成功了,用户可以付款。

  但付款成功后却发现无法下载,没有下载的链接,经过检查看到付款成功后订单状态还是Pending,这对于购买实物就是进入等待发货的状态,而我们销售的是虚拟商品,应该是直接完成状态,查找网上资料,还要在Ubercart的Conditional actions中添加一个Trigger(订单状态发生改变时)和一个Action(设置订单状态为已完成),这样用户通过PayPal付款后,订单状态就从Pending改为了Completed,然后就可以有下载权限了。

  测试成功后,可以将Ubercart中设置为使用实际的PayPal帐号,然后再行测试,需要注意的是因为PayPal对每一笔交易收取0.3+3%左右的费用,所以测试商品的价格至少要高于0.3美元,否则扣款不成功不会返回收款成功的信息,我们刚开始用0.01美元测试就无法下载,后来改为0.5美元后测试就OK了。

  国内估计用这套系统的人还比较少,我们把这些记录在上面,希望对其他人有帮助。需要自己测试、体验可以去这个网站看看:http://sale.mingluji.com


  2011年9月补充:上面的设置我们自己内部测试都成功了(用沙盒和正式服务器都成功了),然后投入了实际使用,在实际使用中发现有一部分(大约一半)客户通过PayPal付款到我们帐号成功了,但Ubercart中的订单状态还是In checkout,也就是订单无法自动完成,用户无法获得下载权限。这种情况我们分析是客户没有在PayPal网站上付款成功后点击返回我们网站造成了,我们自己模拟这个过程确实有这个问题,已经遇到过多次客户发邮件来询问如何下载了,看来是必须解决了。

  我查了一些资料,似乎应该在网站的PayPal帐号设置IPN(即时付款通知),我就打开了这个功能,通知的网址填写的是http://sale.mingluji.com/uc_paypal/ipn,不过从drupal的日志看,显示“IPN failed with HTTP error Unable to find the socket transport "ssl" - did you forget to enable it when you configured PHP?, code -492436848.”报错信息,可能必须要用https才行吧,那还有些麻烦。

  而我们另外一个名录中文自助购买网站采用了支付宝作为支付接口,却没有遇到这样的问题。经过比较,发现支付宝支付完成后是提示自动返还购买网站,而PayPal在支付完成后还有一个中间选择页面,客户可以选择返回自己的PayPal帐号页面还是返回网站,我们估计那些选择返回自己PayPal帐号的用户就会发生网站上订单状态无法更新的情况。进一步在网站PayPal帐号后台中可以找到“用户信息”-“网站付款习惯设定”-“网站付款的自动返回”和“付款数据传输(可选)”,默认都是关闭,我全部改为开启,返回URL设置成网站首页。同事测试付款过程,发现这次就没有提供选择的中间页面了,而是直接到提示返回网站的页面,然后跳转到我们网站上并且马上提示订单已经完成。而这个时候查看drupal日志,IPN报错信息依然存在,估计设置了自动返还后,那个IPN的设置就可有可无了。

  希望经过上面的设置能解决一些客户付款后无法自己下载的问题,这个需要持续观察一段时间,如果后面的订单中再不出现付款成功而状态依然是In checkout的情况那就好了。


  2013年4月补充:2012年底设置了一个新站Profile Report,也接收paypal付款,因为不存在实时下载,相对简单一些,在Drupal 7和Ubercart 3上搭建成功。2013年4月调试在另一个站Postcode Database Supermarket设置接收paypal付款,收款换了另外一个paypal帐号来重新设置,在paypal帐号设置中关闭了IPN,只开启了自动返回网站,经过反复测试也可以成功付款后自动完成订单、允许下载,不需要额外添加conditional actions,注意可以把/admin/store/settings/payment/method/paypal_wps中的Show debug info in the logs for Instant Payment Notifications.开启,以便在系统日志中看到与uc_paypal的ipn相关的记录。

自由标签:

评论

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

最近一个月也在做ubercart, paypal还没测试,alipay仅支持国内的架势让我有些头疼,公司的老外不懂中文。。。

你的网站看了,样式虽然简单,但是很module都很实用

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

刚才把你以前对drupal的文章都看了下,很多都能给我启发,还是要谢谢你。也有几点:

1.带有ubercart模块的皮肤可以去drupal下fushion以及基于fushion皮肤的子皮肤,可以美化页面效果,也不会增加工作量。

2.其实不建议直接修改module内的文件,以及themes内的文件,不适合2次开发,drupal的皮肤是可以拷贝到你的皮肤内,然后直接修改的。当然,node,comment之类要拷贝父级皮肤。

3.说实话。。。大型数据库用drupal。。。总是不好说好说坏。。。因为node加content type的数据库冗余真的很大。

4.首页建议只开启一种cache模式。

如果有不对的也请告诉我,和谐drupal社会,从我做起,^-^玩笑。。

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

我是去年底才开始用Drupal的,而且没有PHP编程经验,到现在也只能算是Drupal新手,只是这半年一直在折腾Drupal平台,把一些经验教训记录在博客中,自然有不对的地方,希望各位真正高手指正!

你说的几点交流一下:

1、我很懒,基本上全部都是用的drupal 6默认的garland主题皮肤,没有换用其它的,肯定有更好、更合适的,你说的对,应该还是花些时间换用皮肤来做些页面美化工作,我在以后的新站建设或者老站改版的时候注意;

2、Drupal有自己的规范结构,而且非常井然有序,对于定制化也有充分的支持和相应的建议,我本身不是程序员出身,现在也只是图快、能解决问题就行,显得不够规范严谨,真是希望以后有专门的程序员来配合我做这方面的工作;

3、我在大数据量网站方面使用Drupal平台确实是摸着石头过河,你说的冗余确实很大,一个本来就很大的数据可能会导入Drupal成为Node后,附加上了数倍的数据量。我现在最大的一个站点有数百万Node,一些处理非常耗时,访问速度也受影响。不过用Drupal的好处还是网站搭建快,如果有针对性编程开发对于大型数据库来说肯定最理想了,但时间、成本都耗不起,只有目前这样先尽量用好的硬件对付。

4、考虑到大规模数据的访问,我用Drupal的一开始就安装了Boost模块,一开始是Boost和Core Cache都同时开启也没有问题,后来发现偶有出错的情况,后来就只开启Boost而对Core Cache关闭了,我说的Cache基本上都是指的对整站,没有专门针对首页进行特别设置。你说的首页建议开启一种cache是指的开启哪一种更合适呢?如何专门只针对首页开启某种cache?

欢迎多多交流!

James Qi / 祁劲松

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

要是对提高性能感兴趣,也可以试试集群.pressflow配置集群还是比较简单的.另外除了刚才提到的前置cache,后边也可以用memcache做后置cache.

另外刚才看到你说升级了服务器的内存到多达64G,这样配置的话,用varnish应该会有很明显的速度提升的;另外,有钱买内存,何不买固态盘呢...固态盘应该比万转服务器盘快很多吧.

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

我们现在人手有限,主要精力还得放在网站内容建设上面,对系统架构进行大的调整、优化还有些顾不过来,只能是先进行一些小的优化尝试,并添加一些硬件来设法改善。

等发展到一定阶段,再去尝试你说的Pressflow、Varnish、Memcache等系统。

固体硬盘我们也曾经考虑过,不过在容量、价格、稳定性等方面还有些问题,所以暂时没有用,以后还是会考虑适当时候再用。

James Qi / 祁劲松

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

我们以前用过Squid来加速MediaWiki网站,现在的Drupal服务器上其实也安装有Squid,只是没有让Squid缓存Drupal网站的内容,而是直接传递到Apache了。我看了一下Squid与Drupal的资料,好像不太推荐这样的组合。

Varnish我没有用过,可能机制上与Squid类似吧?我们网站的特点是数据量大,访问很分散,不是那种内容数量少而访问集中的情况,估计用前端缓存的效果不会太好。

你说的Pressflow我还没有用过,刚去看了,是对Drupal进行了一些性能优化的专门版本,以后再去详细了解,谢谢推荐。

James Qi / 祁劲松

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

我们当时做首页的时候,开始都设置了block的cache,view的cache,但是最后发现因为首页的动态内容相对都很多,后来还是把首页的block,view的cache都关闭了,同时基于客户的很多变态要求。。。不得不改成了手写代码。。。和你一样,我们也是关闭了Anonymous page caching,只开启了boost。不知道你是不是有用其他的cache模块,如果只用了一个boost,通常就不会有问题,如果还用了其他的,可以在boost设置里把首页给排除掉。

话说我们项目没碰到你这个首页报错的问题,不过你可以试试一个,如果首页报错了,进mysql里,先清cahce_view,然后检查首页,接着依次清理并查看cache_block,cache表中的variables列,整个cache,最后是session,不过清空session的时候最好在半夜,免得把正登陆着的用户给T了。。。

-- 发自IP地址: 192.168.0.133 (位置 | 谁是)

我们多数网站的内容相对来说变化不频繁,基本上都是搭建后变化很少的,内容多是我们自己提供(只有少数几个网站是用户提交的内容,首页会变化比较多),所以block和views的cache我们都是打开了,也没有多的手写代码,在网站内容都导入、处理完成后,只要最后发布前把core cache和boost file cache都清空一次基本上就可以了。

另外,我们多数网站都只是内容展示、查询,把用户注册都关闭了,只有少数需要用户提交内容的网站放开了注册。

James Qi / 祁劲松