某移動(dòng)APP跳轉(zhuǎn)至微信支付的完整流程
編輯導(dǎo)語:我們平時(shí)使用的移動(dòng)APP是如何跳轉(zhuǎn)到微信支付的呢?本篇作者就給我們介紹了移動(dòng)APP跳轉(zhuǎn)至微信支付的完整流程,一起來看一下。
一
聲明一下,我說的移動(dòng)APP指的是移動(dòng)端的APP(下文的移動(dòng)APP、商戶APP指的都是一個(gè)意思),不是指充話費(fèi)的運(yùn)營商。首先我們還是先從一些概念入手,來談?wù)勚Ц丁?/p>
問自己一個(gè)問題:你接觸過的支付場景有哪些?
直接上圖吧。
這個(gè)圖我不再做過多的解釋。下面看一個(gè)例子:
二
在這個(gè)圖中,我們可以發(fā)現(xiàn),商家通過生產(chǎn)廠家把零部件生產(chǎn)并組裝出來之后形成汽車(產(chǎn)品),當(dāng)這個(gè)產(chǎn)品通過商家賣給用戶或者消費(fèi)者的時(shí)候,這個(gè)產(chǎn)品就變成了有商業(yè)性質(zhì)的商品了,也就發(fā)生了市場行為,在整個(gè)市場行為里面有商家的銷售行為、買家的購買行為、還有涉及到雙方皆有的交易環(huán)節(jié)。這個(gè)市場行為里面因?yàn)橘I賣關(guān)系的產(chǎn)生,所以在商家和買家之間形成了債券和債務(wù)的關(guān)系,我們再來看跟我們關(guān)系比較密切的例子:
(1)消費(fèi)者老江從某公司買辦公用品,辦公用品從產(chǎn)品變成商品,進(jìn)入交易。
這就是支付存在的前提,即存在買賣的交易。
(2)辦公用品從該公司轉(zhuǎn)移到老江手里, 這就完成了商品所有權(quán)的轉(zhuǎn)移。
這個(gè)轉(zhuǎn)移也導(dǎo)致了老江和該公司之間形成了債權(quán)和債務(wù)關(guān)系(債權(quán)和債務(wù)的含義自己去百度查)。
(3)老江通過現(xiàn)金或者其他方式來完成支付,清償了這個(gè)債務(wù)。
(4)老江拿到辦公用品,辦公用品從商品變?yōu)橄M(fèi)品,交易過程完成。
這是一個(gè)完整的交易過程,我們基于這樣的交易過程來給支付下個(gè)定義:
基于上面的這個(gè)思考,于是為了保障消費(fèi)者的權(quán)益,中間機(jī)構(gòu)擔(dān)保形式的支付形式漸漸在商業(yè)的行為中,如下圖:
比如現(xiàn)在的支付寶、微信本質(zhì)上也是一種擔(dān)保機(jī)構(gòu)。
第三方支付的概念:是指具備一定實(shí)力和信譽(yù)保障的獨(dú)立機(jī)構(gòu)(阿里巴巴),具有國家頒發(fā)的合法的支付業(yè)務(wù)經(jīng)營許可證(支付牌照)并通過與銀聯(lián)或網(wǎng)聯(lián)對接而促成交易雙方進(jìn)行交易的網(wǎng)絡(luò)支付模式;
第三方支付的業(yè)務(wù)模式:在第三方支付模式當(dāng)中,買方選購商品后,使用第三方平臺(tái)提供的賬戶進(jìn)行貨款支付(買家先把錢支付給第三方),并由第三方通知賣家貨款到賬、要求發(fā)貨;買方收到貨物,檢驗(yàn)貨物并確認(rèn)后,第三方支付再將款項(xiàng)轉(zhuǎn)至賣家賬戶;只不過在這個(gè)過程里面,第三方支付必須要是國家合法的機(jī)構(gòu),這個(gè)就是支付牌照。
再回過頭看下三方支付的業(yè)務(wù)模式:
國內(nèi)比較著名的持牌第三方支付公司有:
三
接下來我們看下電商交易的過程,以下為案例:業(yè)務(wù)場景(以下流程均以該場景為例):
用戶在蘇寧易購APP提交訂單并通過微信支付完成扣款,我們先看看頁面跳轉(zhuǎn)。
這個(gè)是我們每個(gè)人在購買一個(gè)商品的時(shí)候,我們?nèi)庋勰芸吹玫降捻撁嫣D(zhuǎn),真正的交易環(huán)節(jié)是不是這樣的,看下面的圖:
這個(gè)我今天要跟大家分享的主要內(nèi)容:首先思考一個(gè)問題,在這個(gè)業(yè)務(wù)流程中,數(shù)據(jù)流程圖怎么畫出來?
同樣我們一樣要先拿到微信的接口文檔,再去設(shè)計(jì)流程。
我們在之前的文章中提到了,對于微信支付通道,必須要先拿到預(yù)定單的字段,同樣,我們設(shè)計(jì)的流程如下:
接下來就是從蘇寧易購跳轉(zhuǎn)到微信APP的支付流程:
上圖中的右下角有一個(gè)問題,想一想。我們再把上面的流程深入下:
整個(gè)從移動(dòng)APP(商戶APP、移動(dòng)APP)跳轉(zhuǎn)到微信支付的完整流程就是這樣的:
微信交易狀態(tài)主動(dòng)查詢的接口:
再來思考一個(gè)問題:如果商戶系統(tǒng)查詢后依然無結(jié)果無反饋,該怎么處理?
接著查,一般查詢間隔時(shí)間為2n秒,n為自然數(shù),一般不超過5,比如第一次查詢是在13秒開始的,下次查詢在15秒開始,再下一次在19秒開始,第三次查詢在21秒開始。
如果連續(xù)超過5次反復(fù)查詢依然無結(jié)果,不再繼續(xù)查詢,可認(rèn)為服務(wù)器已宕機(jī),此時(shí)需要人工干預(yù),盡快聯(lián)系運(yùn)維人員定位原因。
對賬怎么對?
請關(guān)注下期,再見。
本文由 @產(chǎn)品經(jīng)理研究站 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
5:對于支付的系統(tǒng)流程及關(guān)鍵邏輯梳理得很清楚,收獲很多,感謝。
收銀臺(tái)如果是通過小程序方式來完成的話,這個(gè)流程是怎么樣的?
你好,有個(gè)疑問希望解答一下。
我之前做過一個(gè)購買應(yīng)用的app,最開始是以支付寶的同步通知為支付成功的判斷標(biāo)準(zhǔn),后來測試發(fā)現(xiàn)有bug,頁面中顯示的支付狀態(tài)是服務(wù)端的訂單狀態(tài),因?yàn)橹Ц秾毜漠惒酵ㄖ醒舆t,在異步通知到達(dá)之前,應(yīng)用顯示為未購買狀態(tài)。
后來改為以異步通知為準(zhǔn),當(dāng)app收到同步通知后,主動(dòng)向服務(wù)端查詢訂單狀態(tài),但這樣也有個(gè)問題,異步通知是有延遲的,當(dāng)查詢的時(shí)候,如果因?yàn)檠舆t還沒到,依然會(huì)返回未支付狀態(tài)。
最后的解決方案是:app收到同步通知后,進(jìn)入loading狀態(tài),此時(shí)隔1s請求一次支付狀態(tài),當(dāng)查詢到服務(wù)端訂單狀態(tài)成功后,才算支付成功。這個(gè)方案也有點(diǎn)問題,網(wǎng)絡(luò)順暢的時(shí)候,異步通知其實(shí)不到1s就返回到服務(wù)端了,但這個(gè)方案至少要用戶等1s,體驗(yàn)不太好,我感覺apple pay有可能就是這樣做的。
關(guān)于照顧用戶體驗(yàn)方面,有沒有什么更好的方案可以使用?
這是講得最清楚的文章!可以求1份圖嗎?
這種圖文介紹一起來挺好的,介紹的也很詳細(xì),感謝作者
這不是產(chǎn)品是技術(shù)吧,這么詳細(xì)
地道的產(chǎn)品
牛
真的一個(gè)很簡單的操作,背后卻飽含著并不簡單的設(shè)計(jì)
說的對
簡而言之,需要第三方的支付公司的參與,哈哈哈哈,不知道這樣理解對不對,這個(gè)跟每個(gè)人都息息相關(guān),但是對我這方面來說,理解起來還是有點(diǎn)難的。
對,需要和三方支付對接
講得十分清楚和完整,思路更加清晰了, 謝謝分享!
持續(xù)關(guān)注
哇中間的程序這么多這么復(fù)雜,謝謝分享,學(xué)到啦!
中間的程序原來有這么多,了解了了解了,謝謝分享!