您在這裡

首頁 » Forums » 疑難雜症 » 模組/Modules

紅陽科技 BuySafe 金流連接模組

artt's 的頭像
由 artt 在 2010-08-03 (二) 09:43 發表

Dear all,

目前模組 uc_suntech_buysafe 我已經上傳到 https://drupaltaiwan.org/module/buysafe。

5 月底在評估金流機制時，想說既然國內沒有直接支援 drupal 金流的 3rd party 廠商，那麼跟誰簽都一樣，反正註定要自己開發了。

沒想到綠界的工程師的熱情與眾不同，硬是把它開發出來了。在似乎沒有對 drupal 有很深的認識之下，快速的提供介面出來，真是令人佩服。

Anyway, 我都已經答應紅陽的陳小姐要簽了，也莫名固執地以為哪家廠商都一樣。因此在上週拿到測試帳號之後，還是排時間先把這件工作做掉。

雖然我已經做了 20 多次的正向、反向的單元測試並且結果非常好，我還是要事先做個聲明：這是個 as-is 的成品，請自行確認使用結果。

Art

各位加油 , 我是覺得百家爭鳴很好啦. 本來幾家同業比的就該是在服務上, 而不是在看誰先作出模組 , 以 OPEN Source 的觀念來看, 綠界作出來, 就是不怕被參考, 服務才是重要的, by the way .. 之前沒有補足的模組順道一併提供在 http://drupaltaiwan.org/forum/20100520/4307 ,如此六種金流就補足了. 之前有點瓶頸在某些付款方式並非即時知道結果的, 得靠幕後方式運作, 但這部份 ubercart 實在有夠刁鑽, 或者說我功力不夠, 真的對 Drupal 不熟, 用硬幹的方式還是交卷先 , 所以目前非即時回傳成功付款資訊的金流如 虛擬帳號 , 超商條碼 ,超商代碼等方式也能在消費者付完款後將付款狀態回傳給 ubercart 了. 有夠累.... 有興趣先用看看, 如有使用上的問題或建議還請不吝指教..

藍新的金流模組我這邊上禮拜就開發完畢了，現在正在測試中，如沒有其他要修改的地方，下禮拜我把使用文件寫一寫就可以公開了～
這裡可以講一下開發心得，有些沒有及時回傳狀態的付款方式，我就讓它保持在 in_checkout ，然後靠 cron 去撈銷帳資訊來比對。
撈的到就表示這筆單有接受，撈不到就 cancel 這筆單。

只要不是一步到位的付款方式都有可能產生斷點，在處理上都要注意上面的這種狀況。
比較有可能發生的付款方式有支付寶跟WebATM，信用卡不太會是因為它會主動 feedback 去觸發我們設定的一個網址。
其他的我都可以包裹一整個付款方式的資訊傳給藍新的付款伺服器，接不接受立即有傳回值可以檢查。

martellwang, tokimeki 二位真強。我想今年起 Drupal 大量應用在商業網站應是指日可待。

關於如果是不連續收款動作，建議「Checkout 之後，等待收款動作完成」這種狀況，可以在 Store Administration -> Configuration -> Order Setting 那裡再建立新的 status, 例如 waiting payment, 它的 State 建議可以仍設為 In Checkout。

Ubercart 對於 State 與 Status 的應用貫穿了整個 Ubercart 系統，狀態(State)與狀況(Status) 的邏輯又可以接續到 Ubercart 中的 Conditional Actions 繼續使用。這樣子您的收款動作又可以接回到 Ubercart 系統的預設處理還輯了。

謝謝建議 , 我再來 check 看看我的流程是否能如您所說的那樣去運轉, 目前綠界有幾家客戶拿去用了, 我也在等他們回報我使用心得 , 目前綠界模組的一些畫面還沒美化過 , 以實用為優先考量, 有建議就會越來越好用的.

針對綠界金流在此做個說明

現綠界金流已提供六種付款方式(ECPay 線上刷卡/WebATM/PayPal/超商條碼/超商代碼/銀行虛擬帳號)

但由於（超商條碼/超商代碼/銀行虛擬帳號），無法馬上得到付款狀態，故無法和（ECPay 線上刷卡/WebATM/PayPal）一樣皆為　In_checkout

下面是訂單進行時,訂單狀態順序表現
------------------------------------------------------------------------------------------------------------------------------------------
付款方式 [ Payment 未送出前(訂單確認畫面) > Payment 送出> 付款成功]
ECPay 線上刷卡/WebATM/PayPal [ In_checkout > In_checkout > Payment_received]
超商條碼/超商代碼/銀行虛擬帳號 [ In_checkout > pending > Payment_received]
------------------------------------------------------------------------------------------------------------------------------------------

在 Ubercart 中一張訂單由生到滅是有 state 的，分別為 canceled, in checkout, post checkout, payment received, completed，這幾個 state 是由 ubercart 固定的，並且也應用在 Ubercart 中的 conditional actions 裡頭。Order 一出生就處於 in checkout 的狀態(state)。

而 state 太粗了，因此每個 state 下又有幾種 status (狀況)。status 是開發者可以再新增的。參考我上傳的這張圖片(取自 administer -> store administration -> configuration -> order settings)。

我追過 google checkout, 2checkout, paypal 的程式，它們在收款這佪地方有增加 status，有的把這個 status 仍留在 state: in checkout 的狀態，有的則把新增加的 status 放在 state: post checkout 裡頭。

所以，如果是等待確認收款的時候，定一個叫做 waiting payment 的 status，而這個 status 掛在 in checkout 或是 post checkout 的 state 底下，我想應該都是可以的。

必要的話（我只使用信用卡收款，不曉得不連續收款時還有哪些動作／情境要考慮），也可以再設定/coding 一下相關的 conditional actions，讓整個動作串連起來。這樣子，該處理出貨的，該扣庫存的，該發 notification 的，就由 ubercart 接手自動處理了。甚至還可以設定自己的自動化動作，讓訂單流程更系統化。Ubercart 在這個地方做得還不錯。

我稍微說明一下這幾個 status 的用途：

  • canceled：訂單取消時用。可以是手動取消 (你必須確認代收單位也願意配合消單)、或是代收單位沒有訂單紀錄、經過一段時間訂單仍未完成 (例如：信用卡的單經過 21 天未結帳)
  • in_checkout：未完成的訂單。每當按下結帳連結時，訂單狀態就會進入 in_checkout ，除非取消或是完成付款程序，否則訂單就會處於此狀態。要注意的是，每按一次結帳連結，就會產生一張新的訂單，所以必須有個機制去檢查此狀態的訂單是否是無效訂單。
  • pending：待處理訂單。當代收單位接受付款時，訂單的狀態會處於此狀態 (確切來說，是確認代收流程無誤後，呼叫 uc_cart_complete_sale 來使訂單改變狀態)。
  • processing：訂單處理中。這個狀態我沒有使用，請其他網友補充使用情境吧。
  • payment_received：收到付款。向代收單位撈銷單資料，若已銷單 (收到款項) 則訂單會處於此狀態 (確切來說，是確認銷單無誤後，呼叫 uc_payment_enter 來使訂單改變狀態)。
  • completed：訂單完成。確認銀貨兩訖後，由商店的管理人員手動改變訂單的狀態。