WO2019179249A1 - 一种支付方法、装置及电子设备 - Google Patents

一种支付方法、装置及电子设备 Download PDF

Info

Publication number
WO2019179249A1
WO2019179249A1 PCT/CN2019/073895 CN2019073895W WO2019179249A1 WO 2019179249 A1 WO2019179249 A1 WO 2019179249A1 CN 2019073895 W CN2019073895 W CN 2019073895W WO 2019179249 A1 WO2019179249 A1 WO 2019179249A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
transaction
request
information
server
Prior art date
Application number
PCT/CN2019/073895
Other languages
English (en)
French (fr)
Inventor
周健
赵大成
吴昊
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2019179249A1 publication Critical patent/WO2019179249A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • 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/20—Point-of-sale [POS] network systems
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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/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/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device

Definitions

  • the present application relates to the field of electronic payment, and in particular, to a payment method, device, and electronic device.
  • scanning information codes (such as two-dimensional code) for payment is a common payment method.
  • the merchant scans the customer's information code or the customer scans the merchant's information code, obtains the other party's information by scanning the information code, and sends a payment request containing various information to the server, the server. After successfully processing the transaction, the payment success message is returned to both parties.
  • the prompt information of the payment success may not be received after the payment operation of the two parties due to problems such as the network or the device.
  • the payment result is unknown, the payment may have been successful on the server, and the payment may not be successful.
  • the customer re-pays, it may cause double payment, and if the customer does not pay again, the transaction cannot continue normally. This situation affects the experience of both parties.
  • the embodiment of the present specification provides a payment method, device, and service server, and the technical solution is as follows:
  • a payment method is provided, which is applied to a payment terminal that scans a payment information code and submits a payment request to a server, and does not receive a payment result, wherein the payment information code is a payment. End generating, the payment information code and the payment request at least the identification information of the transaction, the method comprising:
  • the payment end receives the user's re-payment operation, obtains the payment end user information by scanning the payment information code provided by the payment terminal, and sends a re-payment request to the server, where the re-payment request includes at least the identifier of the current transaction. information;
  • the payment terminal displays the payment success information without determining whether the re-payment request is successful
  • the payment end determines whether the re-payment request is successful
  • the payment terminal caches the re-payment request locally, and automatically re-sends when the transmission condition is met;
  • the server After receiving the re-payment request, the server queries, according to the transaction identifier information included in the re-payment request, whether the transaction corresponding to the transaction identifier has been successfully paid. If the transaction is not successfully paid, the server processes the re-request. The request is paid to make the transaction successful.
  • a payment method is further provided, where the payment information is applied to the payment end to scan the payment information code and submit the payment request to the server, and the payment result is not received, wherein the payment information code is The payment end generates, the payment information code and the payment request at least the identification information of the transaction, the method includes:
  • the payment end receives the user's re-payment operation, obtains the payment end user information by scanning the payment information code provided by the payment terminal, and sends a re-payment request to the server, where the re-payment request includes at least the identifier of the current transaction. information;
  • the payment end determines whether the re-payment request is successful
  • the payment terminal displays the payment success information, and caches the re-payment request locally, and automatically re-sends when the transmission condition is met;
  • the payment terminal displays the payment success information, and the transaction ends.
  • a payment method is further provided, where the payment information is applied to the payment end to scan the payment information code and submit the payment request to the server, and the payment result is not received, wherein the payment information code is The payment end generates, the payment information code and the payment request at least the identification information of the transaction, the method includes:
  • the server receives a re-payment request sent by the payment end after the user re-payment operation, and the re-payment request includes at least the identification information of the current transaction;
  • the server queries, according to the transaction identifier information included in the re-payment request, whether the transaction corresponding to the transaction identifier has been successfully paid. If the transaction is not successfully paid, the server processes the re-payment request to make the transaction successfully paid. .
  • a payment device which is applied to a payment terminal that scans a payment information code and submits a payment request to a server, and does not receive a payment result, wherein the payment information code is a payment. End generation, the payment information code and the payment request at least the identification information of the transaction, the device includes:
  • the re-payment module is configured to enable the payment terminal to receive the user's re-payment operation, obtain the payment-end user information by scanning the payment information code provided by the payment terminal, and send a re-payment request to the server, where the re-payment request includes at least The identification information of the transaction;
  • a request judging module configured to enable the payment end to determine whether the re-payment request is successful
  • the request caching module is configured to: after the re-payment request is unsuccessful, cause the payment end to display the payment success information, and cache the re-payment request locally, and automatically re-send when the sending condition is met;
  • the information display module is configured to enable the payment terminal to display the payment success information after the re-payment request is successful, and the transaction ends.
  • a payment device is further provided, where the payment device scans the payment information code and submits a payment request to the server, and the payment result is not received, wherein the payment information code is The payment end generates, the payment information code and the payment request at least the identification information of the transaction, the device includes:
  • a request receiving module configured to enable the server to receive a re-payment request sent by the payment terminal after the user re-payment operation, where the re-payment request includes at least the identification information of the current transaction;
  • a transaction judging module configured to enable the server to query, according to the transaction identifier information included in the re-payment request, whether the transaction corresponding to the transaction identifier has been successfully paid, and if the transaction is not successfully paid, the server processes the re-payment request In order for the transaction to be successfully paid.
  • the transaction identification information is added to the payment information code of the payment end, so that the transaction is unique.
  • the payment terminal may enter the scan code mode through the newly added re-payment function, and complete the payment again by scanning the payment information code provided by the payment terminal.
  • the re-payment will send the re-payment request with the previous transaction identification information to the server again. If the re-payment is successful, the payment-side caches the re-payment request, and automatically re-sends the transmission condition until the transmission is successful.
  • the server avoids double payment through the same transaction identification information carried in the first payment information and the re-payment information. This solution will not make the payment end user pay more, but also guarantee the payment success and improve the experience of both parties.
  • any of the embodiments of the present specification does not need to achieve all of the above effects.
  • FIG. 1a is a flow chart showing a payment method according to an exemplary embodiment of the present specification
  • FIG. 1b is another flow chart of a payment method according to an exemplary embodiment of the present specification
  • FIG. 2 is a schematic diagram of a re-payment interface shown in an exemplary embodiment of the present specification
  • FIG. 3 is a flow chart showing user qualification evaluation shown in an exemplary embodiment of the present specification.
  • FIG. 4 is a flow chart of a first payment in a payment method shown in an exemplary embodiment of the present specification
  • FIG. 5 is another flow chart of a payment method according to an exemplary embodiment of the present specification.
  • FIG. 6 is another flow chart of a payment method shown in an exemplary embodiment of the present specification.
  • Figure 7 is a schematic diagram of a payment device shown in an exemplary embodiment of the present specification.
  • FIG. 8 is another schematic diagram of a payment device according to an exemplary embodiment of the present specification.
  • FIG. 9 is a schematic structural diagram of an electronic device according to an exemplary embodiment of the present specification.
  • first, second, third, etc. may be used to describe various information in this application, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as the second information without departing from the scope of the present application.
  • second information may also be referred to as the first information.
  • word "if” as used herein may be interpreted as "when” or “when” or “in response to a determination.”
  • scanning information code for payment is a common payment method, and the information code is information.
  • the merchant scans the customer's information code or the customer scans the merchant's information code, obtains the other party's information by scanning the information code, and will include payment requests for various information.
  • the server After being sent to the server, the server successfully processes the transaction and returns the prompt information of the payment success to the paying parties.
  • the prompt information of the payment success may not be received after the payment operation of the two parties due to problems such as the network or the device.
  • the payment result is unknown, the payment may have been successful on the server, and the payment may not be successful.
  • the customer re-pays, it may cause double payment, and if the customer does not pay again, the transaction cannot continue normally. This situation affects the experience of both parties.
  • the embodiment of the present specification provides a payment method, and a payment device for performing the method.
  • the operating system architecture of the solution of the embodiment of the present specification is first described.
  • the entity involved in the embodiment of the present specification includes: a payment end, a server end, and a payment end, wherein:
  • the payment end is the payment originator of the transaction and is the terminal used by the customer to pay the money.
  • the payment terminal may be a device specially used for payment, or may be a payment function software installed on the smart terminal (for example, a mobile phone with an Alipay wallet installed), and the payment terminal has a scan code function, an information code generation function and a cache function;
  • the server is the intermediate processing party of the transaction, and may be an independent payment platform.
  • the server is responsible for receiving the transaction request information sent by the payment terminal or the payment terminal, and processing the transaction according to the content in the transaction request information, and processing the result. Returning to the payment terminal or the payment terminal, for example, the server receives the payment request sent by the payment terminal, deducts the corresponding amount of the payment terminal according to the information contained in the payment request, pays the corresponding amount of the payment terminal, and sends the transaction result information to the payment separately. End and collection end;
  • the receiving end is the payee of the transaction, and is the terminal used by the merchant to collect money. It can usually be a machine with scanning code.
  • the specific form of the information code may be a two-dimensional code (also called a two-dimensional barcode), a one-dimensional barcode or a variable barcode, and the form of the information code does not affect the implementation of the present application.
  • the payment method is applied to the case where the payment end scans the payment information code and submits a payment request to the server, and the payment result is not received.
  • the payment information code is generated by the payment terminal, and the payment information code and the payment request at least the identification information of the transaction, the method may include the following steps:
  • the payment end receives a re-payment operation of the user.
  • the application scenario of the re-payment operation initiated by the payment end user is: the payment end generates and displays the payment information code, and the payment end scans the payment information code and submits a payment request to the server.
  • the payment end In some cases, if the device has a problem or the network appears The problem is that the payment parties are unable to receive the payment result. At this time, the payment result is unknown. In order to complete the transaction as soon as possible and avoid wasting the time of both users, the payment end user needs to initiate re-payment.
  • the payment information code generated by the payment end includes the identification information of the transaction, and the payment end obtains the identification information by scanning the payment information code, and carries the identification information into the payment request, and submits it to the server.
  • This identification information uniquely identifies this transaction in all transactions on the server.
  • the re-payment operation may be an operation of the re-payment interface provided by the user to the payment end, and the re-payment interface may be implemented by: the payment-side payment information code page is displayed, the payment information code is displayed on the payment information code page, and the re-payment operation is provided. interface.
  • the re-payment interface is provided in the form of a button, and the payment end user can implement the operation of the re-payment interface by clicking the button.
  • the server generates a payment information code.
  • the payment end scans the payment information code of the payment end. To obtain user information on the receiving end;
  • the payment request sent to the server is submitted by the scanning code. If the payment terminal submits the payment request and does not receive the payment result, it is likely that there is a problem with the device or network at the receiving end. Scan the code and submit the request, the success rate of receiving the payment result is higher.
  • the payment end receives the user's operation on the re-payment interface and enters the scan code mode, and obtains the identification information of the user of the payment end by scanning the payment information code provided by the payment terminal. It should be noted that the re-payment is the same as the first payment.
  • the transaction when the payment terminal starts to re-pay into the scan code mode, carries the previous transaction identification information.
  • the payment end sends a re-payment request to the server, where the re-payment request includes at least the identification information of the current transaction.
  • the payment end Before the payment end sends a re-payment request to the server, it is usually necessary to input the payment amount by the payment end user and click to confirm the payment. At this time, the identification information of the user of the payment end, the identification information of the payment end user, the payment amount information, the payment time information and the identification information of the transaction are integrated into the re-payment request, and the re-payment request is sent. To the server.
  • the payment terminal displays the payment success information without determining whether the re-payment request is successful.
  • the payment end receives the feedback information of the server for the re-payment request, indicating that the server has been able to receive and process the re-transaction request, and the payment end does not process.
  • the payment end caches the re-payment request, and automatically re-sends when the sending condition is met;
  • the payment user can leave the payment terminal (business), but the payment request may still be unsuccessful for some reason.
  • the payment terminal caches the transaction locally.
  • the payment terminal will automatically send a re-payment request to the server, so that the server can receive the re-payment request.
  • the server queries, according to the transaction identifier information included in the re-payment request, whether the corresponding transaction has been successfully paid. If the transaction is not successfully paid, the server processes the re-payment request to make the payment successful.
  • the server After receiving the re-payment request, the server queries the corresponding previous payment request according to the transaction identification information included in the re-payment request, and two situations may occur:
  • the server receives the previous payment request and has processed the amount of the account of the payment end user and the payee user, that is, the previous payment request has made the transaction successful, but the processing result information is not sent. Return to the payment and collection terminals. At this point, the server does not need to process the transaction.
  • the server processes the transaction and completes the payment.
  • the re-payment request may arrive at the server first, and the first time the payment request arrives at the server.
  • the server can still follow the above processing logic, that is, the server first follows the second case when receiving the re-payment request: The server does not query the corresponding payment request, the server processes the transaction, and completes the payment; the server receives the first payment request again, and follows the situation one, the server queries the transaction identification information that the payment has been successful, and no longer processes the transaction.
  • the embodiment of the present specification provides a user qualification evaluation method to eliminate a malicious customer to a certain extent.
  • the method may include the following steps:
  • step S302 determining whether the qualification information of the user of the payment end meets the preset condition, if the preset condition is met, step S303 is performed, and if the preset condition is not met, step S304 is performed;
  • the qualification information can usually be the credit information of the payment end user, such as: obtaining the credit information of the payment end user's Sesame Credit Score, Tencent Credit Score, etc., and determining whether to open the re-payment function by judging the credit information of the payment end user.
  • the qualification information is not limited to credit information, and other qualification information may be selectively obtained according to actual conditions, such as: obtaining the number of transactions between the payment end user and the payment end user, transaction time and the like.
  • the information is used to determine whether the paying end user is a frequent customer of the merchant, and then according to the judgment result, whether to open the re-payment function, and the like.
  • the open re-payment function may be a re-payment interface of the open payment end.
  • the payment two-dimensional code page displays a re-payment button
  • the payment two-dimensional code page does not display the re-payment button.
  • the open re-payment function may be an operation permission of the open payment end user for the re-payment interface, for example, whether the re-payment function is open or not, the payment re-payment button is displayed on the payment QR code page, and the difference is whether the payment end user can click the The button opens to re-pay.
  • the re-payment button can be grayed out to indicate that it is inoperable.
  • the malicious customer (paying end user) no longer allows the payment end to continue networking or delete the local transaction cache, because the first payment, that is, the payment end scans the payment terminal's payment QR code and submits a payment request to the server
  • the transaction information and the relevant information of the payment end user have been stored in the payment receiving end, and the receiving end can still provide the transaction information and recover the money through subsequent appeals and the like, without worrying about the security problem.
  • the re-payment in the embodiment of the present specification is in the case where the first payment is unsuccessful, as shown in FIG. 4, and the method performed at the time of the first payment is explained:
  • the payment end generates a payment information code, where the payment information code includes transaction identification information.
  • the payment end obtains the transaction identification information and the payment end user information by scanning the payment information code of the payment end.
  • FIG. 5 a payment method performed on a payment terminal according to an embodiment of the present specification.
  • the payment end receives the re-payment operation of the user, and obtains the user information of the payment end by scanning the two-dimensional code of the payment provided by the payment receiving end;
  • the payment end sends a re-payment request to the server, where the re-payment request includes at least the identification information of the current transaction.
  • the payment terminal displays the payment success information without determining whether the re-payment request is successful.
  • step S504 The payment end determines whether the re-payment request is successful; if the payment request is unsuccessful, step S505 is performed, and if the payment request is successful, the payment end process ends;
  • the payment terminal caches the re-payment request locally, and automatically resends when the sending condition is met.
  • the payment method executed on the server side is an embodiment of the present specification.
  • the server receives a re-payment request sent by the payment end after the user re-payment operation, where the re-payment request includes at least the identification information of the current transaction.
  • step S602. The server queries, according to the transaction identifier information included in the re-payment request, whether the re-payment request corresponding to the transaction identifier has been successfully paid. If the payment is not successful, step S603 is performed. If the payment is successful, the server ends. ;
  • the server processes the re-payment request to make the transaction successfully pay.
  • the embodiment of the present specification further provides a payment device.
  • the device is applied to the payment end to scan the payment two-dimensional code and submit a payment request to the server, and the payment result is not received.
  • the payment two-dimensional code and the payment request include at least the identification information of the current transaction, and the device may include: a re-payment module 710, a request determination module 720, and a request. a cache module 730 and an information display module 740,
  • the re-payment module 710 is configured to enable the payment terminal to receive the re-payment operation of the user, obtain the payment-end user information by scanning the two-dimensional code of the payment provided by the payment terminal, and send a re-payment request to the server, where the re-payment request is Containing at least the identification information of the transaction;
  • the request judging module 720 is configured to enable the payment end to determine whether the re-payment request is successful
  • the request caching module 730 is configured to: after the re-payment request is unsuccessful, cause the payment terminal to display the payment success information, and cache the re-payment request locally, and automatically re-send when the sending condition is met;
  • the information display module 740 is configured to: after the re-payment request is successful, cause the payment terminal to display the payment success information, and the transaction ends.
  • the embodiment of the present specification further provides a payment device.
  • the device is applied to the payment end to scan the payment two-dimensional code and submit a payment request to the server, and the payment result is not received.
  • the payment two-dimensional code is generated by the payment terminal, and the payment two-dimensional code and the payment request include at least the identification information of the current transaction, and the device may include: a request receiving module 810 and a transaction determining module 820.
  • the request receiving module 810 is configured to: enable the server to receive a re-payment request sent by the payment end after the user re-payment operation, where the re-payment request includes at least the identification information of the current transaction;
  • the transaction judging module 820 is configured to enable the server to query whether the transaction corresponding to the transaction identifier has been successfully paid according to the transaction identifier information included in the re-payment request, and if the transaction is not successfully paid, the server processes the re-payment Request to make the transaction successful.
  • the embodiment of the present application further provides an electronic device including at least a memory, a processor, and a computer program stored on the memory and operable on the processor, wherein the processor implements the foregoing payment method when the program is executed, the method
  • the payment end scans the payment two-dimensional code and submits the payment request to the server, and the payment result is not received, wherein the payment two-dimensional code is generated by the payment terminal, and the payment two-dimensional code and the payment request at least include The identification information of the transaction, the method includes at least:
  • the payment end receives the user's re-payment operation, obtains the payment end user information by scanning the payment two-dimensional code provided by the payment terminal, and sends a re-payment request to the server, where the re-payment request includes at least the current transaction.
  • Identification information ;
  • the payment end determines whether the re-payment request is successful
  • the payment terminal displays the payment success information, and caches the re-payment request locally, and automatically re-sends when the transmission condition is met;
  • the payment terminal displays the payment success information, and the transaction ends.
  • the embodiment of the present application further provides another electronic device, including at least a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the foregoing payment method when the program is executed, wherein the processor implements the foregoing payment method when the program is executed, wherein the method is applied to the payment end scanning the payment two-dimensional code and submitting the payment request to the server, and the payment result is not received, wherein the payment two-dimensional code is generated by the payment terminal, and the payment two-dimensional code and the payment request are at least Containing identification information of the transaction, the method includes at least:
  • the server receives a re-payment request sent by the payment end after the user re-payment operation, and the re-payment request includes at least the identification information of the current transaction;
  • the server queries, according to the transaction identifier information included in the re-payment request, whether the transaction corresponding to the transaction identifier has been successfully paid. If the transaction is not successfully paid, the server processes the re-payment request to make the transaction successfully paid. .
  • FIG. 9 is a schematic diagram showing a hardware structure of a more specific computing device provided by an embodiment of the present specification.
  • the device may include a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050.
  • the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040 implement communication connections within the device with each other through the bus 1050.
  • the processor 1010 can be implemented by using a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits for performing correlation.
  • the program is implemented to implement the technical solutions provided by the embodiments of the present specification.
  • the memory 1020 can be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like.
  • the memory 1020 can store an operating system and other applications.
  • the technical solution provided by the embodiment of the present specification is implemented by software or firmware, the related program code is saved in the memory 1020 and is called and executed by the processor 1010.
  • the input/output interface 1030 is used to connect an input/output module to implement information input and output.
  • the input/output/module can be configured as a component in the device (not shown) or externally connected to the device to provide the corresponding function.
  • the input device may include a keyboard, a mouse, a touch screen, a microphone, various types of sensors, and the like, and the output device may include a display, a speaker, a vibrator, an indicator light, and the like.
  • the communication interface 1040 is configured to connect a communication module (not shown) to implement communication interaction between the device and other devices.
  • the communication module can communicate by wired means (such as USB, network cable, etc.), or can communicate by wireless means (such as mobile network, WIFI, Bluetooth, etc.).
  • Bus 1050 includes a path for communicating information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.
  • the above device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040, and the bus 1050, in a specific implementation, the device may also include necessary for normal operation. Other components.
  • the above-mentioned devices may also include only the components necessary for implementing the embodiments of the present specification, and do not necessarily include all the components shown in the drawings.
  • the embodiment of the present specification further provides a computer readable storage medium, where the computer program is stored, and when the program is executed by the processor, the foregoing payment method is implemented, and the method is applied to the payment end to scan and pay the two-dimensional code and to the server.
  • the method at least includes:
  • the payment end receives the user's re-payment operation, obtains the payment end user information by scanning the payment two-dimensional code provided by the payment terminal, and sends a re-payment request to the server, where the re-payment request includes at least the current transaction.
  • Identification information ;
  • the payment end determines whether the re-payment request is successful
  • the payment terminal displays the payment success information, and caches the re-payment request locally, and automatically re-sends when the transmission condition is met;
  • the payment terminal displays the payment success information, and the transaction ends.
  • the embodiment of the present specification further provides a computer readable storage medium, where the computer program is stored, and when the program is executed by the processor, the foregoing payment method is implemented, and the method is applied to the payment end to scan and pay the two-dimensional code and to the server.
  • the method at least includes:
  • the server receives a re-payment request sent by the payment end after the user re-payment operation, and the re-payment request includes at least the identification information of the current transaction;
  • the server queries, according to the transaction identifier information included in the re-payment request, whether the transaction corresponding to the transaction identifier has been successfully paid. If the transaction is not successfully paid, the server processes the re-payment request to make the transaction successfully paid. .
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, 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 disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.
  • the embodiment of the present specification further provides a payment system, where the payment information is generated by the payment end, and the payment information code is generated by the payment terminal, where the payment information is sent to the server and the payment result is not received.
  • the payment information code and the payment request include at least the identification information of the transaction, and the system includes:
  • the payment end is configured to receive a re-payment operation of the user, obtain the payment end user information by scanning the payment information code provided by the payment terminal, and send a re-payment request to the server, where the re-payment request includes at least the Identification information of this transaction;
  • the payment end is configured to generate a payment information code for the payment end to scan
  • the payment end is configured to display payment success information without determining whether the re-payment request is successful; and determine whether the re-payment request is successful;
  • the payment end is configured to cache the re-payment request locally when the payment request is unsuccessful, and automatically resend when the sending condition is met;
  • the server is configured to, after receiving the re-payment request, query, according to the transaction identifier information included in the re-payment request, whether the transaction corresponding to the transaction identifier has been successfully paid, and if the transaction is not successfully paid, the server processes The re-payment request causes the transaction to be successfully paid.
  • the device embodiment since it basically corresponds to the method embodiment, reference may be made to the partial description of the method embodiment.
  • the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, ie may be located A place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the objectives of the present application. Those of ordinary skill in the art can understand and implement without any creative effort.
  • the embodiments of the present specification can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technical solution of the embodiments of the present specification may be embodied in the form of a software product in essence or in the form of a software product, which may be stored in a storage medium such as a ROM/RAM. Disks, optical disks, and the like, including instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the embodiments of the present specification or embodiments.
  • a computer device which may be a personal computer, server, or network device, etc.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • a typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, and a game control.
  • the various embodiments in the specification are described in a progressive manner, and the same or similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • the device embodiments described above are merely illustrative, and the modules described as separate components may or may not be physically separated, and the functions of the modules may be the same in the implementation of the embodiments of the present specification. Or implemented in multiple software and/or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without any creative effort.

