WO2020134738A1 - 聚合支付的后台架构方法、***、计算机设备及存储介质 - Google Patents

聚合支付的后台架构方法、***、计算机设备及存储介质 Download PDF

Info

Publication number
WO2020134738A1
WO2020134738A1 PCT/CN2019/119788 CN2019119788W WO2020134738A1 WO 2020134738 A1 WO2020134738 A1 WO 2020134738A1 CN 2019119788 W CN2019119788 W CN 2019119788W WO 2020134738 A1 WO2020134738 A1 WO 2020134738A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
information
node
client
payment
Prior art date
Application number
PCT/CN2019/119788
Other languages
English (en)
French (fr)
Inventor
侯俊丞
杨凯星
Original Assignee
广州市百果园信息技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 广州市百果园信息技术有限公司 filed Critical 广州市百果园信息技术有限公司
Priority to JP2021538273A priority Critical patent/JP7118281B2/ja
Priority to EP19905428.9A priority patent/EP3889870B1/en
Priority to RU2021121118A priority patent/RU2768197C1/ru
Priority to KR1020217023698A priority patent/KR102553831B1/ko
Priority to US17/419,613 priority patent/US20220084031A1/en
Priority to SG11202107131SA priority patent/SG11202107131SA/en
Publication of WO2020134738A1 publication Critical patent/WO2020134738A1/zh

Links

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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4015—Transaction verification using location information
    • 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]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • 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
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4015—Transaction verification using location information
    • G06Q20/40155—Transaction verification using location information for triggering transactions
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing

