本發(fā)明涉及電子商務(wù)
技術(shù)領(lǐng)域：
，更具體地說，涉及一種多支付渠道選擇的方法及系統(tǒng)。
背景技術(shù)：
：隨著網(wǎng)絡(luò)支付渠道的日益增長，各種手機話費支付、充值卡支付、電子錢包支付等層出不窮，而應(yīng)用(包含web/wap站點、app等)也越來越多地存在支付的需求，各種應(yīng)用需要在多種支付渠道之間進行選擇，在面對多種支付渠道的時候，如何能快速、準(zhǔn)確地選擇符合條件的渠道并有序的顯示給用戶選擇是一個需要解決的問題?，F(xiàn)有的網(wǎng)絡(luò)支付的方案中，每個應(yīng)用集成了各種支付渠道以完成支付需求，在對各種支付渠道進行選擇時，支付渠道的顯示和排列方式固定，不夠靈活，并且缺乏針對多國家支付的處理。技術(shù)實現(xiàn)要素：本發(fā)明要解決的技術(shù)問題在于，針對如何快速而準(zhǔn)確地選擇符合條件的支付渠道及現(xiàn)有網(wǎng)絡(luò)支付的缺陷，提供一種多支付渠道選擇的方法及系統(tǒng)。本發(fā)明解決上述問題的技術(shù)方案是提供一種多支付渠道選擇的方法，該方法包括以下步驟：S1、用戶通過APP向支付渠道選擇模塊發(fā)送支付請求；S2、所述支付渠道選擇模塊根據(jù)所述支付請求選擇支付渠道，生成支持所述支付請求的支付渠道的支持列表，并顯示給所述用戶以供所述用戶選擇。在上述多支付渠道選擇的方法中，在所述步驟S2之前，還包括以下步驟：所述支付渠道選擇模塊分析所述支付請求的參數(shù)，其中，所述支付請求的 參數(shù)包括訪問類型和國家碼；根據(jù)所述支付請求的參數(shù)，判斷所述支付請求是否指定了支付渠道，若指定了支付渠道，則執(zhí)行下一步驟；判斷指定的支付渠道是否支持所述支付請求，若所述指定的支付渠道支持所述支付請求，則進行具體的支付操作。在上述多支付渠道選擇的方法中，所述步驟S2包括以下步驟：a.判斷支付渠道是否支持所述支付請求的訪問類型，若支持，則執(zhí)行下一步驟，否則顯示“支付渠道不支持當(dāng)前的支付請求”；b.判斷所述支付請求是否是WAP訪問，若是，則執(zhí)行下一步驟，否則執(zhí)行步驟e，否則顯示“支付渠道不支持當(dāng)前的支付請求”；c.判斷支付渠道是否支持所述支付請求的網(wǎng)絡(luò)類型，若支持，則執(zhí)行下一步驟，否則顯示“支付渠道不支持當(dāng)前的支付請求”；d.判斷支付渠道是否支持所述支付請求的APN接入點，若支持，則執(zhí)行S下一步驟，否則顯示“支付渠道不支持當(dāng)前的支付請求”；e.檢查支付渠道是否能夠通過所述APP的黑白名單過濾，若通過，則執(zhí)行下一步驟，否則顯示“支付渠道不支持當(dāng)前的支付請求”；f.檢查所述APP是否能夠通過支付渠道的黑白名單過濾，若通過，則顯示支付渠道支持所述支付請求，并將該支付渠道增加到所述支持列表中。在上述多支付渠道選擇的方法中，在所述步驟a之前還包括：判斷支付渠道是否支持所述支付請求的國家碼。在上述多支付渠道選擇的方法中，所述步驟S2進一步包括：設(shè)置支付渠道的優(yōu)先等級，根據(jù)該優(yōu)先等級對所述支持列表的支付渠道進行排序。本發(fā)明還提供了一種多支付渠道選擇的系統(tǒng)，該系統(tǒng)包括多個支付渠道，所述系統(tǒng)還包括多個APP和支付渠道選擇模塊，其中：所述APP用于向所述支付渠道選擇模塊發(fā)送支付請求；所述支付渠道選擇模塊用于根據(jù)所述支付請求選擇支付渠道，生成支持所述支付請求的支付渠道的支持列表，并顯示給用戶以供所述用戶選擇。在上述多支付渠道選擇的系統(tǒng)中，所述支付渠道選擇模塊包括：分析模塊，用于分析所述支付請求的參數(shù)，其中，所述支付請求的參數(shù)包括訪問類型和國家碼；第一判斷模塊，用于根據(jù)所述支付請求的參數(shù)，判斷所述支付請求是否指定了支付渠道；第二判斷模塊，用于判斷指定的支付渠道是否支持當(dāng)前的所述支付請求，若所述指定的PC支持所述當(dāng)前的支付請求，則進行具體的支付操作。在上述多支付渠道選擇的系統(tǒng)中，所述支付渠道選擇模塊還包括：第三判斷模塊，用于依次判斷支付渠道是否支持所述支付請求的訪問類型、所述支付請求是否是WAP訪問、支付渠道是否支持所述支付請求的網(wǎng)絡(luò)類型以及支付渠道是否支持所述支付請求的APN接入點；檢查模塊，用于依次檢查支付渠道是否能夠通過所述APP的黑白名單過濾以及檢查所述APP是否能夠通過支付渠道的黑白名單過濾。在上述多支付渠道選擇的系統(tǒng)中，所述支付渠道選擇模塊還包括：第四判斷模塊，用于判斷支付渠道是否支持所述支付請求的國家碼。在上述多支付渠道選擇的系統(tǒng)中，所述支付渠道選擇模塊還包括：設(shè)置模塊，用于設(shè)置支付渠道的優(yōu)先等級；排序模塊，用于根據(jù)該優(yōu)先等級對所述支持列表的支付渠道進行排序。本發(fā)明的多支付渠道選擇的方法及系統(tǒng)涵蓋了多國家支付的情況，定義了通用的支付請求參數(shù)，方便用戶選擇支付渠道，同時，對支持支付請求的支持列表進行了靈活的排序，結(jié)合了用戶的個人習(xí)慣。此外，將排序后的支持列表顯示出來以供用戶選擇，簡化了APP對支付的處理，使APP能夠?qū)Ｗ⒂谧陨順I(yè)務(wù)邏輯處理。附圖說明圖1是本發(fā)明的多支付渠道選擇的方法的流程圖。圖2是本發(fā)明的多支付渠道選擇的方法實施例的流程圖。圖3是本發(fā)明的判斷支付渠道是否符合當(dāng)前的支付請求的流程圖。圖4是圖2中的步驟S206的具體實現(xiàn)的流程圖。圖5是本發(fā)明的多支付渠道選擇的系統(tǒng)的結(jié)構(gòu)示意圖。圖6是實施本發(fā)明的多支付渠道選擇系統(tǒng)時的交互流程圖。圖7是本發(fā)明的支付渠道選擇模塊實施例的結(jié)構(gòu)框圖。具體實施方式如圖1所示，是本發(fā)明的多支付渠道選擇的方法的流程圖。該方法包括以下步驟：S1、用戶通過APP向支付渠道選擇模塊發(fā)送支付請求；在此步驟中，APP(application，應(yīng)用)使用HTTPGET和POST向支付渠道選擇模塊發(fā)送支付請求，當(dāng)然，支付請求需要進行加密或者簽名以確保請求真實有效，具體的加密或者簽名在此不進行詳細說明。進一步地，不同的用戶使用的APP不同，APP的參數(shù)包括應(yīng)用ID、應(yīng)用名稱、黑白名單過濾標(biāo)識以及過濾名單列表，其中，應(yīng)用ID表示不同的APP的編號；應(yīng)用名稱表示不同的應(yīng)用，如京東、手機天貓、美團等；黑白名單過濾標(biāo)識表示該APP中支持或者不支持的支付渠道，其包括三種狀態(tài)，分別為：白名單、黑名單以及關(guān)閉，白名單表示只允許使用該白名單的過濾列表當(dāng)中的支付渠道，黑名單表示不允許使用該黑名單的過濾列表中的支付渠道，關(guān)閉則表示該黑白名單過濾不起效。S2、所述支付渠道選擇模塊根據(jù)所述支付請求選擇支付渠道，生成支付所述支付請求的支付渠道的支持列表，并顯示給所述用戶以供所述用戶選擇。進一步地，支付渠道包括以下參數(shù)：渠道ID，渠道的唯一編碼；渠道名稱；渠道類型，如手機話費支付、第三方支付等；渠道所支持國家，該參數(shù)可以為多個國家；支持的運營商列表；渠道狀態(tài)，如正常、關(guān)閉、暫停等；渠道支持的訪問方式，如WEB、WAP；支持的WAP連接方式，如移動網(wǎng)絡(luò)、WIFI；允許連接網(wǎng)絡(luò)列表，如移動網(wǎng)絡(luò)名稱等；渠道優(yōu)先級，該參數(shù)值越高表示越優(yōu)先顯示該支付渠道，同一支付渠道在不同的國家對于不同的應(yīng)用中可以有不同的優(yōu)先級；黑白名單過濾標(biāo)識以及過濾列表。支付渠道選擇模塊根據(jù)支付請求進行選擇支付渠道前，先對支付請求進行分析，分析出支付請求所包含各個參數(shù)，如用戶常用渠道列表、國家碼、訪問類型等，具體的支付請求的參數(shù)及相應(yīng)的說明如下表：為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實施例，對本發(fā)明進行進一步詳細說明。應(yīng)當(dāng)理解，此處所描述的具體實施例僅用以解釋本發(fā)明，并不用于限定本發(fā)明。如圖2所示，是本發(fā)明的多支付渠道選擇的方法實施例的流程圖。在本實 施例中，該方法包括以下步驟：S201、用戶在APP上點擊支付；此時，用戶在APP上購買某商品或支付某費用等時。S202、該APP向支付渠道選擇模塊發(fā)送支付請求；此時，該APP傳遞支付請求的參數(shù)給支付渠道選擇模塊。S203、支付渠道選擇模塊分析當(dāng)前的支付請求的參數(shù)；此時，分析該APP傳遞的支付請求的參數(shù)是否符合要求，如當(dāng)前的支付請求的參數(shù)是否包括了必選參數(shù)、參數(shù)值是否符合要求等。S204、根據(jù)當(dāng)前的支付請求的參數(shù)，判斷當(dāng)前的支付請求是否指定PC(PAYMENTCHANNEL，支付渠道)，若指定了PC，則執(zhí)行S205，否則執(zhí)行S206；S205、判斷指定的PC是否支持當(dāng)前的支付請求，若該指定的PC支持當(dāng)前支付請求，則進行具體的支付操作，即根據(jù)支付項計算對應(yīng)的支付金額，以進入渠道支付處理，否則執(zhí)行S208；在此步驟中，判斷指定的PC是否支持當(dāng)前的支付請求，即判斷支付渠道是否符合支付請求，具體的步驟將在下面進行詳細的說明，在此不再贅述。S206、根據(jù)當(dāng)前支付請求的參數(shù)選擇支持當(dāng)前支付請求的PC，生成支持當(dāng)前支付請求的支付渠道的支持列表，并將該支持列表進行排序，若沒有支持該支付請求的PC，執(zhí)行步驟S208；S207、顯示支付渠道的支持列表，供用戶選擇；此時，用戶在列表中選擇支付渠道時，進行具體的支付操作，即根據(jù)支付項計算對應(yīng)的支付金額，以進入渠道支付處理。S208、顯示“不支持當(dāng)前支付請求”。如圖3所示，是本發(fā)明的判斷支付渠道是否符合當(dāng)前的支付請求的流程圖。在本實施例中，判斷支付渠道是否符合當(dāng)前的支付請求是為了選擇支持渠道，其具體包括以下步驟：S301、判斷PC是否支持支付請求的visitType(訪問類型)，若支持，則執(zhí)行S302；在此步驟中，若不支持則顯示“支付渠道不支持當(dāng)前的支付請求”。S302、判斷當(dāng)前的支付請求是否是WAP訪問，若是，則執(zhí)行S303，否則執(zhí)行S305；S303、判斷PC是否支持當(dāng)前的支付請求的NetworkType(網(wǎng)絡(luò)類型)，若支持，則執(zhí)行S304；在此步驟中，若不支持則顯示“支付渠道不支持當(dāng)前的支付請求”。S304、判斷PC是否支持當(dāng)前的支付請求的APN接入點，若支持，則執(zhí)行S305；在此步驟中，若不支持則返回“支付渠道不支持當(dāng)前的支付請求”。S305、檢查PC是否能夠通過APP的黑白名單過濾，若通過，則執(zhí)行S306；在此步驟中，若不通過則返回“支付渠道不支持當(dāng)前的支付請求”。S306、檢查APP是否能夠通過PC的黑白名單過濾，若通過，則顯示支付渠道支持當(dāng)前支付請求，并將該支付渠道增加到所述支持列表中在此步驟中，若不通過則顯示“支付渠道不支持當(dāng)前的支付請求”。在本實施例中，通過上述步驟，可以確定指定的支付渠道是否符合當(dāng)前的支付請求，同時也可以選擇出符合當(dāng)前的支付請求的支付渠道。如圖4所示，是圖2中的步驟S206的具體實現(xiàn)的流程圖。在本實施例中，根據(jù)支付請求的參數(shù)選擇支付渠道，具體包括以下步驟：S401、獲取所有支付渠道，保存到渠道列表中；S402、判斷渠道列表是否為空，如該列表不為空，則執(zhí)行S403，否則返回空；S403、根據(jù)支付請求的參數(shù)迭代出支持當(dāng)前支付請求的支持列表；在該步驟中，具體包括以下步驟：判斷支付渠道是否支持當(dāng)前支付請求的國家碼(COUNTRY_CODE)；判斷支付渠道是否支持當(dāng)前支付請求，若支持，則將該支付渠道增加到支持當(dāng)前支付請求的渠道列表中。此部分內(nèi)容，上述已進行詳細說明，如圖3所示，為了節(jié)省篇幅，在此不再贅述。S404、對支持當(dāng)前支付請求的支持列表進行排序。在此步驟中，可以根據(jù)渠道優(yōu)先級控制，對支持當(dāng)前支付請求的渠道列表進行排序。下面將對渠道優(yōu)先級控制的排序進行詳細說明：有時為了滿足特定的排序要求，例如開拓某些支付渠道的市場或者是某些渠道要進行打折優(yōu)惠，需要控制不同支付渠道的展示先后順序，為了滿足這種要求，需要對于PC進行優(yōu)先級配置，一個渠道在不同的國家、針對不同的應(yīng)用，可以有不同的優(yōu)先級(Priority)。為了能夠在用戶常用渠道之前顯示指定的渠道，可以通過渠道優(yōu)先級等級(PriorityGrade)來控制，當(dāng)PriorityGrade＝0時，渠道為普通渠道，排序遵照用戶常用渠道和普通渠道的正常排序順序顯示，當(dāng)PriorityGrade＝1時，渠道將優(yōu)先于用戶常用渠道和普通渠道并按照優(yōu)先級排序顯示。為對支付渠道進行優(yōu)先級控制，對支付渠道設(shè)置如下表的優(yōu)先級配置參數(shù)，以設(shè)置支付渠道的優(yōu)先級：進一步地，設(shè)置支付渠道的優(yōu)先級，具體包括以下步驟：根據(jù)支付請求中的確定的CC或者是MCC映射找到country(需要預(yù)先配置CC、MCC和country的映射關(guān)系，例如CC＝86，MCC＝460映射country＝CN)；在優(yōu)先級配置數(shù)據(jù)當(dāng)中獲取指定國家和應(yīng)用的渠道(country＝CN，并且APP＝APP1)，保存到集合優(yōu)先支付渠道列表(priorityChannelList)中；在優(yōu)先級配置數(shù)據(jù)當(dāng)中獲取只有默認優(yōu)先級的渠道(country為空并且APP為空)，保存到集合默認優(yōu)先支付渠道列表(defaultPriorityChannelList)中；對defaultPriorityChannelList當(dāng)中的渠道，判斷該渠道是否在priorityChannelList當(dāng)中存在，若不存在，將該渠道加入到priorityChannelList 中；對于priorityChannelList中的渠道先按照priorityGrade的降序進行排序，且對相同priorityGrade的渠道按照priority進行排序；得到支付渠道的優(yōu)先級順序。下面舉例來說明根據(jù)渠道優(yōu)先級控制來對支持當(dāng)前支付請求的渠道列表進行排序：payment_channelcountryAPPprioritypriorityGradePC1CNAPP161PC1USAPP150PC2CNAPP180PC2USAPP161PC3CNAPP190PC3USAPP180PC450PC4USAPP170優(yōu)先級排序示例結(jié)果：對于中國用戶(country＝CN)的支付渠道排序如下：PC1(priorityGrade為1priority為6)；PC3(priorityGrade為0priority為9)；PC2(priorityGrade為0priority為8)；PC4(priorityGrade為0priority為5)。對于美國用戶(country＝US)的支付渠道排序如下：PC2(priorityGrade為1priority為6)；PC3(priorityGrade為0priority為8)；PC4(priorityGrade為0priority為7)；PC1(priorityGrade為0priority為5)。如果支付請求中傳遞了FavoriteChannel，則需要將對應(yīng)的PC按順序調(diào)整到priorityGrade為0的渠道列表的最前部，例如在上述對于美國用戶的例子中傳遞 了FavoriteChannel為PC1，則支付渠道排序變?yōu)椋篜C2(priorityGrade為1priority為6)；PC1(priorityGrade為0priority為5用戶常用渠道)；PC3(priorityGrade為0priority為8)；PC4(priorityGrade為0priority為7)。在此步驟中，還可以根據(jù)用戶的常用支付渠道對支持當(dāng)前支付請求的渠道列表進行排序。其中，APP可以緩存或者記錄用戶的常用支付渠道，例如web類型的使用cookie，在提交支付請求時將用戶常用的支付渠道(或者渠道列表)傳遞給支付渠道選擇模塊，PCSM將優(yōu)先顯示這些支付渠道供用戶選擇(當(dāng)然，前提是這些支付渠道滿足當(dāng)前的支付請求)，例如用戶最近三次的支付渠道分別為pc1、pc2、pc3，而支付渠道pc2因為某些原因暫時無法使用，在PCSM當(dāng)中的pc2的渠道狀態(tài)被設(shè)置為暫停，當(dāng)提交支付請求后，PCSM檢查提交的常用渠道，排除pc2，最終展現(xiàn)給用戶的渠道為pc1、pc3。進一步地，在此步驟中，還可以結(jié)合支付熱度對支持當(dāng)前支付請求的渠道列表進行排序，當(dāng)渠道優(yōu)先級相同的情況下，PCSM將通過分析支付成功的次數(shù)，優(yōu)先顯示支付成功次數(shù)多的支付渠道，即支付熱度。PCSM需要記錄所有支付請求，用于進行統(tǒng)計，數(shù)據(jù)項至少包含：AppID應(yīng)用IDPayRequestID支付請求IDPayItemCode支付項PayRequestTime支付請求時間Country國家PayChannel支付渠道PayStatus支付狀態(tài)：等待支付、支付成功、支付失敗PCSM在后臺對于支付請求進行分析統(tǒng)計，每隔一段時間，統(tǒng)計當(dāng)前時間向前一定時間跨度內(nèi)各渠道按照國家、應(yīng)用、支付項進行分類后的支付成功的請求次數(shù)，在進行渠道展示的時候優(yōu)先顯示那些成功次數(shù)多的渠道。需要設(shè)定定時器timer，每隔t1時間間隔，統(tǒng)計當(dāng)前時間tc到tc向前減t2時間長度的時間點 (t3)之間的每個APP的每個payItem在每個country使用每種渠道支付成功的次數(shù)。如下表，統(tǒng)計的一示例，AppIDPayRequestIDPayItemCodePayRequestTimeCountryPayChannelPayStatusAPP1100001payItem3020150305123000CNPC1successAPP2200001payItem920150306123100CNPC1successAPP2200011payItem3020150306123200CNPC1successAPP1100002payItem520150306133200USPC2successAPP1100003payItem3020150306143300CNPC2failAPP1100004payItem3020150306153400CNPC2successAPP1100005payItem3020150306163500CNPC2successAPP1100015payItem3020150306163600CNPC2successAPP1100006payItem3020150306173600CNPC1successAPP1100007payItem3020150306183600CNPC1successAPP3300001payItem420150306123700CNPC3success時間間隔t1＝3小時，時間跨度t2＝12小時，當(dāng)前時間tc(timer最近一次觸發(fā)時間)＝20150307000000，則t3＝tc-t2＝2015030612000000，統(tǒng)計2015030612000000到20150307000000之間AppID、PayItemCode、Country、PayChannel都相同的并且狀態(tài)為成功的支付請求的數(shù)量，得到的成功次數(shù)統(tǒng)計，如下表：AppIDPayItemCodeCountryPayChannelcountAPP1payItem30CNPC14APP1payItem30CNPC23APP1payItem5USPC21APP2payItem9CNPC12APP3payItem4CNPC31最終在20150307000000時間點后支付請求的相關(guān)參數(shù)AppID＝APP1、PayItemCode＝payItem30、Country＝CN時，渠道PC1將優(yōu)先于PC2顯示。如圖5所示，是本發(fā)明的多支付渠道選擇的系統(tǒng)的結(jié)構(gòu)示意圖。在本發(fā)明中，該系統(tǒng)包括多個支付渠道、多個APP以及支付渠道選擇模塊，其中，每個 APP對應(yīng)不同的用戶，APP用于向支付渠道選擇模塊發(fā)送支付請求；支付渠道選擇模塊用于根據(jù)支付請求選擇支付渠道，生成支持所述支付請求的支付渠道的支持列表，并顯示給用戶以供用戶選擇。進一步地，如圖6所示，是實施本發(fā)明的多支付渠道選擇系統(tǒng)時的交互流程圖。USER表示用戶，用戶在點擊支付時，本發(fā)明的多支付渠道選擇系統(tǒng)則顯示支持列表供用戶選擇，這樣用戶可以快速準(zhǔn)確地選擇符合自己支付請求的支付渠道。如圖7所示，是本發(fā)明的支付渠道選擇模塊實施例的結(jié)構(gòu)框圖。在本實施例中，該支付渠道選擇模塊包括：分析模塊71，用于分析所述支付請求的參數(shù)；支付請求的參數(shù)在上述已說明，在此不再贅述。第一判斷模塊72，用于根據(jù)所述支付請求的參數(shù)，判斷所述支付請求是否指定了支付渠道；第二判斷模塊73，用于判斷指定的支付渠道是否支持當(dāng)前的所述支付請求，若所述指定的PC支持所述當(dāng)前的支付請求，則進行具體的支付操作。第三判斷模塊74，用于依次判斷支付渠道是否支持所述支付請求的訪問類型、所述支付請求是否是WAP訪問、支付渠道是否支持所述支付請求的網(wǎng)絡(luò)類型以及支付渠道是否支持所述支付請求的APN接入點；檢查模塊75，用于依次檢查支付渠道是否能夠通過所述APP的黑白名單過濾以及檢查所述APP是否能夠通過支付渠道的黑白名單過濾。第四判斷模塊76，用于判斷支付渠道是否支持所述支付請求的國家碼。設(shè)置模塊77，用于設(shè)置支付渠道的優(yōu)先等級；排序模塊78，用于根據(jù)該優(yōu)先等級對所述支持列表的支付渠道進行排序。綜述，本發(fā)明的多支付渠道選擇的方法及系統(tǒng)，涵蓋了多國家支付的情況，定義了通用的支付請求參數(shù)，方便用戶選擇支付渠道，同時，對支持支付請求的支持列表進行了靈活的排序，結(jié)合了用戶的個人習(xí)慣。此外，將排序后的支持列表顯示出來以供用戶選擇，簡化了APP對支付的處理，使APP能夠?qū)Ｗ⒂谧陨順I(yè)務(wù)邏輯處理。以上所述，僅為本發(fā)明較佳的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本
技術(shù)領(lǐng)域：
的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應(yīng)該以權(quán)利要求的保護范圍為準(zhǔn)。當(dāng)前第1頁1 2 3