Landscapes

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

Abstract

本申请提供一种支付方法、装置及电子设备，在支付端的付款信息码中增加本次交易标识信息，以使本次交易具有唯一性。当支付双方的第一次支付没有及时接收到支付成功信息时，支付端可通过新增的重新支付功能进入扫码模式，通过扫描收款端提供的收款信息码再次完成支付。其中，重新支付时会将携带之前交易标识信息的重新支付请求再次发送给服务端，若没有发送成功，则支付端缓存该重新支付请求，在满足发送条件时自动再次发送直到发送成功。

Description

一种支付方法、装置及电子设备 技术领域
本申请涉及电子支付领域，尤其涉及一种支付方法、装置及电子设备。
背景技术
随着移动支付的普及，越来越多的人在线下商铺购买商品时，会通过终端设备的支付装置进行支付，其中，扫描信息码(如二维码)进行支付是一种常见的支付方式，当前信息码的支付方式有两种：商户扫描顾客的信息码或顾客扫描商户的信息码，通过扫描信息码获取对方的信息，并将包含各种信息的支付请求发送给服务端，服务端成功处理这笔交易后，将支付成功的提示信息返回给支付双方。
现有技术中，商户扫描顾客的信息码后，可能会因为网络或设备等问题，导致双方支付操作之后迟迟收不到支付成功的提示信息。此时支付结果未知，可能在服务端已经支付成功，也可能并没有支付成功。此时如果顾客重新支付，可能会造成双倍支付，如果顾客不重新支付，交易就无法继续正常进行。这种情况影响了双方的体验。
发明内容
针对上述技术问题，本说明书实施例提供一种支付方法、装置、及业务服务器，技术方案如下：
根据本说明书实施例的第一方面，提供一种支付方法，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，该方法包括：
支付端接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
支付端在无需确定所述重新支付请求是否成功的情况下，展示支付成功信息；以及
支付端判断所述重新支付请求是否成功；
若重新支付请求没有成功，支付端将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
其中，服务端接收到重新支付请求后，根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
根据本说明书实施例的第二方面，还提供一种支付方法，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，该方法包括：
支付端接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
支付端判断所述重新支付请求是否成功；
若重新支付请求没有成功，支付端展示支付成功信息，并将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
若重新支付请求成功，支付端展示支付成功信息，本次交易结束。
根据本说明书实施例的第三方面，还提供一种支付方法，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，该方法包括：
服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
根据本说明书实施例的第四方面，提供一种支付装置，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，该装置包括：
重新支付模块：用于使支付端接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
请求判断模块：用于使支付端判断所述重新支付请求是否成功；
请求缓存模块：用于当重新支付请求没有成功后，使支付端展示支付成功信息，并将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
信息展示模块：用于当重新支付请求成功后，使支付端展示支付成功信息，本次交易结束。
根据本说明书实施例的第五方面，还提供一种支付装置，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，该装置包括：
请求接收模块：用于使服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
交易判断模块：用于使服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
本说明书实施例所提供的技术方案，在支付端的付款信息码中增加本次交易标识信息，以使本次交易具有唯一性。当支付双方的第一次支付没有及时接收到支付成功信息时，支付端可通过新增的重新支付功能进入扫码模式，通过扫描收款端提供的收款信息码再次完成支付。其中，重新支付时会将携带之前交易标识信息的重新支付请求再次发送给服务端，若没有发送成功，则支付端缓存该重新支付请求，在满足发送条件时自动再次发送直到发送成功。而服务端通过第一次支付信息和重新支付信息中携带的相同的交易标识信息避免双倍支付。本方案既不会使支付端用户多付钱，又能保证支付成功，提升了支付双方的体验。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1a是本说明书一示例性实施例示出的支付方法的一种流程图；
图1b是本说明书一示例性实施例示出的支付方法的另一种流程图；
图2是本说明书一示例性实施例示出的重新支付接口的一种示意图；
图3是本说明书一示例性实施例示出的用户资格评估的一种流程图；
图4是本说明书一示例性实施例示出的支付方法中首次支付的一种流程图；
图5是本说明书一示例性实施例示出的支付方法的另一种流程图；
图6是本说明书一示例性实施例示出的支付方法的另一种流程图；
图7是本说明书一示例性实施例示出的支付装置的一种示意图；
图8是本说明书一示例性实施例示出的支付装置的另一种示意图；
图9是本说明书一示例性实施例示出的一种电子设备的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
随着移动支付的普及，越来越多的人在线下商铺购买商品时，会通过终端设备的支付装置进行支付，其中，扫描信息码进行支付是一种常见的支付方式，而信息码是信息码的常见展现形式之一，当前信息码的支付方式有两种：商户扫描顾客的信息码或顾客 扫描商户的信息码，通过扫描信息码获取对方的信息，并将包含各种信息的支付请求发送给服务端，服务端成功处理这笔交易后，将支付成功的提示信息返回给支付双方。
现有技术中，商户扫描顾客的信息码后，可能会因为网络或设备等问题，导致双方支付操作之后迟迟收不到支付成功的提示信息。此时支付结果未知，可能在服务端已经支付成功，也可能并没有支付成功。此时如果顾客重新支付，可能会造成双倍支付，如果顾客不重新支付，交易就无法继续正常进行。这种情况影响了双方的体验。
针对以上问题，本说明书实施例提供一种支付方法，以及一种用于执行该方法的支付装置，下面首先对本说明书实施例方案的运行系统架构进行说明。参，本说明书实施例方案涉及的实体包括：支付端、服务端、收款端，其中：
支付端是交易的支付发起方，是顾客支付钱款时所使用的终端。支付端可以是专门用于支付的设备，也可以是安装在智能终端的具有支付功能的软件(例如安装了支付宝钱包的手机)，支付端具备扫码功能，信息码生成功能与缓存功能；
服务端是交易的中间处理方，可以是一个独立的支付平台，服务端负责接收支付端或收款端发送的交易请求信息，根据交易请求信息中的内容对交易做出处理，并将处理结果返回给支付端或收款端，例如，服务端接收支付端发送的支付请求，按照支付请求中包含的信息扣除支付端的相应金额，给付收款端相应金额，并分别将交易结果信息发送给支付端和收款端；
收款端是交易的收款方，是商户收款所使用的终端，通常可以为具备扫码功能的机具。
为了发送与接收相关的交易请求，上述三种实体均需要具备连接互联网的功能。信息码的具体形式可以是二维码(也称二维条形码)、一维条形码或可变条码等，信息码的形式不影响本申请方案的实现。
下面对本实施例涉及的支付方法进行详细说明，参见图1a与图1b所示，该支付方法应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，该方法可以包括以下步骤：
S101，支付端接收用户的重新支付操作；
在支付端用户发起重新支付操作的应用场景为：支付端生成并展示支付信息码，收款端扫描支付信息码并向服务端提交支付请求，在某些情况下，如设备出现问题或网络 出现问题，支付双方迟迟无法收到支付结果，此时支付结果未知，为了使交易尽快完成，避免浪费双方用户的时间，需要由支付端用户发起重新支付。
在上述过程中，支付端生成的支付信息码包含本次交易的标识信息，收款端通过扫描支付信息码获取该标识信息，并将标识信息携带到支付请求中，一并提交到服务端。该标识信息可在服务端的所有交易中唯一标识本次交易。
重新支付操作可以为用户对支付端提供的重新支付接口的操作，重新支付接口的实现方式可以为：支付端支成支付信息码页面，在支付信息码页面展示支付信息码，并提供重新支付操作接口。如图2所示，以按钮的形式提供该重新支付接口，支付端用户可通过点击该按钮实现对重新支付接口的操作。
S102，服务端生成收款信息码；
S103，支付端扫描收款端的收款信息码。以获取收款端的用户信息；
通常来说，发送给服务端的支付请求由扫码的一端提交的，若收款端提交支付请求没有收到支付结果，则很可能是收款端的设备或网络有问题，此时换由支付端扫码并提交请求，收到支付结果的成功率较高。
支付端接收用户对重新支付接口的操作并进入扫码模式，通过扫描收款端提供的收款信息码获取收款端用户的身份识别信息，需要注意的是，重新支付与首次支付属于同一次交易，在支付端开始重新支付进入扫码模式时，会携带之前的交易标识信息。
S104，支付端向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
在支付端向服务端发送重新支付请求之前，通常需要先由支付端用户输入支付金额并点击确认支付。此时将收款端用户的身份识别信息，支付端用户本身的身份识别信息，支付金额信息，支付时间信息和本次交易的标识信息一并整合到重新支付请求中，将该重新支付请求发送给服务端。
S105，支付端在无需确定所述重新支付请求是否成功的情况下，展示支付成功信息；
重新支付请求发送后，根据是否收到服务端对该重新支付请求的反馈信息，后续执行步骤有所不同。参见图1a与图1b，分为S106a和S106b。
S106a，支付端收到服务端对重新支付请求的的反馈信息，则说明服务端已能接收并处理重新交易请求，支付端不再处理。
S106b，若重新支付请求没有成功，支付端缓存重新支付请求，当满足发送条件时自动再次发送；
当展示支付成功信息后，支付端用户(顾客)即可离开收款端(商户)，但此时支付请求可能仍会因为某些原因无法成功。例如：支付端网络不通，则由支付端将该次交易缓存在本地，当网络连通时，支付端将自动将重新支付请求发送给服务端，以使服务端能够收到该重新支付请求。
S107，服务端根据所述重新支付请求中包含的交易标识信息查询对应的交易是否已经成功支付，若没有成功支付，服务端处理所述重新支付请求以使其成功支付。
服务端收到重新支付请求后，根据重新支付请求中包含的交易标识信息查询对应的先前的支付请求，可能出现两种情况：
情况一，支付已经成功，服务端收到了先前的支付请求并对支付端用户和收款端用户的账户做出了金额处理，即先前的支付请求已经使该交易成功，但处理结果信息没有发送回支付端和收款端。此时服务端不需要再对交易做出处理。
情况二，支付没有成功，或没有查询到对应的支付请求。此时服务端处理该交易，完成支付。
需要注意的是，重新支付请求可能先到达服务端，而首次支付请求后到达服务端，此时服务端仍可遵循上述的处理逻辑，即，服务端先收到重新支付请求时遵循情况二：没有查询到对应的支付请求，服务端处理交易，完成支付；服务端再收到首次支付请求，遵循情况一，服务端根据交易标识信息查询到支付已经成功，不再对交易做出处理。
在某些情况下，可能会出现恶意顾客，即顾客在支付端点击重新支付却不再让支付端继续联网或删除本地交易缓存，导致交易缓存在支付端后无法通过联网发送给服务端。
针对上述问题，本说明书实施例提供一种用户资格评估方法，以在一定程度上杜绝恶意顾客，参见图3所示，该方法可以包括以下步骤：
S301，获取支付端用户的资格信息；
S302，确定支付端用户的资格信息是否满足预设条件，若符合预设条件，执行步骤S303，若不满足预设条件，执行步骤S304；
资格信息通常情况下可以为支付端用户的信用信息，如：获取支付端用户的芝麻信用分，腾讯信用分等等信用信息，并通过判断支付端用户的信用信息来决定是否开放重 新支付功能。但资格信息并不局限于信用信息，也可以根据实际情况选择性获取其他的资格信息，如：获取支付端用户与收款端用户的交易次数，交易时间等信息。通过这些信息判断支付端用户是否为商户的常客，再根据判断结果确定是否开放重新支付功能，等等。
S303，开放支付端的重新支付功能；
开放重新支付功能可以是开放支付端的重新支付接口，例如：当开放重新支付功能时，支付二维码页面显示重新支付按钮，当未开放重新支付功能时，支付二维码页面不显示重新支付按钮。
或，开放重新支付功能可以是开放支付端用户对于重新支付接口的操作权限，例如：不管是否开放重新支付功能，支付二维码页面均显示重新支付按钮，区别在于支付端用户是否能够通过点击该按钮开启重新支付。在某些情况下，可将重新支付按钮置灰表示其不可操作。
S304，关闭支付端的重新支付功能。
需要注意的是，即使恶意顾客(支付端用户)不再让支付端继续联网或删除本地交易缓存，因为在首次支付，即收款端扫描支付端的支付二维码并向服务端提交支付请求时，本次交易信息和支付端用户的相关信息已经存储于收款端，收款端仍可提供交易信息并通过后续申诉等操作追回该笔钱款，无需担心安全问题。
本说明书实施例中的重新支付是在发生在首次支付不成功的情况下，参见图4所示，对于首次支付时执行的方法进行说明：
S401，支付端生成支付信息码，所述支付信息码中包含交易标识信息；
S402，收款端通过扫描支付端的支付信息码获取交易标识信息与支付端用户信息；
S403，向服务端发送支付请求，所述支付请求中至少包含所述本次交易的标识信息；
S404，未接收到客户端针对支付请求的回馈信息。
为了更清楚地说明本说明书实施例的方案，下面分别再从单侧的角度，对于执行的方法进行说明：
参见图5所示，为本说明书实施例在支付端执行的支付方法。
S501，支付端接收用户的重新支付操作，通过扫描收款端提供的收款二维码获取收款端用户信息；
S502，支付端向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
S503，支付端在无需确定所述重新支付请求是否成功的情况下，展示支付成功信息；
S504，支付端判断所述重新支付请求是否成功；若支付请求不成功，执行步骤S505，若支付请求成功，则支付端流程结束；
S505，支付端将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送。
参见图6所示，为本说明书实施例在服务端执行的支付方法。
S601，服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
S602，服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的重新支付请求是否已经成功支付，若没有成功支付，执行步骤S603，若已经成功支付，则服务端流程结束；
S605，服务端处理所述重新支付请求以使所述交易成功支付。
关于支付端与服务端的单侧执行方法细节，可以参见前面实施例的描述，这里不再赘述。
相应于上述方法实施例，本说明书实施例还提供一种支付装置，参见图7所示，该装置应用于收款端扫描支付二维码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付二维码为支付端生成，所述支付二维码与支付请求至少包含本次交易的标识信息，所述装置可以包括：重新支付模块710，请求判断模块720，请求缓存模块730和信息展示模块740，
重新支付模块710：用于使支付端接收用户的重新支付操作，通过扫描收款端提供的收款二维码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
请求判断模块720：用于使支付端判断所述重新支付请求是否成功；
请求缓存模块730：用于当重新支付请求没有成功后，使支付端展示支付成功信息，并将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
信息展示模块740：用于当重新支付请求成功后，使支付端展示支付成功信息，本次交易结束。
相应于上述方法实施例，本说明书实施例还提供一种支付装置，参见图8所示，该装置应用于收款端扫描支付二维码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付二维码为支付端生成，所述支付二维码与支付请求至少包含本次交易的标识信息，所述装置可以包括：请求接收模块810和交易判断模块820。
请求接收模块810：用于使服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
交易判断模块820：用于使服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
本申请实施例还提供一种电子设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现前述支付方法，该方法应用于收款端扫描支付二维码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付二维码为支付端生成，所述支付二维码与支付请求至少包含本次交易的标识信息，所述方法至少包括：
支付端接收用户的重新支付操作，通过扫描收款端提供的收款二维码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
支付端判断所述重新支付请求是否成功；
若重新支付请求没有成功，支付端展示支付成功信息，并将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
若重新支付请求成功，支付端展示支付成功信息，本次交易结束。
本申请实施例还提供另一种电子设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现前述支付方法，该方法应用于收款端扫描支付二维码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付二维码为支付端生成，所述支付二维码与支付请求至少包含本次交易的标识信息，所述方法至少包括：
服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
图9示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述的支付方法，该方法应用于收款端扫描支付二维码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付二维码为支付端生成，所述支付二维码与支付请求至少包含本次交易的标识信息，所述方法至少包括：
支付端接收用户的重新支付操作，通过扫描收款端提供的收款二维码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
支付端判断所述重新支付请求是否成功；
若重新支付请求没有成功，支付端展示支付成功信息，并将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
若重新支付请求成功，支付端展示支付成功信息，本次交易结束。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述的支付方法，该方法应用于收款端扫描支付二维码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付二维码为支付端生成，所述支付二维码与支付请求至少包含本次交易的标识信息，所述方法至少包括：
服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本说明书实施例还提供一种支付系统，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，该系统包括：
支付端、收款端、服务端；
所述支付端，用于接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
所述收款端，用于生成收款信息码以供支付端扫描；
所述支付端，用于在无需确定所述重新支付请求是否成功的情况下，展示支付成功信息；以及判断所述重新支付请求是否成功；
所述支付端，用于在支付请求没有成功的情况下，将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
所述服务端，用于接收到重新支付请求后，根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (14)

  1. 一种支付方法，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，所述方法包括：
    支付端接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
    支付端在无需确定所述重新支付请求是否成功的情况下，展示支付成功信息；以及
    支付端判断所述重新支付请求是否成功；
    若重新支付请求没有成功，支付端将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
    其中，服务端接收到重新支付请求后，根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
  2. 如权利要求1所述的方法，其特征在于，所述收款端扫描支付信息码之前，还包括：
    支付端接收用户的付款请求并生成支付信息码页面，其中，所述支付信息码页面包含支付信息码与重新支付操作接口。
  3. 如权利要求1所述的方法，其特征在于，所述本次交易的标识信息为支付端根据预设算法计算得出，所述预设算法用于计算标识信息以使所述标识信息能在服务端的所有交易中唯一标识本次交易。
  4. 如权利要求1所述的方法，其特征在于，所述本次交易的标识信息包括支付端用户交易序列号信息与支付端用户信息。
  5. 如权利要求1所述的方法，其特征在于，所述服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，包括：
    服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易，并使用支付端用户信息，收款端用户信息，支付金额信息对所述对应的交易进行校验，以判断所述对应的交易是否已经成功支付。
  6. 如权利要求1所述的方法，其特征在于，所述支付端接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求， 包括：
    支付端接收用户对重新支付接口的操作并进入扫码模式，通过扫描收款端提供的收款信息码获取收款端用户信息；
    支付端接收用户的确认支付操作后，向服务端发送重新支付请求。
  7. 如权利要求1所述的方法，其特征在于，所述支付端接收用户的重新支付操作前，还包括：
    判断支付端用户是否满足预设条件，若满足预设条件，向支付端用户开放重新支付功能。
  8. 如权利要求7所述的方法，其特征在于，所述判断支付端用户是否满足预设条件，若满足预设条件，向支付端用户开放重新支付功能，包括：
    对支付端用户进行信用评估，若支付端用户通过所述信用评估，向所述支付端用户开放重新支付功能。
  9. 一种支付方法，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，所述方法包括：
    支付端接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
    支付端判断所述重新支付请求是否成功；
    若重新支付请求没有成功，支付端展示支付成功信息，并将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
    若重新支付请求成功，支付端展示支付成功信息，本次交易结束。
  10. 一种支付方法，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，所述方法包括：
    服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
    服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
  11. 一种支付装置，应用于收款端扫描支付信息码并向服务端提交支付请求、且未 收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，所述装置包括：
    重新支付模块：用于使支付端接收用户的重新支付操作，通过扫描收款端提供的收款信息码获取收款端用户信息，向服务端发送重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
    请求判断模块：用于使支付端判断所述重新支付请求是否成功；
    请求缓存模块：用于当重新支付请求没有成功后，使支付端展示支付成功信息，并将所述重新支付请求缓存在本地，当满足发送条件时自动再次发送；
    信息展示模块：用于当重新支付请求成功后，使支付端展示支付成功信息，本次交易结束。
  12. 一种支付装置，应用于收款端扫描支付信息码并向服务端提交支付请求、且未收到支付结果的情况下，其中，支付信息码为支付端生成，所述支付信息码与支付请求至少包含本次交易的标识信息，所述装置包括：
    请求接收模块：用于使服务端接收支付端在用户重新支付操作后发送的重新支付请求，所述重新支付请求中至少包含所述本次交易的标识信息；
    交易判断模块：用于使服务端根据所述重新支付请求中包含的交易标识信息查询所述交易标识对应的交易是否已经成功支付，若所述交易没有成功支付，服务端处理所述重新支付请求以使所述交易成功支付。
  13. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求9所述的方法。
  14. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求10所述的方法。
