在第1期和第2期中，我們只考慮了微信和APP下的使用場(chǎng)景，但是依托內(nèi)部資源獲得的流量畢竟是有限的。H5下因不可喚起微信，所以長(zhǎng)期都是以引導(dǎo)下載APP或者關(guān)注公眾號(hào)的形式存在，作用有限。直到有一天，開(kāi)發(fā)GG說(shuō)微信支付支持H5下喚起了，仿佛看到了春天的到來(lái)，跟開(kāi)發(fā)討論了一下，覺(jué)得可行，于是糾集設(shè)計(jì)、后端和支付的程序員立馬搞了起來(lái)。
H5下的免密支付采用的是APP的邏輯，即與用戶(hù)名關(guān)聯(lián)起來(lái)。流程如下：先判斷是否登錄以控制是否展示投保模塊，當(dāng)用戶(hù)在登錄態(tài)下完成信息填寫(xiě)后，觸發(fā)立即支付按鈕喚起微信支付，此時(shí)判斷該賬戶(hù)是否關(guān)聯(lián)了微信免密支付服務(wù)，若關(guān)聯(lián)則完成后續(xù)的存單和發(fā)起扣款請(qǐng)求；若沒(méi)有開(kāi)通則調(diào)用微信H5下支付接口（帶免密支付的），用戶(hù)在完成首期款支付后，在微信的支付完成頁(yè)會(huì)有個(gè)是否開(kāi)通自動(dòng)續(xù)期的勾選操作，若用戶(hù)勾選則微信會(huì)為用戶(hù)自動(dòng)開(kāi)通免密代扣服務(wù)。
為什么不采用微信框架下的開(kāi)通流程呢？微信下的開(kāi)通流程需要將openID與簽約關(guān)聯(lián)起來(lái)，如果可以實(shí)現(xiàn)的話(huà)，就要求商家必須能獲取到用戶(hù)的openID。但是因?yàn)檎麄€(gè)流程并不涉及微信框架下的m站的頁(yè)面交互，僅僅是從外部框架下的H5頁(yè)面直接跳轉(zhuǎn)到微信本身的支付頁(yè)，而調(diào)用微信支付的過(guò)程中并不能獲取到openID，因此無(wú)法實(shí)現(xiàn)。
總結(jié)
3期上線(xiàn)后，百萬(wàn)醫(yī)療項(xiàng)目算是完成了整個(gè)版本的迭代，一個(gè)完整的項(xiàng)目已經(jīng)成型落地。前后歷時(shí)兩個(gè)多月的時(shí)間，上線(xiàn)首日訂單破400，打破健康險(xiǎn)/醫(yī)療險(xiǎn)頻道單品單日銷(xiāo)售記錄，上線(xiàn)60天訂單2000+，實(shí)現(xiàn)預(yù)收保費(fèi)200W+，續(xù)期率高達(dá)97%，但受限于用戶(hù)數(shù)和流量，后勁表現(xiàn)不足，現(xiàn)日均訂單量已減少到十幾單。后續(xù)將通過(guò)與第三方機(jī)構(gòu)合作、頭條等信息流廣告推廣等進(jìn)行引流，提高日單量。
