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都清空一次基本上就可以了。
另外，我們多數網站都隻是内容展示、查詢，把用戶注冊都關閉了，隻有少數需要用戶提交内容的網站放開了注冊。