您在這裡

詳細記錄在Drupal的Ubercart中設置接受PayPal付款

James Qi 在 2011年8月17日 - 10:42 發表

  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相關的記錄。

自由标簽:

回應

最近一個月也在做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的,而且沒有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 / 祁勁松

要是對提高性能感興趣,也可以試試集群.pressflow配置集群還是比較簡單的.另外除了剛才提到的前置cache,後邊也可以用memcache做後置cache.

另外剛才看到你說升級了服務器的内存到多達64G,這樣配置的話,用varnish應該會有很明顯的速度提升的;另外,有錢買内存,何不買固态盤呢...固态盤應該比萬轉服務器盤快很多吧.

我們現在人手有限,主要精力還得放在網站内容建設上面,對系統架構進行大的調整、優化還有些顧不過來,隻能是先進行一些小的優化嘗試,并添加一些硬件來設法改善。

等發展到一定階段,再去嘗試你說的Pressflow、Varnish、Memcache等系統。

固體硬盤我們也曾經考慮過,不過在容量、價格、穩定性等方面還有些問題,所以暫時沒有用,以後還是會考慮适當時候再用。

James Qi / 祁勁松

我們以前用過Squid來加速MediaWiki網站,現在的Drupal服務器上其實也安裝有Squid,隻是沒有讓Squid緩存Drupal網站的内容,而是直接傳遞到Apache了。我看了一下Squid與Drupal的資料,好像不太推薦這樣的組合。

Varnish我沒有用過,可能機制上與Squid類似吧?我們網站的特點是數據量大,訪問很分散,不是那種内容數量少而訪問集中的情況,估計用前端緩存的效果不會太好。

你說的Pressflow我還沒有用過,剛去看了,是對Drupal進行了一些性能優化的專門版本,以後再去詳細了解,謝謝推薦。

James Qi / 祁勁松

我們當時做首頁的時候,開始都設置了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都清空一次基本上就可以了。

另外,我們多數網站都隻是内容展示、查詢,把用戶注冊都關閉了,隻有少數需要用戶提交内容的網站放開了注冊。

James Qi / 祁勁松

發表新回應

Plain text

  • 不允許使用 HTML 標籤。
  • 自動將網址與電子郵件地址轉變為連結。
  • 自動斷行和分段。