CN112215593A - Payment method, payment device, server and storage medium - Google Patents
Payment method, payment device, server and storage medium Download PDFInfo
- Publication number
- CN112215593A CN112215593A CN202011081303.2A CN202011081303A CN112215593A CN 112215593 A CN112215593 A CN 112215593A CN 202011081303 A CN202011081303 A CN 202011081303A CN 112215593 A CN112215593 A CN 112215593A
- Authority
- CN
- China
- Prior art keywords
- payment
- selector
- payment application
- service
- application program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 98
- 230000015654 memory Effects 0.000 claims description 14
- 238000004590 computer program Methods 0.000 claims description 6
- 238000004806 packaging method and process Methods 0.000 claims description 6
- 238000001514 detection method Methods 0.000 claims description 5
- 230000006870 function Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 238000012360 testing method Methods 0.000 description 4
- 238000012795 verification Methods 0.000 description 3
- 238000003491 array Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
- G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/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
-
- 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/382—Payment protocols; Details thereof insuring higher security of transaction
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The embodiment of the application discloses a payment method, a payment device, a server and a storage medium, wherein the method comprises the following steps: acquiring a payment request sent by a user terminal, wherein the payment request carries a payment application program identifier; determining a plurality of sub-selectors and service selectors corresponding to the payment application program identification in a payment selector according to the payment request; acquiring target configuration information corresponding to the payment application program identifier in each sub-selector of the plurality of sub-selectors, wherein the target configuration information in each sub-selector is different; and loading the target configuration information into a service calling entity of the service selector, and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information to finish payment. By implementing the method, the complexity of calling the payment interface can be reduced, and the payment is more convenient and faster.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a payment method, an apparatus, a server, and a storage medium.
Background
Payment is widely used in websites or Application programs (APP) at present, but the threshold of the payment license plate is too high, not all companies can have the payment license plate of themselves to make payment, most companies are accessed to a third party payment mode, and the third party payment can be accessed to a plurality of payment modes at the same time, so that users can select favorite payment modes. However, the payment methods are too many in variety, each payment method can be divided into a common merchant edition, a service provider edition, a bank service provider edition and the like, and payment in many different scenes is provided in each large edition, such as APP payment, JSAPI payment, H5 payment and the like, each payment has an own interface document, and when various payment methods are accessed, each payment interface calling method is different, so that the payment operation is complicated. Therefore, how to make calling the payment interface simpler becomes an urgent problem to be solved.
Disclosure of Invention
The embodiment of the application provides a payment method, a payment device, a server and a storage medium, which can reduce the complexity of calling a payment interface, make the calling of the payment interface simpler, and make the payment more convenient and faster.
The first aspect of the embodiment of the application discloses a payment method, which comprises the following steps:
acquiring a payment request sent by a user terminal, wherein the payment request carries a payment application program identifier;
determining a plurality of sub-selectors and service selectors corresponding to the payment application program identification in a payment selector according to the payment request;
acquiring target configuration information corresponding to the payment application program identifier in each sub-selector of the plurality of sub-selectors, wherein the target configuration information in each sub-selector is different;
and loading the target configuration information into a service calling entity of the service selector, and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information to finish payment.
A second aspect of an embodiment of the present application discloses a payment device, including:
the system comprises a first acquisition unit, a second acquisition unit and a payment processing unit, wherein the first acquisition unit is used for acquiring a payment request sent by a user terminal, and the payment request carries a payment application program identifier;
a determining unit, configured to determine, in a payment selector, a plurality of sub-selectors and a service selector corresponding to the payment application identifier according to the payment request;
a second obtaining unit, configured to obtain, in each sub-selector of the multiple sub-selectors, target configuration information corresponding to the payment application identifier, where the target configuration information in each sub-selector is different;
and the calling unit is used for loading the target configuration information into a service calling entity of the service selector and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information so as to complete payment.
In a third aspect of embodiments of the present application, a server is disclosed, which includes a processor, a memory, and a network interface, where the processor, the memory, and the network interface are connected to each other, where the memory is used to store a computer program, and the computer program includes program instructions, and the processor is configured to call the program instructions to execute the method of the first aspect.
A fourth aspect of the embodiments of the present application discloses a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program includes program instructions, which, when executed by a processor, cause the processor to execute the method of the first aspect.
In the embodiment of the application, a server may obtain a payment request sent by a user terminal, where the payment request carries a payment application identifier, determine a plurality of sub-selectors and service selectors corresponding to the payment application identifier in a payment selector according to the payment request, further obtain target configuration information corresponding to the payment application identifier in each sub-selector of the plurality of sub-selectors, where the target configuration information in each sub-selector is different, load the target configuration information into a service invocation entity of the service selector, and invoke an interface corresponding to the payment application identifier by using the service invocation entity loaded with the target configuration information to complete payment. By implementing the method, the complexity of calling the payment interface can be reduced, the calling of the payment interface is simpler, and the payment is more convenient and faster.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic flow chart of a payment method provided in an embodiment of the present application;
fig. 2 is a schematic structural diagram illustrating a structure for loading target configuration information into a service invocation entity according to an embodiment of the present application;
FIG. 3 is a schematic flow chart diagram of another payment method provided by the embodiments of the present application;
fig. 4 is a schematic structural diagram of a payment device provided in an embodiment of the present application;
fig. 5 is a schematic structural diagram of a server according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Please refer to fig. 1, which is a flowchart illustrating a payment method according to an embodiment of the present disclosure. The payment method described in this embodiment is applied to a server, and includes the following steps:
s101: and acquiring a payment request sent by a user terminal, wherein the payment request carries a payment application program identifier.
The payment application identifier is used to indicate a payment method selected by a user through a user terminal, where the payment application identifier may be a number, a bit value, or other information, and the application is not limited. For example, table 1 shows the correspondence between the payment application id and the payment method. As can be seen from table 1, if the payment application identifier carried in the payment request received by the server is 1, it may be determined that the payment method selected by the user through the user terminal is payment method 1, and if the payment application identifier carried in the payment request received by the server is 2, it may be determined that the payment method selected by the user through the user terminal is payment method 2.
Table 1:
| payment application identification | Payment mode |
| 1 | Payment mode 1 |
| 2 | Payment mode 2 |
| 3 | Payment mode 3 |
| 4 | Payment mode 4 |
S102: a plurality of sub-selectors and service selectors corresponding to the payment application identification are determined in the payment selector according to the payment request.
The sub-selector may include a configuration selector, a payment type selector, and an order generation selector, and may further include other selectors, which are not limited in this application. Optionally, the sub-selector may be determined according to the payment application identifier, and the sub-selector corresponding to different payment application identifiers may be different, for example, if the payment application identifier is the target payment application identifier, the sub-selector may further include an open authentication system (OpenId) selector.
S103: and acquiring target configuration information corresponding to the payment application program identification in each sub-selector of the plurality of sub-selectors, wherein the target configuration information in each sub-selector is different.
In one implementation, the sub-selectors may include a configuration selector, a payment type selector, and an order generation selector, and the server may obtain target configuration information corresponding to the payment application identification from each sub-selector. Different sub-selectors and different configuration information configured in the sub-selectors exist, so that the target configuration information acquired by the server from each sub-selector also exists differently. For example, the server may obtain the target configuration item from the configuration selector, may obtain the target payment method from the payment type selector, and may obtain the order number from the order generation selector.
In one implementation, the server may obtain a target configuration item corresponding to the payment application identification in the configuration selector. Optionally, the configuration selector is configured with configuration items of multiple payment manners, for example, a correspondence between the payment application identifier and the configuration item is shown in table 2. As can be seen from table 2, if the payment application identifier carried in the payment request received by the server is 1, the target configuration item may be determined to be configuration item 1, and if the payment application identifier carried in the payment request received by the server is 2, the target configuration item may be determined to be configuration item 2. Optionally, the server may determine the target configuration item corresponding to the payment application identifier directly according to the corresponding relationship between the payment application identifier and the configuration item, or may determine the payment method according to the corresponding relationship between the payment application identifier and the payment method, and then determine the target configuration item corresponding to the payment application identifier according to the corresponding relationship between the payment method and the configuration item.
Table 2:
| payment application identification | Payment mode |
| 1 | Configuration item 1 |
| 2 | Configuration item 2 |
| 3 | Configuration item 3 |
| 4 | Configuration item 4 |
Optionally, the target configuration item may include a global configuration item and a sub-payment configuration item, where the global configuration item may be a configuration item that is common to different payment manners, for example, the global configuration item may include a test environment white list switch, a repeated payment verification switch, a recalculated amount verification switch, a number of payment failure retries, whether an order is expired, and the like, and may also be other configuration information, which is not limited in this application. The switch may be turned on when the server obtains the target configuration item, or may be turned on or off according to other conditions, which is not limited in the present application. The testing environment white list can be used to indicate that only the user is in the white list, the subsequent payment can be made, and if not, the payment function is not available. The sub-payment configuration item may be configuration information about the user, for example, may be official information provided by a certain payment method when the user opens the payment method, such as an Application Identification (app id), a merchant number, a merchant key, a callback notification domain name, and the like.
In one implementation, the server may obtain a target payment method corresponding to the payment application identification in the payment type selector. Optionally, the server may obtain, in the payment type selector, a target payment method enumeration corresponding to the payment application identifier. The payment type selector is configured with enumeration of each payment method class and enumeration of corresponding sub-payment methods, and it should be understood that the target payment method corresponding to the payment application program identifier in the present application is a sub-payment method corresponding to a certain payment method class. For example, the payment method category a includes a sub-payment method a1, a sub-payment method a2, a sub-payment method A3, and a sub-payment method a4, and assuming that the payment method corresponding to the payment application identifier is the sub-payment method a2, the server obtains, in the payment type selector, an enumeration that the target payment method corresponding to the payment application identifier is the sub-payment method a 2.
In one implementation, the server may obtain an order number corresponding to the payment application identification in an order generation selector. Specifically, the server may determine the target order generation rule corresponding to the payment application identifier, and then generate the order number according to the payment application identifier and the target order generation rule. Optionally, the order generation selector is configured with order generation rules of multiple payment manners, and then the target order generation rule corresponding to the payment application identifier may be determined according to a preset correspondence, where the payment request also carries data such as a user ID, a payment scenario, a timestamp, and a random character string. For example, the correspondence between the payment application identifier and the order generation rule pre-stored in the order generation selector may be determined, or may be determined according to the correspondence between the payment application identifier, the payment scenario, and the order generation rule pre-stored in the order generation selector. If the order generation selector stores the corresponding relationship between the payment application identifier and the order generation rule in advance, the target order generation rule corresponding to the payment application identifier may be obtained according to the corresponding relationship between the payment application identifier and the order generation rule. If the order generation selector stores the corresponding relationship among the payment application program identifier, the payment scene and the order generation rule in advance, the target order generation rule corresponding to the payment application program identifier can be obtained according to the corresponding relationship among the payment application program identifier, the payment scene and the order generation rule. Optionally, the order generation rule may also be one or more, for example, the order generation rule may be the first character of the pinyin of each word of the payment method name corresponding to the payment application identifier, followed by connecting the random character string and then connecting the time stamp, or the first character of the pinyin of each word of the payment method name corresponding to the payment application identifier, followed by connecting the time stamp and then connecting the user ID, or another order generation rule, which is not limited in this application.
In one implementation, the sub-selector may further include an OpenId selector, and the OpenId selector is configured with an OpenId. If the payment application program identifier is the payment application program identifier, the server can acquire the OpenId from the OpenId selector; if the payment application identification is not a payment application identification, then the server may not obtain the OpenId from the OpenId selector. For example, the server may detect whether the payment application identifier matches the target payment application identifier, obtain an OpenId corresponding to the payment application identifier in the OpenId selector if the detection result is that the payment application identifier matches the target payment application identifier, and may not obtain the OpenId from the OpenId selector if the detection result is that the payment application identifier does not match the target payment application identifier.
S104: and loading the target configuration information into a service calling entity of the service selector, and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information to finish payment.
In one implementation, the server may obtain a service invocation entity from the service selector according to the payment application identifier, where the service invocation entity has functions of obtaining a terminal IP, invoking a payment method interface, encrypting, and verifying a signature, so as to invoke the payment interface through the loaded service invocation entity subsequently. After the server acquires the target configuration information corresponding to each sub-selector according to the payment application identifier and acquires the service invocation entity in the service selector, the target configuration information may be loaded into the service invocation entity, for example, as shown in fig. 2, and the service invocation entity loaded with the target configuration information invokes an interface corresponding to the payment application identifier to complete payment.
In the embodiment of the application, a server may obtain a payment request sent by a user terminal, where the payment request carries a payment application identifier, determine a plurality of sub-selectors and service selectors corresponding to the payment application identifier in a payment selector according to the payment request, further obtain target configuration information corresponding to the payment application identifier in each sub-selector of the plurality of sub-selectors, where the target configuration information in each sub-selector is different, load the target configuration information into a service invocation entity of the service selector, and invoke an interface corresponding to the payment application identifier by using the service invocation entity loaded with the target configuration information to complete payment. By implementing the method, the complexity of calling the payment interface can be reduced, the calling of the payment interface is simpler, and the payment is more convenient and faster.
Please refer to fig. 3, which is a flowchart illustrating another payment method according to an embodiment of the present disclosure. The payment method described in this embodiment is applied to a server, and includes the following steps:
s301: a service invocation entity corresponding to the payment application identification is configured in the service selector.
In one implementation, a service invocation entity corresponding to the payment application identification may be configured in the service selector. The service calling entity can comprise an acquisition terminal IP, a calling payment mode interface, an encryption and signature checking function and other functions, and can be configured with other functions according to the requirement of calling the payment mode interface.
In an implementation manner, the service invocation entity configured in the service selector and corresponding to the payment application identifier may be a data packet in a specified format corresponding to the payment application identifier, such as a JAR packet, or an interface document corresponding to the payment application identifier, or may be a service invocation entity configured in the service selector and corresponding to the payment application identifier according to other manners, which is not limited in this application.
For example, a service invocation entity corresponding to the payment application program identifier may be configured in the service selector according to the data packet and the interface document in the specified format corresponding to the payment application program identifier, and a specific implementation manner may be to first determine whether the payment application program corresponding to the payment application program identifier has a data packet in the specified format, such as a JAR packet, and if the payment application program corresponding to the payment application program identifier has a data packet in the specified format, service information required for invoking the payment means interface may be acquired from the data packet in the specified format, for example, the service information may be an interface invocation manner, an encryption manner, or a signature verification manner. The service information is then encapsulated to obtain a service invocation entity, and the service invocation entity is configured into the service selector. Optionally, if the payment application program corresponding to the payment application program identifier does not have a data packet in a specified format, the interface document corresponding to the payment application program identifier may be obtained, the service information may be obtained from the interface document, then the service information may be encapsulated to obtain the service invocation entity, and then the service invocation entity is configured in the service selector.
S302: configuration information corresponding to the payment application identification is configured in each sub-selector.
In one implementation, the sub-selector may include a configuration selector, a payment type selector, and an order generation selector, and the server may determine that the payment application identifies a corresponding configuration item and configure the configuration item into the configuration selector; one or more payment methods corresponding to the payment application program identification can also be determined, and the one or more payment methods are configured into the payment type selector; an order generation rule corresponding to the payment application identification may also be determined and configured into an order generation selector.
In one implementation, the configuration selector configures configuration items of multiple payment methods, where the configuration items include a global configuration item and a sub-payment configuration item, where the global configuration item may be a configuration item common to different payment methods. For example, the global configuration item may include a white list switch of the testing environment, a repeated payment checking switch, a recalculated amount checking switch, a retry number of payment failures, a determination whether an order is expired, and the like, and may also be other configuration information, which is not limited in this application. The switch may be turned on when the server obtains the configuration item, or may be turned on or off according to other conditions, which is not limited in the present application. The testing environment white list can be used to indicate that only the user is in the white list, the subsequent payment can be made, and if not, the payment function is not available. The sub-payment configuration item may be configuration information about the user, for example, may be official information provided by a certain payment method when the user opens the payment method, such as an AppId, a merchant number, a merchant key, a callback notification domain name, and the like. Wherein the global configuration item and the sub-payment configuration items can be encapsulated using the encapsulated entity class. The configuration items can be directly obtained after the server obtains the payment request, and it should be noted that the data in the sub-configuration items can be configured in advance, or configured after the user sends the payment request through the user terminal.
In an implementation manner, the payment type selector configures multiple payment manners or enumerations corresponding to multiple payment manners, and considering that a payment manner may belong to a corresponding payment manner class, which has multiple sub-payment manners, where the payment manner is one of the sub-payment manners, for example, the payment manner a includes a payment manner a1, a payment manner a2, a payment manner A3, and a payment manner a4, when the payment type selector configures enumeration of a payment manner, enumeration of the payment manner class corresponding to a payment manner and enumeration of the payment sub-class corresponding to the payment manner class may be configured.
In an implementation manner, the order generation selector configures order generation rules corresponding to multiple payment manners, each payment manner may correspond to one order generation rule, or multiple payment manners correspond to one order generation rule, the order generation rules of multiple payment manners may be the same or different, and are not limited in this application. For example, the order generation rule may be the first character of the pinyin of each word of the payment name corresponding to the payment method, followed by the random character string and then the time stamp, or the first character of the pinyin of each word of the payment name corresponding to the payment method, followed by the time stamp and then the user ID, or other order generation rules.
In one implementation, the sub-selector may further include an OpenId selector, and the OpenId selector is configured with an OpenId.
In an implementation manner, if a new payment method is added to a payment system, a payment selector required for invoking the payment method interface may be correspondingly added to the payment system, the payment selector may include a service selector, and configuration information required for invoking the payment method interface is configured in the service selector, and in order to successfully invoke the payment method interface, other configuration information is also required, and according to a difference in function, the other configuration information may be configured to different selectors, and the payment selector may further include a configuration selector, a payment type selector, an order generation selector, and also may include other selectors.
In an implementation manner, if a new payment method is added to a payment system, a service selector corresponding to the new payment method may be added to the payment system, and configuration information required by the new payment method is added to each original sub-selector. For example, the sub-selector in the payment system includes a configuration selector, a payment type selector, and an order generation selector, and when the new payment method is the payment method B, a configuration item corresponding to the payment method B is added to the configuration selector, a payment method enumeration corresponding to the payment method B is added to the payment method selector, and an order generation rule corresponding to the payment method B is added to the order generation selector, where the order generation rule may be an original order generation rule or a newly designed order generation rule. It can be seen that splitting the whole payment into multiple selectors enables access to a third party payment mode to be simply accomplished by configuring the relevant contents of the payment into the various selectors when accessing a payment.
S303: and acquiring a payment request sent by a user terminal, wherein the payment request carries a payment application program identifier.
S304: a plurality of sub-selectors and service selectors corresponding to the payment application identification are determined in the payment selector according to the payment request.
S305: target configuration information corresponding to the payment application program identification is obtained in each sub-selector of the sub-selectors, wherein the target configuration information in each sub-selector is different.
S306: and loading the target configuration information into a service calling entity of the service selector, and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information to finish payment.
The specific implementation of steps S303 to S306 may refer to the specific description of steps S101 to S104 in the above embodiment, and is not described herein again.
In the embodiment of the application, the server may configure a service invocation entity corresponding to the payment application program identifier in the service selector, configure configuration information corresponding to the payment application program identifier in each sub-selector, then, the server may obtain a payment request sent by the user terminal, where the payment request carries the payment application program identifier, determine a plurality of sub-selectors and service selectors corresponding to the payment application program identifier in the payment selector according to the payment request, further, obtain target configuration information corresponding to the payment application program identifier in each sub-selector of the plurality of sub-selectors, where the target configuration information in each sub-selector is different, then, load the target configuration information into the service invocation entity of the service selector, and invoke an interface corresponding to the payment application program identifier by using the service invocation entity loaded with the target configuration information, to complete the payment. By implementing the method, the complexity of calling the payment interface can be reduced, the calling of the payment interface is simpler, and the payment is more convenient and faster.
Please refer to fig. 4, which is a schematic structural diagram of a payment device according to an embodiment of the present disclosure. The payment device includes:
a first obtaining unit 401, configured to obtain a payment request sent by a user terminal, where the payment request carries a payment application identifier;
a determining unit 402, configured to determine, in a payment selector, a plurality of sub-selectors and a service selector corresponding to the payment application identifier according to the payment request;
a second obtaining unit 403, configured to obtain, in each sub-selector of the multiple sub-selectors, target configuration information corresponding to the payment application identifier, where the target configuration information in each sub-selector is different;
a calling unit 404, configured to load the target configuration information into a service calling entity of the service selector, and call, by using the service calling entity loaded with the target configuration information, an interface corresponding to the payment application identifier, so as to complete payment.
In an implementation manner, the sub-selectors include a configuration selector, a payment type selector, and an order generation selector, and the second obtaining unit 403 is specifically configured to:
acquiring a target configuration item corresponding to the consumption information in the configuration selector;
acquiring a target payment mode corresponding to the payment application program identifier in the payment type selector;
and determining a target order generation rule corresponding to the payment application program identifier, and generating an order number in the order generation selector according to the payment application program identifier and the target order generation rule.
In an implementation manner, the sub-selector further includes an open authentication system OpenId selector, and the second obtaining unit 403 is specifically configured to:
detecting whether the payment application identification matches a target payment application identification;
and if the detection result is that the payment application program identifier is matched with the target payment application program identifier, acquiring the OpenId corresponding to the payment application program identifier in the OpenId selector.
In an implementation manner, the apparatus further includes a configuration unit 405, specifically configured to:
configuring a service invocation entity corresponding to the payment application program identification in the service selector;
configuring configuration information corresponding to the payment application identification in the respective sub-selectors.
In an implementation manner, the configuration unit 405 is specifically configured to:
judging whether a data packet in a specified format exists in the payment application program corresponding to the payment application program identifier;
and if the judgment result is that the payment application program corresponding to the payment application program identification has the data packet in the specified format, acquiring service information from the data packet in the specified format, packaging the service information to obtain a service calling entity, and configuring the service calling entity into the service selector.
In an implementation manner, the configuration unit 405 is further configured to:
if the judgment result is that the payment application program corresponding to the payment application program identifier does not have the data packet in the specified format, acquiring an interface document corresponding to the payment application program identifier;
and acquiring service information from the interface document, packaging the service information to obtain a service calling entity, and configuring the service calling entity into the service selector.
In one implementation, the sub-selectors include a configuration selector, a payment type selector, and an order generation selector, and the configuration unit 405 is specifically configured to:
determining a configuration item corresponding to the payment application program identification, and configuring the configuration item into the configuration selector;
determining one or more payment modes corresponding to the payment application program identification, and configuring the one or more payment modes into the payment type selector;
and determining an order generation rule corresponding to the payment application program identifier, and configuring the order generation rule into the order generation selector.
It can be understood that the functions of the functional units of the payment apparatus described in the embodiment of the present application may be specifically implemented according to the method in the embodiment of the method described in fig. 1 or fig. 3, and the specific implementation process may refer to the description related to the embodiment of the method in fig. 1 or fig. 3, and is not described herein again.
In this embodiment of the application, a first obtaining unit 401 obtains a payment request sent by a user terminal, where the payment request carries a payment application identifier, a determining unit 402 determines, in a payment selector, a plurality of sub-selectors and a service selector corresponding to the payment application identifier according to the payment request, a second obtaining unit 403 obtains, in each sub-selector of the plurality of sub-selectors, target configuration information corresponding to the payment application identifier, where the target configuration information in each sub-selector is different, and a calling unit 404 loads the target configuration information into a service calling entity of the service selector, and uses the service calling entity loaded with the target configuration information to call an interface corresponding to the payment application identifier, so as to complete payment. By implementing the method, the complexity of calling the payment interface can be reduced, the calling of the payment interface is simpler, and the payment is more convenient and faster.
Please refer to fig. 5, which is a schematic structural diagram of a server according to an embodiment of the present disclosure. The server described in this embodiment includes: a processor 501, a memory 502, and a network interface 503. The processor 501, the memory 502, and the network interface 503 may exchange data with each other.
The Processor 501 may be a Central Processing Unit (CPU), and may also be other general purpose processors, Digital Signal Processors (DSP), Application Specific Integrated Circuits (ASIC), Field-Programmable Gate arrays (FPGA) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, and so on. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 502 may include both read-only memory and random access memory, and provides program instructions and data to the processor 501. A portion of the memory 502 may also include non-volatile random access memory. Wherein, the processor 501, when calling the program instruction, is configured to perform:
acquiring a payment request sent by a user terminal, wherein the payment request carries a payment application program identifier;
determining a plurality of sub-selectors and service selectors corresponding to the payment application program identification in a payment selector according to the payment request;
acquiring target configuration information corresponding to the payment application program identifier in each sub-selector of the plurality of sub-selectors, wherein the target configuration information in each sub-selector is different;
and loading the target configuration information into a service calling entity of the service selector, and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information to finish payment.
In one implementation, the sub-selectors include a configuration selector, a payment type selector, and an order generation selector, and the processor 501 is specifically configured to:
obtaining a target configuration item corresponding to the payment application identification in the configuration selector;
acquiring a target payment mode corresponding to the payment application program identifier in the payment type selector;
and determining a target order generation rule corresponding to the payment application program identifier, and generating an order number in the order generation selector according to the payment application program identifier and the target order generation rule.
In an implementation manner, the sub-selector further includes an OpenId selector of an open authentication system, and the processor 501 is specifically configured to:
detecting whether the payment application identification matches a target payment application identification;
and if the detection result is that the payment application program identifier is matched with the target payment application program identifier, acquiring the OpenId corresponding to the payment application program identifier in the OpenId selector.
In one implementation, the processor 501 is further configured to:
configuring a service invocation entity corresponding to the payment application program identification in the service selector;
configuring configuration information corresponding to the payment application identification in the respective sub-selectors.
In one implementation, the processor 501 is specifically configured to:
judging whether a data packet in a specified format exists in the payment application program corresponding to the payment application program identifier;
and if the judgment result is that the payment application program corresponding to the payment application program identification has the data packet in the specified format, acquiring service information from the data packet in the specified format, packaging the service information to obtain a service calling entity, and configuring the service calling entity into the service selector.
In one implementation, the processor 501 is further configured to:
if the judgment result is that the payment application program corresponding to the payment application program identifier does not have the data packet in the specified format, acquiring an interface document corresponding to the payment application program identifier;
and acquiring service information from the interface document, packaging the service information to obtain a service calling entity, and configuring the service calling entity into the service selector.
In one implementation, the sub-selectors include a configuration selector, a payment type selector, and an order generation selector, and the processor 501 is specifically configured to:
determining a configuration item corresponding to the payment application program identification, and configuring the configuration item into the configuration selector;
determining one or more payment modes corresponding to the payment application program identification, and configuring the one or more payment modes into the payment type selector;
and determining an order generation rule corresponding to the payment application program identifier, and configuring the order generation rule into the order generation selector.
In a specific implementation, the processor 501 and the memory 502 described in this embodiment of the present application may execute the implementation described in the payment method provided in fig. 1 or fig. 3 in this embodiment of the present application, and may also execute the implementation of the payment apparatus described in fig. 4 in this embodiment of the present application, which is not described herein again.
In this embodiment of the present application, the processor 501 may obtain a payment request sent by a user terminal, where the payment request carries a payment application identifier, and then determine, in a payment selector, a plurality of sub-selectors and a service selector corresponding to the payment application identifier according to the payment request, and further obtain, in each sub-selector of the plurality of sub-selectors, target configuration information corresponding to the payment application identifier, where the target configuration information in each sub-selector is different, and then load the target configuration information into a service invocation entity of the service selector, and invoke, by using the service invocation entity after loading the target configuration information, an interface corresponding to the payment application identifier, so as to complete payment. By implementing the method, the complexity of calling the payment interface can be reduced, the calling of the payment interface is simpler, and the payment is more convenient and faster.
The embodiment of the present application also provides a computer-readable storage medium, in which program instructions are stored, and when the program is executed, some or all of the steps of the payment method in the corresponding embodiment of fig. 1 or fig. 3 may be included.
It should be noted that, for simplicity of description, the above-mentioned embodiments of the method are described as a series of acts or combinations, but those skilled in the art should understand that the present application is not limited by the order of acts described, as some steps may be performed in other orders or simultaneously according to the present application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.
Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by associated hardware instructed by a program, which may be stored in a computer-readable storage medium, and the storage medium may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.
The payment method, the payment device, the payment server and the storage medium provided by the embodiments of the present application are described in detail above, and a specific example is applied in the description to explain the principles and the embodiments of the present application, and the description of the above embodiments is only used to help understanding the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.
Claims (10)
1. A payment method, comprising:
acquiring a payment request sent by a user terminal, wherein the payment request carries a payment application program identifier;
determining a plurality of sub-selectors and service selectors corresponding to the payment application program identification in a payment selector according to the payment request;
acquiring target configuration information corresponding to the payment application program identifier in each sub-selector of the plurality of sub-selectors, wherein the target configuration information in each sub-selector is different;
and loading the target configuration information into a service calling entity of the service selector, and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information to finish payment.
2. The method of claim 1, wherein the sub-selectors comprise a configuration selector, a payment type selector, and an order generation selector; the obtaining target configuration information corresponding to the payment application identifier in each of the plurality of sub-selectors includes:
obtaining a target configuration item corresponding to the payment application identification in the configuration selector;
acquiring a target payment mode corresponding to the payment application program identifier in the payment type selector;
and determining a target order generation rule corresponding to the payment application program identifier, and generating an order number in the order generation selector according to the payment application program identifier and the target order generation rule.
3. The method of claim 1, wherein the sub-selectors further comprise an open authentication system (OpenId) selector; the obtaining target configuration information corresponding to the payment application identifier in each of the plurality of sub-selectors includes:
detecting whether the payment application identification matches a target payment application identification;
and if the detection result is that the payment application program identifier is matched with the target payment application program identifier, acquiring the OpenId corresponding to the payment application program identifier in the OpenId selector.
4. The method of claim 1, wherein before the obtaining the payment request sent by the user terminal, the method further comprises:
configuring a service invocation entity corresponding to the payment application program identification in the service selector;
configuring configuration information corresponding to the payment application identification in the respective sub-selectors.
5. The method of claim 4, wherein configuring a service invocation entity corresponding to the payment application identification in the service selector comprises:
judging whether a data packet in a specified format exists in the payment application program corresponding to the payment application program identifier;
and if the judgment result is that the payment application program corresponding to the payment application program identification has the data packet in the specified format, acquiring service information from the data packet in the specified format, packaging the service information to obtain a service calling entity, and configuring the service calling entity into the service selector.
6. The method of claim 5, further comprising:
if the judgment result is that the payment application program corresponding to the payment application program identifier does not have the data packet in the specified format, acquiring an interface document corresponding to the payment application program identifier;
and acquiring service information from the interface document, packaging the service information to obtain a service calling entity, and configuring the service calling entity into the service selector.
7. The method of claim 4, wherein the sub-selectors comprise a configuration selector, a payment type selector, and an order generation selector; the configuring, in each sub-selector, configuration information corresponding to the payment application identification includes:
determining a configuration item corresponding to the payment application program identification, and configuring the configuration item into the configuration selector;
determining one or more payment modes corresponding to the payment application program identification, and configuring the one or more payment modes into the payment type selector;
and determining an order generation rule corresponding to the payment application program identifier, and configuring the order generation rule into the order generation selector.
8. A payment device, comprising:
the system comprises a first acquisition unit, a second acquisition unit and a payment processing unit, wherein the first acquisition unit is used for acquiring a payment request sent by a user terminal, and the payment request carries a payment application program identifier;
a determining unit, configured to determine, in a payment selector, a plurality of sub-selectors and a service selector corresponding to the payment application identifier according to the payment request;
a second obtaining unit, configured to obtain, in each sub-selector of the multiple sub-selectors, target configuration information corresponding to the payment application identifier, where the target configuration information in each sub-selector is different;
and the calling unit is used for loading the target configuration information into a service calling entity of the service selector and calling an interface corresponding to the payment application program identifier by using the service calling entity loaded with the target configuration information so as to complete payment.
9. A server, comprising a processor, a memory, and a network interface, the processor, the memory, and the network interface being interconnected, wherein the memory is configured to store a computer program comprising program instructions, and wherein the processor is configured to invoke the program instructions to perform the method of any of claims 1-7.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions that, when executed by a processor, cause the processor to carry out the method according to any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011081303.2A CN112215593B (en) | 2020-10-10 | 2020-10-10 | Payment method, device, server and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011081303.2A CN112215593B (en) | 2020-10-10 | 2020-10-10 | Payment method, device, server and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112215593A true CN112215593A (en) | 2021-01-12 |
| CN112215593B CN112215593B (en) | 2024-04-09 |
Family
ID=74053183
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011081303.2A Active CN112215593B (en) | 2020-10-10 | 2020-10-10 | Payment method, device, server and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112215593B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114677138A (en) * | 2021-05-19 | 2022-06-28 | 腾讯云计算（北京）有限责任公司 | Data processing method, data processing equipment and computer readable storage medium |
| CN116402510A (en) * | 2023-04-14 | 2023-07-07 | 广东车卫士信息科技有限公司 | Non-inductive payment method, medium and equipment based on high concurrency network service |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140006257A1 (en) * | 2012-06-28 | 2014-01-02 | Martin Von Der Emde | Consistent Interface for Payment Order, Payment Order Processing Statement and Product Valuation Data |
| WO2015074409A1 (en) * | 2013-11-19 | 2015-05-28 | Tencent Technology (Shenzhen) Company Limited | Payment binding management method, payment server, client, and system |
| CN105830104A (en) * | 2013-08-14 | 2016-08-03 | 脸谱公司 | Methods and systems for facilitating e-commerce payments |
| CN106875186A (en) * | 2016-06-20 | 2017-06-20 | 阿里巴巴集团控股有限公司 | A kind of offline electronic payment method and apparatus |
| CN107103454A (en) * | 2017-04-25 | 2017-08-29 | 深圳创维－Rgb电子有限公司 | A kind of on-line payment method and system |
| CN109754234A (en) * | 2019-01-11 | 2019-05-14 | 北京顺丰同城科技有限公司 | A kind of polymerization method of payment and device |
| CN110533406A (en) * | 2019-09-04 | 2019-12-03 | 中国工商银行股份有限公司 | A kind of payment call method, apparatus and system |
| CN111738706A (en) * | 2020-06-23 | 2020-10-02 | 江苏苏宁银行股份有限公司 | Aggregated payment system, method and equipment |
-
2020
- 2020-10-10 CN CN202011081303.2A patent/CN112215593B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140006257A1 (en) * | 2012-06-28 | 2014-01-02 | Martin Von Der Emde | Consistent Interface for Payment Order, Payment Order Processing Statement and Product Valuation Data |
| CN105830104A (en) * | 2013-08-14 | 2016-08-03 | 脸谱公司 | Methods and systems for facilitating e-commerce payments |
| WO2015074409A1 (en) * | 2013-11-19 | 2015-05-28 | Tencent Technology (Shenzhen) Company Limited | Payment binding management method, payment server, client, and system |
| CN106875186A (en) * | 2016-06-20 | 2017-06-20 | 阿里巴巴集团控股有限公司 | A kind of offline electronic payment method and apparatus |
| CN107103454A (en) * | 2017-04-25 | 2017-08-29 | 深圳创维－Rgb电子有限公司 | A kind of on-line payment method and system |
| CN109754234A (en) * | 2019-01-11 | 2019-05-14 | 北京顺丰同城科技有限公司 | A kind of polymerization method of payment and device |
| CN110533406A (en) * | 2019-09-04 | 2019-12-03 | 中国工商银行股份有限公司 | A kind of payment call method, apparatus and system |
| CN111738706A (en) * | 2020-06-23 | 2020-10-02 | 江苏苏宁银行股份有限公司 | Aggregated payment system, method and equipment |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114677138A (en) * | 2021-05-19 | 2022-06-28 | 腾讯云计算（北京）有限责任公司 | Data processing method, data processing equipment and computer readable storage medium |
| CN116402510A (en) * | 2023-04-14 | 2023-07-07 | 广东车卫士信息科技有限公司 | Non-inductive payment method, medium and equipment based on high concurrency network service |
| CN116402510B (en) * | 2023-04-14 | 2024-01-30 | 广东车卫士信息科技有限公司 | Non-inductive payment method, medium and equipment based on high concurrency network service |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112215593B (en) | 2024-04-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109492378B (en) | Identity verification method based on equipment identification code, server and medium | |
| WO2022016847A1 (en) | Automatic test method and device applied to cloud platform | |
| US20010005885A1 (en) | Cryptographic policy filters and policy control method and apparatus | |
| US20160378990A1 (en) | Validating firmware on a computing device | |
| US20200264863A1 (en) | Hot update method, operating system, terminal device, and storage medium | |
| CN109299015B (en) | Software testing method, device and system | |
| US20230269103A1 (en) | Blockchain-based user information processing method and system | |
| CN111177003A (en) | Test method, device, system, electronic equipment and storage medium | |
| CN110806971A (en) | Version testing method and device and electronic equipment | |
| CN112215593B (en) | Payment method, device, server and storage medium | |
| RU2734027C2 (en) | Method and device for preventing an attack on a server | |
| EP3659058A1 (en) | Devices and methods for key attestation with multiple device certificates | |
| CN109145651B (en) | Data processing method and device | |
| CN112383402B (en) | Dual idempotent verification method and server | |
| CN112000853B (en) | Method for generating/feeding back unique identifier of equipment, medium, client and server | |
| CN114546837A (en) | Interface test method, device, equipment and storage medium | |
| CN112788017B (en) | Security verification method, device, equipment and medium | |
| CN114237821A (en) | Self-discovery method and device for Kubernetes container cluster, electronic device and storage medium | |
| CN112559352A (en) | Interface test method, device, equipment and storage medium | |
| CN113886894A (en) | Digital signature method and digital signature device | |
| CN111158935B (en) | Application program detection method and device, computer equipment and storage medium | |
| CN114039873B (en) | Audit method and operation and maintenance security audit system aiming at client type | |
| CN112261051B (en) | User registration method, device and system | |
| CN111309410B (en) | Program object determining method and device | |
| CN114615008B (en) | Method and device for controlling black-and-white lists of mass storage distributed system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |