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相关的记录。
评论11
很有帮助，谢谢
最近一个月也在做ubercart, paypal还没测试，alipay仅支持国内的架势让我有些头疼，公司的老外不懂中文。。。
你的网站看了，样式虽然简单，但是很module都很实用
恩，还是我
刚才把你以前对drupal的文章都看了下，很多都能给我启发，还是要谢谢你。也有几点:
1.带有ubercart模块的皮肤可以去drupal下fushion以及基于fushion皮肤的子皮肤，可以美化页面效果，也不会增加工作量。
2.其实不建议直接修改module内的文件，以及themes内的文件，不适合2次开发，drupal的皮肤是可以拷贝到你的皮肤内，然后直接修改的。当然，node,comment之类要拷贝父级皮肤。
3.说实话。。。大型数据库用drupal。。。总是不好说好说坏。。。因为node加content type的数据库冗余真的很大。
4.首页建议只开启一种cache模式。
如果有不对的也请告诉我，和谐drupal社会，从我做起，^-^玩笑。。
我其实还是Drupal新手
我是去年底才开始用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？
欢迎多多交流！
drupal 大量数据网站的处理性能一直是他的短版，
drupal 大量数据网站的处理性能一直是他的短版，
是的，我现在遇到drupal大数据量网站的问题比较明显了
是的，我现在遇到drupal大数据量网站的问题比较明显了，例如数据库负载超高、内部搜索速度慢、cron运行报错等等，还在继续寻找解决办法
varnish+pressflow
试试用varnish做前置cache,另外用pressflow提到标准D6
集群也是个不错的办法
要是对提高性能感兴趣,也可以试试集群.pressflow配置集群还是比较简单的.另外除了刚才提到的前置cache,后边也可以用memcache做后置cache.
另外刚才看到你说升级了服务器的内存到多达64G,这样配置的话,用varnish应该会有很明显的速度提升的;另外,有钱买内存,何不买固态盘呢...固态盘应该比万转服务器盘快很多吧.
我们现在人手有限，主要精力还得放在网站内容建设上面，对系统
我们现在人手有限，主要精力还得放在网站内容建设上面，对系统架构进行大的调整、优化还有些顾不过来，只能是先进行一些小的优化尝试，并添加一些硬件来设法改善。
等发展到一定阶段，再去尝试你说的Pressflow、Varnish、Memcache等系统。
固体硬盘我们也曾经考虑过，不过在容量、价格、稳定性等方面还有些问题，所以暂时没有用，以后还是会考虑适当时候再用。
数据量大，访问很分散的网站估计用前端缓存的效果不会太好
我们以前用过Squid来加速MediaWiki网站，现在的Drupal服务器上其实也安装有Squid，只是没有让Squid缓存Drupal网站的内容，而是直接传递到Apache了。我看了一下Squid与Drupal的资料，好像不太推荐这样的组合。
Varnish我没有用过，可能机制上与Squid类似吧？我们网站的特点是数据量大，访问很分散，不是那种内容数量少而访问集中的情况，估计用前端缓存的效果不会太好。
你说的Pressflow我还没有用过，刚去看了，是对Drupal进行了一些性能优化的专门版本，以后再去详细了解，谢谢推荐。
关于cache
我们当时做首页的时候，开始都设置了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了。。。
我们多数网站的内容相对来说变化不频繁
我们多数网站的内容相对来说变化不频繁，基本上都是搭建后变化很少的，内容多是我们自己提供（只有少数几个网站是用户提交的内容，首页会变化比较多），所以block和views的cache我们都是打开了，也没有多的手写代码，在网站内容都导入、处理完成后，只要最后发布前把core cache和boost file cache都清空一次基本上就可以了。
另外，我们多数网站都只是内容展示、查询，把用户注册都关闭了，只有少数需要用户提交内容的网站放开了注册。