01、目標(biāo)

在APP內(nèi)實(shí)現(xiàn)會(huì)員自動(dòng)續(xù)費(fèi)的功能

02、流程

2.1、會(huì)員自動(dòng)續(xù)費(fèi)授權(quán)

會(huì)員自動(dòng)續(xù)費(fèi)本質(zhì)是委托扣款模式。只有用戶完成簽約，商戶才可以對(duì)用戶賬戶進(jìn)行自動(dòng)扣款，從而完成會(huì)員訂單的支付操作。

用戶在應(yīng)用內(nèi)通過(guò)微信或支付寶的SDK完成代扣簽約，微信或支付寶在用戶簽約成功后將簽約信息通過(guò)異步通知的方式通知給商戶后臺(tái)。商戶后臺(tái)需要維護(hù)用戶的簽約信息，簽約ID為核心信息，在訂單的代扣請(qǐng)求中用于驗(yàn)證授權(quán)。

2.2、會(huì)員到期后自動(dòng)發(fā)起續(xù)費(fèi)流程

系統(tǒng)在檢測(cè)用戶會(huì)員即將到期后，發(fā)起該用戶自動(dòng)續(xù)費(fèi)流程。需要完成訂單創(chuàng)建及訂單支付環(huán)節(jié)(代扣)，***在支付通知回調(diào)時(shí)為用戶延遲會(huì)員時(shí)間。續(xù)費(fèi)訂單和普通訂單主要區(qū)別在于是否調(diào)用委托代扣接口。

03、委托扣款授權(quán)

用戶委托扣款授權(quán)是會(huì)員自動(dòng)續(xù)費(fèi)的前提，主要有支付中簽約和純簽約兩種模式。

3.1、支付中簽約

支付的同時(shí)完成代扣協(xié)議的簽約。只需要在原先的下單參數(shù)增加簽約信息就可以支持簽約功能，看上去非常適合我們會(huì)員自動(dòng)續(xù)費(fèi)的場(chǎng)景。在用戶下單購(gòu)買會(huì)員連續(xù)包月之后一并完成簽約功能。

然而在實(shí)踐的過(guò)程中發(fā)現(xiàn)有個(gè)問題忽略了，支付中簽約默認(rèn)是不開啟簽約的，需要用戶手動(dòng)開啟委托代扣。我們是希望可以提高用戶簽約比例的，需要用戶手動(dòng)勾選這一步的操作成本真的太大了，不符合我們的預(yù)期。

3.2、僅簽約

純簽約模式是商戶先通過(guò)前端頁(yè)面調(diào)用純簽約接口與用戶完成代扣協(xié)議簽約，當(dāng)需要扣款時(shí)可調(diào)用申請(qǐng)扣款接口進(jìn)行自動(dòng)扣款。用戶在簽約后商戶后臺(tái)會(huì)接收到回調(diào)通知。

04、方案設(shè)計(jì)

調(diào)整后會(huì)員自動(dòng)續(xù)費(fèi)基本流程如下所示：

4.1、自動(dòng)續(xù)費(fèi)流程優(yōu)化

使用僅簽約接口，不使用支付中簽約接口

僅簽約接口可以限定用戶必須簽約后才可以購(gòu)買連續(xù)包月商品。為了模擬用戶簽約并支付的體驗(yàn)，在用戶簽約成功后由系統(tǒng)發(fā)起自動(dòng)續(xù)費(fèi)流程。

4.2、如何避免會(huì)員簽約后的重復(fù)續(xù)費(fèi)

優(yōu)化流程后，用戶簽約成功之后需要發(fā)起自動(dòng)續(xù)費(fèi)流程。這里需要確保不會(huì)對(duì)用戶重復(fù)續(xù)費(fèi)，這里可以考慮使用簽約ID作為訂單冪等元素。相同的簽約ID只會(huì)發(fā)起一次自動(dòng)續(xù)費(fèi)。

4.3、如何避免會(huì)員到期后的重復(fù)續(xù)費(fèi)

當(dāng)會(huì)員到期后會(huì)發(fā)起自動(dòng)續(xù)費(fèi)流程，這里可以考慮使用會(huì)員到期時(shí)間戳作為訂單冪等元素。若會(huì)員續(xù)費(fèi)成功，會(huì)員到期時(shí)間戳?xí)鄳?yīng)延長(zhǎng)，不會(huì)再觸發(fā)會(huì)員即將到期的邏輯。若會(huì)員續(xù)費(fèi)失敗，會(huì)員到期時(shí)間戳還是不變，也不會(huì)發(fā)起多個(gè)續(xù)費(fèi)訂單。

05、小結(jié)

在功能實(shí)現(xiàn)時(shí)換個(gè)思路可能會(huì)有不一樣的發(fā)現(xiàn)。在這個(gè)功能上，使用僅簽約接口可以模擬用戶支付并簽約的效果，符合我們的預(yù)期