CN106327167B - Method and device for realizing network payment - Google Patents
Method and device for realizing network payment Download PDFInfo
- Publication number
- CN106327167B CN106327167B CN201510330912.XA CN201510330912A CN106327167B CN 106327167 B CN106327167 B CN 106327167B CN 201510330912 A CN201510330912 A CN 201510330912A CN 106327167 B CN106327167 B CN 106327167B
- Authority
- CN
- China
- Prior art keywords
- payment
- condition
- option dimension
- option
- user
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 230000004044 response Effects 0.000 claims abstract description 34
- 238000013475 authorization Methods 0.000 claims description 10
- 238000012795 verification Methods 0.000 claims description 4
- 230000007423 decrease Effects 0.000 claims description 2
- 230000008569 process Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- 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/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
- G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
-
- 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/08—Payment architectures
- G06Q20/16—Payments settled via telecommunication systems
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The application provides a method for realizing network payment, which comprises the following steps: transmitting a first payment request to a fund server of a payment channel provider based on a first payment condition; the payment conditions of the payment channel comprise at least one option dimension with different possible values, and the first payment condition comprises a determined option dimension value; after receiving the payment refusal response of the fund server, sending a second payment request to the fund server based on a second payment condition, wherein at least one option dimension value of the second payment condition is different from that of the first payment condition. Through the technical scheme of the application, the operation amount of the user in payment attempt is reduced, the successful probability of payment is improved, and the situation that remote payment cannot be completed through a network is reduced.
Description
Technical Field
The present application relates to the field of data processing technologies, and in particular, to a method and an apparatus for implementing network payment.
Background
With the continuous development of network technology, online transaction has become an important transaction mode in people's life, and online payment is an essential component in the online transaction process.
In online payments, particularly in cross-border transactions, payment failures of unknown cause are often encountered. In the prior art, when a payment failure occurs in such a situation, a payment server of a merchant or a payment server of a third-party platform returns a message of the payment failure to a user and terminates the payment. The user needs to reopen the payment page of the order, and even needs to return to the shopping cart to perform the next payment attempt, so that the operation is complicated and the efficiency is low; for users who are not familiar with network payments, it is likely that multiple attempts are experienced and yet the transaction has to be aborted because of unsuccessful payments, and still not satisfactory results are obtained after a significant amount of time and effort has been expended.
Disclosure of Invention
In view of the above, the present application provides a method for implementing network payment, including:
transmitting a first payment request to a fund server of a payment channel provider based on a first payment condition; the payment conditions of the payment channel comprise at least one option dimension with different possible values, and the first payment condition comprises a determined option dimension value;
after receiving the payment refusal response of the fund server, sending a second payment request to the fund server based on a second payment condition, wherein at least one option dimension value of the second payment condition is different from that of the first payment condition.
The application also provides a device for realizing network payment, which comprises:
a first payment request unit for transmitting a first payment request to a fund server of a payment channel provider based on a first payment condition; the payment conditions of the payment channel comprise at least one option dimension with different possible values, and the first payment condition comprises a determined option dimension value;
and the second payment request unit is used for sending a second payment request to the fund server based on a second payment condition after receiving the payment refusing response of the fund server, wherein at least one option dimension value of the second payment condition is different from that of the first payment condition.
According to the technical scheme, in the embodiment of the application, after the payment request based on the first payment condition fails, the payment request is reinitiated by adopting the second payment condition with different option dimension values; by the method or the device running on the payment node, the operation amount of the user in payment attempt is greatly reduced, and the efficiency of the user is improved; meanwhile, the embodiment of the application provides a means for trying the payment conditions of all option dimension values, which is beneficial to improving the probability of successful payment and reducing the occurrence of the situation that remote payment cannot be completed through a network.
Drawings
FIG. 1 is a flow chart of a method for implementing network payment in an embodiment of the present application;
FIG. 2 is a flow chart of interaction among a terminal, a payment server and a fund server in an application example of the application;
fig. 3 is a hardware configuration diagram of a terminal or a server;
fig. 4 is a logic structure diagram of an apparatus for implementing network payment in the embodiment of the present application.
Detailed Description
When a user makes a network payment, a payment channel used for the payment is generally determined first. The payment channel includes credit card, debit card, user's fund account on the third party payment platform, etc., it should be noted that different cards or fund accounts of the same user belong to different payment channels. Each payment channel has a respective payment condition, which may include various dimensions, such as currency of payment, authorization method, etc., according to the type of the payment channel and the function provided by the provider of the payment channel (e.g., card issuing bank, third party payment platform, etc.). These dimensions may be deterministic dimensions, for example, if a certain payment channel can only be used for RMB collection, the currency of the payment channel belongs to deterministic dimensions; or an option dimension, which has two or more possible values, and which dimension value is to be used to form the payment condition can be selected by the user.
For a payment channel comprising option dimension payment conditions, in network payment, especially cross-border payment, providers of the payment channel often set different check strictness degrees for the payment conditions of different option dimension values. For example, the stringency of checks with local currency is typically lower than those with dollar payments; as another example, the strictness of the verification for Payment using 3D (Three-Domain Secure) is generally lower than that for Payment using MOTO (Mail Order and Telephone Order Payment). In other words, when the value of the currency option dimension is adopted as the payment condition of the local currency, the probability of successful payment is generally higher than that of the payment condition adopting the value of the currency option dimension as the dollar amount; when the value of the option dimension in the authorization mode is the payment condition for 3D payment, the probability of successful payment is generally higher than that of the payment condition for MOTO payment.
Therefore, for a certain payment channel, when payment is carried out by adopting a payment condition of a group of option dimension values (including one to more specific values of the option dimension) and the payment fails, other values of the option dimension can be replaced for trial again, and the payment channel provider can accept the payment and the payment is successful.
The embodiment of the application provides a new method for realizing network payment, which can replace payment conditions with different option dimension values to initiate a payment request again after payment fails, thereby reducing user operation, improving user efficiency, and simultaneously reducing the situation that network payment cannot be successfully realized, so as to solve the problems in the prior art.
According to different practical application scenarios, the method in the embodiment of the application can be applied to different payment nodes. For example, when a user applies for payment to a payment channel provider through a payment server of a merchant or a payment server of a third party payment platform, if the merchant or the payment server of the third party payment platform performs message transmission between a user terminal and a fund server of the payment channel provider, the method in the embodiment of the present application may be applied to the payment server of the merchant or the third party payment platform. For another example, if the user terminal directly applies for payment to the fund server of the payment channel provider, the method of the embodiment of the present application may be applied to the user terminal.
It should be noted that the payment server of the merchant or the third party payment platform refers to a physical or logical entity where software for realizing the user payment function is operated, and completes the payment process through message exchange with the user terminal and the fund server of the payment channel provider; the fund server of the payment channel provider refers to a physical or logical entity where software for operating the user fund account is located, for example, the payment channel may be a background system of a card issuing bank when the payment channel is a credit card, and the payment channel may be a server for managing the user fund account of a third party payment platform when the payment channel is the fund account of the third party payment platform. In the embodiment of the present application, the types and specific implementation forms of the payment server, the fund server and the user terminal are not limited.
In this embodiment, a flow of a method for implementing network payment is shown in fig. 1.
In the embodiment of the application, when the user makes payment, the payment condition of the used payment channel comprises at least one option dimension. As previously mentioned, the option dimension has two or more different possible values. When different option dimension values are used, it is equivalent to making payments with different payment conditions.
The payment node (comprising a payment server of a merchant, a payment server of a third-party payment platform, a user terminal and the like) sends a first payment request to the fund server, wherein the first payment request adopts a first payment condition (with a determined option dimension value). The payment node may determine the option dimension value of the first payment condition according to the current selection of the user, may also obtain the option dimension value of the first payment condition according to the default setting of the user, and may also determine the option dimension value of the first payment condition according to the default setting with the fund server, which is not limited in this embodiment.
And 120, after receiving the payment refusal response of the fund server, sending a second payment request to the fund server based on a second payment condition, wherein at least one option dimension value of the second payment condition is different from that of the first payment condition.
If the funding server returns a response to the payment request based on the first payment conditions that payment is denied, the payment node changes the payment conditions and re-initiates the payment request with a second payment condition having a different option dimension value than the first payment condition. For the payment channel with more than one option dimension, the value of only one option dimension can be modified to obtain the second payment condition, and the values of two or more option dimensions can also be modified simultaneously. Since the payment channel provider usually applies different check strictness degrees to different payment conditions, it is possible to pay successfully after changing the payment conditions.
The payment node may determine the second payment condition in various ways according to actual application scenario requirements.
In one example, after receiving the payment denial response from the funding server, the payment node may recommend to the user to attempt a re-payment with an option dimension value (at least one option dimension value being different) different from the first payment condition, determine the second payment condition with the recommended option dimension value as the option dimension value of the second payment condition if the user agrees, and send a second payment request to the funding server based on the second payment condition.
In a second example, after receiving the response of the fund server to reject the payment, the payment node may generate a second payment condition (at least one option dimension value is different) by itself using an option dimension value different from the first payment condition, and initiate a second payment request using the generated second payment condition, which may be performed without user intervention.
For the application scenario in which the payment node is a payment server, in the above two examples, the payment server of the merchant or the third-party payment platform can summarize, through the payment processes of multiple users, which payment condition or conditions are more loosely verified by the provider of the same kind of payment channel (e.g., a credit card of a certain bank, a certain type of account of a certain third-party payment platform), or which payment condition or conditions are adopted is more easily accepted by the provider of the payment channel; after receiving the response of refusing payment, the payment condition which is more easily accepted by the payment channel provider can be recommended to the user or directly adopted for initiating the next payment request.
In a third example, the payment node may display an interface for specifying the option dimension value to the user after receiving the payment refusal response from the fund server, and use the obtained option dimension value specified by the user as the option dimension value of the second payment condition. At least one of the option dimension values designated by the user is different from the option dimension value of the first payment condition.
The manners of determining the dimension value of the second payment condition option in the above three examples may be used alone or in combination. For example, after receiving the payment refusal response, the payment node may recommend a new option dimension value to the user first, and if the user agrees, the recommended option dimension value is used for the second payment condition; and if the user does not agree, enabling the user to select the option dimension value of the second payment condition.
When payments are made based on different payment conditions, the payment information (e.g., account number or card number, password, expiration date, confirmation of reservation, etc.) that needs to be provided to the funding server may vary. Before receiving the response of refusing payment, the payment node provides the fund server with the payment information required when the user pays in the first payment condition; if the payment information required for the second payment condition is within the range of the payment information required for the first payment condition, the payment node may transmit the saved payment information to the fund server without acquiring it from the user again; if the second payment condition requires the provision of payment information not included in the first payment condition, the payment node may receive payment information for the second payment request from the user before sending the second payment request to the funding server. Before sending the second payment request, the payment node can only collect the part of the payment information which is not included in the first payment condition to the user or does not collect the payment information to the user, so that the user does not need to repeatedly input the payment information, the operation of the user is further reduced, and the efficiency is improved.
If the response returned by the funding server to the second payment request is still a decline payment response, the payment node may again modify the option dimension value, get the new payment condition and try again until the payment is successful or traverse all possible option dimension values and combinations thereof.
It should be noted that the payment channel provider typically returns a payment denial response including two types, a payment denial response with unspecified reason (also called universal denial) and a payment denial response with a specified reason. In the payment refusal response of the designated reason, the payment channel provider can give the reason of refusing payment, such as insufficient account balance, wrong password, mismatching of the card number and the validity period and the like; in the reason-unspecified reject payment response, the payment channel provider does not give a specific reject reason. Due to the fact that the payment response is rejected for the specified reason, or the user is required to input the payment information again, or even the user is required to change another payment channel, the payment response rejection method and the payment response rejection device are more suitable for the situation that the payment response rejection is general rejection.
Therefore, in the embodiment of the application, after the payment request adopting the first payment condition is rejected, the second payment condition is formed by the new option dimension value to carry out the payment request again, so that the user does not need to manually complete all operations for requesting payment again, the workload of the user is reduced, and the efficiency of the user is improved; meanwhile, different payment conditions have different payment success rates, and the embodiment of the application can conveniently traverse all possible payment conditions, thereby bringing convenience to users and improving the success probability of network payment; by running the method provided by the embodiment of the application on the payment node, the situation that the user still has to give up the transaction due to the fact that the user cannot pay successfully through the network after multiple attempts in the prior art can be greatly reduced.
In one application example of the application, a user uses a credit card of the user as a payment channel to pay in a cross-border transaction through a payment server of a third-party payment platform. The payment condition of the credit card comprises two option dimensions of supporting currency and an authorization mode, wherein the value of the currency dimension can be RMB, dollars or Euros, and the value of the authorization mode can be MOTO payment or 3D payment. In the present application example, the interaction flow between the user terminal, the payment server and the fund server of the credit card issuing bank is shown in fig. 2.
The user pays through the third-party payment platform, the user determines that the payment is carried out by taking the payment of the dollar and the MOTO as the first payment condition on the terminal, and the terminal sends the first payment condition of the user and the payment information required by the payment under the first payment condition to the payment server.
The payment server initiates a first payment request to the fund server according to the first payment condition and the payment information provided by the user; the funding server returns a generic denial response to the payment server.
The payment server sends notification and prompt messages to the user terminal, the user terminal informs the user of payment failure in a popup window or webpage mode and prompts the user whether to retry by taking Euro and 3D payment as new payment conditions.
And after the user clicks an agreement button on a prompt interface of the terminal, the terminal informs the payment server of the agreement information of the user. And the payment server initiates a second payment request to a fund server of the card issuing bank by taking the Euro and the 3D payment as second payment conditions.
Corresponding to the above flow implementation, the embodiment of the application further provides a device for implementing network payment. The apparatus may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, the device in the logical sense is formed by reading a corresponding computer program instruction into a memory for running through a Central Processing Unit (CPU) of a payment node (terminal or server). In terms of hardware, in addition to the CPU, the memory, and the nonvolatile memory shown in fig. 3, a terminal where the device for implementing network payment is located generally includes other hardware such as a chip for transmitting and receiving a wireless signal, and a server where the device for implementing network payment is located generally includes other hardware such as a board for implementing a network communication function.
Fig. 4 is a diagram illustrating an apparatus for implementing network payment according to an embodiment of the present application, where the apparatus includes a first payment request unit and a second payment request unit, where: the first payment request unit is used for sending a first payment request to a fund server of a payment channel provider based on a first payment condition; the payment conditions of the payment channel comprise at least one option dimension with different possible values, and the first payment condition comprises a determined option dimension value; the second payment request unit is used for sending a second payment request to the fund server based on a second payment condition after receiving the payment refusal response of the fund server, wherein at least one option dimension value of the second payment condition is different from that of the first payment condition.
In one example, the apparatus further includes a second payment condition recommending unit configured to recommend the option dimension value to the user as the option dimension value of the second payment condition after the user agrees after receiving the payment refusal response from the fund server; at least one of the recommended option dimension values is different from the option dimension value of the first payment condition.
In another example, the apparatus further includes a second payment condition specifying unit configured to adopt the option dimension value specified by the user as the option dimension value of the second payment condition after receiving the payment denial response from the fund server; at least one of the user-specified option dimension values is different from the option dimension value of the first payment condition.
Optionally, the apparatus further comprises: and a payment information collection unit for receiving payment information for the second payment request from the user before sending the second payment request to the fund server.
Optionally, the option dimension includes currency and an authorization manner, and the value of the authorization manner includes a cardless payment MOTO payment and a payment verification 3D payment.
Optionally, the payment denial response of the fund server includes: a reject payment response for unspecified reason.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
Claims (8)
1. A method for enabling network payments, comprising:
transmitting a first payment request to a fund server of a payment channel provider based on a first payment condition; the payment conditions of the payment channel comprise at least one option dimension, and each option dimension has at least two known values for alternative use; the option dimension is determined according to the type of the payment channel and the function provided by the payment channel provider, and comprises at least one of currency and an authorization mode; the first payment condition comprises a determined option dimension value;
after receiving a payment refusing response of the fund server and after the user agrees, taking the option dimension value recommended to the user as the option dimension value of the second payment condition; at least one of the recommended option dimension values is different from the option dimension value of the first payment condition; or, automatically generating a second payment condition, at least one option dimension value of the generated second payment condition being different from the first payment condition;
a second payment request is sent to the funding server based on the second payment condition.
2. The method of claim 1, further comprising: payment information for the second payment request is received from the user prior to sending the second payment request to the funding server.
3. The method of claim 1, wherein the authorization means is selected from the group consisting of a cardless payment MOTO payment and a payment verification 3D payment.
4. The method of claim 1, wherein the funding server's response to declining payment comprises: a reject payment response for unspecified reason.
5. An apparatus for enabling network payments, comprising:
a first payment request unit for transmitting a first payment request to a fund server of a payment channel provider based on a first payment condition; the payment conditions of the payment channel comprise at least one option dimension, and each option dimension has at least two known values for alternative use; the option dimension and the known value thereof are determined according to the type of the payment channel and the function provided by the payment channel provider, and comprise at least one of currency and an authorization mode; the first payment condition comprises a determined option dimension value;
the second payment condition recommending unit is used for recommending the option dimension value to the user as the option dimension value of the second payment condition after the payment refusing response of the fund server is received and the user agrees; at least one of the recommended option dimension values is different from the option dimension value of the first payment condition; or, automatically generating a second payment condition, at least one option dimension value of the generated second payment condition being different from the first payment condition;
and the second payment request unit is used for sending a second payment request to the fund server based on the second payment condition.
6. The apparatus of claim 5, further comprising: and a payment information collection unit for receiving payment information for the second payment request from the user before sending the second payment request to the fund server.
7. The apparatus of claim 5, wherein the authorization means is selected from a group consisting of a cardless payment MOTO payment and a payment verification 3D payment.
8. The apparatus of claim 5, wherein the funding server's response to decline payment comprises: a reject payment response for unspecified reason.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510330912.XA CN106327167B (en) | 2015-06-15 | 2015-06-15 | Method and device for realizing network payment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510330912.XA CN106327167B (en) | 2015-06-15 | 2015-06-15 | Method and device for realizing network payment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106327167A CN106327167A (en) | 2017-01-11 |
| CN106327167B true CN106327167B (en) | 2021-06-29 |
Family
ID=57732239
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510330912.XA Active CN106327167B (en) | 2015-06-15 | 2015-06-15 | Method and device for realizing network payment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106327167B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107292598A (en) * | 2017-05-31 | 2017-10-24 | 杭州大搜车汽车服务有限公司 | One kind pays method for routing and pays route middleware |
| CN109472563A (en) * | 2018-10-26 | 2019-03-15 | 数贸科技（北京）有限公司 | The means of payment based on cross-border payment platform automates O&M method and device |
| CN109829717A (en) * | 2018-12-15 | 2019-05-31 | 深圳壹账通智能科技有限公司 | O&M method, apparatus, computer installation and the storage medium of payment channel |
| CN111784384B (en) * | 2020-06-19 | 2022-07-19 | 支付宝(杭州)信息技术有限公司 | Payment service data processing method, device, equipment and system |
| CN113435871A (en) * | 2021-06-29 | 2021-09-24 | 未鲲(上海)科技服务有限公司 | Payment channel abnormity checking method and device, computing equipment and storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103366275A (en) * | 2009-06-09 | 2013-10-23 | Sk普兰尼特有限公司 | Electronic money payment system and electronic money payment method |
| CN103870992A (en) * | 2014-03-17 | 2014-06-18 | 中国工商银行股份有限公司 | Cross-border multi-currency data processing system and method |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015071784A2 (en) * | 2013-09-30 | 2015-05-21 | De Waal André | Method of calculating and reporting currency exchange rates |
| CN103679445B (en) * | 2013-12-17 | 2017-10-13 | 广州云移信息科技有限公司 | Method of network payment and its network payment system |
| CN104268746A (en) * | 2014-09-17 | 2015-01-07 | 江苏爱心消费支付服务有限公司 | Card-free payment method |
| CN104463585A (en) * | 2014-11-26 | 2015-03-25 | 隆藏电子商务（上海）有限公司 | Industrial payment method and electronic device |
-
2015
- 2015-06-15 CN CN201510330912.XA patent/CN106327167B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103366275A (en) * | 2009-06-09 | 2013-10-23 | Sk普兰尼特有限公司 | Electronic money payment system and electronic money payment method |
| CN103870992A (en) * | 2014-03-17 | 2014-06-18 | 中国工商银行股份有限公司 | Cross-border multi-currency data processing system and method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106327167A (en) | 2017-01-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11080712B2 (en) | Secondary account management platform | |
| US10433128B2 (en) | Methods and systems for provisioning multiple devices | |
| CN106327167B (en) | Method and device for realizing network payment | |
| RU2708947C2 (en) | Device with several identifiers | |
| US10902415B2 (en) | Payment card binding method, trust evaluation method, apparatus, and electronic device | |
| US20170228723A1 (en) | Resource provider account token provisioning and processing | |
| CA2887683C (en) | Social payment method and apparatus | |
| US20170186008A1 (en) | Methods and apparatus for authenticating and authorizing secondary accounts | |
| US20150161620A1 (en) | System and method for risk and fraud mitigation for merchant on-boarding | |
| US20180144335A1 (en) | Automated digital method and system of providing or sharing access | |
| US10803428B2 (en) | Method, non-transitory computer-readable medium, and system for payment approval | |
| US11232424B2 (en) | System and method for processing a transaction using account information on file | |
| US11580531B2 (en) | Systems and methods for minimizing user interactions for cardholder authentication | |
| US20170364917A1 (en) | Assurance of identity information | |
| US10692087B2 (en) | Electronic financial service risk evaluation | |
| CN111784347A (en) | Resource transfer method and device | |
| US11501289B2 (en) | Computer system and computer-implemented method for secure payment transaction | |
| US20230067630A1 (en) | Systems and methods for handling transfers | |
| US10217087B2 (en) | Multicomputer processing of client device request data using centralized event orchestrator | |
| CN110852866A (en) | Method, apparatus, and storage medium for managing a plurality of resources | |
| TW201913479A (en) | Payment method and integrated payment system | |
| US20230196314A1 (en) | Funds transfer service methods and systems for facilitating funds transfers | |
| WO2016199052A1 (en) | A system and method for enabling a transaction by extraction of transaction data | |
| US20230394467A1 (en) | System and method for providing restricted token usage during an onboarding phase | |
| US20230297995A1 (en) | Allocating payment transaction portions to more than one funding source via a single card |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | 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: 1233020 Country of ref document: HK |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20200923 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200923 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| TA01 | Transfer of patent application right | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240221 Address after: Guohao Times City # 20-01, 128 Meizhi Road, Singapore Patentee after: Advanced Nova Technology (Singapore) Holdings Ltd. Country or region after: Singapore Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee before: Innovative advanced technology Co.,Ltd. Country or region before: Cayman Islands |
|
| TR01 | Transfer of patent right |