2008-12-30 65 views
2

我們有一個免費增值產品,如果已經支付了每月訂閱,那麼可以使用某些功能;如果沒有支付,那麼免費功能仍然可用。驗證免費增值產品訂閱服務的方法是有效的

這裏是我正在考慮對其進行處理,但要檢查:

)當有人購買他們的訂閱,將創建

1週期性結算進度。

2)用戶將有一個字段(paid_up)設定爲「Y」

3)當用戶重新登錄時,認證腳本檢查是否paid_up是「Y」。如果是,它創建會話標記

4)我想我需要一個批處理腳本來切換切換。想知道如何去做?存儲成功處理的最後一張信用卡的日期?

回答

0

當然,你會創建一個名爲'last_payment'的列。如果使用MySQL,則可以將其創建爲DATE字段。每次您收到每月付款,我假設信用卡結算公司會在您的網站上發佈一些內容。 (即PayPal發送IPN)。每個這是接收到的時間,你會做一個查詢,如:

UPDATE members SET `last_payment`=CURDATE() WHERE user_id='$user_id'; 

我建議上運行CRON一個腳本運行,每24小時一次,並執行此查詢:

UPDATE members SET paid_up='N' WHERE DATEDIFF(CURDATE(),last_payment) > '30'; 

這更新所有未付款30天或更長時間的記錄,並將pay_up字段設置爲N.然後,您的正常登錄代碼將起作用。

如果你不想使用cron,您可以登錄查詢更改爲類似這樣:

SELECT 1 FROM members WHERE 
username='$user' AND password='$password' 
AND DATEDIFF(last_payment) <= '30'; 

順便說一句,你的信用卡處理公司可能會向您發送POST的方式當一個訂閱取消,這將使您能夠設置paid_up字段N.

希望這會有所幫助。隨意評論,如果您有任何疑問:)

+0

嗯,我可以做到這一點...感謝您獲取特定於代碼的內容,始終熱愛這一點。 – AFG 2008-12-31 06:23:50

+0

如果你喜歡這個,我會很感激,如果你點擊我的名字旁邊的小刻度標記,所以我可以得到一些代表。對於這個答案:-) – 2008-12-31 08:19:23

0

我會從另一端工作,並有付費字段與付費日期存儲在那裏。這樣,您可以讓用戶取消這些付款,並仍能從他們所做的付款中受益。

0

如果經常性結算過程是您在您身邊運行的東西,您可以將這些檢查作爲過程的一部分加入。我會考慮這個問題的方法算法是這樣的:

對於每個對他們的帳戶由於
       運行計費
       如果成功的客戶:
               將0重置爲0
               將其標記爲付費客戶
               繼續到下一個賬號
       否則:
               增加它們的重試計數器
               將警告發送到客戶
               如果他們的重試計數器達到最大值:
                        切換開關以將它們標記爲空

如果其他情況下運行計費並僅告訴您結果,請將「在其帳戶上運行結算」替換爲「從上次計費嘗試中讀取結果」 」。假設您的計費按每天計劃運行,您的重試計數器將執行類似寬限期的操作,以便他們有機會修復計費問題,而不僅僅是因爲他們的卡已過期或因此而撤銷其高級功能。

0

之前寫過一些這些,你應該做幾件事。

首先,如其他人所述,您需要某種類型的paid_through_date字段。這很重要,原因很多,但主要的一點是,如果您的服務器正在關閉,它會爲您提供額外的靈活性,並且您決定用戶應該獲得額外一天的免費服務。只需將他們的paid_through_date值推回一天即可。這也使得免費試用很容易實施。

其次,不要使用諸如Authorize.net的Automated Recurring Billing之類的東西,即使您正在訂閱系統上工作。您希望完全控制付款的安排時間,並且在大多數情況下將該責任卸載到您的網關只是一個壞主意。大多數網關將允許您在其服務器上存儲信用卡。他們會給你一張該卡的身份證,你可以針對該中間身份證而不是卡本身發放費用。

三,LOG ALL TRANSACTIONS。我不能過分強調這一點。實際上,您應該也可以將此日誌公開給用戶。基本上只是他們所做的所有付款,金額和最終餘額的表格。將發票也放入此表中也很常見。發票的金額爲正數,付款和信用金額爲負數,並且只需爲用戶總結所有數據即可獲得最終餘額。如果需要,您可以非常容易地將任意信用額度引入此表。

運行一個cron腳本,每隔24小時觸發一次,檢查用戶需要生成發票的用戶。這個cron腳本應該有三個重要的屬性:首先,如果它由於某種原因不運行,你不應該失去一天的收費。其次,如果它每天運行一次以上,或者如果它在中途中止並重新運行,它不應該向兩次人員收費。第三,如果服務器上的日期偶然更改爲2090,則不應該自動爲所有用戶開具數百萬美元的帳單。同樣,重置到過去的日期(值得注意的是,1970年1月1日)也應該導致它地獄。根據我的經驗,夏時制很難成爲問題。

我認爲這涵蓋了大部分的重要內容,但在結算系統中總是有一些小問題需要注意。