CN114677131A - Payment method, device and equipment - Google Patents

Payment method, device and equipment Download PDF

Info

Publication number
CN114677131A
CN114677131A CN202210305441.7A CN202210305441A CN114677131A CN 114677131 A CN114677131 A CN 114677131A CN 202210305441 A CN202210305441 A CN 202210305441A CN 114677131 A CN114677131 A CN 114677131A
Authority
CN
China
Prior art keywords
payment
order
merchant
user
serial number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210305441.7A
Other languages
Chinese (zh)
Inventor
周健
赵大成
吴昊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Priority to CN202210305441.7A priority Critical patent/CN114677131A/en
Publication of CN114677131A publication Critical patent/CN114677131A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • 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
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The embodiment of the specification discloses a payment method, a payment device and payment equipment. And the user regenerates a unique identifier DOI of the digital object according to the order serial number of the payment order and the user identification of the user aiming at the payment order with unknown result, and the unique identifier DOI is provided for the merchant to scan. After the merchant scans, the order number, the amount, the user identification, the merchant identification and the like are sent to the payment platform together. When the payment platform processes the order, whether the business is processed or not is judged according to the order serial number, and repeated payment is avoided.

Description

Payment method, device and equipment
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a payment method, device, and apparatus.
Background
With the popularization of mobile payment, the mobile code scanning payment has wider and wider application range.
In the prior art, the payment of the customer and the merchant on the payment platform may not be immediately checked due to various conditions such as network, equipment and the like. If the merchant requires repeated payment at this time, and the user is worried about receiving more money, the user can only wait or give up the purchase, which affects the experience of both parties.
Based on this, a more convenient payment scheme is needed.
Disclosure of Invention
The embodiment of the specification provides a payment method, a payment device and payment equipment, which are used for solving the following problems: to provide a more convenient payment scheme.
Based on this, this specification embodiment provides a payment method, including:
the user client acquires an order serial number and a user identification corresponding to the payment order with the unknown result;
generating a digital object unique identifier DOI comprising the order serial number and the user identification;
and displaying the DOI so that the merchant scans the DOI to retry payment.
Meanwhile, another payment method is also provided in an embodiment of the present specification, including:
a merchant client scans a DOI (digital object unique identifier) displayed by a user client to acquire a user identifier and an order serial number contained in the DOI, wherein the DOI is generated after the user client confirms that a payment order execution result is unknown;
acquiring merchant identification and transaction amount;
generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and sending the payment order to the server side so that the server side can pay.
Meanwhile, an embodiment of the present specification further provides another payment method, including:
the server receives a payment order sent by a merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
and judging whether a paid order with the same order serial number exists or not, if not, executing the payment according to the user identification, the merchant identification and the transaction amount, and if so, not executing the payment.
Correspondingly, the embodiments of this specification also provide a payment device, including:
the acquisition module is used for acquiring an order serial number and a user identification corresponding to the payment order with the unknown result by the user client;
the generating module generates a digital object unique identifier DOI containing the order serial number and the user identification;
and the display module displays the DOI so that the merchant scans the DOI to retry payment.
Meanwhile, embodiments of the present specification also provide another payment apparatus, including:
the system comprises a scanning module, a merchant client, a payment module and a payment module, wherein the merchant client scans a DOI (digital object unique identifier) displayed by a user client to obtain a user identifier and an order serial number contained in the DOI, and the DOI is generated by the user client after confirming that a payment order execution result is unknown;
the acquisition module acquires a merchant identifier and a transaction amount;
the generation module generates a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and the sending module is used for sending the payment order to the server so that the server can pay.
Meanwhile, embodiments of the present specification also provide another payment apparatus, including:
the system comprises a receiving module and a service end, wherein the service end receives a payment order sent by a merchant client, and the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
a judging module for judging whether the paid order with the same order serial number exists or not,
and the payment module does not execute the payment if the payment module exists, and executes the payment according to the user identification, the merchant identification and the transaction amount if the payment module does not exist.
Correspondingly, the embodiments of this specification also provide a payment device, including:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
the user client acquires an order serial number and a user identification corresponding to the payment order with the unknown result;
generating a digital object unique identifier DOI comprising the order serial number and the user identification;
and displaying the DOI so that the merchant scans the DOI to retry payment.
Meanwhile, embodiments of the present specification further provide another payment device, including:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
a merchant client scans a DOI (digital object unique identifier) displayed by a user client to acquire a user identifier and an order serial number contained in the DOI, wherein the DOI is generated after the user client confirms that a payment order execution result is unknown;
acquiring merchant identification and transaction amount;
generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and sending the payment order to the server side so that the server side can pay.
Meanwhile, an embodiment of the present specification further provides another payment apparatus, including:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
the server receives a payment order sent by a merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
and judging whether a paid order with the same order serial number exists or not, if not, executing the payment according to the user identification, the merchant identification and the transaction amount, and if so, not executing the payment.
Correspondingly, embodiments of the present specification also provide a non-volatile computer storage medium storing computer-executable instructions configured to:
the user client acquires an order serial number and a user identification corresponding to the payment order with the unknown result;
generating a digital object unique identifier DOI containing the order serial number and the user identification;
and displaying the DOI so that the merchant scans the DOI to retry payment.
Meanwhile, embodiments of the present specification also provide another non-volatile computer storage medium storing computer-executable instructions configured to:
a merchant client scans a DOI (digital object unique identifier) displayed by a user client to acquire a user identifier and an order serial number contained in the DOI, wherein the DOI is generated after the user client confirms that a payment order execution result is unknown;
acquiring merchant identification and transaction amount;
generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and sending the payment order to the server side so that the server side can pay.
Meanwhile, embodiments of the present specification also provide a non-volatile computer storage medium storing computer-executable instructions configured to:
the server receives a payment order sent by a merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
and judging whether a paid order with the same order serial number exists or not, if not, executing the payment according to the user identification, the merchant identification and the transaction amount, and if so, not executing the payment.
The embodiment of the specification adopts at least one technical scheme which can achieve the following beneficial effects:
aiming at a payment order with unknown result (namely, for a certain payment order, the server does not return a payment result after a certain time, and the user and a merchant do not know success or failure), the user regenerates a digital object unique identifier DOI according to the order serial number of the payment order and the user identification of the user, and provides the digital object unique identifier DOI for the merchant to scan. After the merchant scans, the order number, the amount, the user identification, the merchant identification and the like are sent to the payment platform together. When the payment platform processes the order, whether the business is processed or not is judged according to the order serial number, repeated payment is avoided, and user experience is improved. In addition, before payment, the user can check the order number again according to the merchant information and/or the creation time contained in the order number, so that the payment system is safer.
Drawings
FIG. 1a is a schematic diagram of a prompt message issued by a payment application for a payment order of unknown outcome;
FIG. 1b is a schematic diagram of an overall process flow according to an embodiment of the present disclosure;
FIG. 2 is a schematic flow chart diagram illustrating aspects of a user client provided by an embodiment of the present disclosure;
FIG. 3 is a schematic flow chart diagram of aspects of a merchant client provided by an embodiment of the present description;
FIG. 4 is a flow diagram illustrating aspects of a server provided by an embodiment of the present disclosure;
FIG. 5 is a schematic diagram of a payment device on the part of a user provided in an embodiment of the present specification;
fig. 6 is a schematic structural diagram of a payment device on the side of a merchant according to an embodiment of the present specification;
fig. 7 is a schematic structural diagram of a payment device on the merchant side according to an embodiment of the present specification.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step are within the scope of the present application.
It is currently common to make payments using Digital Object Identifiers (DOIs). The DOI may be in a form such as a barcode, a two-dimensional code, or the like. When a user scans a code to create a payment order for payment, a payment result may not be obtained later due to poor network, equipment problems, and the like, as shown in fig. 1a, where fig. 1a is a schematic diagram of a payment application sending out prompt information for a payment order with unknown result. At this point, it is possible that the payment order has been successful in the background of the payment server, but is not visible to both the merchant and the customer. If the customer is rescanned or the merchant is rescanned to the user, the customer may be paid twice the price. In such a situation where both parties cannot immediately confirm the payment result, a second payment is often required, and repeated payments need to be avoided in the process.
Based on this, the embodiments of the present specification provide a payment scheme, where a user code scanning merchant generates a payment order and sends the payment order to a server, but a payment result is unknown, a user generates a two-dimensional code, and then the two-dimensional code is handed to the merchant to scan and generate another payment order containing the same order serial number, so as to perform a retry payment. The server side judges according to the order serial number, the user can not be charged more money, the payment success can be guaranteed, the merchant can collect money successfully, and the user experience is improved.
It should be noted that, before the solution provided by the embodiment of the present specification, a payment has been made in advance by scanning the DOI provided by the merchant, and the status is prompted to be unknown. As shown in fig. 1b, fig. 1b is a schematic diagram of an overall execution flow according to an embodiment of the present disclosure. In the framework, each client and server is located on the corresponding terminal device. If the user client and the merchant client do not receive the success or failure information returned by the server within a certain time, the user client determines that the payment order is in an unknown state, and the user clicks the're-transaction' displayed on the user terminal, namely, the scheme provided by the specification is entered.
Specifically, the scheme includes three aspects, namely, a user client, a merchant client, and a server, for the aspect of the user client, as shown in fig. 2, fig. 2 is a schematic flow diagram of the aspect of the user client provided in the embodiment of the present specification, and the schematic flow diagram includes:
s201, the user client side obtains an order serial number and a user identification corresponding to the payment order with the unknown result.
The order number is generated by the user when scanning the DOI provided by the merchant, and is typically a string of numbers of fixed length that uniquely identifies the payment order. In other words, the order number is not repeated each time the user scans the code to create a transaction. The current time, the user ID, and the merchant ID may be included in the calculation factor in the generation method, that is, the genecode (user ID, merchant ID, current time) may achieve this goal. The user then enters an amount to pay. And the order serial number information can be stored locally and deleted after the transaction result is returned by the server. It is easy to understand that the current time is the creation time of the order number.
When the server side does not return the transaction result all the time, the user client side sends a prompt as shown in fig. 1 at this time, receives a payment retry instruction of the user, and obtains the order number from the local. The user identification may be, for example, a user ID, a mobile phone number, and the like, and may be directly obtained through the user client.
S203, generating a digital object unique identifier DOI containing the order serial number and the user identification.
That is, after receiving an instruction sent by a user to retry payment, a readable DOI is generated in the user client according to the order number and the user identifier based on a preset algorithm.
S205, displaying the DOI so that a merchant can scan the DOI to retry payment, wherein the payment order with the unknown result is generated in advance by the user client and is sent to the server.
As a specific application, the order number may include specific information of creation time, user ID, and merchant ID. In other words, the algorithm for generating the order serial number may be a reversible encryption algorithm, and the server may obtain the creation time, the user ID, and the merchant ID information included in the order serial number by using a corresponding decryption algorithm when obtaining the order serial number, so that other further security verification may be performed.
For the implementation steps of the merchant client, as shown in fig. 3, fig. 3 is a schematic flow chart of the merchant client according to the embodiment of the present disclosure, including:
s301, a merchant client scans a DOI (digital object unique identifier) displayed by a user client to obtain a user identifier and an order number contained in the DOI, wherein the DOI is generated by the user client after confirming that a payment order execution result is unknown.
S303, acquiring a merchant identifier and transaction amount;
the transaction amount may be derived from manual revenue input and the merchant identification may be automatically obtained by the merchant client from the payment application, as may the user identification, such as a user ID, mobile phone number, etc.
S305, generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount.
Specifically, the payment order generated at this time and the payment order generated by the previous user are two payment orders generated for the same transaction. In the two payment orders, the user identification, the order serial number, the merchant identification and the transaction amount are all the same. That is, the two orders are not distinguished from each other when viewed by the server, and the server can process any one of the orders when the order arrives. Of course, other information may also be included in the payment order, such as the time of generation of the payment order. The two orders are clearly different in generation time.
S307, the payment order is sent to the server side so that the server side can pay.
As for the execution steps of the server side aspect, as shown in fig. 4, fig. 4 is a schematic flow chart of the server side aspect provided in the embodiment of the present specification, and includes:
s401, the server receives a payment order sent by the merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount.
And S403, judging whether the paid order with the same order serial number exists or not, if not, executing the payment according to the user identifier, the merchant identifier and the transaction amount, and if so, not executing the payment.
It will be readily appreciated that the server itself has a database that can be invoked to store historical orders that have been successfully paid. When a payment order is received by the server, the transaction corresponding to the payment order may have two states:
first, there has been a payment order to complete payment for the transaction. At this time, the server may query the paid order with the same order number from the history database, so as to determine that the order is a repeat transaction, and not process the order. And, the information of successful payment can be returned to the clients of both parties.
Second, no payment order completes payment for the transaction. Then the server cannot query the historical database for paid orders with the same order number. Therefore, the server side can process the payment order, complete payment, return successful payment information to the client sides of the two sides, and store the payment order information to the historical database. In this case, when the server receives the payment order initiated by the user before, the server can also determine that the payment order is a paid order according to the order number, and does not perform any further processing.
Thus, the server will only make one payment process regardless of the order of arrival of the two orders. When the user and the merchant both submit the same payment request because the result is unknown, repeated payment is avoided, and the user experience is improved.
In addition, in practical application, in order to avoid that a malicious user evades payment (for example, when the user pays at a merchant a, the user intentionally fails first, then generates a two-dimensional code, succeeds in payment, and captures the two-dimensional code, then the merchant B also intentionally fails, and then uses the two-dimensional code captured with the image to pay, at this time, the server side judges that the payment has succeeded according to the order number in the two-dimensional code, and returns a payment success message, but actually does not execute a deduction), further security verification can be performed before payment is to be performed after the server side judges that the payment order is not a repeated payment.
As mentioned above, the order number may be generated by using a reversible encryption algorithm according to information such as user identification, merchant identification, creation time, and the like. Therefore, the server can avoid the malicious user by using the information of the merchant identification and/or the creation time contained in the order serial number.
For the method for avoiding the malicious user by adopting the merchant identification, the method comprises the following steps: judging whether the merchant identification contained in the payment order is the same as another merchant identification in the order serial number or not; and if the user identification, the merchant identification and the transaction amount are the same, executing the payment according to the user identification, the merchant identification and the transaction amount. That is, the merchant identifier contained in the order serial number is obtained by adopting a decryption algorithm, and is compared with the merchant identifier in the transaction order to determine whether the merchant identifier is the same. And if the order serial numbers are not repeated and the merchant identifications are the same, the payment is carried out. If the merchant identifications are different, payment is not carried out any more, and the payment safety is improved.
In practical application, a malicious user can be avoided according to the creation time contained in the order number, and the method comprises the following steps: determining a local receipt time for the payment order; calculating a time interval of the receiving time and the creating time; and judging whether the time interval does not exceed a threshold value, and if not, executing the payment according to the user identification, the merchant identification and the transaction amount.
That is, a time-to-live limit (e.g., one minute set empirically) is set for each order number, and if the time from creation to transmission to the server is exceeded for any order number, it is determined that the order number is invalid. For the payment order which is not repeatedly paid, the order serial number of the payment order is required to be paid within the validity period, otherwise, the server side does not execute payment any more, and the payment safety is improved.
Obviously, the server may also perform the above two security verification methods simultaneously. In addition, at the server, other information such as user identification and transaction amount can be adopted for further auxiliary verification, and the safety performance is further improved.
Based on the same idea, the present invention further provides a payment apparatus, as shown in fig. 5, where fig. 5 is a schematic structural diagram of a payment apparatus on the user side provided in an embodiment of this specification, and includes:
an obtaining module 501, configured to obtain, by a user client, an order serial number and a user identifier corresponding to a payment order with an unknown result;
a generating module 503, configured to generate a digital object unique identifier DOI including the order number and the user identifier;
and a display module 505 for displaying the DOI so that the merchant scans the DOI to retry payment.
Further, the order number includes information of the user identifier, the merchant identifier, and the creation time.
Meanwhile, another payment apparatus is provided in an embodiment of the present specification, as shown in fig. 6, fig. 6 is a schematic structural diagram of a payment apparatus on the merchant side provided in the embodiment of the present specification, and includes:
a scanning module 601, where a merchant client scans a digital object unique identifier DOI displayed by a user client to obtain a user identifier and an order number included in the DOI, where the DOI is generated by the user client after confirming that a payment order execution result is unknown;
the obtaining module 603 obtains a merchant identifier and a transaction amount;
a generating module 605, configured to generate a payment order including the user identifier, the order serial number, the merchant identifier, and the transaction amount;
the sending module 607 sends the payment order to the server, so that the server can make payment.
Meanwhile, an embodiment of the present specification further provides another payment apparatus, as shown in fig. 7, fig. 7 is a schematic structural diagram of a payment apparatus on the aspect of a merchant provided by an embodiment of the present specification, and includes:
a receiving module 701, in which a server receives a payment order sent by a merchant client, where the payment order at least includes a user identifier, an order serial number, a merchant identifier, and a transaction amount;
the determining module 703 determines whether there is a paid order with the same order number;
and the payment module 705 does not execute the payment if the user identifier, the merchant identifier and the transaction amount exist, and executes the payment if the user identifier, the merchant identifier and the transaction amount do not exist.
Further, when the order serial number includes another merchant identification information, the payment module 705 determines whether the merchant identification included in the payment order is the same as another merchant identification in the order serial number; and if the user identification, the merchant identification and the transaction amount are the same, executing the payment according to the user identification, the merchant identification and the transaction amount.
Further, when the order serial number includes creation time information, the payment module 705 determines local reception time for the payment order, calculates a time interval between the reception time and the creation time, determines whether the time interval does not exceed a threshold, and if the time interval does not exceed the threshold, executes the payment according to the user identifier, the merchant identifier, and the transaction amount.
Correspondingly, the embodiment of the present application further provides a payment device, including:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
the user client acquires an order serial number and a user identification corresponding to the payment order with the unknown result;
generating a digital object unique identifier DOI comprising the order serial number and the user identification;
and displaying the DOI so that the merchant scans the DOI to retry payment.
Meanwhile, an embodiment of the present specification further provides another payment apparatus, including:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
a merchant client scans a DOI (digital object unique identifier) displayed by a user client to acquire a user identifier and an order serial number contained in the DOI, wherein the DOI is generated after the user client confirms that a payment order execution result is unknown;
acquiring merchant identification and transaction amount;
generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and sending the payment order to the server side so that the server side can pay.
Meanwhile, an embodiment of the present specification further provides another payment apparatus, including:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
the server receives a payment order sent by a merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
and judging whether a paid order with the same order serial number exists or not, if not, executing the payment according to the user identification, the merchant identification and the transaction amount, and if so, not executing the payment.
Based on the same inventive concept, embodiments of the present application further provide a corresponding non-volatile computer storage medium, in which computer-executable instructions are stored, where the computer-executable instructions are configured to:
the user client acquires an order serial number and a user identification corresponding to the payment order with the unknown result;
generating a digital object unique identifier DOI comprising the order serial number and the user identification;
and displaying the DOI so that the merchant scans the DOI to retry payment.
Based on the same inventive concept, the embodiment of the present application further provides another corresponding non-volatile computer storage medium, in which computer-executable instructions are stored, where the computer-executable instructions are set as:
a merchant client scans a DOI (digital object unique identifier) displayed by a user client to acquire a user identifier and an order serial number contained in the DOI, wherein the DOI is generated after the user client confirms that a payment order execution result is unknown;
acquiring merchant identification and transaction amount;
generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and sending the payment order to the server side so that the server side can pay.
Based on the same inventive concept, the embodiment of the present application further provides another corresponding non-volatile computer storage medium, in which computer-executable instructions are stored, where the computer-executable instructions are configured to:
the server receives a payment order sent by a merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
and judging whether a paid order with the same order serial number exists or not, if not, executing the payment according to the user identification, the merchant identification and the transaction amount, and if so, not executing the payment.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. Especially, as for the device, apparatus and medium type embodiments, since they are basically similar to the method embodiments, the description is simple, and the related points may refer to part of the description of the method embodiments, which is not repeated here.
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 or modules 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.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium that stores computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be regarded as a hardware component and the means for performing the various functions included therein may also be regarded as structures within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
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 units may be implemented in the same software and/or hardware or in one or more pieces of software and/or hardware when implementing the embodiments 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 has been 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.
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 computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include transitory computer readable media (transient media) such as modulated data signal numbers and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description 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 so forth) having computer-usable program code embodied therein.
Embodiments of the present 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 transactions or implement particular abstract data types. Embodiments of the present description may also be practiced in distributed computing environments where transactions 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.

