<object id="vqvqa"></object>
  • <th id="vqvqa"><video id="vqvqa"></video></th> <code id="vqvqa"></code>
    1. <big id="vqvqa"></big>

      <code id="vqvqa"><nobr id="vqvqa"></nobr></code>
      無憂支付網首頁
      24小時服務電話
      QQ:1145248264
      本站出售
      站內搜索
      您當前的位置:主頁 > 支付接口申請相關知識 >

      接入三方支付通道的一些注意點和說明

      添加時間:2022-06-22

        內卡(國內銀行卡)是目前大部分商戶都支持的,也是我們最熟悉的銀行卡,因此下面我們先從內卡通道說起。需要特別說明的是,這里的內卡支付是狹義上的,單指卡基支付,不包含賬基支付。

        在接入內卡通道的過程中,有很多細節需要確認,每個細節都可能會影響通道是否可用和支付成敗。下面我們以提問的形式介紹接入各種通道過程中的一些注意點及說明。

        1、支持的卡種有哪些?

        一般支持的卡種有借記卡、貸記卡,極少數情況下會支持準貸記卡。

        2、支持的銀行有哪些?是否提供卡BIN表或者對卡BIN有限制?

        在接入通道的時候,通道方(Vendor)分為兩類:一類是銀行直連,一類是第三方支付通道。直連銀行支持的支付品牌基本只有本行,比如工行快捷直連通道支持的銀行只有工商銀行。第三方支付或收單服務商支持多個支付品牌,比如連連聚合支付可以支持農業銀行、招商銀行、建設銀行等支付品牌(圖1所示為某支付通道支持的支付品牌),在接入的時候需要明確它們各自支持哪些銀行。

      支付通道支持的支付品牌(信用卡)

      圖1 某支付通道支持的支付品牌(信用卡)

        除了明確支付通道提供方所支持銀行外,支付通道接入方還會和支付通道方確認是否提供卡BIN表,或者明確不支持哪些卡BIN。如果沒有提供,可以將就使用銀聯的信用卡或借記卡卡BIN,原因簡單來說是按照現行發卡管理辦法,銀行卡BIN均需要向卡組織申請,而國內卡組織就是銀聯,所以理論上銀聯的BIN段一定是最全的。

        為什么需要明確卡BIN支持哪些或者不支持哪些?如果通道不支持某個卡BIN,交易發過去,就會交易失敗,造成支付成功率下降。

        3、支持的交易類型有哪些?

        交易類型有消費、鑒權、預授權、代扣、代付等,具體說明如下。

        ·消費:一般是指我們的扣款交易,狹義上常和預授權區分開來,代表不同的交易類型。比如去超市購物100元,刷卡支付,這個100元的交易類型就是消費。

        ·鑒權:與交易無關,不涉及交易金額,指通過一定手段對用戶身份或卡信息進行驗證。比如很多網站要求實名認證,讓用戶綁定銀行卡,并不扣款,用戶綁卡成功后,實名認證即成功,這其實就是通過銀行卡鑒權來完成實名認證。

        ·預授權:商戶向發卡機構取得一定金額內的扣款權利,后續再向發卡機構進行承兌的業務,消費和結算不在同一時間完成。預授權會占用持卡人卡內額度或者金額,一定時間內如果未進行后續承兌操作,發卡機構會進行撤銷,恢復額度或者退回金額。

        ·代扣:也叫作代收,是由用戶授權、商戶主動發起,對用戶指定賬戶進行扣款的一種支付交易業務。它具有以下幾個特點:支付要素少、按筆收費、沒有退回功能、支持單筆實時代扣和批量代扣。

        有人這么評價代扣通道,“代扣是支付公司生命線,其他的都是重在參與”“代扣是萬丈高樓平地起的基石”。從中可以看出,如果一家公司儲備了代扣的支付能力和支持較多銀行,那么在支付競爭中就會占有很大優勢。在早期支付里,撇開合規性,有代扣能力相當于有了核武器,對競爭對手簡直是降維打擊。

        ·代付:由商戶主動發起,從自身結算賬戶付款給用戶資金賬戶的一種支付交易業務。它具有以下幾個特點:支付要素少、按筆收費、沒有退回或者撤銷功能、支持單筆實時代付和批量代付。

        代扣代付交易的誕生史最早的代扣交易大概是水電煤繳費。經歷過20世紀90年代水電煤繳費的人應該還有印象,當時每個月有人定期上居民家中查水電表度數,之后居民就可以去郵局繳納賬單。但是這樣不太方便,會占用人們的業余時間,一個三四線城市網點就那么多,很多人經常要在周末排長隊。

        后來一些銀行與電信公司、電力公司、自來水公司等公共事業繳費單位合作,允許居民在銀行開通委托支付賬單協議,每個月賬單出詬,自動從居民的銀行卡中將資金劃扣至公共事業繳費單位。

        代扣早期常見的應用業務如圖2所示。

      早期代扣業務

      圖2 早期代扣業務

        而代付最早可以追溯到理財產品分紅,比如基金分紅、保險分紅,當時理財產品會定期付款給客戶,所以產生了代付業務。代付早期常見的應用業務如圖3所示。

      早期代付業務

      圖3 早期代付業務

        4、關聯交易類型有哪些?

        關聯交易類型有沖正、查詢(查詢范圍簽約、交易、退貨、協議號狀態等)、撤銷(當日撤銷)、退貨(隔日走退貨,當日退貨是否也支持)、預授權關聯交易、解約/解綁。下面來看一 個沖正與查詢交易類型的使用案例。

        在支付交易里,返回的結果不只有預料中的成功或失敗,也會因為各種問題(如系統異常)導致收不到支付服務提供商反饋的結果。

        但是交易訂單必須有一個最終時間,不能無限期地等待下去,讓用戶一直看著自己的訂單在處理中,不知道購買是成功還是失敗。遇到這種情況,可以通過沖正或查詢來解決。

        沖正是系統對于交易結果未知的補償機制。商戶因為系統超時、異常等,不確定支付結果,為避免用戶等待或者重復扣款,向支付服務提供商發起沖正交易請求,進行交易回滾。無論原交易是成功還是失敗,均要求取消該筆交易。沖正成功后,商戶可以向用戶反饋支付失敗或者再組織報文重新發起交易。

        沖正與撤銷、退貨看起來有些相似,但是使用起來有很大區別:

        沖正可以對未知結果的訂單進行交易回滾,而撤銷和退貨都只能對明確結果成功的訂單進行交易回滾。

        查詢是另一種對于交易結果未知的補償機制。系統對于無明確交易結果返回的訂單,設定好腳本規則,定時向支付服務提供商發起請求,查詢交易結果,比如每5分鐘查詢一次,一直查詢到第30分鐘。

        在這期間,如果查詢到明確結果成功或者失敗,更新訂單狀態;如果查到最后還是沒有結果,通常的做法是直接置為失敗,第二天商戶查看對賬單確認該交易是否成功,如果成功,則進行退款處理。

        此外,在協議支付或者快捷支付里,需要先簽約,生成協議號,而有生成就有解除,解除協議的過程就叫作解約或者解綁。

        5、是否支持預授權關聯交易?支持哪些?

        預授權關聯交易有多種,在通道接入時需要和通道方明確是否支持以及支持哪些。

        預授權關聯交易有以下幾類。

        預授權完成:預授權交易取得的扣款轉為實際全額扣款結算的處理業務。預授權時,扣款金額并沒有結算給商家,只是在用戶賬戶上臨時凍結;預授權完成時,扣款金額實際全額結算給商家,用戶賬戶全額從凍結變成實際扣款消費。

        ·預授權部分完成:預授權交易取得的扣款轉為實際部分扣款結算的處理業務。預授權部分完成時,扣款金額實際針對請求的部分金額結算給商家,用戶賬戶上從部分金額凍結變成實際扣款消費,剩余金額則會自動撤銷,恢復額度或者退回款項。

        ·預授權完成撤銷:針對已經扣款結算的預授權金額做全額撤銷,退回用戶賬戶,相當于退款功能。撤銷普遍是指全額撤銷。

        ·預授權完成部分撤銷:是指針對已經扣款結算的預授權金額,進行部分金額撤銷,退回用戶賬戶,相當于退款功能。

        ·預授權撤銷:解除預授權交易取得的扣款權利的處理業務。預授權撤銷時,扣款金額從用戶賬戶解凍,恢復額度或者退回款項。

        ·預授權追加:原有預授權因為各種原因需要增加預授權金額,發起交易類型為預授權追加的處理業務。在現實中,有很多商戶會將原有預授權進行預授權撤銷,重新發起一筆預授權追加。

        6、預授權自動解凍時間是多久?

        銀行對于預授權有如下規定:一定時間沒進行預授權完成,就會自動撤銷,一般是30天。一些業務(如酒店業務)為了防止到期自動撤銷、造成損失,就需要明確這個日期,并在這個日期之前進行預授權完成。

        7、是否支持多次退貨、部分退貨?

        交易場景里,用戶有可能不止一次退貨,也有可能僅退部分商品。

        需要明確退貨的這些基本屬性,如果銀行不支持,那么就要 考慮轉賬或代付等替代方案。

        8、需要退款時是否區分撤銷和退貨?撤銷是否只支持全額撤銷?

        有的銀行或者第三方通道只提供退貨接口,有的則提供撤銷和退貨兩個接口。那么在接入的時候,由于撤銷一般都是全額撤銷,并且只支持當天走撤銷,就需要根據銀行或者 第三方通道接口情況做如下處理。

        情況一:只有退貨功能。需要確認當天的交易,是否不管全額還是部分金額退款均可以調用退貨接口,還是同一般退貨接口一樣,需要隔日才能調。

        情況二:提供撤銷和退貨功能。需要確認當天交易部分退款的時候,是可以使用撤銷功能,還是由于撤銷只支持全額,只能隔日使用退貨功能。

        一般情況下,商戶系統需要先承擔當天交易的部分金額的退貨,過了日切時間點后,也就是隔日再交給通道受理。

        9、訂單最長退貨時間是多久?

        退貨時間就是指退款時間,通道方通常會對于訂單線上聯機退貨時間有個最長時間規定,比如60天、90天、 180天、 360天等,過了這段時間,系統就不能聯機發起退款流程,需要人工線下處理。

        10、退款發起和到賬時間分別是什么時候?

        用戶會關心什么時候退款資金到賬,出于降噪需要,也需要提示用戶預計到賬時間。

        在接入通道的時候,要盡量與通道方確認好每個通道或者銀行的到賬時間是幾個工作日,否則給的到賬時間過短,結果沒按時到,用戶會投訴;給的到賬時間過長(比如明明3天可以到賬的,卻寫了15天),會被用戶給差評。

        11、退款是否要求當日進款大于退款?

        一些通道會規定當天的正交易必須大于 負交易才可以退款。

        如果不確認這個問題,進行測試或者分析問題的時候可能會發現,昨天進行的扣款測試交易,今天發起退款時,就是不成功,找來找去也找不出問題。其實就是因為通道做出了這樣的規定,當天發起退款時,還沒有進款,因為負交易大于正交易,所以無法進行。

        之所以會這樣規定,是因為通道資金往往是T+1日結算。前一天的款項已經結算給商戶了,如果第二天交易不做限定,允許商戶直接退款,萬一發生惡意事件,只有退款,沒有進款,且數額巨大,那么會給通道系統帶來系統性風險。

        12、退款退不退手續費?

        退款是否退手續費的屬性在賬戶系統落地數據、收銀系統匹配賬單定制規則時,均需要用到。

        一般情況下,代扣、代付類型通道退款不退手續費,無磁無密、MOTO、快捷類型等通道退款退手續費。

        13、當天一筆訂單同時發生正交易和負交易,對賬單是否有體現?

        正交易一般指收入業務,比如代扣、消費、預授權。負交易一般指退貨、撤銷、代付。如之前所說,一般都是當天走撤銷,隔日走退貨,且撤銷只支持全額撤銷。

        如果發生一筆交易,且當天又進行了全額退款,需要明確第二天對賬單里是否會體現,是兩筆對沖均不顯示,還是均會顯示。這個規則關系到后面的結算對賬系統怎么處理。

        14、支付要素有哪些?

        內卡支付全要素通常情況如下,而外卡會多很多其他要素。

        ·借記卡:卡號、姓名、證件類型、證件號、手機號、短信驗證碼。

        ·信用卡:卡號、姓名、證件類型、證件號、手機號、短信驗證碼、CW、有效期。

        證件類型有很多,一般做國內業務的主要關注是否支持這幾個證件:身份證、護照、港澳居民來往內地通行證(俗稱“回鄉證”)、臺灣居民來往大陸通行證(俗稱“臺胞證”)。表1給出了銀行開戶時需要的證件類型。

      表1 銀行開戶常見證件類型

      銀行開戶常見證件類型
      續表

        在接入時,各個銀行和第三方通道會根據自身實際情況及對于接入通道類型的熟悉程度來確定需要哪些要素。大家對要素的要求各不一樣,也不一定需要上送全要素,而多送和少送要素在支付里均不被允許,會帶來系統性風險,因此明確需要什么要素很重要。測試人員進行測試的時候不僅要測要素正確時會不會支付成功,還要進行排列組合測試某個要素錯誤后支付結果會怎么樣。

        下面分成幾個場景來說明。

        場景一:支付請求時多送了要素,多送要素是錯誤的。

        結果一:扣款成功。

        首先,系統里如果保存數據,這些數據就成為臟數據。其次,如果用戶后續發起拒付,銀行調單,發現要素確實是錯的,那么很可能就會判斷通道或者商戶失責,將金額退回給用戶。畢竟用戶支付要素都是錯誤的,你怎么可以允許支付成功呢?

        結果二:扣款失敗。

        支付里關注的無非三個方面:支付成功率、支付收益(成本或收入)、支付方式覆蓋面。如果銀行不接受多送的要素或者對多送要素也進行驗證,導致支付失敗,那么這些無效交易就會造成支付成功率下降。

        場景二:支付請求時少送了要素。

        結果一:扣款失敗。

        如上面所說,支付里關注的一個方面是支付成功率。少送的原因多數是商戶自己內部配置或者系統錯誤,在中間傳輸的過程中某些要素被攔截或者丟失導致未上送。

        要素少送的話,結果多數是支付失敗,這些無效交易造成了支付成功率下降,是很嚴重的事情。

        結果二:扣款成功。

        要素少送時,極少數情況下會扣款成功。這種情況發生的原因最有可能是通道方自己內部對于某些要素并不做強制校驗,至少不是每次都校驗,極端情況下甚至不校驗。

        這樣的情況很嚴重,意味著如果正常上送要素,有些要素會不被驗證就支付通過,從而帶來上面提到的拒付風險。

        15、關于短信驗證碼的規定。

        短信驗證碼有幾個方面需要確認,這里為了全面,拿涉及簽約和支付兩個流程的快捷通道為例來說明。

        問:短信發送方是誰?

        答:需要明確簽約短信發送方、交易短信發送方分別是誰,是通道側還是商戶側。

        問:同一筆交易里,簽約與交易兩個環節均為通道發送,短信如何發送?

        答:需要明確是兩個環節均需要發送,用戶會收到兩條短信,還是只會下發一條。更好的用戶體驗是,在一筆交易里如果既有簽約流程又有交易流程,下發了簽約短信,支付短信就不下發了;如果已簽約,本次只有支付交易,那么就單獨下發支付短信?傊脩糁粫盏揭粭l短信。

        問:短信驗證碼長度是多少?

        答:前端頁面基于盡可能在前面攔截一些已知錯誤的思路,會做出一些設計,比如輸入短信驗證碼字符數量超了會報錯,因此需要明確短信驗證碼字符長度,通常為6位或4位。

        問:短信驗證碼發送間隔時間與次數分別是多少?

        答:由于短信發送是有成本的,各通道方出于成本考慮以及防止惡意點擊或者錯點,通常會規定短信發送間隔時間(比如60s),有些甚至會規定每天最多發送的次數。在接入通道的時候,需要根據這些屬性做好相應的前端系統配置。

        比如通道規定短信驗證碼發送間隔時間為60s,那么前臺倒計時就需要至少60s,防止用戶因點擊收不到短信驗證碼,對支付體驗不滿,甚至放棄支付。比如通道規定了每張卡短信驗證碼最多發送的次數,那么前臺就需要做好相應的計數服務,統計好發送次數。

        問:短信驗證碼發送方是否與賠付相關?

        答:出于各種原因用戶可能會有拒付要求,比如非本人支付、卡被盜等,短信驗證碼作為一種身份信息驗證,需要與通道方明確是否誰發送誰驗證誰負責。

        問:短信內容是什么?

        答:短信中會有相關的行為+發送方,通常會在開頭或末尾展示發送方或交易商戶,以便用戶知道發送主體。在交易中,一些第三方通常會以自己作為后綴結尾,如[xx支付],導致用戶在商戶網站購物時看到短信來自一個完全不認識的短信發送方,會產生困惑,甚至投訴。

        在接入的過程中,商戶應當盡可能要求通道方用自己的商戶名稱作為發送方顯示在短信中。支付服務提供方應當在設計短信內容配置模板時,支持根據簽入商戶主體不同展示不同名稱。

        16、通道是否限制商戶側和用戶側的單筆、單日、單月額度?

        大多數通道會對用戶有個限額,單筆限額多少、單日限額多少、單月限額多少,不能超限。如果超限還上送交易,通道會返回類似“該筆交易已超限額”的錯誤。

        對于一些代扣類、鑒權類通道,一些銀行對商戶也有限額,甚至限次,不希望調用太多。

        對于銀行通道以及用戶限額限次,如何避免超限呢?一種方法是進行計數服務,對當天的交易筆數進行計數統計。此外,還可以進行重試服務,遇到這種情況就將交易拋送到其余通道去處理。

        17、支付要素對于可選項和必選項是怎么要求的?

        在接入通道的實際過程中,有些銀行或第三方支付會提供可選項,允許商戶按照自己的需求自行選擇,既可以上送最小支付要素(只有必選項)的交易請求,也可以上送最大支付要素(必選項+可選項)的交易請求。

        什么情況用最小支付要素,什么情況用最大支付要素呢?可以看下面的幾種情形。

        對于有風險的用戶,希望要 索驗證盡全,這時候往往選擇最大支付要素。

        ·對于新用戶,或者在某些場景希望進行某些鑒權認證的時候,需要收集盡量全的信息,也會用到最大支付要素。

        ·如果希望支付成功率高、用戶轉換率高,就會傾向于讓用戶輸入少一些、停留時間短一些,會選擇使用最小支付要素。

        在有可選支付要素的情況下,我們需要明確以下問題。

        問題一:必選項+可選項的排列組合是怎樣的?

        答:如果有多個可選項存在,比如3個,那么這些可選項的排列組合是C?3=3,而現實情況肯定不會允許隨意組合,送什么都行。接口開發文檔中也只會標記哪些是可選的,不會對這些做特別說明,所以就要明確如果需要可選,到底要怎樣上送。

        問題二:對于可選項上送的要素,是否一定會驗證?

        答:理想情況是對于上送的要素一定會驗證,但實際情況并非如此,有的銀行或通道是送了就一定會驗證,有的對于可選要素的定義則是上送了也不保證一定驗證,比如其系統庫不支持,或者 其路由策略會路由到不需要這個要素的通道等。

        因此這一點需要明確,對于前者,可選要素是可以使用的;而對于后者,則需要放棄可選要素,只使用必選要素,否則還是會帶來上面提到的要素錯誤弓|起的持卡人拒付或者“臟數據”問題。

        支付里的一個很重要的準則是支付要素應準確。

        18、接入方式是專線還是公網?

        顧名思義,專線就是專用網絡,誰接入誰獨享,安全性高,但流程復雜,整個項目周期也會拉長,另外需要定期支付專線費用。

        公網是指公共網絡,會有多個商戶一起在同一網絡進行請求交易,接入方式快,也沒有費用,缺點就是可能會因為其他商戶的問題(如瞬時交易過大等)影響自己的交易。

        19、通道每秒并發量是多少?公用還是專用?

        并發量相當于網紅飯店的同時最大接納量。如果人過多,已經超過同時最大接納量,飯店就需要采取分流、排隊甚至推薦到分店的做法來緩解人流壓力。支付通道也是一樣,需要明確通道并發量是多少,這個并發是自己獨享還是很多商戶公用。當并發過大的時候,就采取與分店緩解人流壓力類似的做法。支付中常用的方法有以下兩種。

        ·分隊列處理。如果通道每秒最多只能受理10筆交易,由于上線了營銷活動,現有100筆交易同時進來,那么可以把這100筆交易分成10隊,每隊10筆排隊處理。這樣,就讓原本全部交易蜂擁而入、超過容量,結果可能會有90筆失敗的情況,變成秩序井然、每筆都會成功的情況。

        ·轉通道處理。還是一樣的情況,通道每秒最多只能受理10筆交易,那么平時在通道的建設中都要有多個通道互為備份。遇到這種情況的時候,可以把多出的交易上送給其余通道進行支付。就像我們在超市結賬時,一個收銀臺忙不過來,排隊人太多,那就再開一個柜臺處理,加快速度,緩解壓力。

        20、否有最低交易金額限制?

        在接入支付通道的過程中,日常我們的最低交易金額為0·01元,即1分錢,但是也會有一些通道做出不一樣的規定,比如最低交易金額為0·1元或1元。在接入的時候要明確這些細節,避免因為這些小細節而交易失敗。

        21、日切時間和賬單獲取時間分別是什么時候?

        日切時間點是指上一個工作日結束的時間點。比如我們說日切時間是每天24點,一般不特別說明,下一工作日就是次日0點之后。交易數據、給出的對賬單數據等就是以0點至24點為一個統計日,0點以后的交易對賬單要到下一個工作日給出。

        除了日切時間外,還要關注賬單獲取時間。只有通道方上傳了賬單,商戶才能下載到。為了避免不停地輪詢下載,商戶需要與通道方明確他們上傳的時間,然后在給出的時間基礎上設置一個時間差,到時間了再去下載。

        22、對賬單支持哪些獲取方式?

        對賬單的獲取方式有以下三種。

        登錄后臺下載。通道方為商戶開設后臺賬號和密碼,商戶登錄后進行人工對賬單下載或導出。

        ·郵件推送。商戶向收單機構(通道方)提供郵箱地址,收單機構按照規定定時推送。

        FTP下載,這是推薦的方式。隨著接入通道增多,人工下載變得費時費力,而FTP下載可以自動完成,實現加活不加人,這是系統輕量化運營中重要的一環。

        FTP下載根據對象關系不同可分成兩種:一種是商戶主動去收單機構下載,一種是由收單機構主動推送到商戶FTP地址。不管是哪種,在接入的時候,均會涉及地址、用戶名、密碼、目錄、IP白名單。

        如果是商戶去收單機構下載,需要收單機構向商戶提供下載的目標地址、用于身份允許的用戶名、密碼、下載的目錄地址;而商戶需要給收單機構對應的IP地址,以事先配置到收單機構白名單里。

        如果是收單機構主動推送到商戶,則反過來,由商戶向收單機構提供下載的目標地址、用于身份允許的用戶名、密碼、推送的目錄地址;而收單機構需要給商戶對應的IP地址,以事先配置到商戶的白名單里。

        23、結算是用全額結算還是凈額結算?

        全額結算(Gross Settlement)是對交易的已收資金進行全數結算、劃撥,不做費用扣除。凈額結算(Net Settlement)是對交易的已收資金扣除手續費之后再進行結算、劃撥,或者是雙方互有買賣,對各自應收應付資金互為抵扣之后再進行結算。

        采用什么樣的結算方式關系到后續程序的對賬規則是結算扣手續費凈額結算,還是不扣手續費全額結算,手續費后續另算。

        24、是否有測試環境并提供測試卡信息、生產卡信息?

        商戶平時會接入的支付通道很多,大大小小的銀行都會涉及,而測試人員基本不太可能擁有每一家銀行的借貸卡。

        在接入通道的初期,如果能夠與支付服務提供商(通道)確認好,收集好相關卡信息,或者測試時有可進行協助的聯系人,會使得項目測試全面、高效很多。

        以上是筆者這些年接入通道的一些經驗,只要按照上面這些問題確認好,一個通道的接入基本就已經成功了大半。

      關閉

      1.點擊下面按鈕復制微信號

      ***********

      2.打開微信→查找微信號

      加為好友 開始支付接入

      午夜福利在线永久视频
      <object id="vqvqa"></object>
    2. <th id="vqvqa"><video id="vqvqa"></video></th> <code id="vqvqa"></code>
      1. <big id="vqvqa"></big>

        <code id="vqvqa"><nobr id="vqvqa"></nobr></code>