Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
In the service processing process, the service response server can establish an association relationship with the service participants to provide corresponding service support for the service participants, and the service response server configures corresponding service basic information for the service participants to use when processing the service after establishing the association relationship. When a service to be processed exists between a service requester and a service participant, the service requester client interacts with a service response server based on service basic information and service supplementary information corresponding to the service to be processed to complete a processing process of the service to be processed. For example, the service supplementary information may be input to the service requester client by the service requester. In the related art, when the service basic information configured by the service response server is fixed, the service participant (or the service response server, the entrusted technical service provider, etc.) can output the service basic information in the form of a graphic code to provide the service basic information required for completing the service to the service requester. For example, the business participant can print and post the graphic code to be analyzed by the business requester; or, the graphic code is displayed to the service requester through the service participant client. Then, the service requester may parse the graphic code through the service requester client to obtain service basic information, and input service supplementary information of the service to be processed (related to the service participant) in the service requester client, so as to perform processing on the service to be processed based on the obtained service basic information and the input service supplementary information.
In practical application, for the same service, there may exist a plurality of service response servers capable of providing service support to a service participant, that is, the service participant may establish an association relationship with the plurality of service response servers, and each associated service response server configures corresponding service basic information for the service participant client. Meanwhile, each service response server has a corresponding service requester client, and the service requester client can complete service processing through service basic information configured by the service response server matched with the service requester client. In this case, the corresponding graphic code may be generated for each piece of service basic information configured by each service response server. In other words, each graphic code corresponds to a service response server. Then, when the service requester needs to initiate the service processing related to the service participant, the graphic code may be selected according to the actual requirement, and the service requester client corresponding to the selected graphic code is adopted to perform scanning to complete the service processing.
However, in the above scenario, when a business participant establishes an association relationship with a plurality of business response servers, a corresponding graphic code needs to be generated for the business basic information configured by each business response server, and when a business participant establishes an association relationship with other business response servers, a corresponding graphic code still needs to be generated for output display for the business basic information configured by a newly associated business response server, which results in higher cost and low efficiency.
Taking the application scenario of the merchant cash register as an example, a user (a service requester) uses a payment client (such as a mobile phone, i.e. a service requester client) installed with a mobile payment App to scan the cash register (such as a two-dimensional cash register) displayed by a merchant (a service participant), the payment code comprises receipt information of a merchant on a corresponding payment platform (a business response server side) (or the payment code comprises an access path for acquiring the receipt information and needs to be further acquired by accessing a background server), the mobile payment App acquires the receipt information (business basic information) of the merchant by analyzing the payment code and displays the receipt information on an App interface for confirmation by a user, and the user can input order information (business supplementary information provided by the merchant, such as transaction amount) and submit a payment application after confirming that the receipt information of the merchant is correct, so that the mobile payment App is in butt joint with the payment platform to complete a subsequent payment process.
The same merchant may cooperate with multiple different payment platforms (e.g., with payment platforms such as a paypal, wechat, etc.), each of which may assign corresponding billing information (e.g., an account, an identification number, a payment platform name, an access address of the payment platform, etc. assigned to the merchant) to the merchant. Then, when the merchant supports a plurality of payment platforms, each payment platform generates a corresponding payment receipt code according to the distributed receipt information for the merchant to display to the user. For example, a merchant may post at the merchant storefront for a user to pay for a code scan. In this way, a situation of "one-user multi-code" occurs, that is, a shop front of one merchant is pasted with merchant cash register codes generated by a plurality of payment platforms. Since the mobile payment apps are usually associated with the payment platforms (that is, each payment platform develops a corresponding mobile payment App), the user needs to select a collection code supported by the mobile payment App installed by the user to scan to complete the payment.
It can be seen that when a merchant interfaces with multiple payment platforms, the receipt information configured for each payment platform needs to generate a corresponding cash register code for the merchant to display to the user. Moreover, when a merchant cooperates with a new payment platform (for example, the merchant may also cooperate with platforms such as the kyoto and the unionpay), the receipt information configured for the newly cooperating payment platform still needs to be regenerated into a corresponding payment code for output display, and then the merchant needs to post and display the newly obtained payment code, which results in higher cost and low efficiency.
Similarly, in a social scene, the same user (service participant) may register to obtain account information (service basic information) on a plurality of social platforms (service response servers), and when a friend (to-be-processed service) is added, the user needs to respectively display two-dimensional codes (generated according to the account information) of each social platform to other users (service requesters) for code scanning and adding the friend. After the other users scan the two-dimensional code through the mobile phone to obtain the account information of the user, the other users input the verification information (namely service supplementary information; such as the user name, the account, the remark and the like of the other users), and therefore the friend adding application of the user is completed.
The present specification aims to provide a service processing scheme based on a graphic code, which can merge the graphic codes corresponding to the respective service terminals of each service into one graphic code supporting interoperability under the condition that the same service participant client establishes an association relationship with a plurality of service response service terminals, so that each service requester can implement the service processing related to the service participant client by scanning the graphic code supporting interoperability. And when the client of the service participant establishes the association relationship with other new service response server subsequently, the graphic code corresponding to the new service response server can be merged without replacing the graphic code supporting the interoperability, thereby reducing the cost and improving the service processing efficiency.
Fig. 1 is a schematic architecture diagram of a service processing system based on a graphic code according to an exemplary embodiment. As shown in fig. 1, the system may include a server 11, a network 12, a number of electronic devices such as a cell phone 13, a cell phone 14, a PC15, and a PC 16.
The server 11 may be a physical server comprising a separate host, or the server 11 may be a virtual server hosted by a cluster of hosts. In the operation process, the server 11 serves as an index platform for recording the service basic information of each service participant client for querying.
Handsets 13-14 and PCs 15-16 are just two types of electronic devices that may be used by a service participant or a service requester. In practice it is obvious that also electronic devices of the type such as: tablet devices, notebook computers, Personal Digital Assistants (PDAs), wearable devices (e.g., smart glasses, smart watches, etc.), etc., which are not limited by one or more embodiments of the present disclosure. In operation, the electronic device may act as a service participant client or a service requestor client. The business response server establishes an association relationship with the business participant client, configures business basic information for the business participant client, acquires the configured business basic information by the business requester client (when a to-be-processed business exists between the business requester client and the business participant), and completes business processing based on the business basic information and the business supplement information corresponding to the to-be-processed business.
And the network 12 for interaction between the respective electronic devices and the server 11 may include various types of wired or wireless networks. In one embodiment, the Network 12 may include the Public Switched Telephone Network (PSTN) and the Internet. Meanwhile, the electronic devices such as the mobile phones 13-14 and the PCs 15-16 can also carry out communication interaction through the network 12.
Referring to fig. 2, fig. 2 is a flowchart of a service processing method based on a graphic code according to an exemplary embodiment. As shown in fig. 2, the method applied to the service requester client may include the following steps:
step 202, analyzing a service graphic code of a service participant to obtain identification information of the service participant, wherein the service participant is associated with at least one service response server, each associated service response server is configured with corresponding service basic information for the service participant, and the mapping relationship between the service basic information and the identification information, which are generated for the service participant by each associated service response server, is uploaded to an index platform for recording.
In this embodiment, the service response server provides a service support to the service participant, and after the service participant and the service response server establish an association relationship, the service response server configures service basic information to the service participant, where the service basic information is information that needs to be used when implementing the service. Then, when there is a need to implement the service between the service requester and the service participant, the service requester can implement service processing based on the service basic information configured by the service response server through the service requester client matched with the service response server.
For example, in the application scenario of the merchant cash register, the service requester includes a payer (that is, the service requester client includes a payment client), the service graphic code includes a cash register graphic code, the service participants include merchants (that is, the service participant client includes a merchant client), the service response server associated with the merchant client includes payment platform servers, and each payment platform server is configured with corresponding receipt information (that is, service basic information; for example, account information of the merchant client) for the merchant client.
The merchant establishes an association with the payment platform by registering with the payment platform. The payment platform can allocate corresponding account, identification number and other receipt information to the merchant as service basic information of the payment service. Then, when the user has a service payment requirement with the merchant (for example, the user purchases a commodity from the merchant and then needs to pay a corresponding fee to the merchant), the user may interact with the payment platform based on the receipt information through a mobile payment App (installed in the electronic device of the user), so as to complete a service of paying a fee to an account registered by the merchant on the payment platform.
In this embodiment, an index platform is configured in the service processing system based on the graphic code for recording service basic information of each service participant. The service participant can send a registration request to the index platform through the service participant client so that the index platform allocates unique identification information to the service participant. Then, the index platform may record a mapping relationship between the identification information of the service participant and the service basic information of the service participant.
Based on the configuration of the index platform, the service graph code of the service participant is not used for recording service basic information as in the related art, but is used for recording identification information of the service participant. And because the identification information is used for representing the identity of the service participant, the identification information has the characteristics of fixation and uniqueness. Therefore, the service graphic code of the service participant is not required to be changed and is fixed. Then, the service requester client can obtain the identification information of the service participant by scanning the service graphic code and analyzing the identification information, and further query the service basic information of the service participant to the index platform through the identification information, so that the service processing is performed by using the service basic information supported by the service requester client in the service basic information of the service participant.
And 204, sending a query request aiming at the service participant to the index platform based on the identification information, so that the index platform determines candidate service basic information corresponding to the identification information according to the recorded mapping relation.
In this embodiment, in one case, the access address of the index platform may be recorded in the service graph code; in another case, the access address of the index platform may also be configured in the service request client corresponding to each service response server, for example, the access address may be written in an installation package of the service request client.
Taking recording the access address in the service graphic code as an example, the service graphic code of the service participant can be generated by the service participant client, the index platform or other technical service providers providing the generated service graphic code based on the identification information of the service participant and the access address of the index platform. Then, the service requester client may parse the service graphic code to obtain an access address of the index platform, and further send a query request to the index platform according to the access address, where the query request includes identification information of a service participant.
Step 206, obtaining the target service basic information matched with the service request party client in the candidate service basic information, and implementing the service processing related to the service participant based on the target service basic information and the service supplementary information input by the service request party client.
In this embodiment, the mapping relationship between the service basic information and the corresponding identification information of each service participant is uploaded to the index platform for recording. Therefore, the index platform can find out the service basic information corresponding to the identification information contained in the query request as the candidate service basic information according to the recorded mapping relation.
In one case, the index platform may identify target service basic information matched with the service requester client from the candidate service basic information, and return the identified target service basic information to the sender of the query request (i.e., the service requester client), so that the service requester client may receive the target service basic information returned by the index platform to achieve the acquisition of the target service basic information.
In another case, after the index platform queries and obtains the candidate service basic information, the index platform can directly return the candidate service basic information to the service requester client. Then, the service requester client may receive the candidate service basic information returned by the index platform, and identify the service basic information matched with itself in the candidate service basic information as the target service basic information.
And aiming at the mode of identifying the target service basic information, when the service response service end configures the service basic information, the service end identification of the service response service end can be recorded in the service basic information. In other words, the service end identifier of the service end configured with any service basic information is recorded in any service basic information. Based on the setting of the service basic information, the service basic information recorded with the target service end identification can be searched in the candidate service basic information, the searched service basic information is used as the target service basic information, and the target service end identification is the service end identification of the service response service end corresponding to the service requester client. In the case that the index platform identifies the target service basic information, a client identifier of a sender (service requester client) may be recorded in the query request, so as to determine a server identifier corresponding to the client identifier.
Further, after the target server identifier is determined, when performing service processing, a service request may be sent to a service response server corresponding to the service requester client based on the target service basic information and the service supplementary information input by the service requester to perform service processing. The service response server is the service response server corresponding to the target server identification.
In this embodiment, taking an application scenario of a merchant cash register as an example, a service participant includes a merchant, a service requester includes a payer, service supplementary information includes order information of an order to be paid, a service response server associated with a merchant client includes a payment platform server, and service basic information configured by each payment platform server for the merchant includes order receiving information.
Correspondingly, please refer to fig. 3, where fig. 3 is a flowchart of a service processing method based on a graphic code according to an exemplary embodiment. As shown in fig. 3, the method applied to the index platform may include the following steps:
step 302, receiving a query request aiming at a service participant and sent by a service requester client based on identification information of the service participant, wherein the service participant is associated with at least one service response server, each associated service response server is configured with corresponding service basic information aiming at the service participant, the mapping relationship between the service basic information generated by each associated service response server for the service participant and the identification information is uploaded to an index platform for recording, and the identification information is obtained by analyzing a service graphic code of the service participant by the service requester client.
Step 304, determining candidate service basic information corresponding to the identification information according to the recorded mapping relationship, so that the service requester client performs service processing related to the service participant based on the service basic information matched with the service requester client in the candidate service basic information and the service supplementary information input by the service requester to the service requester client.
In this embodiment, when a business participant establishes an association relationship with other business response servers except for the currently established association relationship, the other response servers can add configured business basic information to the index platform for recording; and the other response server side can also generate corresponding business graphic codes from the configured business basic information, and then return the business graphic codes to the business participants so that the business participants interact with the index platform and add the business basic information recorded by the business graphic codes to the index platform for recording.
Aiming at the condition that other response service terminals add service basic information, the index platform receives a first addition request (the first addition request comprises identification information of the service participant client and first updating service basic information configured by the other service response service terminals aiming at the service participant after the incidence relation is established between the first addition request and the service participant) sent by other service response service terminals relevant to the service participant client, and adds the corresponding relation between the identification information and the first updating service basic information in the mapping relation.
Aiming at the condition that a service participant adds service basic information, an index platform receives a second adding request sent by a service participant client, wherein the second adding request comprises the identification information and second updating service basic information configured by other service response servers aiming at the service participant after an incidence relation is established between the second adding request and the service participant, the second updating service basic information is obtained by analyzing updating graphic codes from other service response servers by the service participant client, and the updating graphic codes are generated by the other service response servers according to the second updating service basic information. And after receiving a second adding request, the index platform adds the corresponding relation between the identification information and the second updating service basic information in the recorded mapping relation.
It should be noted that, for the detailed process of the service processing method, reference may be made to the embodiment shown in fig. 2, which is not described herein again.
Correspondingly, please refer to fig. 4, fig. 4 is a flowchart of a service information maintenance method according to an exemplary embodiment. As shown in fig. 4, the method is applied to a business participant client or a business response server, and may include the following steps:
step 402, when any business response server establishes an association relation with a business participant, obtaining basic information of the business to be merged configured by the business response server for the business participant.
In this embodiment, when any service response server establishes an association relationship with a service participant, the service response server may interact with the index platform, and further add the service basic information to be merged to the index platform. Or the service participant client interacts with the index platform, and further adds the service basic information to be merged into the index platform.
Aiming at the condition that a business participant adds business basic information, after the incidence relation is established between any business response server side and the business participant, the business response server side generates the business basic information to be merged corresponding to the business participant, generates a corresponding business graphic code based on the business basic information to be merged, and then sends the business graphic code to a business participant client side. Then, after receiving the service graphic code (i.e. the service graphic code generated by any service response server based on the service basic information to be merged), the service participant client may parse the received service graphic code to obtain the service basic information to be merged.
Step 404, sending an adding request for the mapping relationship between the basic information of the service to be merged and the identification information of the service participant to an index platform, so that the index platform records the mapping relationship.
In this embodiment, the mapping relationship between the identification information and the corresponding service basic information recorded by the index platform is used to determine candidate service basic information corresponding to the identification information when the index platform receives a query request, which is sent by a service requester client based on the identification information and is directed to the service participant, the service basic information used by the service requester client to perform service processing related to the service participant is the service basic information matched with the service requester client in the candidate service basic information, the service supplementary information used by the service requester client to perform the service processing is input by the service requester, and the service requester client obtains the identification information by analyzing a service graphic code of the service participant. It should be noted that, for the detailed process of the service processing method, reference may be made to the embodiment shown in fig. 2, which is not described herein again.
As can be seen from the above embodiments, by introducing the index platform for recording the service basic information of each service participant, the service pattern codes corresponding to each service response server can be merged into one service pattern code supporting interoperability (recording the identification information allocated to the service participant by the index platform) under the condition that the same service participant establishes an association relationship with a plurality of service response servers, so that each service requester can implement the service processing related to the service participant by scanning the service pattern code supporting interoperability. The service graphic code supporting interoperability only needs to contain identification information distributed to the service participants by the index platform, and does not need to contain service basic information distributed to the service participants by each service response server. On one hand, the service graphic code supporting the interoperability contains relatively less information, which is beneficial to improving the efficiency of generating the service graphic code and the accuracy and speed of analyzing the service graphic code by the service requester client, thereby improving the user experience. On the other hand, when the service participant establishes the association relationship with other new service response service terminals subsequently, the service graphic code corresponding to the new service response service terminal can be combined without replacing the service graphic code supporting the interoperability, thereby reducing the cost and improving the service processing efficiency.
Meanwhile, the index platform only needs to execute query operation aiming at the service basic information, and does not need to execute complex operations related to data processing, such as generating a service graphic code, aggregating a plurality of service graphic codes, assisting a service requester client to implement service processing and the like, so that more processing resources are avoided being occupied; therefore, the smooth operation of the service can be ensured under the condition of low performance requirement on the index platform.
In addition, the service basic information configured by each service response server is recorded through the index platform, and the service basic information configured by each service response server does not need to be combined into one graphic code, so that the original information format of the service basic information configured by each service response server can be reserved, each service response server is allowed to generate the service basic information according to the respective information format, and differentiated services are provided for service participants.
For convenience of understanding, the technical solution of the present specification is described in detail below by taking an application scenario of the merchant cash register as an example, and the processing procedure of the social scenario is similar to this.
Referring to fig. 5, fig. 5 is a schematic diagram of a code scanning payment architecture according to an exemplary embodiment. As shown in fig. 5, the architecture includes an indexing platform 50, a merchant client 51 used by a merchant, a payment platform server 52 of a payment platform, and a payment client 53 used by a user. The merchant client 51, the payment platform server 52 and the payment client 53 may all access the order-receiving information of the merchant recorded in the index platform 50 through the merchant identifier of the merchant.
Referring to fig. 6, fig. 6 is a schematic diagram of a service information maintenance method according to an exemplary embodiment. As shown in fig. 6, the interaction process between the parties may include the following steps:
at step 602, the merchant client 51 registers with the index platform 50 to obtain a merchant identifier.
In step 604, the merchant client 51 obtains the merchant two-dimensional code to be merged from the payment platform server 52.
For example, a merchant may initiate registration with the payment platform server 52 through the merchant client 51 to obtain account information on the payment platform. Meanwhile, the payment platform server 52 may generate a merchant two-dimensional code based on the account information, the payment platform name, the access address of the payment platform, and other billing information.
In step 606, the merchant client 51 parses the merchant two-dimensional code to be merged to obtain the order receiving information to be merged.
For example, after acquiring the merchant two-dimensional code, the merchant client 51 may scan and analyze the merchant two-dimensional code to obtain the order receiving information, that is, the order receiving information to be merged.
In step 608, the merchant client 51 sends the order receiving information to be merged and the merchant identifier of the merchant client to the indexing platform 50.
For example, the merchant client 51 creates an addition request for the order receipt information, where the addition request includes the combined order receipt information and the merchant identifier of the merchant client.
In step 610, the index platform 50 records the correspondence between the order receiving information and the merchant identifier.
In the foregoing example, after receiving the addition request, the index platform reads the order receiving information and the merchant identifier included in the addition request, and establishes a mapping relationship between the order receiving information and the merchant identifier. Specifically, when the index platform allocates the merchant identifier to the merchant, a storage space may be allocated for the merchant identifier, so as to store the order receipt information corresponding to the merchant identifier. For example, as shown in table 1:
TABLE 1
In this embodiment, the merchant identification information is used to represent the identity of the merchant on the index platform, and has the characteristics of being fixed and unique. Thus, the merchant's passcode may be generated by the merchant client, the indexing platform, or other technical service provider that provides for the generation of the passcode based on the merchant identification and the access address of the indexing platform. Then, the user can scan the payment receiving code through the payment client and further analyze the payment receiving code to obtain the merchant identifier and the access address of the index platform, so that the order receiving information corresponding to the merchant identifier is inquired from the index platform through the access address, and then payment is completed by utilizing the inquired order receiving information. This will be explained with reference to fig. 7.
Referring to fig. 7, fig. 7 is a schematic diagram illustrating payment based on a cash register according to an exemplary embodiment. As shown in fig. 7, the payment process may include the steps of:
in step 702, the payment client 53 scans the merchant's passcode to obtain the merchant identifier and the access address of the index platform.
At step 704, payment client 53 sends a query request (containing a merchant identification) to indexing platform 50 via the access address.
In step 706, the index platform 50 queries the recorded mapping relationship for order receipt information corresponding to the merchant identifier included in the query request.
At step 708, the indexing platform 50 returns the queried order receipt information (i.e., candidate order receipt information) to the payment client 53.
In this embodiment, when the payment platform configures the order receipt information, the payment platform may record its own server identifier in the order receipt information. For example, the order receipt information includes the name of the payment platform, which is called the above-mentioned server identifier. Based on the setting of the order receiving information, the order receiving information recorded with the target server identification can be searched in the candidate order receiving information, the searched order receiving information is used as the target order receiving information, and the target server identification is the server identification of the payment platform corresponding to the payment client.
In this embodiment, the index platform 20 may also identify target order receipt information matching the payment client from the candidate order receipt information, and return the identified target order receipt information to the payment client 53. In this case, the payment client 53 may record its own client identification in the query request for determining the server identification corresponding to the client identification.
For example, the name of the payment platform a is a, the client identifier of a payment App (installed in a payment client of a user) of the payment platform is a, and if the order receiving information recorded with a is found to exist in the candidate order receiving information, the order receiving information is used as the order receiving information supported by the payment client a; otherwise, the payment client s does not support the current merchant, and the transaction is terminated.
In step 710, the payment client 53 identifies the receipt information supported by itself in the receipt information returned by the index platform 20 and displays the receipt information for the user to confirm.
In step 712, the payment client 63 completes payment according to the order receiving information confirmed by the user and the order information input by the user.
In this embodiment, when completing payment to the merchant based on the target order receiving information, the payment client 53 may first display the account information of the merchant for the user to confirm, and after completing confirmation of the account information of the merchant and interaction of the order information, the user confirms submission of payment. For example, the order information is payment information such as a transaction amount of an order currently generated by the user with the merchant, and is inquired from the merchant by the user, or is actively notified by the merchant. The user may fill in payment information to the payment client 63 and confirm the payment, and then the payment client 63 submits a payment request instruction (including account information of the merchant and order information filled in by the user) to the payment platform, so that the payment instruction is processed by the payment platform, the payment process is completed, and payment results are returned to the payment client and the merchant client.
As can be seen from the above embodiments, by introducing the index platform for recording the receipt information of each merchant client, the payment codes corresponding to each payment platform can be merged into one payment code supporting interoperability (merchant identifier allocated to the merchant client by the index platform) under the condition that the same merchant client establishes an association relationship with multiple payment platforms, so that each user can implement the payment service related to the merchant client by scanning the payment code supporting interoperability. The cash register code supporting interoperability only comprises identification information distributed to the merchant by the index platform, and does not need to comprise business basic information distributed to the merchant by each business response server. On one hand, the mutual communication supported collection code contains relatively less information, which is beneficial to improving the efficiency of generating the collection code and the accuracy and speed of analyzing the collection code by the payment client, thereby improving the user experience. On the other hand, when the merchant establishes the incidence relation with other new payment platforms subsequently, the collection codes corresponding to the new payment platforms can be combined, and the collection codes supporting the interoperability do not need to be replaced, so that the cost is reduced, and the service processing efficiency is improved.
Meanwhile, the index platform only needs to execute query operation aiming at receipt information, and does not need to execute complex operations related to data processing, such as generating a collection code, aggregating a plurality of collection codes, assisting a payment client to implement a payment process and the like, so that more processing resources are avoided being occupied; therefore, the payment process can be ensured to be smoothly carried out under the condition of low performance requirement on the index platform.
In addition, the order receiving information configured by each payment platform is recorded through the index platform, the order receiving information configured by each payment platform does not need to be combined into one cash register, the original information format of the order receiving information configured by each payment platform can be reserved, each payment platform is allowed to generate the order receiving information according to the respective information format, and therefore differentiated services are provided for merchants.
Corresponding to the above method embodiments, the present specification further provides an embodiment of a service processing apparatus based on a graphic code.
The embodiment of the service processing device based on the graphic code in the specification can be applied to electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.
Referring to fig. 8, fig. 8 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 8, at the hardware level, the apparatus includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, but may also include hardware required for other services. The processor 802 reads a corresponding computer program from the non-volatile memory 810 into the memory 808 and then runs the computer program to form a service processing device based on graphic codes on a logic level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 9, in a software implementation, the service processing apparatus based on a graphic code is applied to a service requester client, and may include:
the identification analysis unit 91 analyzes a service graphic code of a service participant to obtain identification information of the service participant, the service participant is associated with at least one service response server, each associated service response server is configured with corresponding service basic information for the service participant, and a mapping relation between the service basic information and the identification information, which is generated by each associated service response server for the service participant, is uploaded to an index platform for recording;
a sending unit 92, configured to send, to the index platform, an inquiry request for the service participant based on the identification information, so that the index platform determines, according to a recorded mapping relationship, candidate service basic information corresponding to the identification information;
and a service processing unit 93 configured to acquire target service basic information matched with the service requester client from the candidate service basic information, and implement service processing related to the service participant based on the target service basic information and service supplementary information input by the service requester client.
Alternatively to this, the first and second parts may,
further comprising: an address resolution unit 94, which resolves the service graphic code to obtain an access address of the index platform;
the sending unit 92 is specifically configured to: and sending the query request to the index platform according to the access address, wherein the query request comprises the identification information.
Optionally, the service processing unit 93 is specifically configured to:
receiving the target service basic information returned by the index platform, wherein the target service basic information is identified and obtained from the candidate service basic information by the index platform;
or receiving the candidate service basic information returned by the index platform, and identifying the service basic information matched with the service requester client in the candidate service basic information as the target service basic information.
Optionally, any service basic information records a service end identifier of a service end configured with the service basic information;
identifying the target service basic information by the following method: searching the service basic information recorded with the target service end identification in the candidate service basic information, and taking the searched service basic information as the target service basic information, wherein the target service end identification is the service end identification of the service response service end corresponding to the service requester client;
the service processing unit 93 is specifically configured to: and sending a service request to a service response server corresponding to the service requester client based on the target service basic information and the service supplementary information to implement service processing.
Optionally, the service participant includes a merchant, the service requester includes a payer, the service supplementary information includes order information of an order to be paid, the service response server associated with the merchant client includes a payment platform server, and the service basic information configured by each payment platform server for the merchant includes order receiving information.
The embodiment of the service processing device based on the graphic code in the specification can be applied to electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.
Referring to fig. 10, fig. 10 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 10, at the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile storage 1010, although other hardware required for services may be included. The processor 1002 reads a corresponding computer program from the non-volatile memory 1010 to the memory 1008 and then runs the computer program to form a service processing device based on graphic codes on a logic level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 11, in a software implementation, the service processing apparatus based on a graphic code is applied to an index platform, and may include:
a first receiving unit 1101, configured to receive a query request, which is sent by a service requester client based on identification information of a service participant and is addressed to the service participant, where the service participant is associated with at least one service response server, each associated service response server configures corresponding service basic information for the service participant, a mapping relationship between the service basic information generated by each associated service response server for the service participant and the identification information is uploaded to an index platform for recording, and the identification information is obtained by the service requester client analyzing a service graphic code of the service participant;
the determining unit 1102 determines candidate service basic information corresponding to the identification information according to the recorded mapping relationship, so that the service requester client performs service processing related to the service participant based on the service basic information matched with the service requester client in the candidate service basic information and service supplementary information input by the service requester to the service requester client.
Optionally, the method further includes:
a second receiving unit 1103, configured to receive a first addition request sent by another service response server associated with the service participant, where the first addition request includes the identification information and first updated service basic information configured by the other service response server for the service participant after an association relationship is established between the other service response server and the service participant;
a first adding unit 1104, which adds the corresponding relationship between the identification information and the first updated service basic information in the mapping relationship.
Optionally, the method further includes:
a third receiving unit 1105, configured to receive a second addition request sent by the service participant client, where the second addition request includes the identification information and second updated service basic information configured by other service response servers for the service participant after an association relationship is established between the second addition request and the service participant, where the second updated service basic information is obtained by the service participant client analyzing an updated graphic code from the other service response servers, and the updated graphic code is generated by the other service response servers according to the second updated service basic information;
a second adding unit 1106 adds the corresponding relationship between the identification information and the second updated service basic information in the mapping relationship.
Optionally, the service participant includes a merchant, the service requester includes a payer, the service supplementary information includes order information of an order to be paid, the service response server associated with the merchant client includes a payment platform server, and the service basic information configured by each payment platform server for the merchant includes order receiving information.
The embodiment of the service basic information maintenance device in the present specification can be applied to electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.
Referring to fig. 12, fig. 12 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 12, at the hardware level, the apparatus includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile memory 1210, although it may also include hardware required for other services. The processor 1202 reads the corresponding computer program from the non-volatile memory 1210 into the memory 1208 and then runs the computer program, thereby forming a service basic information maintenance device on a logic level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 13, in a software implementation, the service basic information maintaining apparatus may include:
an obtaining unit 1301, configured to, when any service response server establishes an association relationship with a service participant, obtain basic information of a service to be merged, configured by the any service response server for the service participant;
a sending unit 1302, configured to send an addition request for a mapping relationship between the basic information of the service to be merged and the identification information of the service participant to an index platform, so that the index platform records the mapping relationship;
the mapping relation between the identification information recorded by the index platform and the corresponding service basic information is used for determining candidate service basic information corresponding to the identification information when the index platform receives a query request aiming at the service participant and sent by a service requester client based on the identification information, the service basic information adopted by service processing carried out by the service requester client and related to the service participant is service basic information matched with the service requester client in the candidate service basic information, service supplementary information adopted by the service requester client for carrying out the service processing is input by the service requester, and the service requester client obtains the identification information by analyzing a service code of the service participant.
Optionally, the obtaining unit 1301 is specifically configured to:
and analyzing the service graphic code generated by any service response server based on the service basic information to be merged to obtain the service basic information to be merged.
Optionally, the service participant includes a merchant, the service requester client includes a payment client, the service supplementary information includes order information of an order to be paid, the service response server associated with the merchant client includes a payment platform server, and the service basic information of the service information configured by each payment platform server for the merchant includes order receiving information.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention 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.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer 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 disk storage, quantum memory, graphene-based storage media 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.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.