CN101154282A - 一种实现支付的系统及方法 - Google Patents
一种实现支付的系统及方法 Download PDFInfo
- Publication number
- CN101154282A CN101154282A CNA200610140654XA CN200610140654A CN101154282A CN 101154282 A CN101154282 A CN 101154282A CN A200610140654X A CNA200610140654X A CN A200610140654XA CN 200610140654 A CN200610140654 A CN 200610140654A CN 101154282 A CN101154282 A CN 101154282A
- Authority
- CN
- China
- Prior art keywords
- account
- payment platform
- payment
- user
- money
- 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
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本发明公开了一种实现支付的系统,包括一个以上为用户提供转账业务的支付平台,支付平台之间彼此相连;其中,第一支付平台,用于如果本次业务属于需要担保的延迟到账业务,根据收到第一用户的含有第二支付平台信息、第二用户账户、金额的支付请求,将所述金额的支付款转入具有安全保障的账户;接收并转发来自第一用户的转账指令;第二支付平台,用于根据第一支付平台的转账指令通过所述具有安全保障的账户将支付款转入第二用户账户。同时,本发明还公开一种实现支付的方法。应用本发明,可以实现跨支付平台的安全支付。
Description
技术领域
本发明涉及通信和计算机技术领域,特别是指一种实现支付的系统及方法。
背景技术
目前,各个银行之间通过银联实现通存通取业务。一般情况下,银行不提供货到付款这样的担保业务。如果用户之间要进行安全的支付,就必须通过提供安全支付功能的第三方支付平台进行。
参见图1所示,支付平台1与支付平台2都是第三方平台,支付平台1与支付平台2都为用户提供服务,由于支付平台1和2之间没有做到互通,所以属于支付平台1和支付平台2的用户之间需要进行交易,目前没有提供任何安全保障。例如:提供担保服务的支付平台1内部的用户A和用户B可以直接进行安全交易,支付平台2内部的用户C和用户D也可以直接进行安全交易,但是,支付平台1内部的用户和支付平台2内部的用户之间,如用户A和用户C之间目前无法进行有安全担保的交易。
综上所述,目前的支付系统无法实现跨支付平台进行安全支付,因此,用户体验不好,用户之间交易非常不方便。
发明内容
本发明的目的是提供一种实现支付的系统及方法,使跨支付平台的用户实现安全支付。
本发明方提供的一种实现支付的方法包括:
A.第一支付平台收到第一用户发送的含有第二支付平台信息、第二用户账户以及金额信息的支付请求后,判断本次业务是否属于需要担保的延迟到账业务,如果属于,执行步骤B,否则,结束本流程;
B.第一支付平台将支付款从第一用户账户转入具有安全保障的账户;
C.当第一支付平台收到第一用户的到账请求后,从所述具有安全保障的账户中将款转给第二用户账户。
所述具有安全保障的账户为第一支付平台的系统账户,或第二支付平台的系统账户。
当所述具有安全保障的账户为第一支付平台的系统账户时,步骤B第一支付平台是直接将支付款从第一用户账户转入自身的系统账户。
当所述具有安全保障的账户为第二支付平台的系统账户时,并且第一支付平台和第二支付平台之间具有信任关系时,步骤B包括:
B11、第一支付平台从第一用户账户将支付款转入自身系统的账户;
B12、第一支付平台将支付款从自身系统的账户中将支付款转入第二支付平台的系统账户;
B12、第二支付平台通知第二用户有未到账付款。
当所述具有安全保障的账户为第二支付平台的系统账户,第一支付平台和第二支付平台之间不具有信任关系时,该方法进一步包括:
预先为第一支付平台在第二支付平台中开设的预存一定资金的私有账户,则步骤B包括:
B21、第一支付平台将款从个人账户转入自身的系统账户;
B22、第一支付平台确定所述私有账户的资金是否充足,如果不足,则第一支付平台从自身的系统账户将所述支付款转入所述在第二支付平台中开设的预存一定资金的私有账户,否则,执行步骤B23;
B23、第二支付平台将款从所述私有账户中转入第二支付平台的系统账户。
当所述具有安全保障的系统账户为第一支付平台的系统账户时,步骤C包括:
C11、当第一支付平台收到第一用户的到账请求后,将款从自身系统账户中转入第二支付平台系统账户;
C12、第二支付平台将款从自身系统账户转入第二用户账户。
当所述具有安全保障的系统账户为第二支付平台的系统账户时,步骤C包括:
C21、当第一支付平台收到第一用户的到账请求后,第一支付平台通知第二平台进行到账操作;
C22、第二支付平台收到该通知后,从自身的系统账户中将款转入第二用户账户。
在步骤B之后,进一步包括:
当第一支付平台收到第一用户的撤销付款请求后,在第一支付平台和第二支付平台做出撤销许可后,从所述具有安全保障的账户中将支付款转给第一用户账户。
在步骤A之前,该方法进一步包括:
A1、第一支付平台收到该支付请求后,利用第一用户身份信息对第一用户进行认证,如果认证通过,则执行步骤A,否则,结束本流程。
在步骤A中如果本次业务不属于需要担保的延迟到账业务,在结束本流程之前,该方法进一步包括:
第一支付平台将支付款直接转入第二用户账户。
所述具有安全保障的账户为催收支付项,在步骤A之前,该方法还进一步包括:
A1、第二支付平台收到第二用户的含有第一支付平台信息、第一用户账户、金额的催款请求后,向第一支付平台发送催款请求;
A2、第一支付平台根据收到的催款请求,建立催款支付项,并根据催款支付项向第一用户进行催收。
当所述催款支付项是在第一支付平台中建立时,步骤C包括:
C31、第一支付平台将支付款从催款支付项中转入第二支付平台的系统账户;
C32、第二支付平台将所述支付款从自身的系统账户转入第二用户账户。
步骤A2中所述催款支付项是在第一支付平台中建立,或在第二支付平台在第一支付平台的私有账户中建立。
在步骤B和步骤C之间,该方法进一步包括:第二支付平台通知第二用户有未到账的付款。
本发明提供的一种实现支付的系统包括:包括一个以上为用户提供转账业务的支付平台,其特征在于,支付平台之间彼此相连;其中,
第一支付平台,用于如果本次业务属于需要担保的延迟到账业务,根据收到第一用户的含有第二支付平台信息、第二用户账户、金额的支付请求,将所述金额的支付款转入具有安全保障的账户;接收并转发来自第一用户的的转账指令;
第二支付平台,用于根据第一支付平台的转账指令通过所述具有安全保障的账户将支付款转入第二用户账户。
所述具有安全保障的账户为第一支付平台的系统账户,或第二支付平台的系统账户。
如果本次业务不属于需要担保的延迟到账业务,所述第一支付平台还用于:将所述金额的支付款直接转入第二用户账户。
所述第一支付平台还包括认证单元,用于对接收到的第一用户的所述支付请求中第一用户身份信息进行认证。
所述第二支付平台还包括通知模块,用于在第一支付平台将所述金额的支付款转入具有安全保障的账户后,通知第二用户有未到账的付款,和/或,用于在支付款转入第二用户账户后,通知第二用户支付款转入成功。
通过上述本发明的技术方案可知,本发明利用具有安全保障的账户实现跨支付平台需要进行担保交易的安全支付问题。在本发明中,具有安全保障的账户包括即具有信任关系的两个支付平台的系统账户,不具有信任关系的支付平台中一个支付平台在另一个支付平台的私有账户,当交易双方没有达成协议之前,从支付用户账户将支付款转移到具有安全保障的账户中,如果交易双方达成协议,再从具有安全保障的账户中将所述支付款转移到收入用户账户。
附图说明
图1为现有技术中支付系统的结构示意图;
图2为为本发明的系统结构示意图;
图3为实现本发明方法的具体实施例一流程示意图;
图4为实现本发明方法的具体实施例二流程示意图;
图5为实现本发明方法的具体实施例三流程示意图;
图6为实现本发明方法的具体实施例四流程示意图。
具体实施方式
需要说明的是,以下将支付用户称为第一用户,支付用户所属支付平台称为第一支付平台,收入用户称为第二用户,收入用户所属支付平台称为第二支付平台。
参见图2所示,实现本发明的支付系统包括一个以上为用户提供转账业务的支付平台,支付平台之间彼此相连。其中,第一支付平台,用于在本次业务属于需要担保的延迟到账业务时,根据收到第一用户的含有第二支付平台信息、第二用户账户、金额的支付请求,将所述金额的支付款转入具有安全保障的账户;接收并转发来自第一用户的的转账指令;第二支付平台,用于根据第一支付平台的转账指令通知所述具有安全保障的账户将支付款转入第二用户账户。所述第一支付平台还包括认证单元,用于对接收到的第一用户的所述支付请求中第一用户身份信息进行认证。
当然,如果本次业务不属于需要担保的延迟到账业务,所述第一支付平台需要将所述金额的支付款直接转入第二用户账户。
所述第二支付平台还包括通知模块,用于在第一支付平台将所述金额的支付款转入具有安全保障的账户后,通知第二用户有未到账的付款,和/或,用于在支付款转入第二用户账户后,通知第二用户支付款转入成功。
在本发明中,所述具有安全保障的账户为第一支付平台的系统账户,或第二支付平台的系统账户。
下面结合图2和图3,以支付方发起支付请求为实施例一详细描述本发明的技术方案。
参见图3所示,本实施例实现支付的具体过程如下:
步骤301:第一用户向第一支付平台发送含有第一用户身份信息、第二支付平台信息、第二用户账户以及金额信息的支付请求。
步骤302:第一支付平台收到该支付请求后,利用第一用户身份信息对第一用户进行认证,如果认证通过,则执行步骤303,否则,结束本流程。
步骤303:第一支付平台判断本次业务是否属于需要担保的延迟到账业务,如果是,则执行步骤304,否则,执行步骤307。
步骤304:第一支付平台将支付款从第一用户账户转入第一支付平台的系统账户,并通知第二支付平台第一用户已经支付。
步骤305:第二支付平台收到该通知后,再通知第二用户第一用户已经支付。
步骤306:第二用户收到该通知后,完成和第一用户约定的交易任务户。如果第一用户同意到账,通知第一支付平台进行到账操作。
步骤307:第一支付平台进行到账操作,结束本流程。进行到账操作具体步骤为:第一支付平台将转款到第二支付平台。第二支付平台将款转入第二用户账户,通知第二用户已到账。
在步骤303中,如果本次业务属于需要担保的延迟到账业务,作为替代方案,步骤304~307可以这样执行:第一支付平台将支付款从第一用户账户转入第二支付平台,第二支付平台暂存该支付款,然后第二支付平台通知第二用户有未到账的付款。第二用户收到该通知后,完成和第一用户约定的交易任务户,第一用户同意到账,通知第一支付平台进行到账操作;第一支付平台收到该通知后,通知第二支付平台进行转账操作。第二支付平台将款转入第二用户账户。
下面结合图2和图4,以收入方发起催款请求为实施例二详细说明本发明的技术方案。
参见图4所示,本实施例实现安全支付的具体过程如下:
步骤401:第二用户向第二支付平台发送催款请求,其中包括第二用户身份信息、第一支付平台信息、第一用户账户信息、金额。
步骤402:第二支付平台收到该催款请求后,利用第二用户身份信息对第二用户进行认证,如果认证通过,通知第一支付平台建立催收支付项,否则,结束本流程。
步骤403:第一支付平台收到该通知后,建立催收支付项。
步骤404:第一支付平台向第一用户发送催款通知。
步骤405:第一用户收到该催款通知后,如果同意支付,则向第一支付平台发送付款请求。
步骤406:第一支付平台收到该付款请求后,判断本次业务是否为延迟到账业务,如果是,执行步骤407,否则,执行步骤411。
步骤407:第一支付平台从第一用户账户将支付款转入催收支付项。
步骤408:第一支付平台通知第二支付平台第一用户已经支付。
步骤409:第二支付平台收到该通知后,再向第二用户发送第一用户已经支付的通知。
步骤410:第一用户和第二用户完成交易。如果第一用户同意支付,则向第一支付平台发送同意支付的通知。
步骤411:第一支付平台进行到账操作。第一支付平台进行到账操作的步骤可以包括:第一支付平台将款转入第二支付平台;第二支付平台将款转入第二用户账户,并通知第二用户已到账。
步骤410中如果第一用户不同意支付款项,则向第一支付平台发送撤销付款的通知,在第一支付平台和第二支付平台都做出撤销许可后,将款从催收支付项中转入第一用户账户,结束本流程。
在步骤407中,如果本次业务属于需要担保的延迟到账业务,作为替代方案,步骤408~411可以这样执行:第二支付平台建立催收支付项,再通知第一支付平台。当第一用户向第一支付平台发送同意支付的通知后,第一支付平台通知第二支付平台第一用户同意支付,并将支付款从第一支付平台转入第二支付平台催收支付项,第二支付平台再从催收支付项将支付款转入第二用户账户。
以下实施例三是以第一支付平台作为普通用户在第二支付平台建立自己的私有账户,并与存有一定资金的情况下,实现支付的方法。
下面结合图2和图5以支付用户为发起方为实施例三详细说明本发明的技术方案。
参见图5所示,本实施例实现安全支付的具体过程如下:
步骤501:第一用户向第一支付平台发送支付请求,其中含有第一用户身份信息、第二支付平台信息,第二用户账户信息、金额等信息。
步骤502:第一支付平台收到该支付请求后,对第一用户进行认证,如果认证通过,则将款从第一用户账户转入系统账户,即第一支付平台的系统账户,否则,结束本流程。
步骤503:第一支付平台操作自己在第二支付平台的私有账户,将款转入第二支付平台的系统账户。
步骤504:第二支付平台判断本次业务是否需要安全担保的延迟到账,如果是,执行步骤505,否则,第一支付平台操作自己在第二支付平台上的私有账户执行直接到账,款立刻汇入第二用户账户,结束本流程。
步骤505:第二支付平台通知第二用户第一用户已经支付。
步骤506:第一用户和第二用户完成交易。如果第一用户同意支付,第一用户向第一支付平台发送到账请求。
步骤507:第一支付平台收到该支付请求后,进行转账操作。
第一支付平台进行转账操作的步骤可以包括:第一支付平台向第二支付平台发送到账通知,第二支付平台收到该通知后,将款从自身系统账户转入第二用户账户,最后通知第二用户转账成功。
步骤506中如果第一用户不同意支付,则向第一支付平台发送撤销请求,在第一支付平台和第二支付平台都同意撤销的情况下,第一支付平台将款从系统账户转入第一用户账户。
实施例四是以第二支付平台作为普通用户在第一支付平台建立自己的私有账户,并与存有一定资金的情况下,实现支付的方法。
下面结合图2和图6以收入用户为发起方为实施例四详细说明本发明的技术方案。
参见图6所示,本实施例实现安全支付的具体过程如下:
步骤601:第二用户向第二支付平台发送催收支付项建立请求,其中包括第二用户身份信息、第一支付平台信息、第一用户账户信息、金额等。
步骤602:第二支付平台收到该请求后,对第二用户进行认证,如果认证通过,通知第一支付平台建立第二支付平台在第一支付平台的私有账户到第一用户的催收支付项。
步骤603:第二支付平台收到该通知后,建立从第二支付平台私有账户到第一用户账户的催收支付项。
步骤604:第一支付平台通知第一用户有催收款项。
步骤605:第一用户收到该通知后,向第一支付平台发送支付请求。
步骤606:第一支付平台收到支付请求后,判断本次业务是否属于延迟到账类型,如果是,则将款从第一用户账户转入催收支付项,执行步骤607,否则,执行步骤610。
步骤607:第一支付平台通知第二支付平台有未到账的付款。
步骤608:第二支付平台收到该通知后,通知第二用户有未到账的付款。
步骤609:第一用户和第二用户完成交易。如果第一用户同意支付,第一用户向第一支付平台发送到账请求。
步骤610:第一支付平台进行到账操作。即:第一支付平台将款转入第二支付平台在第一支付平台的私有账户;第一支付平台通知第二支付平台款已经到账;第二支付平台收到该通知后,从系统账户向第二用户账户转款,并通知第二用户转账已经成功。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (19)
1.一种实现支付的方法,其特征在于,该方法包括以下步骤:
A.第一支付平台收到第一用户发送的含有第二支付平台信息、第二用户账户以及金额信息的支付请求后,判断本次业务是否属于需要担保的延迟到账业务,如果属于,执行步骤B,否则,结束本流程;
B.第一支付平台将支付款从第一用户账户转入具有安全保障的账户;
C.当第一支付平台收到第一用户的到账请求后,从所述具有安全保障的账户中将款转给第二用户账户。
2.根据权利要求1所述的方法,其特征在于,所述具有安全保障的账户为第一支付平台的系统账户,或第二支付平台的系统账户。
3.根据权利要求1所述的方法,其特征在于,当所述具有安全保障的账户为第一支付平台的系统账户时,步骤B第一支付平台是直接将支付款从第一用户账户转入自身的系统账户。
4.根据权利要求1所述的方法,其特征在于,当所述具有安全保障的账户为第二支付平台的系统账户时,并且第一支付平台和第二支付平台之间具有信任关系时,步骤B包括:
B11、第一支付平台将支付款从第一用户账户转入自身系统的账户;
B12、第一支付平台将支付款从自身系统的账户中将支付款转入第二支付平台的系统账户;
B12、第二支付平台通知第二用户有未到账付款。
5.根据权利要求1所述的方法,其特征在于,当所述具有安全保障的账户为第二支付平台的系统账户,第一支付平台和第二支付平台之间不具有信任关系时,该方法进一步包括:
预先为第一支付平台在第二支付平台中开设的预存一定资金的私有账户,
则步骤B包括:
B21、第一支付平台将款从个人账户转入自身的系统账户;
B22、第一支付平台确定所述私有账户的资金是否充足,如果不足,则第一支付平台从自身的系统账户将所述支付款转入所述在第二支付平台中开设的预存一定资金的私有账户,否则,执行步骤B23;
B23、第二支付平台将款从所述私有账户中转入第二支付平台的系统账户。
6.根据权利要求1所述的方法,其特征在于,当所述具有安全保障的系统账户为第一支付平台的系统账户时,步骤C包括:
C11、当第一支付平台收到第一用户的到账请求后,将款从自身系统账户中转入第二支付平台系统账户;
C12、第二支付平台将款从自身系统账户转入第二用户账户。
7.根据权利要求1所述的方法,其特征在于,当所述具有安全保障的系统账户为第二支付平台的系统账户时,步骤C包括:
C21、当第一支付平台收到第一用户的到账请求后,第一支付平台通知第二平台进行到账操作;
C22、第二支付平台收到该通知后,从自身的系统账户中将款转入第二用户账户。
8.根据权利要求1所述的方法,其特征在于,在步骤B之后,进一步包括:
当第一支付平台收到第一用户的撤销付款请求后,在第一支付平台和第二支付平台做出撤销许可后,从所述具有安全保障的账户中将支付款转给第一用户账户。
9.根据权利要求1所述的方法,其特征在于,在步骤A之前,该方法进一步包括:
A1、第一支付平台收到该支付请求后,利用第一用户身份信息对第一用户进行认证,如果认证通过,则执行步骤A,否则,结束本流程。
10.根据权利要求1所述的方法,其特征在于,在步骤A中如果本次业务不属于需要担保的延迟到账业务,在结束本流程之前,该方法进一步包括:
第一支付平台将支付款直接转入第二用户账户。
11.根据权利要求1所述的方法,其特征在于,所述具有安全保障的账户为催收支付项,在步骤A之前,该方法还进一步包括:
A1、第二支付平台收到第二用户的含有第一支付平台信息、第一用户账户、金额的催款请求后,向第一支付平台发送催款请求;
A2、第一支付平台根据收到的催款请求,建立催款支付项,并根据催款支付项向第一用户进行催收。
12.根据权利要求11所述的方法,其特征在于,当所述催款支付项是在第一支付平台中建立时,步骤C包括:
C31、第一支付平台将支付款从催款支付项中转入第二支付平台的系统账户;
C32、第二支付平台将所述支付款从自身的系统账户转入第二用户账户。
13.根据权利要求11或12所述的方法,其特征在于,步骤A2中所述催款支付项是在第一支付平台中建立,或在第二支付平台在第一支付平台的私有账户中建立。
14.根据权利要求1所述的方法,其特征在于,在步骤B和步骤C之间,该方法进一步包括:第二支付平台通知第二用户有未到账的付款。
15.一种实现支付的系统,包括一个以上为用户提供转账业务的支付平台,其特征在于,支付平台之间彼此相连;其中,
第一支付平台,用于如果本次业务属于需要担保的延迟到账业务,根据收到第一用户的含有第二支付平台信息、第二用户账户、金额的支付请求,将所述金额的支付款转入具有安全保障的账户;接收并转发来自第一用户的转账指令;
第二支付平台,用于根据第一支付平台的转账指令通过所述具有安全保障的账户将支付款转入第二用户账户。
16.根据权利要求15所述的系统,其特征在于,所述具有安全保障的账户为第一支付平台的系统账户,或第二支付平台的系统账户。
17.根据权利要求15所述的系统,其特征在于,如果本次业务不属于需要担保的延迟到账业务,所述第一支付平台还用于:将所述金额的支付款直接转入第二用户账户。
18.根据权利要求15所述的系统,其特征在于,所述第一支付平台还包括认证单元,用于对接收到的第一用户的所述支付请求中第一用户身份信息进行认证。
19.根据权利要求15所述的系统,其特征在于,所述第二支付平台还包括通知模块,用于在第一支付平台将所述金额的支付款转入具有安全保障的账户后,通知第二用户有未到账的付款,和/或,用于在支付款转入第二用户账户后,通知第二用户支付款转入成功。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA200610140654XA CN101154282A (zh) | 2006-09-29 | 2006-09-29 | 一种实现支付的系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA200610140654XA CN101154282A (zh) | 2006-09-29 | 2006-09-29 | 一种实现支付的系统及方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101154282A true CN101154282A (zh) | 2008-04-02 |
Family
ID=39255926
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA200610140654XA Pending CN101154282A (zh) | 2006-09-29 | 2006-09-29 | 一种实现支付的系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101154282A (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103399846A (zh) * | 2013-08-05 | 2013-11-20 | 苏州鼎富软件科技有限公司 | 开放式网络翻译方法 |
CN106302558A (zh) * | 2015-05-11 | 2017-01-04 | 阿里巴巴集团控股有限公司 | 一种业务处理方法和装置 |
WO2017011995A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证变更以及数据交互处理的方法、系统及装置 |
WO2017011996A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证变更以及数据交互处理的方法、系统及装置 |
WO2017012013A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证的退回方法以及电子支付系统 |
WO2017011997A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证变更以及数据交互处理的方法、系统及装置 |
CN106600254A (zh) * | 2016-12-16 | 2017-04-26 | 天脉聚源(北京)科技有限公司 | 用户的多帐户管理方法及装置 |
CN106899539A (zh) * | 2015-12-17 | 2017-06-27 | 阿里巴巴集团控股有限公司 | 跨系统的业务操作执行方法、业务平台以及目标系统 |
CN108074083A (zh) * | 2016-11-18 | 2018-05-25 | 腾讯科技(深圳)有限公司 | 一种请求处理方法、服务器及客户端 |
CN109034820A (zh) * | 2018-06-27 | 2018-12-18 | 阿里巴巴集团控股有限公司 | 一种对已发出消息的处理方法及装置 |
-
2006
- 2006-09-29 CN CNA200610140654XA patent/CN101154282A/zh active Pending
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103399846A (zh) * | 2013-08-05 | 2013-11-20 | 苏州鼎富软件科技有限公司 | 开放式网络翻译方法 |
CN106302558A (zh) * | 2015-05-11 | 2017-01-04 | 阿里巴巴集团控股有限公司 | 一种业务处理方法和装置 |
CN106302558B (zh) * | 2015-05-11 | 2020-01-21 | 阿里巴巴集团控股有限公司 | 一种业务处理方法和装置 |
WO2017011995A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证变更以及数据交互处理的方法、系统及装置 |
WO2017011996A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证变更以及数据交互处理的方法、系统及装置 |
WO2017012013A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证的退回方法以及电子支付系统 |
WO2017011997A1 (zh) * | 2015-07-21 | 2017-01-26 | 深圳市银信网银科技有限公司 | 一种电子凭证变更以及数据交互处理的方法、系统及装置 |
CN111565183A (zh) * | 2015-12-17 | 2020-08-21 | 阿里巴巴集团控股有限公司 | 跨系统的业务操作执行方法、业务平台以及目标系统 |
CN106899539A (zh) * | 2015-12-17 | 2017-06-27 | 阿里巴巴集团控股有限公司 | 跨系统的业务操作执行方法、业务平台以及目标系统 |
US11200566B2 (en) | 2015-12-17 | 2021-12-14 | Advanced New Technologies Co., Ltd. | Enhancing performance of inter-system service operations |
CN106899539B (zh) * | 2015-12-17 | 2020-03-20 | 阿里巴巴集团控股有限公司 | 跨系统的业务操作执行方法、业务平台以及目标系统 |
CN108074083A (zh) * | 2016-11-18 | 2018-05-25 | 腾讯科技(深圳)有限公司 | 一种请求处理方法、服务器及客户端 |
CN106600254A (zh) * | 2016-12-16 | 2017-04-26 | 天脉聚源(北京)科技有限公司 | 用户的多帐户管理方法及装置 |
CN109034820B (zh) * | 2018-06-27 | 2021-08-31 | 创新先进技术有限公司 | 一种对已发出消息的处理方法及装置 |
CN109034820A (zh) * | 2018-06-27 | 2018-12-18 | 阿里巴巴集团控股有限公司 | 一种对已发出消息的处理方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101154282A (zh) | 一种实现支付的系统及方法 | |
CN101154283A (zh) | 一种实现支付的系统及方法 | |
US8793169B2 (en) | Method and system to charge an account | |
KR20100138887A (ko) | Sim 칩 은행 시스템 및 방법 | |
CN102521744A (zh) | 网络支付方法及装置 | |
CN101996368A (zh) | 一种跨银行批量付款方法及系统 | |
WO2004049093B1 (en) | Scheme for spreading and facilitating remote e-services | |
CN113837732A (zh) | 互联网资源转移方法、转账方法及装置 | |
JP2017505960A (ja) | 送金システム及び方法 | |
CN100485727C (zh) | 实现个人电子支票卡的系统和方法 | |
CN101916421A (zh) | 一种外汇汇款业务处理方法及系统 | |
EP1455317A2 (en) | Method for securing card transactions by using mobile device | |
CN109583867A (zh) | 渠道对接系统及方法 | |
CN101201956A (zh) | 自动圈存pos和实现电子钱包ic卡自动圈存的系统及方法 | |
CN103455915A (zh) | 一种支付的实现方法和终端 | |
WO2009129749A1 (zh) | 手机支付方法、系统及终端 | |
CN102467788A (zh) | 实现自助打印服务的方法、装置及系统 | |
CN101894334A (zh) | 支付方法、系统、移动终端及其支付方法及系统 | |
CN1595460A (zh) | 一种通过局部无线网络完成银行交易的系统及方法 | |
CN102208069A (zh) | 用手机另路确认的银行在线支付系统和方法 | |
CN101751701B (zh) | 非接触电子票证共享系统及其共享方法 | |
CN102955999B (zh) | 电子钱包的圈存方法及系统 | |
CN102270326A (zh) | 基于智能网支付类增值业务的鉴权计费系统和方法 | |
CN201993844U (zh) | 手机号支付平台、支付交易系统 | |
CN101378429A (zh) | 一种电话购物的支付方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1114442 Country of ref document: HK |
|
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20080402 |
|
REG | Reference to a national code |
Ref country code: HK Ref legal event code: WD Ref document number: 1114442 Country of ref document: HK |