Claims (14)

1. A payment method, comprising:
the user client acquires an order serial number and a user identification corresponding to the payment order with the unknown result; the payment order with the unknown result is generated by scanning the payment code by the user client side, and is sent to the server side, so that the payment result of the order with the unknown result is sent to the server side;
generating a digital object unique identifier DOI comprising the order serial number and the user identification;
and displaying the DOI so that a merchant client scans the DOI to retry payment, and the DOI is sent to the server after being scanned by the merchant client so that the server judges whether the paid order with the same order serial number exists.
2. The method as claimed in claim 1, wherein the order number comprises information of the user identifier, the merchant identifier and the creation time.
3. The method of claim 1, wherein the payment order has an order number that is unique, and wherein the order number information is stored locally at the user client.
4. A payment method, comprising:
a merchant client scans a digital object unique identifier DOI displayed by a user client to obtain a user identifier and an order sequence number contained in the DOI, wherein the DOI is generated by the user client after confirming that a payment order execution result is unknown;
acquiring merchant identification and transaction amount;
generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and sending the payment order to the server side so that the server side can pay.
5. A payment method, comprising:
the server receives a payment order sent by a merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount; the payment order is an order with an unknown payment result, the payment order with the unknown result is generated by scanning a payment code by the user client, and the payment order with the unknown result is sent to the server side and then is sent to the order with the unknown payment result;
and judging whether a paid order with the same order serial number exists or not, if not, executing the payment according to the user identification, the merchant identification and the transaction amount, and if so, not executing the payment.
6. The method according to claim 5, wherein when the order number includes another merchant identification information, if the order number does not exist, the payment is executed according to the user identification, the merchant identification and the transaction amount, further comprising:
judging whether the merchant identification contained in the payment order is the same as another merchant identification in the order serial number or not;
and if the user identification, the merchant identification and the transaction amount are the same, executing the payment according to the user identification, the merchant identification and the transaction amount.
7. The method according to claim 5, when the order serial number includes creation time information, if the order serial number does not exist, the payment is executed according to the user identifier, the merchant identifier and the transaction amount, further comprising:
determining a local receipt time for the payment order;
calculating a time interval of the receiving time and the creating time;
and judging whether the time interval does not exceed a threshold value, and if not, executing the payment according to the user identification, the merchant identification and the transaction amount.
8. The method of claim 5, further comprising:
the server side is provided with a database, and the database is used for storing the historical orders of successful payment.
9. A payment device, comprising:
the acquisition module is used for acquiring an order serial number and a user identification corresponding to the payment order with the unknown result by the user client; the payment order with unknown result is an order with unknown payment result, which is generated by scanning payment codes by the user client and is sent to the server;
the generating module generates a digital object unique identifier DOI containing the order serial number and the user identification;
and the display module is used for displaying the DOI so that a merchant client scans the DOI to retry payment, and the DOI is sent to the server after being scanned by the merchant client so that the server judges whether paid orders with the same order serial number exist or not.
10. A payment device, comprising:
the system comprises a scanning module, a merchant client, a payment module and a payment module, wherein the merchant client scans a DOI (digital object unique identifier) displayed by a user client to obtain a user identifier and an order serial number contained in the DOI, and the DOI is generated by the user client after confirming that a payment order execution result is unknown;
the acquisition module acquires a merchant identifier and a transaction amount;
the generation module generates a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and the sending module is used for sending the payment order to the server so as to facilitate the payment of the server.
11. A payment device, comprising:
the system comprises a receiving module and a service end, wherein the service end receives a payment order sent by a merchant client, and the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
a judging module for judging whether the paid order with the same order serial number exists or not,
and the payment module does not execute the payment if the payment module exists, and executes the payment according to the user identification, the merchant identification and the transaction amount if the payment module does not exist.
12. A payment device, comprising:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
the user client acquires an order serial number and a user identification corresponding to the payment order with the unknown result; the payment order with unknown result is an order with unknown payment result, which is generated by scanning payment codes by the user client and is sent to the server;
generating a digital object unique identifier DOI comprising the order serial number and the user identification;
and displaying the DOI so that a merchant client scans the DOI to retry payment, and the DOI is sent to the server after being scanned by the merchant client so that the server judges whether the paid order with the same order serial number exists.
13. A payment device, comprising:
a memory storing a payment program;
a processor that invokes the payment program in the memory and performs:
a merchant client scans a DOI (digital object unique identifier) displayed by a user client to acquire a user identifier and an order serial number contained in the DOI, wherein the DOI is generated after the user client confirms that a payment order execution result is unknown;
acquiring merchant identification and transaction amount;
generating a payment order containing the user identification, the order serial number, the merchant identification and the transaction amount;
and sending the payment order to the server side so that the server side can pay.
14. A payment device, comprising:
a memory storing a payment program;
a processor calling the payment program in the memory and executing:
the server receives a payment order sent by a merchant client, wherein the payment order at least comprises a user identifier, an order serial number, a merchant identifier and a transaction amount;
and judging whether a paid order with the same order serial number exists or not, if not, executing the payment according to the user identification, the merchant identification and the transaction amount, and if so, not executing the payment.
CN202210305441.7A 2018-05-31 2018-05-31 Payment method, device and equipment Pending CN114677131A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210305441.7A CN114677131A (en) 2018-05-31 2018-05-31 Payment method, device and equipment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210305441.7A CN114677131A (en) 2018-05-31 2018-05-31 Payment method, device and equipment
CN201810548007.5A CN109003071B (en) 2018-05-31 2018-05-31 Payment method, device and equipment

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201810548007.5A Division CN109003071B (en) 2018-05-31 2018-05-31 Payment method, device and equipment

