2011-08-22 71 views
1

我目前使用wepay和rails。不要擔心這個帖子與wepay無關。Rails - 創建單獨的表或繞過所有模型驗證?

  1. 因此,當客戶想要從我的網站購買某些東西時,他/她將被重定向到wepay。
  2. 然後,在付款後,wepay會將用戶重定向到/ purchases/received
  3. 經過X段時間後,Wepay還會對/ purchases/callback進行郵寄通知,告訴我付款已被捕獲(信用卡處理速度較慢)

所以我原來的計劃如下:

  1. 用於購買模型,有一個字段,wepay_id和wepay_confirmed。
  2. 當用戶發生在wepay訂單時,重定向/ puchases /接收將創建一個實例購買並保存在我的分貝
  3. 當回調被稱爲查找由wepay_id然後設置wepay_confirmed爲true。

但是,由於我發現X時間量可能非常快,因此/ purchases/received會創建對象之前調用/ purchases/callback。

所以現在我有兩個選擇:

  1. 允許/採購/回調只用ID創建一個空的購買情況,並確認= TRUE。當我這樣做時,我意識到我不再能以傳統方式驗證我的模型。這真讓我感到困惑。
  2. 創建一個名爲Wepay_Confirmed的單獨表。每當調用回調函數時,都要在wepay_confirmed中創建一個條目。將此表中存在的(checkout_id)映射到Purchase.confirmed屬性。

我在想做2.我該怎麼做?我是否必須爲特定模型生成映射到Wepay_Confirmed的腳手架?

如果您有任何其他建議,請回復

+2

爲什麼在將訪問者發送給wepay之前不創建購買實例?另一方面的好處是,您也可以通過這種方式跟蹤放棄的購買。 –

+0

@Josh你會介意作爲一個單獨的答案回答這個問題嗎?我有一些意見要跟進 – disappearedng

+0

@Josh很好的想法,我總是忽略這樣的小細節,這是在這種情況下最簡單的答案。 –

回答

0

如果從第二個辦法,你不需要腳手架它。您可以創建一個遷移並在其他「腳手架」中使用它。腳手架實際上只是一種開始使用資源的方式。我不認爲你的意圖是有一個完整的資源。除非是這樣,否則你可以用它作爲腳手架。

2

我會盡量保持您的應用程序的方式,因爲它確實有意義,但是您應該查看向wepay返回錯誤代碼並讓它們在創建記錄後提交請求。

只需通過電子郵件發送開發商在上和WePay得到這個迴應:

德文 - 嗨,

我們也有自動重試IPN。在 初次嘗試後5分鐘發生重試,如果重試不起作用,我們會在15分鐘後嘗試,然後在一小時後再嘗試 。但是,現在他們只對空的404 響應。

最好的解決方案是實際上只是忽略IPN,如果他沒有 在他的數據庫中有記錄。我們的IPN只告訴 的應用程序通過/ checkout調用查詢結賬細節。他們沒有 結帳的任何細節。因爲無論如何,當他在他的 末端創建結賬對象時,他應該查找 /結帳狀態,因此他不需要IPN告訴他在此 的情況下查詢狀態。

如果這對他不起作用,他也可以發電子郵件給我,電子郵件地址是:[email protected]和 ,我們可以找出解決方案。

安德魯

所以看起來你可以修改你的應用程序的流量忽略IPN的未經備案和手動檢查,或者你可以用404作出迴應,他們將在上述時間間隔重試。

+0

感謝您的電子郵件。我其實很喜歡喬希的建議,所以我暫時會繼續這樣做。 – disappearedng

1

正如我在我的評論中提到的,我個人更傾向於在購買時創建購買記錄,然後將用戶發送到WePay網站,然後將回程和回叫處理爲針對原購買網站完成的操作。

首先,它更準確地匹配交易的實際情況。當用戶從您的網站進行購買時,對我而言這是您應該堅持的一點。

WePay交易的兩個要素(您的網站的回程和收費確認回調)都將按照原始購買記錄進行操作。這還可以讓您看到有多少人在購買WePay時放棄購買流程,這可能會揭示用戶體驗中可能有助於最大化轉化的問題。

1

我創建了一個名爲wepay-rails的寶石,它爲您處理所有這些。在發送付款人給wepay之前,它會創建條目(WepayCheckoutRecord)。它內置一個IPN監聽器,用於處理該記錄的更新。在我的個人導軌應用程序中,我使用WepayCheckoutRecord模型上的狀態機來跟蹤狀態的變化,並隨着狀態在該記錄上的變化而執行「事情」。

我希望有幫助。

Adam -