PCT/CN2019/073895 2018-03-19 2019-01-30 一种支付方法、装置及电子设备 WO2019179249A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810223860.XA CN108446905B (zh) 2018-03-19 2018-03-19 一种支付方法、装置及电子设备
CN201810223860.X 2018-03-19

Publications (1)

Publication Number Publication Date
WO2019179249A1 true WO2019179249A1 (zh) 2019-09-26

Family

ID=63195075

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/073895 WO2019179249A1 (zh) 2018-03-19 2019-01-30 一种支付方法、装置及电子设备

Country Status (3)

Country Link
CN (1) CN108446905B (zh)
TW (1) TWI686753B (zh)
WO (1) WO2019179249A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108446905B (zh) * 2018-03-19 2020-05-12 阿里巴巴集团控股有限公司 一种支付方法、装置及电子设备
CN110163739B (zh) * 2019-04-10 2020-08-18 阿里巴巴集团控股有限公司 支付申诉方法、装置、服务器及可读存储介质
US10963888B2 (en) 2019-04-10 2021-03-30 Advanced New Technologies Co., Ltd. Payment complaint method, device, server and readable storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103500401A (zh) * 2013-09-27 2014-01-08 华为技术有限公司 一种支付方法、装置及系统
CN105095462A (zh) * 2015-07-30 2015-11-25 北京京东尚科信息技术有限公司 处理网页重复请求的方法和系统
CN107038579A (zh) * 2016-02-04 2017-08-11 阿里巴巴集团控股有限公司 一种电子支付业务处理、电子支付方法及装置
CN108446905A (zh) * 2018-03-19 2018-08-24 阿里巴巴集团控股有限公司 一种支付方法、装置及电子设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI464699B (zh) * 2007-03-29 2014-12-11 Alibaba Group Holding Ltd And a payment system and a method for trading with an ID card containing an IC card
CN104077683A (zh) * 2013-02-24 2014-10-01 黄金富 一种用移动电话网络计费结算的支付系统和方法
US9582829B2 (en) * 2014-05-06 2017-02-28 Bank Of America Corporation Dynamically modifying an application questionnaire
US20170262820A1 (en) * 2016-03-11 2017-09-14 Sekurus International Inc. Smart transport solution
CN107730615A (zh) * 2017-01-06 2018-02-23 西安艾润物联网技术服务有限责任公司 支付和税控方法以及停车场收费装置
CN107767140A (zh) * 2017-10-02 2018-03-06 头等尝网络餐饮管理科技（深圳）有限公司 支付方法、装置、设备及可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103500401A (zh) * 2013-09-27 2014-01-08 华为技术有限公司 一种支付方法、装置及系统
CN105095462A (zh) * 2015-07-30 2015-11-25 北京京东尚科信息技术有限公司 处理网页重复请求的方法和系统
CN107038579A (zh) * 2016-02-04 2017-08-11 阿里巴巴集团控股有限公司 一种电子支付业务处理、电子支付方法及装置
CN108446905A (zh) * 2018-03-19 2018-08-24 阿里巴巴集团控股有限公司 一种支付方法、装置及电子设备

