CN106095537A - Android支付插件的管理方法及系统 - Google Patents
Android支付插件的管理方法及系统 Download PDFInfo
- Publication number
- CN106095537A CN106095537A CN201610506657.4A CN201610506657A CN106095537A CN 106095537 A CN106095537 A CN 106095537A CN 201610506657 A CN201610506657 A CN 201610506657A CN 106095537 A CN106095537 A CN 106095537A
- Authority
- CN
- China
- Prior art keywords
- transaction
- service layer
- middle service
- payment platform
- channel
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Accounting & Taxation (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开了一种Android支付插件的管理方法,包括:支付平台为交易接口及交易流程生成配置文件,并提交到中间服务层;前端应用注册自身支持的交易类型回调到中间服务层;中间服务层获取用户交易渠道,根据配置文件调用对应的支付平台交易接口,完成交易。通过上述方式,本发明可以实现业务功能与交易功能的高度耦合性,消除前端平台的工作量,并降低后期扩张维护的投入成本。
Description
技术领域
本发明涉及Android支付技术领域,尤其是涉及一种Android支付插件的管理方法及系统。
背景技术
以往,开发一款具备支付功能的APP时,开发者通常在APP中直接集成这些支付功能,业务功能与支付功能揉合交互。在以银联卡支付为主要交易平台的时代,这种做法勉强可以解决开发需求。但随着微信、支付宝等支付模式逐渐成为普通消费者及商户欢迎的支付渠道,APP需要对接的支付平台越来越多,如果还是按以往的开发方式,开发难度,时间,维护等复杂度呈几何级增长。
Android智能手机通常会安装许多APP,这些APP都专注于实现自己的主要功能,它们通常不关注于次要的功能,以提供给用户良好的体验。比如某交友软件,它专注于好友间聊天、动态分享等。该APP在实现了这些主要功能后,还实现了好友的位置分享功能,按照一般做法,该APP需要集成地图的功能,而这将花量大量的人力物力。
上述方式存在如下缺点:
缺点1:具备支付功能的APP除了支持传统银联卡支付渠道外,还须对新兴支付平台支持,开发者除了关注业务功能外,还须关注多平台的接入,这包括各平台间调用接口,流程,数据报文等差异。
缺点2:后期的扩展、维护需要耗费大量的人力,时间,但效果往往不佳。
缺点3:业务功能与支付功能耦合性强,无法便捷的移植到新的APP上。
发明内容
本发明所要解决的技术问题是:提供一套实现前端应用与金融交易平台交互的机制,使得前端开发人员不必去关注支付平台的API和金融交易流程。
为了解决上述技术问题,本发明采用的技术方案为:提供一种Android支付插件的管理方法,包括:
支付平台为交易接口及交易流程生成配置文件,并提交到中间服务层;
前端应用注册自身支持的交易类型回调到中间服务层;
中间服务层获取用户交易渠道,根据配置文件调用对应的支付平台交易接口,完成交易。
为解决上述问题,本发明还提供一种Android支付插件的管理系统,包括支付平台、中间服务层及前端应用,其中:
支付平台用于为交易接口及交易流程生成配置文件,并提交到中间服务层;
前端应用用于注册自身支持的交易类型回调到中间服务层;
中间服务层用于获取用户交易渠道,根据配置文件调用对应的支付平台交易接口,完成交易。
本发明的有益效果在于:区别于现有技术,本发明通过将交易接口及流程配置成文件形式,并提交到中间服务层,中间服务层在前端获取交易渠道后,根据配置文件调用对应的交易接口,并完成交易。通过上述方式,本发明可以有效消除业务功能与交易功能的高度耦合性,消除前端平台的工作量,并降低后期扩张维护的投入成本。
附图说明
图1为本发明具体实施例中中间服务层以及支付调用API组成示意图;
图2为本发明具体实施例中中间服务层运作流程示意图。
具体实施方式
为详细说明本发明的技术内容、所实现目的及效果,以下结合实施方式并配合附图予以说明。
本发明最关键的构思在于:在支付中间服务层调用前端的API及接口,实现交互机制的有机结合。
本发明实施例一提供一种Android支付插件的管理方法,包括:
支付平台为交易接口及交易流程生成配置文件,并提交到中间服务层;
前端应用注册自身支持的交易类型回调到中间服务层;
中间服务层获取用户交易渠道,根据配置文件调用对应的支付平台交易接口,完成交易。
区别于现有技术,本发明通过将交易接口及流程配置成文件形式,并提交到中间服务层,中间服务层在前端获取交易渠道后,根据配置文件调用对应的交易接口,并完成交易。通过上述方式,本发明可以实现业务功能与交易功能的高度耦合性,消除前端平台的工作量,并降低后期扩张维护的投入成本。
其中,支付平台将各交易类型的接口按中间服务层规范标签形成流程配置文件,并提交给中间服务层。中间服务层在启动时装载所述配置文件。
中间服务层在获取用户交易渠道时,检测中间服务层支持交易类型的渠道是否超过一个;
若是,则显示渠道选择列表,并获取用户选择的交易渠道;
反之,则直接获取用户选择的交易渠道。
中间服务层根据所选交易渠道调用对应的支付平台API完成交易,其中调用过程依据流程配置文件标签定义;
中间服务层调用支付平台API时,判断是否需要前端应用参与执行;
若是,则通过回调交易类型到前端应用,实现交易;
反之,则直接调用支付平台API完成交易。
在完成交易后,中间服务层通过交易监听器返回交易结果给前端应用。
对应地,本发明实施例二提供一种Android支付插件的管理系统,包括支付平台、中间服务层及前端应用,其中:
支付平台用于为交易接口及交易流程生成配置文件,并提交到中间服务层;
前端应用用于注册自身支持的交易类型回调到中间服务层;
中间服务层用于获取用户交易渠道,根据配置文件调用对应的支付平台交易接口,完成交易。
其中,支付平台将各交易类型的接口按中间服务层规范标签形成流程配置 文件,并提交给中间服务层。中间服务层在启动时装载所述配置文件。
中间服务层在获取用户交易渠道时,检测中间服务层支持交易类型的渠道是否超过一个;
若是,则显示渠道选择列表,并获取用户选择的交易渠道;
反之,则直接获取用户选择的交易渠道。
中间服务层根据所选交易渠道调用对应的支付平台API完成交易,其中调用过程依据流程配置文件标签定义;
中间服务层调用支付平台API时,判断是否需要前端应用参与执行;
若是,则通过回调交易类型到前端应用,实现交易;
反之,则直接调用支付平台API完成交易。
在完成交易后,中间服务层通过交易监听器返回交易结果给前端应用
为方便理解,以下结合图1及图2,通过一个具体实施例进行说明。
本发明由支付中间服务层以及支付调用API组成,如图1所示。
本发明基于组件化设计思想,将业务功能与支付功能剥离开来,其中支付功能以组件的形式驻留在系统中,它提供一系列交易接口实现与业务功能的交互。由于各类平台接口,流程存在巨大差异,造成前端开发难度增大。因此如果在两者之间增加一个仲裁机构,解决各类平台的接口流程差异,并提供统一的前端应用接入接口,那么将极大提高前端应用开发效率,并且可以实现功能的解耦及复用。中间服务层扮演的即是中间仲裁角色,它提供了一套交互机制使两者有机结合。
中间服务层的基本原理是将交易接口和流程等变化量以文件的形式配置起来,对前端开发只提供一套统一的API。假设有这样的一类场景:平台A支持交易T(如消费),完成T交易需要调用三个接口实现,调用顺序为a1-a2-a3,而平台B同样支持交易T,但完成该交易需要调用四个接口,调用顺序为b1-b2-b3-b4。可以看出,接口及流程差异无法直接屏蔽,也即前端调用无法以同一套接口和流程去实现基于A平台和B平台的交易。除此之外平台A的交易在调用a2接口时需要前端应用参与数据的交换,而B平台无须前端应用参与任 何动作。这类场景经常出现在功能组件化后的交互过程。中间服务层把a1,a2,a3和b1,b2,b3,b4接口和流程分别以TA,TB文件配置保存起来。变化的接口和流程通过配置后形成一系列有规则的标签项,中间服务层对前端开放发起交易的接口,当前端应用通过该接口对接到中间服务层时,传入平台标识,交易类型,中间服务层从配置文件去读取该交易的执行步骤,调用平台交易接口完成交易,而后将交易结果返回给前端应用。前面提到,在实现交易过程有时需要前端应用参与数据交换,为实现该功能,中间服务层提供一个注册回调的接口,该接口用来实现前端与平台的交互功能。值得注意的是,这种交互区别于前端应用与平台的直接交互,直接交互需要前端应用知道交易流程,是一种双向操作的过程。而通过中间服务层提供的注册回调接口,前端应用只须被动实现交互,亦即前端应用什么时候去实现交互由中间服务层主动发起,如AC1~AC3,BC1~BC4只是单向操作。
中间服务层流程如图2所示,具体包括如下步骤:
S1(loadTransactionXml):第三方支付平台将各交易类型的接口按中间层规范标签形成流程配置文件,并提交给中间服务层。中间服务层在启动时装载这些配置文件;
S2(registerPuppets):前端应用注册自身支持的交易类型回调(如消费P uppet)到中间服务层;
S3(showTransactionChannel):如果中间服务层支持该交易类型有多个渠道(如微信、支付宝、银联平台),则弹出渠道选择列表让用户选择需要的渠道交易;
S4(doTransaction):中间服务层根据所选交易渠道调用对应的第三方平台API完成交易,调用过程依据流程配置文件标签定义;具体地,其中支付平台API的调用依据对应的流程配置文件进行。流程配置文件使用一系列标签定义API调用的条件以及调用结果,调用结果定义了如何选择下一次调用的API;
S5(callback):中间服务层调用第三方平台API过程中,遇到需要前端应用参与执行,通过Puppet回调前端应用实现;
S6(OnTransactionListener):中间服务层通过交易监听器返回交易结果给 前端应用。
因此,本发明适用于第三方商户应用便捷地接入各支付平台,商户应用开发者无须关注各平台交易流程,接口的差异,实现各平台无差别对接。本发明以组件化的思想将业务功能与支付功能完全剥离,并提供一套应用间交互的解决方案。此外,中间服务层屏蔽了各平台接口和流程的差异,在涉及到业务功能与支付功能交互的操作,中间层以回调的机制去完成,本发明可以十分方便地实现新支付平台的扩展。
以上所述仅为本发明的实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等同变换,或直接或间接运用在相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (10)
1.一种Android支付插件的管理方法,其特征在于,包括:
支付平台为交易接口及交易流程生成配置文件,并提交到中间服务层;
前端应用注册自身支持的交易类型回调到中间服务层;
中间服务层获取用户交易渠道,根据配置文件调用对应的支付平台交易接口,完成交易。
2.根据权利要求1所述Android支付插件的管理方法,其特征在于,支付平台将各交易类型的接口按中间服务层规范标签形成流程配置文件,并提交给中间服务层。中间服务层在启动时装载所述配置文件。
3.根据权利要求1所述Android支付插件的管理方法,其特征在于,中间服务层获取用户交易渠道的步骤具体为:
检测中间服务层支持交易类型的渠道是否超过一个;
若是,则显示渠道选择列表,并获取用户选择的交易渠道;
反之,则直接获取用户选择的交易渠道。
4.根据权利要求1所述Android支付插件的管理方法,其特征在于,中间服务层根据所选交易渠道调用对应的支付平台API完成交易,调用过程依据流程配置文件标签定义;
中间服务层调用支付平台API时,判断是否需要前端应用参与执行;
若是,则通过回调交易类型到前端应用,实现交易;
反之,则直接调用支付平台API完成交易。
5.根据权利要求1所述Android支付插件的管理方法,其特征在于,在完成交易后,中间服务层通过交易监听器返回交易结果给前端应用。
6.一种Android支付插件的管理系统,其特征在于,包括支付平台、中间服务层及前端应用,其中:
支付平台用于为交易接口及交易流程生成配置文件,并提交到中间服务层;
前端应用用于注册自身支持的交易类型回调到中间服务层;
中间服务层用于获取用户交易渠道,根据配置文件调用对应的支付平台交易接口,完成交易。
7.根据权利要求6所述Android支付插件的管理系统,其特征在于,支付平台将各交易类型的接口按中间服务层规范标签形成流程配置文件,并提交给中间服务层。中间服务层在启动时装载所述配置文件。
8.根据权利要求6所述Android支付插件的管理系统,其特征在于,中间服务层在获取用户交易渠道时,具体用于:
检测中间服务层支持交易类型的渠道是否超过一个;
若是,则显示渠道选择列表,并获取用户选择的交易渠道;
反之,则直接获取用户选择的交易渠道。
9.根据权利要求6所述Android支付插件的管理系统,其特征在于,中间服务层用于根据所选交易渠道调用对应的支付平台API完成交易,其中调用过程依据流程配置文件标签定义;
中间服务层调用支付平台API时,判断是否需要前端应用参与执行;
若是,则通过回调交易类型到前端应用,实现交易;
反之,则直接调用支付平台API完成交易。
10.根据权利要求6所述Android支付插件的管理系统,其特征在于,在完成交易后,中间服务层通过交易监听器返回交易结果给前端应用。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610506657.4A CN106095537A (zh) | 2016-06-30 | 2016-06-30 | Android支付插件的管理方法及系统 |
PCT/CN2017/090538 WO2018001272A1 (zh) | 2016-06-30 | 2017-06-28 | Android支付插件的管理方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610506657.4A CN106095537A (zh) | 2016-06-30 | 2016-06-30 | Android支付插件的管理方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106095537A true CN106095537A (zh) | 2016-11-09 |
Family
ID=57214266
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610506657.4A Pending CN106095537A (zh) | 2016-06-30 | 2016-06-30 | Android支付插件的管理方法及系统 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN106095537A (zh) |
WO (1) | WO2018001272A1 (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018001272A1 (zh) * | 2016-06-30 | 2018-01-04 | 福建联迪商用设备有限公司 | Android支付插件的管理方法及系统 |
CN108256846A (zh) * | 2016-12-28 | 2018-07-06 | 航天信息股份有限公司 | 一种集成支付的方法及系统 |
CN109308611A (zh) * | 2017-07-28 | 2019-02-05 | 万事达卡亚太私人有限公司 | 增强网页功能 |
CN109582312A (zh) * | 2018-12-04 | 2019-04-05 | 艾体威尔电子技术(北京)有限公司 | 一种智能pos的ui层和逻辑层分离开发方法 |
CN111026388A (zh) * | 2019-10-15 | 2020-04-17 | 福建联迪商用设备有限公司 | 一种适配收单应用的方法及支付中间件 |
CN114253622A (zh) * | 2020-09-22 | 2022-03-29 | 京东科技控股股份有限公司 | 一种支付处理方法、装置、电子设备及存储介质 |
CN114531432A (zh) * | 2022-02-14 | 2022-05-24 | 浙江吉利控股集团有限公司 | 一种基于跨平台的业务通信方法及装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040133460A1 (en) * | 2001-02-13 | 2004-07-08 | Suzanne Berlin | Electronic acquisition system and method using a portal to facilitate data validation and to provide a universal client interface |
CN101458797A (zh) * | 2008-12-22 | 2009-06-17 | 腾讯科技(深圳)有限公司 | 业务处理系统和方法 |
CN101841569A (zh) * | 2010-05-17 | 2010-09-22 | 成都中联信通科技有限公司 | 一种基于web技术实现跨平台的手机支付方法 |
CN105701406A (zh) * | 2015-12-31 | 2016-06-22 | 深圳市证通电子股份有限公司 | 安卓平台运行传统支付应用的方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106095537A (zh) * | 2016-06-30 | 2016-11-09 | 福建联迪商用设备有限公司 | Android支付插件的管理方法及系统 |
-
2016
- 2016-06-30 CN CN201610506657.4A patent/CN106095537A/zh active Pending
-
2017
- 2017-06-28 WO PCT/CN2017/090538 patent/WO2018001272A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040133460A1 (en) * | 2001-02-13 | 2004-07-08 | Suzanne Berlin | Electronic acquisition system and method using a portal to facilitate data validation and to provide a universal client interface |
CN101458797A (zh) * | 2008-12-22 | 2009-06-17 | 腾讯科技(深圳)有限公司 | 业务处理系统和方法 |
CN101841569A (zh) * | 2010-05-17 | 2010-09-22 | 成都中联信通科技有限公司 | 一种基于web技术实现跨平台的手机支付方法 |
CN105701406A (zh) * | 2015-12-31 | 2016-06-22 | 深圳市证通电子股份有限公司 | 安卓平台运行传统支付应用的方法 |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018001272A1 (zh) * | 2016-06-30 | 2018-01-04 | 福建联迪商用设备有限公司 | Android支付插件的管理方法及系统 |
CN108256846A (zh) * | 2016-12-28 | 2018-07-06 | 航天信息股份有限公司 | 一种集成支付的方法及系统 |
CN109308611A (zh) * | 2017-07-28 | 2019-02-05 | 万事达卡亚太私人有限公司 | 增强网页功能 |
CN109582312A (zh) * | 2018-12-04 | 2019-04-05 | 艾体威尔电子技术(北京)有限公司 | 一种智能pos的ui层和逻辑层分离开发方法 |
CN109582312B (zh) * | 2018-12-04 | 2021-09-21 | 艾体威尔电子技术(北京)有限公司 | 一种智能pos的ui层和逻辑层分离开发方法 |
CN111026388A (zh) * | 2019-10-15 | 2020-04-17 | 福建联迪商用设备有限公司 | 一种适配收单应用的方法及支付中间件 |
CN111026388B (zh) * | 2019-10-15 | 2023-08-11 | 福建联迪商用设备有限公司 | 一种适配收单应用的方法及支付中间件 |
CN114253622A (zh) * | 2020-09-22 | 2022-03-29 | 京东科技控股股份有限公司 | 一种支付处理方法、装置、电子设备及存储介质 |
CN114531432A (zh) * | 2022-02-14 | 2022-05-24 | 浙江吉利控股集团有限公司 | 一种基于跨平台的业务通信方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
WO2018001272A1 (zh) | 2018-01-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106095537A (zh) | Android支付插件的管理方法及系统 | |
US12093283B2 (en) | Sharing data in a data storage system | |
Lewin et al. | Co-evolution of global sourcing: The need to understand the underlying mechanisms of firm-decisions to offshore | |
US20070156487A1 (en) | Object model on workflow | |
US20060167714A1 (en) | Channel-aware enterprise service | |
Liang et al. | Optimal pricing model of car-sharing: market pricing or platform pricing | |
CN109508176A (zh) | 一种企业主数据管理平台 | |
Xu et al. | Technological knowledge, product relatedness, and parent control: The effect on IJV survival | |
Henkel | Licensing standard-essential patents in the IoT–A value chain perspective on the markets for technology | |
Neri | Environmental, social and governance (ESG) and integrated reporting | |
CN101005416A (zh) | 一种基于业务规则的跨部门流程协同方法 | |
Pujats et al. | Models for intra-port container terminal cooperation based on volume and vessel transfer | |
CN102945264B (zh) | 智能启用分布式事务的方法 | |
CN108256846A (zh) | 一种集成支付的方法及系统 | |
CN109918414A (zh) | 基于建筑工程量清单的数据处理方法、装置、存储介质和计算机设备 | |
Voelz et al. | What is Different in Quality Management for SOA? | |
CN101777163A (zh) | 多功能多传输方式的商务消费系统 | |
US7567923B2 (en) | System and method for mapping information collected in connection with creation of end-user orders for communications services to the corresponding inter-provider orders | |
US20080177610A1 (en) | Visual responsibility matrix for technical designs or solutions | |
Shi | Telecommunications universal service in China: making the grade on a harmonious information society | |
Kilgore | An acuity tool for heart failure case management: quantifying workload, service utilization, and disease severity | |
US9569542B2 (en) | Method and system for cross-platform real time decision making | |
Hori | Inefficiency in a bilateral trading problem with cooperative investment | |
Wu et al. | Capacity Sharing Contracts and Subsidy Policies Under R&D Uncertainty | |
Li | Technological upgrading and decent work in the manufacturing sector: evidence from seven coastline provinces, China, 2002-2014 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20161109 |