Publications (1)

Publication Number Publication Date
CN114677131A true CN114677131A (en) 2022-06-28

Family

ID=64573328

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202210305441.7A Pending CN114677131A (en) 2018-05-31 2018-05-31 Payment method, device and equipment
CN201810548007.5A Active CN109003071B (en) 2018-05-31 2018-05-31 Payment method, device and equipment

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201810548007.5A Active CN109003071B (en) 2018-05-31 2018-05-31 Payment method, device and equipment

Country Status (1)

Country Link
CN (2) CN114677131A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024152846A1 (en) * 2023-01-18 2024-07-25 支付宝(杭州)信息技术有限公司 Payment processing method and apparatus

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109815256A (en) * 2018-12-21 2019-05-28 聚好看科技股份有限公司 A kind of data processing method, device, electronic equipment and storage medium
CN109922132B (en) * 2019-01-18 2023-04-11 深圳壹账通智能科技有限公司 Form request processing method and device, electronic equipment and storage medium
CN112256480A (en) * 2020-10-22 2021-01-22 全知科技(杭州)有限责任公司 Method for controlling correct service of data repeat request
CN112288533A (en) * 2020-10-30 2021-01-29 云账户技术(天津)有限公司 Payment order fusing protection method and device and electronic equipment
CN113822676A (en) * 2021-10-11 2021-12-21 中国银行股份有限公司 Repeated payment control method and device for aggregated payment cashier desk
CN117787961B (en) * 2024-01-08 2024-06-25 深圳芥舟科技有限公司 Payment ticket business integrated management method and system

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102567877A (en) * 2011-12-01 2012-07-11 福建新大陆电脑股份有限公司 Field payment method, equipment and system
US20150120574A1 (en) * 2013-10-30 2015-04-30 Tencent Technology (Shenzhen) Company Limited Information transmission method, apparatus and system
US20160034862A1 (en) * 2014-07-31 2016-02-04 Ncr Corporation Dynamic network timeout tuning
CN105512869A (en) * 2015-11-26 2016-04-20 中国建设银行股份有限公司 Repeated payment-prevention payment system, method and E-commerce system
CN106296143A (en) * 2015-06-29 2017-01-04 阿里巴巴集团控股有限公司 The electronic trade method of a kind of high availability, Apparatus and system
CN106600269A (en) * 2016-12-28 2017-04-26 中国民生银行股份有限公司 Paying method and platform based on two-dimensional barcode
CN106651333A (en) * 2016-09-20 2017-05-10 联动优势电子商务有限公司 Method and device for preventing repeated payment
CN107527192A (en) * 2017-07-31 2017-12-29 深圳市金立通信设备有限公司 It is a kind of to identify the method for repeating to pay and server
CN107730366A (en) * 2017-10-30 2018-02-23 江西博瑞彤芸科技有限公司 A kind of information processing method of pay invoice management

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090299791A1 (en) * 2003-06-25 2009-12-03 Foundry Networks, Inc. Method and system for management of licenses
CN106779671A (en) * 2015-11-20 2017-05-31 华为技术有限公司 A kind of method of mobile payment and device
CN107730230A (en) * 2017-10-31 2018-02-23 中国银联股份有限公司 A kind of method of payment and vendor end

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102567877A (en) * 2011-12-01 2012-07-11 福建新大陆电脑股份有限公司 Field payment method, equipment and system
US20150120574A1 (en) * 2013-10-30 2015-04-30 Tencent Technology (Shenzhen) Company Limited Information transmission method, apparatus and system
US20160034862A1 (en) * 2014-07-31 2016-02-04 Ncr Corporation Dynamic network timeout tuning
CN106296143A (en) * 2015-06-29 2017-01-04 阿里巴巴集团控股有限公司 The electronic trade method of a kind of high availability, Apparatus and system
CN105512869A (en) * 2015-11-26 2016-04-20 中国建设银行股份有限公司 Repeated payment-prevention payment system, method and E-commerce system
CN106651333A (en) * 2016-09-20 2017-05-10 联动优势电子商务有限公司 Method and device for preventing repeated payment
CN106600269A (en) * 2016-12-28 2017-04-26 中国民生银行股份有限公司 Paying method and platform based on two-dimensional barcode
CN107527192A (en) * 2017-07-31 2017-12-29 深圳市金立通信设备有限公司 It is a kind of to identify the method for repeating to pay and server
CN107730366A (en) * 2017-10-30 2018-02-23 江西博瑞彤芸科技有限公司 A kind of information processing method of pay invoice management

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
冯铭: "电子商务支付模块的研究与设计", 万方数据知识服务平台, 29 November 2017 (2017-11-29), pages 1 - 55 *
张晓莹, 李维, 邹俊伟, 范春晓: "移动商务支付网关的设计与实现", 电信科学, no. 11, 15 November 2003 (2003-11-15), pages 32 - 35 *
阿里云: "当面付接入必读", pages 1 - 5, Retrieved from the Internet <URL:https://doc.aliyun.com/docs/doc.htm?treeID=346&articleID=105322&docType=1> *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024152846A1 (en) * 2023-01-18 2024-07-25 支付宝(杭州)信息技术有限公司 Payment processing method and apparatus