Also Published As

Publication number Publication date
TW201939387A (zh) 2019-10-01
CN108446905A (zh) 2018-08-24
CN108446905B (zh) 2020-05-12
TWI686753B (zh) 2020-03-01

Similar Documents

Publication Publication Date Title
KR102218168B1 (ko) 전자 트랜잭션과 관련되어 전자 계좌를 동작시키기 위한 방법, 장치, 및 시스템
US8504450B2 (en) Mobile remittances/payments
US8332314B2 (en) Text authorization for mobile payments
US8856043B2 (en) Method and system for managing data and enabling payment transactions between multiple entities
US20160110715A1 (en) Method and system for dynamic funding
US20160005024A1 (en) Offline to online payment
US20150339656A1 (en) Verified purchasing by push notification
US20130036051A1 (en) Non-near field communication point of sale experience
WO2012148773A2 (en) Online payment method and device
WO2019179249A1 (zh) 一种支付方法、装置及电子设备
US8683498B2 (en) Systems and methods for facilitating call request aggregation over a network
CA3017280A1 (en) Method and system for efficient shared transaction processing
US20190311347A1 (en) Credit card payment processing method and apparatus
US20150178726A1 (en) System and method for mobile payment authentication
CN111213172A (zh) 通过数字钱包访问ach交易功能
US10592898B2 (en) Obtaining a signature from a remote user
KR20170103907A (ko) 연계된 개인 식별 및 계좌 회수
WO2019025868A1 (en) SYSTEM AND METHOD FOR PROVIDING SECURE SERVICES
US20140006271A1 (en) Cross-network electronic payment processing system and method
US20190156334A1 (en) System and method for providing anonymous payments
US11823171B1 (en) Payment function service
US11562359B2 (en) System and method for performing financial transactions using a wireless personal assistant
US20230103796A1 (en) Event-based triggers of cryptocurrency transactions
US10542112B2 (en) Manageable object processing method and device
US20210201275A1 (en) System and method for smart device communication and transaction processing

Legal Events

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

Ref document number: 19771744

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19771744

Country of ref document: EP

Kind code of ref document: A1