Definitions

  • the present application relates to the field of computer application technology. Specifically, the present application relates to a background architecture method, system, computer device, and storage medium for aggregate payment.
  • the purpose of this application is to solve at least one of the above technical deficiencies, and to disclose a back-end architecture method, system, computer device and storage medium for aggregate payment, so that the third-party payment process has strong isolation and low node coupling , Fast access, practical and flexible.
  • this application discloses a background architecture method for aggregate payment, which includes:
  • this application discloses a back-end architecture system for aggregate payment, including:
  • Access to the front end used to obtain transaction information sent by the client, where the transaction information includes location information of the client;
  • Relay forwarding server used to distribute the transaction information to transaction nodes that have jurisdiction over the location information according to the location information, where the transaction node is a transaction center within a designated area in a distributed transaction system;
  • Transaction node used to match the channel gateway in the channel docking layer that has established a connection relationship with the transaction node according to the transaction node, and sends the transaction request in the transaction information to the transaction through the selected channel gateway Processing in the object; obtaining the processing result of the transaction object, and transmitting the processing result information to the client.
  • the present application discloses a computer device including a memory and a processor.
  • the memory stores computer-readable instructions.
  • the processor causes the processor to perform the above disclosure The steps of the back-end architecture method of aggregate payment.
  • the present application discloses a storage medium storing computer-readable instructions, which when executed by one or more processors, causes the one or more processors to execute the background architecture of the aggregate payment disclosed above Method steps.
  • distributed processing is performed to make the payment processing data faster, and the distributed transaction centers are independent of each other, and a unified communication interface is used to connect with the transaction object to block the payment process of each channel
  • the details of the difference and provide a universal and unified payment access process for the client.
  • the client's merchant only needs to maintain a set of processes that interact with the aggregate payment architecture, which can use all payment channels supported by the payment architecture, data isolation Strong, low node coupling, strong anti-attack ability, low business coupling between clients, more suitable for distributed deployment, high system availability, strong disaster tolerance, unified scheduling interface makes the system expandable, Function iteration has low impact on online business.
  • FIG. 1 is a flow chart of a method for back-end architecture of an aggregate payment in this application
  • Figure 2 is a flow chart of the application transaction information authentication method
  • Figure 3 is a flow chart of a method for distributing transaction information to transaction nodes
  • FIG. 4 is a flowchart of a transaction request method of an application transaction node
  • FIG. 5 is a flowchart of a method for retrying an asynchronous task queue of the application
  • Figure 6 is the overall flow chart of the aggregate payment of this application.
  • FIG. 8 is a flow chart of receiving information of each module of the aggregate payment of the application.
  • FIG. 9 is a block diagram of the basic structure of the computer device of the present application.
  • this application discloses a background architecture method of aggregate payment, which is relative to third-party payment.
  • aggregate payment is not between merchants and banks, it is a channel that exists between merchants and third-party payers.
  • Aggregated payment does not carry out the settlement and transfer of funds, it only completes the control of information flow and data flow in the payment link, aggregates the payment methods provided by different third-party payment institutions, and provides merchants with a unified payment and settlement interface. Reduce the difficulty and cost of merchant access, improve the speed and efficiency of operations, and have better flexibility and convenience.
  • the method of aggregating the payment back-end architecture includes:
  • the client actually refers to a merchant terminal. There are multiple clients, and multiple clients can simultaneously send out the request instruction for analysis.
  • the request instruction is a related data message that records the identity information of the client and the content of the request.
  • the data message is a field combination composed of a prescribed format to facilitate information exchange. In order to distinguish different clients, the data message It includes merchant number information that characterizes the identity of the client and service number information that characterizes the requested service type, to confirm the identity information and request content of the client that sent the request instruction.
  • the transaction information is related information that the request sent by the client is processed by a third party, and the transaction information includes the location information of the client.
  • the transaction information further includes location information of the transaction object pointed to by the transaction information.
  • the transaction object refers to the third-party information requested by the transaction client for transaction processing
  • the location information of the transaction object here refers to the location information of the third party.
  • the third-party information is a payment platform. There are many payment platforms, such as financial platforms such as major banks, WeChat, Alipay, etc. These third-party platforms have corresponding servers to process location information.
  • the location information includes nationality and specific area. You can get the location information by obtaining the location information of the transaction object.
  • the server location information of the trading object are examples of the location information.
  • S2000 Distribute the transaction information to a transaction node having jurisdiction over the location information according to the location information, where the transaction node is a transaction center within a designated area in a distributed transaction system;
  • the transaction node is the core processing layer for business processing, and the creation of business orders and business processing logic are implemented at this layer.
  • the transaction node when the location information is the location information of the client terminal, the transaction node is a transaction center in a designated area of the distributed transaction system. Since the client terminal may be distributed in various locations around the world, in order to quickly respond to payment requests, it can be Set a transaction node anywhere in the world, and select the transaction node that has jurisdiction over the location information to process based on the location information of the client terminal obtained above.
  • the location information is the location information of the transaction object pointed to by the transaction information, it is the location information of the third-party transaction platform. Since the third-party trading platform can be located in various locations around the world, the client of the aggregate payment of this application may also be distributed around the world. In order to quickly respond to the payment request, according to the regional location of the third-party trading platform, there are multiple transaction nodes. Each transaction node is independent of each other, and it is isolated. When one of the transaction nodes is abnormal, it does not affect the normal business processing of the other transaction nodes.
  • each transaction node has its own jurisdiction, a new request instruction, by identifying the location information and business type of the corresponding transaction object, the transaction node corresponding to the jurisdiction can be allocated for processing, but, in order to To further improve the disaster tolerance of business processing, when it is allocated to the corresponding transaction node, by detecting whether the status of the transaction node is available, when it is detected that the status of the transaction node is unavailable, the request instruction is allocated to other available transaction nodes In order to ensure the normal processing of the instructions requested by the transaction information.
  • the channel gateway When a transaction node is allocated, the channel gateway is matched from the channel docking layer that establishes a connection relationship with the transaction node according to the transaction node information. There are multiple different channel gateways stored in the channel docking layer. Different channel gateways communicate with different third-party transaction objects.
  • the channel gateway connects and communicates with the transaction node through the scheduling interface.
  • the channel gateway implements the logic of interacting with third-party transaction objects, shielding the interaction details between different channels upwards.
  • the scheduling interface of each channel gateway in this application is Unified, in order to maintain a consistent transaction process, it should not be changed by the change of channel objects, on the other hand, each channel of the channel gateway layer is logically independent, and does not operate order data. Channels and main processes have little impact, and can be quickly accessed and iterated easily.
  • the unified scheduling interface also facilitates access to new channels. It is only necessary to build a corresponding channel gateway node, and the differences and details of specific third-party transaction objects are hidden in the channel gateway.
  • the channel gateway is an application interface that connects different payment third parties. Different third-party payment platforms require different channel gateways. Therefore, a channel gateway connection library is formed, that is, the channel docking layer, by identifying the request instruction The transaction objects in can be matched with different channel gateways in the channel gateway connection library for business processing.
  • each channel gateway since each channel gateway interacts with a third-party channel using a unified scheduling interface, shielding the interaction details between different channels upwards, each channel is docked to form an independent sub-module, when relevant business processing is required , Just call the corresponding interface directly.
  • the upper core business layer can call a unified interface to maintain a consistent transaction process and not change due to channel changes; on the other hand, each channel of the channel gateway is logically independent and does not operate order data. Changes in one channel have little impact on other channels and the main process, and can be quickly accessed and iterated easily.
  • the transaction request in the transaction information is sent to the corresponding transaction object for processing, at the same time, the transaction result returned by the transaction object is also obtained, and the transaction result information is returned to the customer End.
  • the data reception and distribution in step S1000 and step S2000 are performed in the service access layer, where the service access layer includes an access front end and a relay forwarding server, and the access front end receives transactions sent by the client Information, the transaction information is converted into a protocol format that can be recognized by the background, and after completing tasks such as identity verification, permission control and traffic isolation, the relay and forwarding server performs load balancing and task distribution, and the transaction information is transferred according to a certain distribution strategy.
  • the request information in is sent to the designated transaction node for processing.
  • the payment node calls the communication interface to monitor transaction information and collect result information. It belongs to the core business layer, while the channel gateway and unified scheduling interface belong to the channel docking layer.
  • the core business layer mainly includes the payment center, payment notification asynchronous retry, and payment monitoring.
  • the payment center completes the management and recording of a payment order, and calls the service of the channel gateway of the next layer.
  • Asynchronous retry is responsible for the replay of the asynchronous task to ensure the completion of the order;
  • the payment monitoring is responsible for monitoring and monitoring the payment order.
  • Statistics payment notification is responsible for notifying the client asynchronously after the order is completed.
  • the channel docking layer is mainly responsible for docking the services provided by third-party objects. The docking of each channel forms an independent sub-module, which is convenient for channel management and rapid iteration.
  • This application performs distributed processing based on the address information of the transaction object in the transaction information to make the payment processing data faster, and the distributed deployment of transaction centers are independent of each other.
  • a unified communication interface is used to connect with the transaction object to shield each channel. The details of the payment process are different, and provide a universal and unified payment access process for the client.
  • the client's merchant only needs to maintain a set of processes that interact with the aggregate payment architecture to use all payment channels supported by the payment architecture. , Strong data isolation, low node coupling, strong anti-attack ability, low service coupling between clients, more suitable for distributed deployment, and high system availability, strong disaster tolerance, unified scheduling interface makes the system expand Strong, and the function iteration has low impact on online business.
  • the transaction information initiated by the client will use the encrypted communication protocol to set the verification information to ensure that the communication is not tampered by a third party.
  • the access front end receives the transaction information, the verification information is verified.
  • the client and the access front end During data interaction, a unified information verification method is used, such as encrypting data by means of public and private keys. After receiving the data, the access front end decrypts according to the preset rules of the client and the access front end, thereby ensuring The client and the access front end are not easily tampered with during the data interaction process, making data transmission more secure.
  • the access front end also performs digital signature verification on the message data of the transaction information that can be received to ensure that the requested message originates from the authorized merchant and has not been tampered with and forged. After signature verification Only after the transaction information can the follow-up forwarding action be performed.
  • the access front end detects that the acquired transaction data has signs of tampering and other abnormal conditions, it does not perform subsequent processing, and at the same time sends the detection result information to the client to indicate that the currently transmitted data is unsafe.
  • the transaction information After accessing the front end to verify the transaction data, it means that the current transaction information data is safe, so the transaction information can be parsed, and the identity information and business type of the client sending the transaction information can be obtained by parsing.
  • the identity information of the client can be extracted from the IP address when sending the transaction information and the frame header related fields of the data frame in the information
  • the service type can be the text data frame that characterizes the content from the transmitted data frame Get it.
  • the client When the client's identity information and service type are parsed, the client is authenticated based on the information.
  • the authentication is mainly to identify whether the client has the relevant authority to perform the relevant request business. Therefore, in this application, an identity authority list is also stored in the access front end, and the identity authority list lists all those that meet the requirements
  • the client's identity information and corresponding service type permissions correspond to the identity information and service types in the above identity permission list to determine whether the client has permission to make data processing requests of the service type.
  • the authentication indicates that the client does not have the relevant authority, it sends abnormal information that the authentication fails to the client for reminding.
  • the transaction information sent by it parses out that the types of services to be processed are B and C, and in the identity permission list, there are the types of services that can be processed by the client A , Which includes business type C, but business type B does not have permissions, so it can continue to process business type C related requests, and for business type B, it sends abnormal information to client A to prompt that business B has no permission to handle Permissions.
  • the judgment rule for passing authentication can also be preset by accessing the front end. For example, only one of the services B and C disclosed in the above embodiment has the authority, and the other business does not have the authority. In this case, you can Set two rules, one is to allow the business to perform subsequent actions as long as any one meets the permission requirements, and the other is to not respond to all the transaction information as long as the request for any business type does not pass. Request and send abnormal information to the client to modify the transaction information. The specific rules can be set according to the actual situation.
  • the transaction information After the transaction information is authenticated according to certain preset rules, the transaction information can be distributed to the corresponding transaction node according to the identified location information through the relay and forwarding server.
  • the relay forwarding server After receiving the transaction information, the relay forwarding server provides a forwarding service for the transaction information, and the forwarding rules can be analyzed and determined according to the specific content of the transaction information to ensure that the same payment request message can be processed at the same node.
  • a method for assigning the transaction information to a transaction node having jurisdiction over the location information according to the location information includes:
  • the distribution list is a table that maps related information such as the client's identity information, business type, and other corresponding distribution rules that send transaction information to each other, and the relay server distributes according to the identified business type and the location information of the transaction object.
  • the transaction object is a third-party payment platform that requires business processing identified by the transaction information, such as a bank, WeChat, or Alipay.
  • the location information is the location information of the client. Therefore, when the business type is obtained After that, a transaction node with jurisdictional rights is allocated for processing according to the location information of the client.
  • the location information is the location of the transaction business type Western Sydney.
  • the WeChat terminal and Alipay terminal disclosed above are both domestic payment platforms in China, so the location information is China, while for the bank side, some May involve foreign countries, such as Standard Creating Bank, Citibank, etc., are foreign payment platforms, and the transaction nodes are deployed according to the server locations of these payment platforms.
  • the payment targets are domestic banks, agricultural, industrial, commercial, and construction.
  • the transaction information corresponding to the bank is set to be processed by transaction node A
  • the transaction information of other domestic banks is set to be processed by transaction node B
  • the transaction information of foreign banks is set to be processed by transaction node C
  • non-banks such as WeChat and Alipay are processed
  • the third-party payment platform is set to be processed through transaction node D. Therefore, when the transaction information sent by the client parses out the transaction object and the corresponding location information, it can be distributed according to the location information.
  • each transaction node is independent of each other, in order to ensure the normal processing of each transaction information, the transaction information is divided into nodes according to transaction objects.
  • the transaction information that should be processed on the transaction node is transferred to other transaction nodes in accordance with certain rules, so as to facilitate timely processing.
  • the mentioned transfer to other transaction nodes according to certain rules may be the transaction node that processes the same type of transaction information as the transaction node, or a transaction node configured with the same available channel gateway.
  • identifying the identity information of the business type performance client it can be determined whether multiple transaction information belongs to the same business, and when it belongs to the same business, all the transaction information in the same business is summarized into a transaction node for transactions deal with.
  • the relay server routes the transaction information to the corresponding transaction node by means of HASH.
  • Hashing is to transform an input of any length into a fixed-length output through a hash algorithm, and the output value is a hash value.
  • it refers to routing the data message of the transaction information to the corresponding transaction node according to a specific hash algorithm or rule. In this way, the security of the data during the matching process is ensured.
  • the transaction node is not directly allocated, and the usage status information of the transaction node is first obtained.
  • the use status information is the current traffic ratio and operating parameters of the trading node. By obtaining the traffic ratio, it is determined whether the current trading node exceeds the rated value. When the rated value is exceeded, it means that the current trading node is too saturated, which may affect the transaction The speed of data processing; by identifying the operating parameters, you can determine whether the current trading node is operating normally and is available. When the operating parameters are abnormal, it means that the current trading node is unavailable and the transaction data needs to be transferred.
  • the first preset condition is a standard reference condition set according to the usage status information, for example, when the detected usage status is the flow rate of the transaction node, the first preset condition is set to be that the flow rate of the transaction node is not higher than 85%, when it is detected that the current transaction node is 80%, it means that the current transaction node's usage status meets the first preset condition, otherwise, it is defined as not meeting the preset condition.
  • the transaction information is distributed to the corresponding transaction node according to the identified location information.
  • the distribution rule is rematched, and the rematching distribution rule here is the same as the method of transferring to other trading nodes according to certain rules in step S2100,
  • the rematch may be a transaction node that processes the same type of transaction information as the transaction node, or a transaction node configured with the same and available channel gateway.
  • the above method of identifying usage status is actually a kind of traffic cutting.
  • the relay forwarding server undertakes this function. Since all types of transaction information packets are routed to the corresponding nodes for processing through the relay forwarding service area, they are passed through The forwarding server modifies the configuration of the forwarding rules to achieve the cutting of business traffic.
  • the transaction center When the transaction center receives the transmitted transaction information, it processes the transaction information. In an embodiment, please refer to FIG. 4.
  • the method for the transaction object to process the transaction request includes:
  • the transaction center After the transaction center obtains the transaction information, it is necessary to suggest a unique number for the transaction information in order to facilitate data processing and data monitoring, because in the above service access layer and the identification of the client's identity information, business type and The address information of the business object, so a single number can be generated according to these rules according to certain rules. Because the client with the same identity information may perform multiple requests of the same business type for the same business object, so in order to distinguish, you can use A certain rule ensures that every transaction request in the transaction information matches a single number in a position to facilitate data tracing.
  • a unique order number can be automatically generated through a timeline, for example, beginning with 0001, the transaction request of the transaction information received at a subsequent time is 0002, 0003, etc., the transaction information received at the same time can be random Arrange the order and connect the order number to distinguish.
  • the generation of the order number may be embedded in the client's identity information, business type, and transaction object information, such as the first letter or ID characterizing the client's identity information, the business type number, and the transaction object number, and then
  • the sequence number set in the order of the time axis constitutes the order number. Those with the same client identity information, the same business type, and the same transaction object information can be distinguished from the order number to facilitate data query and traceability.
  • a randomly generated check code can also be embedded in the order number to improve the security of the order.
  • the order number and related data parsed in the transaction information are stored in the database, so as to be easily retrieved at any time.
  • the scheduling interface between the transaction node and the channel gateway is unified. Different channel gateways are connected to the processing servers of different transaction objects.
  • the channel gateway and the scheduling interface form a communication interface. After the transaction information is generated into a single number , By monitoring the single number, you can obtain the corresponding transaction information processing process.
  • the trading center sends the transaction request in the transaction information to the server of the transaction object for processing through the communication interface, and receives the process information at the same time, such as the time to send the transaction information to the transaction formation server, the process status of the transaction processing, and the final result status , Total time etc.
  • the transaction center writes the process data related to the transaction acquired from the communication interface into the asynchronous task queue for caching.
  • the asynchronous task queue multiple different working nodes are set up in a queue according to the data processing steps.
  • One-step related data information the information data is stored to the node, in order to judge the current processing process and processing status.
  • the asynchronous task queue when a link appears in any link in the asynchronous queue, the asynchronous task queue will send information to the transaction node to prompt it to retry the link.
  • the retry process includes:
  • a maximum value for the number of times is set. Therefore, when entering the retry link, each time a retry job is performed in sequence, the current Times, and compare the number with the second threshold.
  • the data anomaly is resolved, and the other tasks in the asynchronous task queue are continued until all tasks are completed.
  • all tasks in the asynchronous task queue are completed, it means that the processing of the current transaction information is completed, the cached asynchronous task queue is deleted, and the data space is released.
  • the above method of this application constitutes a set of aggregate payment system.
  • the client sends transaction information with the payment request to the aggregate payment system.
  • the aggregate payment system communicates with the The third-party transaction object connects and communicates.
  • the third-party transaction object returns the order data to the aggregate payment system.
  • the aggregate payment system extracts the payment link according to the order data and sends the payment link to the client.
  • the client accesses the payment link to complete the payment.
  • the third-party transaction object returns the callback payment result to the aggregate payment system, and the aggregate payment system generates a payment result notification according to its own notification rule and returns it to the client to prompt the payment result.
  • the aggregate payment system includes a business access layer, a core business layer and a channel docking layer, where the business access layer includes an access front end and a relay forwarding server, and the core business layer includes a transaction node,
  • the transaction node includes a database for storing data, an asynchronous module for asynchronous task queue caching and retry, a payment notification module for sending relevant data obtained from the transaction node to the client, and data processing for the entire transaction node
  • the transaction node and each channel gateway in the channel docking layer are connected through a unified scheduling interface, so that different third-party transaction objects can be connected to different transaction payment platforms for transaction processing.
  • the back-end architecture system of the aggregate payment disclosed in this application includes the following functions and module relationships:
  • Access to the front end used to obtain transaction information sent by the client, where the transaction information includes the location information of the transaction object pointed to by the transaction information;
  • Relay forwarding server used to distribute the transaction information to transaction nodes that have jurisdiction over the location information according to the location information, where the transaction node is a transaction center within a designated area in a distributed transaction system;
  • Transaction node used to send the transaction request in the transaction information to the transaction object for processing according to the communication interface established in advance between the transaction node and the transaction object; obtain the processing result of the transaction object, and The processing result information is transmitted to the client.
  • the access front end also includes:
  • Verification module configured to perform verification of verification information of the transaction information, the verification information is set by an encrypted communication protocol
  • Data parsing module configured to perform parsing of the verified transaction information to obtain the identity information and service type of the client that sent the transaction information;
  • Authentication module It is configured to perform matching in the identity permission list based on the parsed identity information and service type for authentication; the transaction information passed by the authentication is used to allocate transaction nodes.
  • the access front end further includes:
  • Flow identification module configured to perform acquisition of the flow value of the transaction information passed the authentication within the first preset time period
  • Selection module configured to allow the transaction information whose flow value is less than or equal to the first preset threshold to be allocated.
  • the relay server includes:
  • Distribution rule matching module configured to perform matching of distribution rules in the distribution list according to the business type of the transaction information, so that the same client type request of the same business type is processed at the same transaction node;
  • Status acquisition module configured to perform acquisition of usage status information of the mapped transaction node according to the allocation rule
  • the judging module is configured to execute judging whether the use status of the transaction node meets the first preset condition
  • Distribution module configured to perform the distribution of the transaction information to the transaction node when the first preset condition is met.
  • the relay and forwarding server further includes a rematching module: configured to perform rematching of the distribution rules to re-determine the transaction node when the use status of the transaction node does not meet the first preset condition.
  • a rematching module configured to perform rematching of the distribution rules to re-determine the transaction node when the use status of the transaction node does not meet the first preset condition.
  • the transaction node includes:
  • Order generation module configured to execute to create a unique ticket number according to the transaction request
  • Invoking module configured to execute processing of the transaction request corresponding to the single number in the transaction object by invoking the communication interface;
  • Asynchronous module configured to execute writing the processing data of the transaction request into the asynchronous task queue for buffering; when the task in the asynchronous task queue is abnormal during the processing, retry;
  • the first deletion module configured to execute deletion of the cached asynchronous task queue after all tasks in the asynchronous task queue are completed.
  • the transaction node also includes:
  • Retry calculation module configured to perform acquisition retry times
  • the second deletion module configured to execute deletion of the asynchronous task queue when the number of retries reaches a second threshold, and feedback abnormal information to the client.
  • the specific working steps of the above disclosed module include: the client sends transaction information, the access front end receives the transaction information, and then sends it to the relay server after authentication and flow control.
  • the forwarding server distributes the transaction information to the corresponding transaction node according to the allocation rules
  • the transaction node creates an order number after receiving the relevant transaction information, and saves the relevant data in the database, and at the same time according to the relevant information of the transaction object analyzed above, Call the communication interface of the relevant channel gateway, the channel gateway communicates with the third-party transaction object, the transaction object returns the order data, the channel gateway receives the order data, and transmits the data to the transaction node, the transaction node will pay the order data
  • the link is extracted and sent to the client.
  • the client directly pays for the transaction by connecting to the payment link.
  • the transaction object recognizes the transaction is successful, it sends an order callback notification to the access front end, and the access front end authenticates the relevant data through the relay
  • the forwarding server is assigned to the original transaction node that was previously assigned according to the allocation rules.
  • the transaction node recognizes the legality of the callback notification. When it is a legal callback notification, it requests the payment notification module to generate a payment result notification, and constructs a data message to transfer the payment.
  • the result notification is directly returned to the corresponding client to prompt the payment result.
  • FIG. 9 for a block diagram of the basic structure of a computer device provided by an embodiment of the present application.
  • the computer device includes a processor, a non-volatile storage medium, a memory, and a network interface connected through a system bus.
  • the non-volatile storage medium of the computer device stores an operating system, a database, and computer-readable instructions.
  • the database may store a sequence of control information.
  • the processor may implement a A background architecture method for aggregate payment.
  • the processor of the computer device is used to provide calculation and control capabilities, and support the operation of the entire computer device.
  • the memory of the computer device may store computer readable instructions.
  • the processor may cause the processor to execute a background architecture method of aggregate payment.
  • the network interface of the computer device is used to connect and communicate with the terminal.
  • the computer device receives status information of the prompting behavior sent by the associated client, that is, whether the associated terminal starts the prompting and whether the user closes the prompting task. By verifying whether the above task conditions are met, the corresponding preset instruction is sent to the associated terminal, so that the associated terminal can perform the corresponding operation according to the preset instruction, thereby effectively supervising the associated terminal.
  • the server controls the associated terminal to continue ringing to prevent the prompting task of the associated terminal from automatically ending after a period of time.
  • the present application also provides a storage medium storing computer-readable instructions, which when executed by one or more processors, cause the one or more processors to perform aggregate payment according to any of the foregoing embodiments Background architecture approach.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Multimedia (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请揭露一种聚合支付的后台架构方法、***、计算机装置及存储介质，包括：获取客户端发送的交易信息，交易信息包括所述客户端的位置信息；根据位置信息将所述交易信息分配至对位置信息具有管辖权限的交易节点，其中，交易节点为分布式交易***中指定区域内的交易中心；根据交易节点在与交易节点预先建立连接关系的渠道对接层中匹配渠道网关，通过所选定的渠道网关将所述交易信息中的交易请求发送至交易对象中进行处理；获取所述交易对象的处理结果，并将处理结果信息传送至客户端，本申请通过分布式的交易节点对交易数据进行处理，使支付处理数据更快捷，且分布式部署的交易中心相互独立，数据隔离性强，节点耦合度低、***拓展性强。

Description

聚合支付的后台架构方法、***、计算机设备及存储介质 技术领域
本申请涉及计算机应用技术领域，具体而言，本申请涉及一种聚合支付的后台架构方法、***、计算机设备及存储介质。
背景技术
随着物联网和移动互联网的快速发展，近年来电子支付行业也得到迅速发展，仅就国内而言，银行、银联等清算机构、第三方支付企业等提供了不同种类，不同技术实现的移动支付服务。并且，在客观需求的影响下，电子支付技术已经渗透到各类领域。然而，在这背景下，各方的服务并没有统一的标准和接口，各类支付工具和平台难以做到完全的兼容。如果把视野扩散到全球层面，每个国家又有各自的渠道商和限入规则，对于有全球化业务的商户，接入成本和接入效率也受到了极大的影响。
国内使用率的第三方支付渠道数量不多，一般商户接入微信或者支付宝两即可覆盖国内90％以上的线上支付需求。所以大部分商户在接入支付渠道时候，都会直接跟第三方渠道直接对接，但是由于各种支付渠道(如微信，支付宝)的支付流程在细节上都有所出入，所以通常要在后端支持多套支付流程。现在国内互联网行业正值出海潮，但是海外的支付渠道种类繁多，而且流程各异，如果采用以前的方法直接与第三方支付渠道对接，那商户必须面临维护多套支付流程的复杂任务。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一，揭露一种聚合支付的后台架构方法、***、计算机装置及存储介质，使在进行第三方支付过程中隔离性强，节点耦合度低、接入快速，实用灵活。
为了达到上述目的，本申请揭露一种聚合支付的后台架构方法，包括：
获取客户端发送的交易信息，所述交易信息包括所述客户端的位置信息；
根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点，其中，所述交易节点为分布式交易***中指定区域内的交易中心；
根据所述交易节点在与所述交易节点预先建立连接关系的渠道对接层中匹配渠道网关，通过所选定的渠道网关将所述交易信息中的交易请求发送至交易对象中进行处理；
获取所述交易对象的处理结果，并将处理结果信息传送至客户端。
另一方面，本申请揭露一种聚合支付的后台架构***，包括：
接入前端：用于执行获取客户端发送的交易信息，所述交易信息包括所述客户端的位置信息；
中继转发服务器：用于根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点，其中，所述交易节点为分布式交易***中指定区域内的交易中心；
交易节点：用于根据所述交易节点在与所述交易节点预先建立连接关系的渠道对接层中匹配渠道网关，通过所选定的渠道网关将所述交易信息中的交易请求发送至所述交易对象中进行处理；获取所述交易对象的处理结果，并将处理结果信息传送至客户端。
另一方面本申请揭露一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行上述揭露的聚合支付的后台架构方法的步骤。
另一方面本申请揭露一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述揭露的聚合支付的后台架构方法的步骤。
本申请的有益效果是：
根据交易信息中的客户端的位置信息，进行分布式处理，使支付处理数据更快捷，且分布式部署的交易中心相互独立，采用统一的通信接口与交易对象连接，以屏蔽各渠道的支付流程上的细节差异，并为客户端提供通用且统一的支付接入流程，客户端的商户仅需要维护一套与本聚合支付架构交互的流程，即可使用支付架构下所支持的所有支付渠道，数据隔离性强，节点耦合度低、抗攻击能力强，客户端之间的业务的耦合性低，更适合分布式部署，且***高可用，容灾性强，统一的调度接口使***拓展性强，功能迭代对线上业务影响低。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本申请一种聚合支付的后台架构方法流程图；
图2为本申请交易信息鉴权方法流程图；
图3为本申请交易信息分配至交易节点的方法流程图；
图4为本申请交易节点的交易请求方法流程图；
图5为本申请异步任务队列重试方法流程图；
图6为本申请聚合支付整体流程图；
图7为本申请聚合支付多层结构示意图；
图8为本申请聚合支付各模块信息接收流程图；
图9为本申请计算机设备基本结构框图。
具体实施方式
具体的，请参阅图1，本申请揭露一种聚合支付的后台架构方法，聚合支付是相对于第三方支付而言的。与第三方支付不同，聚合支付不介于商户和银行之间，它是存在于商户和第三方支付方之间的通道。聚合支付并不进行资金的结算和转移，它只是完成支付环节信息流和数据流的控制，聚合不同第三方支付机构提供的支付方式，为商户提供统一的支付、 结算的接口。降低商户接入的难度和成本，提高运营的速度和效率，具有更好的灵活性和便捷性。
本申请中，聚合支付的后台架构的方法包括：
S1000、获取客户端发送的交易信息，所述交易信息包括所述客户端的位置信息；
客户端实际上是指商户终端，客户端有多个，多个客户端可同时将请求指令发送出去以进行分析。请求指令为记载有客户端身份信息、请求内容的相关数据报文，该数据报文为为了便于信息交互，按照约定好的格式组成的字段组合，为了区分不同的客户端，在该数据报文中包括表征客户端身份的商户号信息以及表征请求的业务类型的业务号信息，以此来确认发送请求指令的客户端的身份信息以及请求内容。
交易信息为由客户端发送的请求通过第三方进行处理的相关信息，其中交易信息中包括客户端所处的位置信息。
在另一实施例中，所述交易信息还包括交易信息指向的交易对象的位置信息。在本申请中，交易对象是指交易客户端请求进行交易处理的第三方信息，而这里的交易对象的位置信息是指该第三方的位置信息，可以理解的是，第三方信息为支付平台，支付平台有很多，比如各大银行、微信、支付宝等金融平台，这些第三方平台有对应的服务器处理位置信息，位置信息包括国籍以及具体的区域，通过获取交易对象的位置信息，则可得到该交易对象的服务器位置信息。
S2000、根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点，其中，所述交易节点为分布式交易***中指定区域内的交易中心；
交易节点是进行业务处理的核心处理层，业务订单的创建以及业务处理逻辑在该层实现。本一实施例中，当位置信息为客户端的位置信息时，交易节点为分布式交易***中指定区域内的交易中心，由于客户端可能分布于全球各个位置，为了快速响应支付请求，因此可在全球任意一个地方设置交易节点，通过上述获取的客户端的位置信息，选择对该位置信息具有管辖权限的交易节点进行处理。
在另一实施例中，当位置信息为交易信息指向的交易对象的位置信息，即为第三方交易平台的位置信息。由于第三方交易平台可以是位于全球各个位置的，本申请的聚合支付的客户端也可能分布的全球各地，为了快速响应支付请求，依据第三方交易平台的区域位置，分别设置有多个交易节点，每个交易节点都是相互独立的，其具有隔离性，当其中一个交易节点出现异常时，不影响其他的交易节点的正常的业务处理。进一步的，每个交易节点都有自己的管辖范围，一个新的请求指令，通过识别对应的交易对象的位置信息以及业务类型，即可分配对对应管辖范围的交易节点进行处理，但是，为了能进一步提高业务处理的容灾性，在分配到对应的交易节点时，通过检测该交易节点的状态是否可用，当检测到该交易节点的状态为不可用时，将请求指令分配到其他可用的交易节点中，以确保该交易信息请求的指令的正常处理。
S3000、根据所述交易节点在与所述交易节点预先建立连接关系的渠道对接层中匹配渠道网关，通过所选定的渠道网关将所述交易信息中的交易请求发送至所述交易对象中进行处理；
当分配了交易节点，则根据交易节点信息从与该交易节点建立连接关系的渠道对接层中匹配渠道网关。在渠道对接层中存储有多个不同的渠道网关，不同的渠道网关与不同的第三方的交易对象连接通信，
渠道网关通过调度接口与交易节点连接通信，在本申请中，渠道网关实现了与第三方交易对象交互的逻辑，向上屏蔽了不同渠道之间的交互细节，本申请每个渠道网关的调度接口是统一的，以便于维护一致的交易流程，不应渠道对象的变化而变化，另一方面渠道网关层的每个渠道逻辑上都是独立的，并且不操作订单数据，某一渠道的变动对其他渠道和主流程几乎不造成影响，可以轻松地做到快速接入和迭代。统一的调度接口，也方便新的渠道接入，只需构建一个对应渠道网关节点即可，具体的与第三方交易对象的差异和细节被隐藏在渠道网关中。
在支付业务过程中，渠道网关为连接不同的支付第三方的应用接口端，不同的第三方支付平台需要不同的渠道网关，因此组成了一个渠道网关连接库，即渠道对接层，通过识别请求指令中的交易对象，在渠道网关 连接库中可匹配不同的渠道网关，以进行业务处理。
在一实施例中，由于每个渠道网关与第三方渠道交互采用统一的调度接口，向上屏蔽不同渠道之间的交互细节，每个渠道对接形成独立的子模块，当需要进行相关的业务处理时，直接调用对应的接口即可。当有新的渠道接入时，只需要构建提供标准、统一接口的渠道网关节点即可，具体的与第三方对接的差异和细节被隐藏在了渠道网关中。这样一方面上层核心业务层能够调用统一的接口，维护一致的交易流程，不因渠道的变化而变动；另一方面渠道网关的每个渠道逻辑上都是独立的，并且不操作订单数据，某一渠道的变动对其他渠道和主流程几乎不造成影响，可以轻松地做到快速接入和迭代。
S4000、获取所述交易对象的处理结果，并将处理结果信息传送至客户端。
本申请中，通过调用对应的通信接口，将所述交易信息中的交易请求发送至对应的交易对象中进行处理的同时，还获取交易对象回传的交易结果，将交易结果信息回传至客户端中。
本申请中，步骤S1000和步骤S2000中的数据的接收以及分配是在业务接入层中进行的，其中业务接入层包括接入前端和中继转发服务器，接入前端接收客户端发送的交易信息，将所述交易信息转换成后台可识别的协议格式，并完成身份验证、权限控制以及流量隔离等任务后，由中继转发服务器进行负载均衡以及任务分配，按照一定的分发策略将交易信息中的请求信息发送至指定的交易节点中进行处理。对于支付节点调用通信接口进行交易信息的监控和结果信息的收集属于核心业务层，而渠道网关以及统一的调度接口属于渠道对接层，核心业务层主要包括支付中心、支付通知异步重试、支付监控等工作，其中支付中心完成个支付订单的管理和记录，以及调用下一层的渠道网关的服务，异步重试负责异步任务的重放，保证订单的完成；支付监控负责对支付订单的监控和统计，支付通知负责在订单完成后异步通知客户端。渠道对接层主要负责对接第三方对象所提供的服务，每个渠道的对接形成独立的子模块，方便渠道管理和快速迭代。
本申请根据交易信息中的交易对象的地址信息，进行分布式处理，使支付处理数据更快捷，且分布式部署的交易中心相互独立，采用统一的通信接口与交易对象连接，以屏蔽各渠道的支付流程上的细节差异，并为客户端提供通用且统一的支付接入流程，客户端的商户仅需要维护一套与本聚合支付架构交互的流程，即可使用支付架构下所支持的所有支付渠道，数据隔离性强，节点耦合度低、抗攻击能力强，客户端之间的业务的耦合性低，更适合分布式部署，且***高可用，容灾性强，统一的调度接口使***拓展性强，功能迭代对线上业务影响低。
在一实施例中，请参阅图2，在获取了客户端发送的交易信息之后，以及在所述根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖的交易节点之前，还包括：
S1100、对所述交易信息的验证信息进行验证，所述验证信息通过加密通信协议设置；
本申请中，由客户端发起的交易信息会采用加密通信协议设置验证信息，以保证通信不受第三方的篡改，接入前端接收交易信息时，对验证信息进行验证，客户端与接入前端进行数据交互时采用统一的信息验证方式，比如通过公钥与私钥的方式，对数据进行加密，接入前端接收到数据后对按照客户端与接入前端预设的规则进行解密，从而确保客户端与接入前端在进行数据交互过程中不容易被篡改，使数据传输更安全。
进一步的，接入前端作为业务接收的最前端还对可接收到的交易信息的报文数据进行数字签名验证以确保请求的报文源自于授权商户，并且未被篡改伪造，进行签名验证后的交易信息才能执行后续的转发动作。当接入前端检测到获取的交易数据有被篡改的迹象等异常情况，则不对其进行后续的处理，同时将检测的结果信息发送至客户端以提示当前传输的数据不安全。
S1200、对验证通过的所述交易信息进行解析，以获取发送交易信息的所述客户端的身份信息以及业务类型；
当接入前端对交易数据进行签名验证后，则表示当前交易信息数据是安全的，故可对该交易信息进行解析，通过解析，以获取发送交易信息的 客户端的身份信息以及业务类型。在本实施例中，客户端的身份信息可从发送交易信息时的IP地址以及信息中的数据帧的帧头相关字段中提取得到，而业务类型可从传输的数据帧中表征内容的文本数据帧中获取得到。
S1300、根据解析出的所述身份信息以及业务类型在身份权限列表中匹配以进行鉴权；
当解析出了客户端的身份信息以及业务类型，根据这些信息对客户端进行鉴权。本申请中，鉴权主要是为了鉴定客户端是否有相关权限执行相关的请求业务，因此在本申请中，在接入前端还存储有身份权限列表，该身份权限列表中罗列了所有符合要求的客户端的身份信息以及对应的业务类型权限，将身份信息以及业务类型在上述身份权限列表中一一对应，以确定该客户端是否有权限进行该业务类型的数据处理请求。
进一步的，鉴权得到该客户端没有相关的权限时，发送鉴权不通过的异常信息给客户端以进行提醒。比如，在一实施例中，对于客户端A，其发送的交易信息中解析出其欲处理的业务类型为B和C，而在身份权限列表中，有关于客户端A的可处理的业务类型，其中包括业务类型C，但是业务类型B不具备权限，因此可继续处理业务类型C的相关请求，而对于业务类型B则发送异常信息给客户端A，以进行提示，说明业务B无权限处理权限。
进一步的，鉴权通过的判断规则也可通过接入前端预先设置，比如上述实施例中揭露的业务B和业务C只有其中一项业务有权限，另一项业务没有权限，此情况下，可设定两种规则，一种是只要任意一项符合权限要求则可允许该业务执行后续的动作，另外一种为，只要任意一项业务类型的请求不通过，则不响应该交易信息的所有请求，并发送异常信息给客户端进行交易信息修改。具体规则可根据实际情况设置。
S1400、鉴权通过的交易信息进行交易节点分配。
当根据一定的预设规则对交易信息鉴权通过后，则可通过中继转发服务器对上述交易信息根据识别的位置信息分配至对应的交易节点。
中继转发服务器收到交易信息后，为交易信息提供转发服务,而转发的规则可以根据交易信息的具体内容加以分析确定转发规则，以确保同一 个支付请求报文能在同一个节点进行处理。
进一步的，在一实施例中，请参阅图3，根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点的方法包括：
S2100、根据所述交易信息的业务类型在分配列表中匹配分配规则，以使同一客户端同一业务类型请求在同一交易节点处理；
分配列表为根据发送交易信息的客户端身份信息、业务类型等相关信息与对应的分配规则相互映射的表格，中继转发服务器根据识别的业务类型以及交易对象的位置信息进行分配。
交易对象为通过交易信息识别的需要进行业务处理的第三方支付平台，比如银行端、微信端或者支付宝端等，在一实施例中，位置信息为客户端的位置信息，因此，当获取了业务类型后，根据所述客户端的位置信息分配具有管辖范围权利的交易节点以进行处理。
在另一实施例中，位置信息为交易的业务类型的位置西悉尼，比如上述揭露的微信端与支付宝端由于都是中国国内的支付平台，因此其位置信息为中国，而对于银行端，有些可能涉及国外，比如渣打银行、花旗银行等等，都是国外的支付平台，根据这些支付平台的服务器位置来部署交易节点，例如，将支付对象为国内银行中、农、工、商、建五大银行对应的交易信息设置为交易节点A处理，将国内其他银行的交易信息设置为通过交易节点B处理，将国外的银行的交易信息设置为通过交易节点C处理，将微信、支付宝等非银行类的第三方支付平台设置为通过交易节点D处理，因此，当客户端发送的交易信息中，解析出了交易对象以及对应位置信息后，则可根据该位置信息进行分配。
进一步的，上述分类并不是完全固定的，由于各个交易节点是相互独立的，为了保证各个交易信息的正常处理，将交易信息按照交易对象划分节点，当其中一个交易节点出现问题时，还可将该交易节点上应当处理的交易信息按照一定的规则转移到其他的交易节点上，以便于及时处理。这里所提到的按照一定的规则转移到其他的交易节点，可以是与该交易节点为处理同类型的交易信息的交易节点上，或者配置有相同，且可用的渠道网关的交易节点。
进一步的，通过识别业务类型业绩客户端的身份信息，可判断多个交易信息是否属于同一笔业务，当属于同一笔业务时，将同一笔业务中的所有交易信息都归纳到一个交易节点中进行交易处理。
进一步的，中继服务器通过哈希(HASH)方式将交易信息路由到对应的交易节点中。哈希是把任意长度的输入通过散列算法变换成固定长度的输出，该输出值则为散列值。本申请中，是指将交易信息的数据报文按照特定的哈希算法或者规则，路由到对应的交易节点。通过该方式，确保在匹配过程中数据的安全性。
S2200、根据所述分配规则获取所映射的交易节点的使用状态信息；
通过步骤S2100的方式匹配了对应的交易节点后，并不直接进行交易节点的分配，还会先获取该交易节点的使用状态信息。使用状态信息为该交易节点当前的流量占比以及运行参数，通过获取流量占比，以确定当前的交易节点是否超过额定值，当超过额定值，表示当前交易节点过于饱和，可能会影响到交易数据处理的速度；通过识别运行参数，可判断当前的交易节点是否运行正常，是否可用，当运行参数异常时，表示当前交易节点不可用，需要转移交易数据。
S2300、判断所述交易节点的使用状态是否符合第一预设条件；
第一预设条件为根据使用状态信息设定的标准参考条件，比如，当检测的使用状态为交易节点的流量占比时，设置第一预设条件为，交易节点的流量占比不高于85％,当检测到当前的交易节点为80％时，表示当前的交易节点的使用状态符合第一预设条件，否则，则定义为不符合预设条件。
以上只是本申请揭露的其中一种使用状态以及第一预设条件的方式，本申请还可以使用其他的使用状态判断方式。
S2400、当符合所述第一预设条件，将所述交易信息分配至所述交易节点中。
当判断出交易节点符合第一预设条件，则将所述交易信息按照所识别的位置信息分配至对应的交易节点。
S2500、当所述交易节点的使用状态不符合第一预设条件时，重新匹配分配规则以重新确定交易节点。
当判断出交易节点的当前使用状态不符合第一预设条件时，则重新匹配分配规则，这里的重新匹配分配规则与步骤S2100中的按照一定的规则转移到其他的交易节点上的方式一样，重新匹配可以是与该交易节点为处理同类型的交易信息的交易节点上，或者是配置有相同，且可用的渠道网关的交易节点。
上述识别使用状态的方式实际上是一种流量切割，由中继转发服务器承担这一功能，由于所有类型的交易信息报文都会通过中继转发服务区路由到对应的节点处理，因此通过在中继转发服务器对转发规则的配置进行修改实现业务流量的切割。
当交易中心接收到传送过来的交易信息后，对交易信息进行处理，在一实施例中，请参阅图4，所述交易对象对所述交易请求进行处理的方法包括：
S3100、根据所述交易请求创建一个唯一的单号；
当交易中心获取了交易信息后，需要对该交易信息建议一个唯一的单号，以便于数据的处理和数据的监控，由于在上述业务接入层中以及识别了客户端的身份信息、业务类型以及业务对象的地址信息，因此可根据这些按照一定的规则生成一个单号，由于同一身份信息的客户端可能针对同一业务对象请求执行多次相同的业务类型的请求，因此，为了进行区分，可根据某一规则确保每一个交易信息中的交易请求都匹配一个位置的单号，以便于数据的追溯。
在一实施例中，可通过时间轴的方式自动生成唯一的订单号，比如以0001开头，后续时间接收到的交易信息的交易请求依次为0002、0003等，相同时间接收到的交易信息可随机排列先后顺序并对订单号进行接续以进行区分。
在另一实施例中，订单号的生成可以起嵌入客户端的身份信息、业务类型以及交易对象信息，比如用表征客户端身份信息的首字母或者ID、业务类型的编号以及交易对象的编号，再加上按照时间轴的顺序设定的序列编号组成订单号，相同客户端身份信息、相同业务类型以及相同交易对象信息的可以从订单号上进行区分，以便于数据查询和追溯。
进一步的，为了保证订单号的安全性，还可以在上述订单号内嵌入随机生成的校验码，以提高订单的安全性。
进一步的，在生成订单后，将所述订单编号以及交易信息中解析的相关数据存储在数据库中，以便于随时调取。
S3200、通过调用所述通信接口在交易对象中对所述单号对应的交易请求进行处理；
交易节点内有多个渠道网关，交易节点与渠道网关的调度接口是统一的，不同的渠道网关对接不同的交易对象的处理服务器，渠道网关与调度接口组成通信接口，将交易信息生成单号后，通过监测该单号则可获取得到对应的交易信息的处理过程。交易中心将交易信息中的交易请求通过通信接口发送至交易对象的服务器中进行处理，同时接收处理的过程信息，比如发送交易信息至交易队形服务器的时间，交易处理的过程状态，最终结果状态，总共用时等等。
S3300、将所述交易请求的处理过程数据写入异步任务队列中缓存；
在一实施例中，交易中心将从通信接口获取的交易的相关过程数据写入异步任务队列中进行缓存，异步任务队列中按照数据处理的步骤呈队列设置多个不同的工作节点，每接收到一步相关数据的信息，该信息数据存储到该节点，以此判断当前处理的过程以及处理的状态。
S3400、当所述异步任务队列中的任务在处理过程出现异常时，进行重试；
在一实施例中，当异步队列中的任何一个环节出现了一场，异步任务队列会自行发送信息至交易节点以促使其进行该环节的重试。请参阅图5，重试的过程包括：
S3410、获取重试的次数；
在一实施例中，为了节约时间，控制处理的速度，会设置一个针对次数的最大值，称为第二阈值，因此，在进入重试环节时，每进行依次重试作业，会记录当前的次数，并将该次数与第二阈值进行对比。
当在第二阈值次数范围内经过重试解决了异常现象，则继续进行异步任务队列中后续任务的执行。
S3420、当所述重试的次数达到第二阈值时删除所述异步任务队列，并反馈异常信息给所述客户端。
当所述重试的次数达到第二阈值，且仍未解决异常现象时，则发送信息给交易节点使其不再发送重试任务请求重试，同时删除该异步任务队列，并将该异常信息反馈给客户端。反馈信息同时会也会保存在数据库中进行存储。
S3500、当所述异步任务队列中的所有任务都完成后删除该缓存的异步任务。
当经过重试后，解决了数据异常的情况，继续异步任务队列中其他的任务，直至所有的任务都完成。当异步任务队列中所有的任务都完成后，表示当前交易信息的处理完毕，删除该缓存的异步任务队列，释放数据空间。
本申请的上述方法构成一套聚合支付***，在一完整的支付交易请求中，请参阅图6，由客户端发送带有支付请求的交易信息给该聚合支付***，聚合支付***通过通信接口与第三方交易对象连接通信，第三方交易对象返回下单数据给聚合支付***，聚合支付***根据该下单数据提取支付链接，并将支付链接发送至客户端，客户端接入支付链接完成支付，第三方交易对象获取了支付结果后，将回调支付结果返回给聚合支付***，聚合支付***按照自己的通知规则生成支付结果通知返回给客户端，以提示支付的结果。
在一实施例中，请参阅图7，聚合支付***包括业务接入层、核心业务层和渠道对接层，其中业务接入层包括接入前端和中继转发服务器，核心业务层包括交易节点，交易节点中包括对数据进行存储的数据库，进行异步任务队列缓存和重试的异步模块、对交易节点中获取的相关数据发送给客户端的支付通知模块、以及对整个交易节点的数据数据处理进程进行监控的支付监控模块，交易节点与渠道对接层中的各个渠道网关通过统一调度接口连接，以便于根据不同的第三方的交易对象连接不同的交易支付平台进行交易处理。
具体的，本申请中揭露的聚合支付的后台架构***，其功能和模块关 系包括：
接入前端：用于执行获取客户端发送的交易信息，所述交易信息包括所述交易信息指向的交易对象的位置信息；
中继转发服务器：用于根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点，其中，所述交易节点为分布式交易***中指定区域内的交易中心；
交易节点：用于根据所述交易节点与所述交易对象预先建立的通信接口将所述交易信息中的交易请求发送至所述交易对象中进行处理；获取所述交易对象的处理结果，并将处理结果信息传送至客户端。
可选的，接入前端还包括：
验证模块：被配置为执行对所述交易信息的验证信息进行验证，所述验证信息通过加密通信协议设置；
数据解析模块：被配置为执行对验证通过的所述交易信息进行解析，以获取发送交易信息的所述客户端的身份信息以及业务类型；
鉴权模块：被配置为执行根据解析出的所述身份信息以及业务类型在身份权限列表中匹配以鉴权；鉴权通过的交易信息进行交易节点分配。
可选的，所述接入前端还包括：
流量识别模块：被配置为执行获取第一预设时间段内鉴权通过了的交易信息的流量值；
选择模块：被配置为允许所述流量值小于或等于第一预设阈值的交易信息进行分配。
可选的，中继转发服务器包括：
分配规则匹配模块：被配置为执行根据所述交易信息的业务类型在分配列表中匹配分配规则，以使同一客户端同一业务类型请求在同一交易节点处理；
状态获取模块：被配置为执行根据所述分配规则获取所映射的交易节点的使用状态信息；
判断模块，被配置为执行判断所述交易节点的使用状态是否符合第一预设条件；
分配模块：被配置为执行当符合所述第一预设条件，将所述交易信息分配至所述交易节点中。
可选的，中继转发服务器还包括重新匹配模块：被配置为执行当所述交易节点的使用状态不符合第一预设条件时，重新匹配分配规则以重新确定交易节点。
可选的，交易节点包括：
订单生成模块：被配置为执行根据交易请求创建一个唯一的单号；
调用模块：被配置为执行通过调用所述通信接口在交易对象中对所述单号对应的交易请求进行处理；
异步模块：被配置为执行将所述交易请求的处理过程数据写入异步任务队列中缓存；当所述异步任务队列中的任务在处理过程出现异常时，进行重试；
第一删除模块：被配置为执行当所述异步任务队列中的所有任务都完成后删除该缓存的异步任务队列。
可选的，交易节点还包括：
重试计算模块：被配置为执行获取重试的次数；
第二删除模块：被配置为执行当所述重试的次数达到第二阈值时删除所述异步任务队列，并反馈异常信息给所述客户端。
在一实施例中，请参阅图8，上述揭露的模块具体的工作步骤包括：客户端发送交易信息，接入前端接收该交易信息，经过鉴权、控流后发送给中继转发服务器，中继转发服务器根据分配规则分配该交易信息至对应的交易节点，交易节点接收到相关的交易信息后创建一个订单号，并将相关数据保存在数据库中，同时根据上述分析的交易对象的相关信息，调用相关渠道网关的通信接口，渠道网关与第三方交易对象通信，交易对象返回下单数据，渠道网关接收该下单数据，并将该数据传送至交易节点，交易节点将下单数据中的支付链接提取出来发送给客户端，客户端通过连接该支付链接直接进行交易支付，交易对象识别到交易成功后，发送订单回调通知至接入前端，接入前端对相关数据进行鉴权后通过中继转发服务器根据分配规则分配到之前所分配到原交易节点，交易节点识别该回调通知 的合法性，当为合法的回调通知后，请求支付通知模块生成支付结果通知，并构建数据报文将该支付结果通知直接返回给对应的客户端，以提示支付的结果。
本申请实施例提供计算机设备基本结构框图请参阅图9。
该计算机设备包括通过***总线连接的处理器、非易失性存储介质、存储器和网络接口。其中，该计算机设备的非易失性存储介质存储有操作***、数据库和计算机可读指令，数据库中可存储有控件信息序列，该计算机可读指令被处理器执行时，可使得处理器实现一种聚合支付的后台架构方法。该计算机设备的处理器用于提供计算和控制能力，支撑整个计算机设备的运行。该计算机设备的存储器中可存储有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器执行一种聚合支付的后台架构方法。该计算机设备的网络接口用于与终端连接通信。
计算机设备通过接收关联的客户端发送的提示行为的状态信息，即关联终端是否开启提示以及用户是否关闭该提示任务。通过验证上述任务条件是否达成，进而向关联终端发送对应的预设指令，以使关联终端能够根据该预设指令执行相应的操作，从而实现了对关联终端的有效监管。同时，在提示信息状态与预设的状态指令不相同时，服务器端控制关联终端持续进行响铃，以防止关联终端的提示任务在执行一段时间后自动终止的问题。
本申请还提供一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述任一实施例所述聚合支付的后台架构方法。

Claims (10)

  1. 一种聚合支付的后台架构方法，其特征在于，包括：
    获取客户端发送的交易信息，所述交易信息包括所述客户端的位置信息；
    根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点，其中，所述交易节点为分布式交易***中指定区域内的交易中心；
    根据所述交易节点在与所述交易节点预先建立连接关系的渠道对接层中匹配渠道网关，通过所选定的渠道网关将所述交易信息中的交易请求发送至交易对象中进行处理；
    获取所述交易对象的处理结果，并将处理结果信息传送至客户端。
  2. 根据权利要求1所述的聚合支付的后台架构方法，其特征在于，所述根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖的交易节点之前，还包括：
    对所述交易信息的验证信息进行验证，所述验证信息通过加密通信协议设置；
    对验证通过的所述交易信息进行解析，以获取发送交易信息的所述客户端的身份信息以及业务类型；
    根据解析出的所述身份信息以及业务类型在身份权限列表中匹配以进行鉴权；
    鉴权通过的交易信息进行交易节点分配。
  3. 根据权利要求2所述的聚合支付的后台架构方法，其特征在于，在执行所述鉴权通过的交易信息进行交易节点分配的步骤之前还包括：
    获取第一预设时间段内鉴权通过了的交易信息的流量值；
    允许所述流量值小于或等于第一预设阈值的交易信息进行分配。
  4. 根据权利要求2所述的聚合支付的后台架构方法，其特征在于，所述根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点的方法包括：
    根据所述交易信息的业务类型在分配列表中匹配分配规则，以使同一客户端同一业务类型请求在同一交易节点处理；
    根据所述分配规则获取所映射的交易节点的使用状态信息；
    判断所述交易节点的使用状态是否符合第一预设条件；
    当符合所述第一预设条件，将所述交易信息分配至所述交易节点中。
  5. 根据权利4所述的聚合支付的后台架构方法，其特征在于，当所述交易节点的使用状态不符合第一预设条件时，重新匹配分配规则以重新确定交易节点。
  6. 根据权利要求1所述的聚合支付的后台架构方法，其特征在于，所述交易对象对所述交易请求进行处理的方法包括：
    根据所述交易请求创建一个唯一的单号；
    通过调用通信接口在交易对象中对所述单号对应的交易请求进行处理；
    将所述交易请求的处理过程数据写入异步任务队列中缓存；
    当所述异步任务队列中的任务在处理过程出现异常时，进行重试；
    当所述异步任务队列中的所有任务都完成后删除该缓存的异步任务队列。
  7. 根据权利要求6所述的聚合支付的后台架构方法，其特征在于，还包括：
    获取重试的次数；
    当所述重试的次数达到第二阈值时删除所述异步任务队列，并反馈异常信息给所述客户端。
  8. 一种聚合支付的后台架构***，包括：
    接入前端：用于执行获取客户端发送的交易信息，所述交易信息包括所述客户端的位置信息；
    中继转发服务器：用于根据所述位置信息将所述交易信息分配至对所述位置信息具有管辖权限的交易节点，其中，所述交易节点为分布式交易***中指定区域内的交易中心；及
    交易节点：用于根据所述交易节点在与所述交易节点预先建立连接关 系的渠道对接层中匹配渠道网关，通过所选定的渠道网关将所述交易信息中的交易请求发送至所述交易对象中进行处理；获取所述交易对象的处理结果，并将处理结果信息传送至客户端。
  9. 一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行如权利要求1至7中任一项权利要求所述的聚合支付的后台架构方法的步骤。
  10. 一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如权利要求1至7中任一项权利要求所述的聚合支付的后台架构方法的步骤。
PCT/CN2019/119788 2018-12-29 2019-11-20 聚合支付的后台架构方法、***、计算机设备及存储介质 WO2020134738A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2021538273A JP7118281B2 (ja) 2018-12-29 2019-11-20 統合支払いのバックエンド構築方法、システム、コンピュータ機器及び記憶媒体
EP19905428.9A EP3889870B1 (en) 2018-12-29 2019-11-20 Background architecture method and system for aggregation payment, computer device, and storage medium
RU2021121118A RU2768197C1 (ru) 2018-12-29 2019-11-20 Способ и система серверной архитектуры для объединения платежей, компьютерное устройство и носитель данных
KR1020217023698A KR102553831B1 (ko) 2018-12-29 2019-11-20 집계 지불을 위한 백엔드 아키텍처 방법 및 시스템, 컴퓨터 디바이스 및 저장 매체
US17/419,613 US20220084031A1 (en) 2018-12-29 2019-11-20 Backend architecture method and system for aggregate payment, computer device, and storage medium
SG11202107131SA SG11202107131SA (en) 2018-12-29 2019-11-20 Background architecture method and system for aggregation payment, computer device, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811638611.3A CN111383022B (zh) 2018-12-29 2018-12-29 聚合支付的后台架构方法、***、计算机设备及存储介质
CN201811638611.3 2018-12-29

Publications (1)

Publication Number Publication Date
WO2020134738A1 true WO2020134738A1 (zh) 2020-07-02

Family

ID=71128323

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/119788 WO2020134738A1 (zh) 2018-12-29 2019-11-20 聚合支付的后台架构方法、***、计算机设备及存储介质

Country Status (8)

Country Link
US (1) US20220084031A1 (zh)
EP (1) EP3889870B1 (zh)
JP (1) JP7118281B2 (zh)
KR (1) KR102553831B1 (zh)
CN (1) CN111383022B (zh)
RU (1) RU2768197C1 (zh)
SG (1) SG11202107131SA (zh)
WO (1) WO2020134738A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110866753B (zh) * 2019-10-24 2021-04-06 腾讯科技（深圳）有限公司 一种第三方结算的控制方法、装置、电子设备和存储介质
CN112819473B (zh) * 2021-02-03 2024-02-23 深圳乐信软件技术有限公司 一种基于数字字典的订单处理方法、服务器、设备及介质
CN113222565A (zh) * 2021-04-22 2021-08-06 深圳华锐金融技术股份有限公司 交易***、交易方法、装置、计算机设备和存储介质
KR20230043631A (ko) * 2021-09-24 2023-03-31 휴렛-팩커드 디벨롭먼트 컴퍼니, 엘.피. 유료 서비스의 전자 결제 처리
CN114119241A (zh) * 2022-01-27 2022-03-01 通联支付网络服务股份有限公司 渠道交易***
CN115860734A (zh) * 2022-12-12 2023-03-28 上海汇付支付有限公司 一种单元化支付方法
CN115796889B (zh) * 2023-01-10 2023-04-18 开鑫科技信息服务(南京)有限公司 适用于交易平台的数据处理方法
CN116664120B (zh) * 2023-06-15 2024-05-24 山东烟台烟草有限公司 一种跨支付通道实现消费者身份唯一标识的方法及***
CN116561735B (zh) * 2023-07-10 2024-04-05 深圳竹云科技股份有限公司 一种基于多认证源的互信认证方法、***及电子设备
CN116894668A (zh) * 2023-09-11 2023-10-17 深圳易能时代科技有限公司 基于支付网关适配器的支付方法及相关设备
CN117808570B (zh) * 2024-02-29 2024-05-07 梅州客商银行股份有限公司 银行分布式***的全链路监控的方法、装置和电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103489095A (zh) * 2013-10-08 2014-01-01 百度在线网络技术（北京）有限公司 电子交易方法、***及支付平台***
CN105427101A (zh) * 2015-11-19 2016-03-23 成都连银信息技术有限公司 支持多种支付通道的统一支付接入网关
CN105474244A (zh) * 2013-08-20 2016-04-06 惠普发展公司，有限责任合伙企业 支付联合服务
CN106779649A (zh) * 2016-12-21 2017-05-31 世纪禾光科技发展（北京）有限公司 转账处理方法及装置

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7822656B2 (en) * 2000-02-15 2010-10-26 Jpmorgan Chase Bank, N.A. International banking system and method
JP2003067570A (ja) * 2001-08-29 2003-03-07 Nippon Atm Kk 通信ネットワークによる金融業務処理方法及びその通信システム並びにプログラム
CN100437610C (zh) * 2002-12-06 2008-11-26 林铭 一种电子交易***的实现方法
JP4889189B2 (ja) * 2003-02-03 2012-03-07 株式会社日本総合研究所 支払代行対応資金管理システム、支払代行対応資金管理システム用プログラム及びそのプログラムを記録した記録媒体
US20080249937A1 (en) * 2007-04-06 2008-10-09 Walls Robert K Payment card based remittance system with delivery of anti-money laundering information to receiving financial institution
US20090158246A1 (en) * 2007-12-18 2009-06-18 Kabira Technologies, Inc. Method and system for building transactional applications using an integrated development environment
WO2009107102A2 (en) * 2008-02-29 2009-09-03 Transact Global (Private) Limited Near-real-time payment transaction facilitation system
JP5070305B2 (ja) 2010-01-29 2012-11-14 株式会社日本総合研究所 取引中継方法および取引中継システム
US20110238476A1 (en) 2010-03-23 2011-09-29 Michael Carr Location-based Coupons and Mobile Devices
EP2646931A4 (en) 2010-12-05 2016-06-22 Ften Inc ALLOCATION OF BALANCES TO A MANAGER OF OPEN ORDERS
US20130046655A1 (en) * 2011-08-16 2013-02-21 Registria, Inc. Methods and systems for dynamically selecting a payment processing gateway
CN103186853B (zh) * 2011-12-31 2016-07-13 北大方正集团有限公司 一种服务器端和客户端移动支付方法、装置及***
US20140156512A1 (en) * 2012-12-04 2014-06-05 Pangea Universal Holdings, Inc. Providing money transfer using a money transfer platform
KR101413585B1 (ko) 2013-05-29 2014-07-04 숭실대학교산학협력단 전압 보상형 화소회로 및 그 구동방법
US9892402B2 (en) 2013-12-18 2018-02-13 Verizon Patent And Licensing Inc. Financial authorization of an online transaction based on a location and an identifier of a user device
US9430918B2 (en) 2014-09-23 2016-08-30 Moneygram International, Inc. Receipt generation service
CN104408584B (zh) * 2014-12-18 2017-11-03 中国农业银行股份有限公司 一种交易关联性的分析方法及***
CN106779666A (zh) * 2016-11-25 2017-05-31 武汉烽火信息服务有限公司 聚合支付平台及支付方法
CN106875190A (zh) * 2017-02-22 2017-06-20 世纪禾光科技发展（北京）有限公司 跨国贸易电子商务平台***大额支付的方法及***
CN107146077B (zh) * 2017-05-02 2021-01-05 广州市智专信息科技有限公司 一种支付方法及相应的便携式终端、第三方支付平台
CN107833052B (zh) * 2017-10-27 2021-02-02 南京物联传感技术有限公司 一种基于区块链的聚合支付***及工作方法
CN109191089B (zh) * 2018-07-23 2021-05-25 福建天泉教育科技有限公司 移动端支付方式适配方法及其***
US11037133B2 (en) * 2018-07-30 2021-06-15 Visa International Service Association System, method, and computer program product for selectively displaying information regarding activity in a geographic area
US11483347B2 (en) * 2018-12-05 2022-10-25 Akamai Technologies, Inc. High performance distributed system of record with secure interoperability to external systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105474244A (zh) * 2013-08-20 2016-04-06 惠普发展公司，有限责任合伙企业 支付联合服务
CN103489095A (zh) * 2013-10-08 2014-01-01 百度在线网络技术（北京）有限公司 电子交易方法、***及支付平台***
CN105427101A (zh) * 2015-11-19 2016-03-23 成都连银信息技术有限公司 支持多种支付通道的统一支付接入网关
CN106779649A (zh) * 2016-12-21 2017-05-31 世纪禾光科技发展（北京）有限公司 转账处理方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3889870A4 *

Also Published As

Publication number Publication date
SG11202107131SA (en) 2021-07-29
CN111383022B (zh) 2020-12-08
US20220084031A1 (en) 2022-03-17
JP2022516265A (ja) 2022-02-25
EP3889870A1 (en) 2021-10-06
JP7118281B2 (ja) 2022-08-15
RU2768197C1 (ru) 2022-03-23
KR20210131317A (ko) 2021-11-02
EP3889870A4 (en) 2022-01-12
EP3889870B1 (en) 2023-02-15
CN111383022A (zh) 2020-07-07
KR102553831B1 (ko) 2023-07-10

Similar Documents

Publication Publication Date Title
WO2020134738A1 (zh) 聚合支付的后台架构方法、***、计算机设备及存储介质
US20210203509A1 (en) Data processing method and apparatus in blockchain network, storage medium, and computer device
CN109447811B (zh) 在区块链网络中查询交易信息的方法、记账节点和介质
CN110032545A (zh) 基于区块链的文件存储方法、***及电子设备
KR102119449B1 (ko) 통합 오픈 api 플랫폼 시스템, 이를 이용한 금융 서비스 방법 및 이를 위한 컴퓨터 프로그램
WO2017020618A1 (zh) 一种电子资源处理方法、设备
CN103942616B (zh) 基于移动互联网的车险测算报价服务***
CN111222841B (zh) 一种基于区块链的数据分配方法及其设备、存储介质
CN112702402A (zh) 基于区块链技术实现政务信息资源共享和交换的***、方法、装置、处理器及其存储介质
CA3175939C (en) Blacklist data sharing method and system based on blockchain
WO2020253634A1 (zh) 一种数据处理方法、***及装置
US9378338B1 (en) System, method, and computer program for validating receipt of digital content by a client device
CN109034683A (zh) 一种数据配送***及配送方法
CN112819675A (zh) 一种银行业务物流管控方法和装置
JP2007005961A5 (zh)
CN107645474A (zh) 登录开放平台的方法及登录开放平台的装置
CA3058529A1 (en) Cross-funds management server-based payment system, and method, device and server therefor
CA3055647A1 (en) Payment system based on shared funds-management server, and method, device and server therefor
CA3161184A1 (en) Payment system based on shared funds-management server, and method, device and server therefor
KR102107454B1 (ko) 금융결제망 다중화 시스템, 이를 이용한 금융 서비스 방법 및 이를 위한 컴퓨터 프로그램
CN106408301A (zh) 一种提高交易指令安全的方法及装置
KR101634945B1 (ko) 비동기식 지역 분산형 지불게이트웨이 운영 방법
CN111541619A (zh) 企业信息联网核查***的自适应主动负载调节方法和装置
CA3055644C (en) Payment system based on shared funds-management server, and method, device and server therefor
CN109960924A (zh) 一种子***登录方法、装置、***及电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19905428

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021538273

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019905428

Country of ref document: EP

Effective date: 20210701