Also Published As

Publication number Publication date
CN109003071A (en) 2018-12-14
CN109003071B (en) 2022-03-04

Similar Documents

Publication Publication Date Title
CN109003071B (en) Payment method, device and equipment
CN113657886B (en) Payment system, method, server device, medium and device
CN114841700B (en) Payment processing method, device, equipment and system
CN111709733B (en) Resource transfer method, device and equipment
CN111915311B (en) Payment checking method and system
CN108874654B (en) Idempotent validity test method, device and equipment and readable medium
CN113112274A (en) Payment information processing method, device, equipment and medium
TWI741555B (en) Method and device for displaying unique identifier of digital object
CN111784356B (en) Payment verification method, device, equipment and storage medium
KR20190075958A (en) Security verification methods and devices based on biometric features
CN108596581B (en) Verification method and device for resource transfer and electronic payment verification method and device
CN113128996B (en) Payment method, device and equipment
CN117436858A (en) Transaction processing method and device based on credit
CN116523523A (en) Authority verification method and device, storage medium and electronic equipment
WO2019137357A1 (en) Payment code acquisition and payment request response method, apparatus and device
CN113419794B (en) Payment processing method and device
CN112115518B (en) Service data verification method and device
CN112837053A (en) Payment processing method and device
CN109559212B (en) Tax refund processing method, device, equipment and system
CN112883752A (en) Two-dimensional code scanning method, device and equipment
CN113409040B (en) Information sending method, device, equipment and medium
CN113419793A (en) Payment processing method and device
CN112596781A (en) Service execution and service configuration method and device
CN116521542A (en) Method and device for service object unlimited, storage medium and electronic equipment
CN116091252A (en) Medical fee payment method and device

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