CN117236965A

CN117236965A - Payment processing method and system

Info

Publication number: CN117236965A
Application number: CN202311267777.XA
Authority: CN
Inventors: 赵鹏飞
Original assignee: AlipayCom Co ltd
Current assignee: AlipayCom Co ltd
Priority date: 2021-03-09
Filing date: 2021-03-09
Publication date: 2023-12-15
Also published as: CN112950219A; CN112950219B

Abstract

In the payment processing method and system provided by the specification, a payment receiving system sends a payment request to a payment server after collecting a payment code; the payment server identifies whether the payment request needs to be verified; when the payment request needs to be verified, the payment server sends the verification request to the collection system and the payment terminal at the same time, and the verification request is displayed through the collection system, so that the collection party and the payment party are timely reminded of the state of the payment request in the payment process, and the payment party is timely reminded of verifying the payment request. When the payer verifies the payment request, the payer can operate through the payment terminal or through the payment system. The payment processing method and the system provided by the specification can prompt the payee and the payer of the state of the payment order in the payment process timely and effectively, improve the capability of code scanning payment anti-lost bill of the off-line scene, and improve the payment success rate.

Description

Payment processing method and system

The application is a divisional application of an application patent application with the application number of 202110252652.4, the application date of 2021, 03 and 09, and the application name of payment processing method and system.

Technical Field

The present disclosure relates to the field of internet, and in particular, to a payment processing method and system.

Background

With the continuous popularization and development of mobile payment technology, mobile payment brings more convenience to people in daily life, and the daily payment mode of people is gradually changed. In a code scanning payment scene, under some special conditions, after a user scans codes, the mobile terminal pops up a secondary verification page to carry out secondary verification on a payment order, such as the scenes of huge transaction amount, insufficient balance, risk of payment and the like. At this time, the collection system side does not display the information that needs to be checked twice, so that the merchant is not prompted to pay the order and needs to be checked twice. If a scene with larger passenger flow is encountered, the illusion that the merchant and the user consider successful payment is easily generated, so that the phenomenon of bill loss is generated. The off-line code scanning payment bill loss problem is a ubiquitous and unavoidable problem.

Therefore, it is necessary to provide a payment processing method and system, which can prompt the payee and the payer about the state of the payment order in the payment process in time, improve the capability of the offline scene code scanning payment anti-lost bill, and improve the payment success rate.

Disclosure of Invention

The specification provides a payment processing method and a payment processing system, which can prompt a payee and a payer of the state of a payment order in the payment process timely and effectively, improve the capability of code scanning payment anti-lost bill of an off-line scene, and improve the payment success rate.

In a first aspect, the present specification provides a payment processing method, applied to a payment server, including: receiving a payment request sent by a collection system, wherein the payment request comprises a device identifier of the collection system, a transaction amount and a payment code of a payment terminal acquired by the collection system; identifying the payment request, and determining whether the payment request needs verification; determining that the payment request needs to be verified, and sending a verification request to the payment terminal and the collection system; and determining that the verification is passed, executing the payment request and transmitting a payment result to the payment receiving system and the payment terminal.

In some embodiments, the identifying the payment request, determining whether the payment request requires verification, comprises: identifying the payment request, determining a collection account associated with a device identifier of the collection system, and identifying a payment account corresponding to the payment code and the device identifier of the payment terminal; and determining whether the payment request requires the verification based on the recognition result of the payment request, including at least one of: comparing the payment request with the payment policy of the payment account, and determining that the payment request needs to be verified when the payment request does not meet the payment policy, otherwise, not needing to be verified; and performing risk assessment on the payment request, and determining that the payment request needs to be verified when the risk value of the payment request is higher than a risk threshold value, otherwise, not needing to be verified.

In some embodiments, the payment policy includes at least one of: a payment limit policy; a collection account restriction policy.

In some embodiments, the authentication request includes at least one of: a confirmation request for the payment request; and an authentication request for a target payer, the target payer including a user associated with the payment terminal.

In some embodiments, the authentication request includes at least one of a payment password authentication request, a biometric authentication request, and a passcode authentication request.

In some embodiments, the biometric authentication request includes at least one of a facial image authentication request, an iris authentication request, a sclera authentication request, a fingerprint authentication request, a palmprint authentication request, a voiceprint authentication request, a bone projection authentication request.

In some embodiments, the authentication request includes: a first authentication request sent to the payment terminal; and a second authentication request sent to the collection system.

In some embodiments, the first authentication request includes at least one of: a confirmation request for the payment request; and an authentication request for a target payer, the target payer including a user associated with the payment terminal.

In some embodiments, the second authentication request includes a request prompting a target payer to complete the authentication through the payment terminal, the target payer including a user associated with the payment terminal.

In some embodiments, prior to said determining that said verification passes, said method further comprises: and receiving a verification result which is sent by the payment terminal or the collection system and is in response to the verification request.

In a second aspect, the present specification provides a payment processing system comprising a payment server comprising at least one storage medium storing at least one instruction set for payment processing and at least one processor; the at least one processor is communicatively coupled to the at least one storage medium, wherein the at least one processor reads the at least one instruction set and implements the payment processing method described in the first aspect of the present specification when the payment processing system is operating.

In a third aspect, the present specification provides a payment processing method applied to a collection system, including: collecting a payment code of a payment terminal; sending a payment request to a payment server, the payment request including a device identification of the payment system, a transaction amount, and the payment code; receiving and displaying a verification request sent by the payment server; and receiving and displaying the payment result sent by the payment server.

In some embodiments, the payment server sends the verification request to the collection system when it determines that the payment request requires verification based on the payment request.

In some embodiments, the authentication request includes at least one of: a confirmation request for the payment request; an authentication request for a target payer, the target payer including a user associated with the payment terminal; and prompting the target payer to complete the request of verification through the payment terminal.

In some embodiments, before the receiving the payment result sent by the payment server, the method further comprises: and receiving an operation of a target payer in response to the verification request, generating a verification result, and sending the verification result to the payment server, wherein the target payer comprises a user associated with the payment terminal.

In some embodiments, the displaying the authentication request sent by the payment server includes at least one of: displaying the verification request through a display screen of the collection system; and broadcasting the verification request through a voice playing device of the collection system.

In a fourth aspect, the present description provides a payment processing system comprising a collection system comprising at least one storage medium storing at least one instruction set for payment processing and at least one processor; the at least one processor is communicatively coupled to the at least one storage medium, wherein the at least one processor reads the at least one instruction set and implements the payment processing method described in the first aspect of the present specification when the payment processing system is operating.

In some embodiments, the collection system further comprises an acquisition device configured to acquire the payment code.

In some embodiments, the checkout system further includes a display device configured to display the verification request.

According to the technical scheme, in the payment processing method and the payment processing system provided by the specification, the payment collecting system sends a payment request to the payment server after collecting the payment code on the payment terminal; the payment server identifies whether the payment request needs to be verified; when the payment request needs to be verified, the payment server sends the verification request to the collection system and the payment terminal at the same time, and the verification request is displayed through the collection system, so that the state of the payment request in the payment process is timely reminded to both the collection party and the payment party, and the payment party is timely reminded to verify the payment request. When the payer verifies the payment request, the payer may complete the payment by operating the payment terminal to generate a verification result in response to the verification request, or by operating the payee system to generate a verification result in response to the verification request. The payment processing method and the system provided by the specification can prompt the payee and the payer of the state of the payment order in the payment process timely and effectively, improve the capability of code scanning payment anti-lost bill of the off-line scene, and improve the payment success rate.

Additional functions of the payment processing methods and systems provided herein will be set forth in part in the description which follows. The following numbers and examples presented will be apparent to those of ordinary skill in the art in view of the description. The inventive aspects of the payment processing methods and systems provided herein may be fully explained by the practice or use of the methods, devices, and combinations described in the following detailed examples.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present description, the drawings that are needed in the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present description, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 shows a schematic application scenario of a payment processing system according to an embodiment of the present disclosure;

FIG. 2 illustrates a hardware schematic of a computing device provided in accordance with an embodiment of the present description;

FIG. 3 shows a flow diagram of a payment processing method provided in accordance with an embodiment of the present disclosure;

FIG. 4 illustrates a flow diagram provided in accordance with an embodiment of the present disclosure for identifying whether a payment request requires verification;

FIG. 5 illustrates an interface diagram of a cash register system displaying a verification request, provided in accordance with an embodiment of the present disclosure;

FIG. 6 illustrates an interface diagram of a cash register system displaying a verification request, provided in accordance with an embodiment of the present disclosure; and

fig. 7 is a schematic diagram of an interface for displaying a verification request by a cash collecting system according to an embodiment of the present disclosure.

Detailed Description

The following description is presented to enable one of ordinary skill in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the disclosure. Thus, the present description is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. For example, as used herein, the singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise. The terms "comprises," "comprising," "includes," and/or "including," when used in this specification, are taken to specify the presence of stated integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

These and other features of the present specification, as well as the operation and function of the related elements of structure, as well as the combination of parts and economies of manufacture, may be significantly improved upon in view of the following description. All of which form a part of this specification, reference is made to the accompanying drawings. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the description. It should also be understood that the drawings are not drawn to scale.

The flowcharts used in this specification illustrate operations implemented by systems according to some embodiments in this specification. It should be clearly understood that the operations of the flow diagrams may be implemented out of order. Rather, operations may be performed in reverse order or concurrently. Further, one or more other operations may be added to the flowchart. One or more operations may be removed from the flowchart.

In an off-line code scanning payment scenario, a payer generates a payment code through a payment terminal, the payment code is aligned to a camera of a collection system, information in the payment code is identified by the collection system, and the information in the payment code is sent to a payment server to complete payment operation. And prompting the payor and the payee of the result of successful payment or unsuccessful payment by the payee system when the payment is successful or unsuccessful. In many cases, the payment order does not need to be checked twice, and the successful code scanning represents the successful payment, so that the payer is habitually not waiting for the payment result after the code scanning action, and the payer is not conscious of confirming the state in the mobile phone screen after the code scanning. In some cases, after the code scanning is successful, the payer needs to perform secondary verification through the payment terminal. In some embodiments, when the payment server performs the code scanning payment limit limiting, if the amount of the current order paid by the code scanning exceeds the preset payment limit, the payment server sends secondary verification information to the payment server so as to prompt the payment server to perform secondary verification on the current order information. In some embodiments, the payment server performs risk assessment on the current payment order, and if the risk assessment result of the current payment order indicates that the current order is at risk, the payment server sends secondary verification information to the payer, so as to prompt the payer to perform secondary verification on the current order information. In some embodiments, when the payment path selected by the payer shows that the payment balance is insufficient to pay the current payment order, the payment server sends secondary verification information to the payer to prompt the payer to perform secondary verification on the current order information to replace the payment path. For example, when the current payment path is the bank card 1 and the balance in the bank card 1 is insufficient, the payment server prompts the payer to change the payment path, for example, to change to the bank card 2 through the payment terminal.

And when the current order requires the secondary verification of the payer, the payment server sends the secondary verification information to the payment terminal. At this time, the payee (i.e., the collection system) does not receive the secondary verification information, nor does it receive a notification that the secondary verification is required. If the payer does not pass the payment terminal in time at this time, the payment order may be in an unfinished state. The payee may not determine the specific status of the current payment order, and may consider that the result of the payee system not displaying the successful payment or the failure payment is caused by unstable network connection or normal delay, and the payee may not prompt the payee in time, thereby causing the failure of payment of the order and causing the loss of the merchant.

The present disclosure provides a payment processing method and system, when a current payment order requires a payer to perform secondary verification, a verification request of the secondary verification is simultaneously sent to a payment collecting system and a payment terminal, the payment collecting system prompts the payee and the payer to verify the current payment order in time, interaction between the payment collecting system and the payment terminal is increased, and the state of the current payment order in the payment process is timely reminded and fed back to the payee and the payer, so that waiting and communication costs are avoided, the payment collecting efficiency is improved, and the probability of losing the order is reduced.

Fig. 1 shows a schematic application scenario of a payment processing system 100 according to an embodiment of the present disclosure. The payment processing system 100 (hereinafter referred to as system 100) may be applied to all scenarios of swipe code payments. The system 001 may include a target payer 110, a payment terminal 130, a payment system 140, and a payment server 160. In some embodiments, system 100 may also include network 120 and database 150.

The target payer 110 may be any user who is performing a payment operation to the payee system 140 through the payee system 140. The target payer 110 and the payee system 140 may conduct a target transaction. The target transaction may include a service transaction. The service transaction may include, but is not limited to, taking a bus, taking a subway, taking an airplane, taking a train, a restaurant service, a hotel service. The target transaction may include a commodity transaction. The commodity may include tangible commodity and intangible commodity. As examples, the tangible goods may include, but are not limited to, home appliances, books; the intangible items may include, but are not limited to, stocks, options.

The target transaction includes the target payer 110 paying the target number of virtual resources to the payee system 140. In particular, the target transaction includes the target payer 110 paying a target number of virtual resources to a collection account associated with the collection system 140. As an example, the virtual resource may be digital currency. The digital currency may include a digital representation of an entity currency. The digital currency may also include virtual digital currency.

The target payer 110 may be a payer of the target transaction; the collection system 140 may be a payee of the target transaction. The target transaction further includes the receipt system 140 providing services or goods to the target payer 110; the target payer 110 is the shared payee of the service and/or the buyer of the commodity; the collection system 140 may be a provider of the service and/or a seller (i.e., merchant) of the item.

The payment terminal 130 may be a smart device associated with the target payer 110. The payment terminal 130 may be a device that performs the target transaction with the payee system 140 by the target payer 110. The payment terminal 130 may be a smart device carrying a target application (target APP). The target payer 110 is a user of the payment terminal 130. The payment terminal 130 may be installed with one or more Applications (APP). The APP can provide the target payer 110 with the ability to interact with the outside world via the network 120 and an interface. The APP includes, but is not limited to: chat-type APP programs, shopping-type APP programs, video-type APP programs, financial-type APP programs, and the like. The target APP refers to a client APP of a payment application that can make a payment to the collection system 140. In some embodiments, the payment terminal 130 may include a mobile device, a tablet, a notebook, or the like, or any combination thereof. In some embodiments, the mobile device may include a smart phone, a smart wearable device, a personal digital assistant, or the like, or any combination thereof. As shown in fig. 1, the target APP in the payment terminal 130 may generate and display a payment code 132 at an interface of the payment terminal 130 in response to an operation of the target payer 110 when the payment terminal 130 is making a payment. The payment code 132 is a readable graphical identifier that carries information. The computer writes information into the payment code 132 by encoding during the generation of the payment code 132. The information in the electronic code may be automatically identified by scanning the payment code 132 through an image input device or an optoelectronic scanning device. The payment code 132 may be a bar code or a two-dimensional code. The two-dimensional code (dimensional barcode), also called two-dimensional bar code, is a bar code with readability which is expanded on the basis of one-dimensional bar code, is characterized by that it uses a certain specific geometric figure to record data symbol information according to black-white alternate graph distributed in planar two-dimensional direction according to a certain rule, and utilizes the concept of "0" bit stream and "1" bit stream which form internal logic basis of computer on the code programming, and uses several geometric shapes correspondent to binary system to represent literal numerical information, and utilizes image input equipment or photoelectric scanning equipment to automatically read so as to implement automatic information processing. Since the black-and-white pattern in the two-dimensional code corresponds to "0" or "1" in the binary number, respectively, the information contained therein is generally identified by identifying the pattern arrangement rule of the black-and-white color. The payment code 132 may carry information associated with the target payer 110, such as a device identification of the payment terminal 130 associated with the target payer 110, or a payment account associated with the target payer 110, etc.

The collection system 140 may store data or instructions for performing the payment processing methods described herein and may execute or be used to execute the data and/or instructions. The collection system 140 may include a hardware device having a data information processing function and a program necessary to drive the hardware device to operate. Of course, the collection system 140 may be just a hardware device with data processing capability, or just a program running in a hardware device.

The collection system 140 may be any form of intelligent device capable of realizing collection function, such as a collection POS system in a mall, an IOT payment tool system, a self-service payment tool in the field of unmanned vending, and a collection system in the field of public transportation, such as a card swiping tool system on a bus, a card swiping gate system of a subway station, etc. In some embodiments, the checkout system 140 may also be a mobile device, tablet, notebook, or the like, or any combination thereof. As shown in FIG. 1, the checkout system and 140 may include an acquisition device 142. In some embodiments, the checkout system 140 may also include a display device 144.

The capture device 142 may be configured to capture a payment code displayed on the payment terminal 130 of the target payer 110. In some embodiments, capture device 142 may also capture the biometric of target payer 110. For example, the biometric characteristic is one or more of a facial image, an iris image, a sclera image, a fingerprint image, a palmprint image, a voiceprint file, a bone projection image, and the like of the target payer 110. In some embodiments, capture device 142 may include a camera. In some embodiments, acquisition device 142 may also include other modules, such as a fingerprint acquisition module, a microphone, and so forth.

Display device 144 may be used to human interface the payee system 140 with the target payer 110. In some embodiments, the human-machine interaction functionality includes, but is not limited to: web browsing, word processing, status prompting, operational input, etc. In some embodiments, display device 144 may include a display screen. The display screen may be a touch screen type Liquid Crystal Display (LCD). The display screen has a Graphical User Interface (GUI) that may enable the targeted payer 110 to human-machine interact with the payee system 140 and/or payment server 160 by touching the Graphical User Interface (GUI) and/or by gestures. In some embodiments, the display device 144 may include a voice playing means, such as a speaker. The speaker may be any form of device that can deliver audio signals. The target payer 110 may receive the voice information transmitted by the collection system 140 through the voice playing device, so as to perform man-machine interaction with the collection system 140. In some embodiments, the display device 144 may also include a voice capture device, such as a microphone. The target payer 110 may input a voice instruction or voice verification code to the payee system 140 via the voice capture device, and so on. In some embodiments, the display device 144 may include one or more of the display screen, the voice playing means, and the voice capturing means. In some embodiments, executable instructions for performing the above-described human-machine interaction functions are stored in one or more processor-executable computer program products or readable storage media. In other embodiments, executable instructions for performing the above-described human interactive functions are stored in database 150 or checkout system 140.

The payment server 160 may store data or instructions for performing the payment processing methods described herein and may execute or be used to execute the data and/or instructions. The target APP refers to a client APP corresponding to the payment server 160. The payment terminal 130 and the payment receiving system 140 may communicate with each other with the payment server 160. The payment server 160 may provide a solution to the payment of the fee for the target payer 110 (payment terminal 130) and the payment system 140 with respect to the target transaction. Payment server 160 may be a third party paymate. The payment server 160 may provide the target payer 110 and the payment system 140 with a target payment service for the target transaction as a payment intermediary for the target payer 110 and the payment system 140.

The payment server 160 may have stored therein a plurality of accounts and a device identification of the device associated with each account. The plurality of accounts includes a payment account 161 corresponding to the target payer 110 and a device identification of the payment terminal 130 associated with the target account 161. The payment account 161 stores therein digital money corresponding to the target payer 110 corresponding to the payment account 161. The payment server 160 may also store the corresponding collection account 164 of the collection system 140 and the device identification of the collection system 140 associated with the collection account 164. A payment agreement may be pre-established between the checkout system 140 and the payment server 160. The payment server 160 may facilitate charging of the target payer 110 by the payment system 140 based on the payment agreement through the digital resource transmission channel. For example, the payment server 160 may extract a target number of payment amounts from the corresponding payment accounts 161 of the target payer 110 through the digital resource transmission channel and transfer to the collection account 164 of the collection system 140.

The payment server 160 may store data or instructions for performing the payment processing methods described herein and may execute or be used to execute the data and/or instructions. The payment server 160 may include a hardware device having a data information processing function and a program necessary to drive the hardware device to operate. Of course, the payment server 160 may also be just a hardware device with data processing capabilities, or just a program running in a hardware device.

The network 120 may facilitate the exchange of information and/or data. As shown in fig. 1, the payment terminal 130, the collection system 140, the payment server 160, and the database 150 may be connected to the network 120 and transmit information and/or data to each other through the network 120. For example, payment server 160 may obtain a payment request from payment terminal 130 via network 120, payment terminal 130 may obtain a verification request from payment server 160 via network 120, payment system 140 and/or payment terminal 130 may obtain a payment result from payment server 160, and so on. In some embodiments, network 120 may be any type of wired or wireless network, or a combination thereof. For example, network 120 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network, a Near Field Communication (NFC) network, or the like. In some embodiments, network 120 may include one or more network access points. For example, network 120 may include one or more wired or wireless network access points through which one or more components of payment terminal 130, collection system 140, payment server 160, and database 150 may connect to network 120 to exchange data and/or information.

Database 150 may store data and/or instructions. In some embodiments, database 150 may store data obtained from payment terminal 130. In some embodiments, database 150 may store data and/or instructions that may be executed by or used to perform the payment processing methods described in this specification by checkout system 140 and/or payment server 160. In some embodiments, database 150 may store data obtained from checkout system 140. The payment terminal 130, the collection system 140, and the payment server 160 may have access to the database 150, and the payment terminal 130, the collection system 140, and the payment server 160 may access data or instructions stored in the database 150 through the network 120. In some embodiments, database 150 may be directly connected to payment terminal 130, payment system 140, and payment server 160. In some embodiments, database 150 may be part of payment server 160. In some embodiments, database 150 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), or the like, or any combination thereof. Exemplary mass storage may include non-transitory storage media (non-transitory storage medium) such as magnetic disks, optical disks, solid state drives, and the like. Example removable storage may include flash drives, floppy disks, optical disks, memory cards, zip disks, tape, and the like. Typical volatile read-write memory can include Random Access Memory (RAM). Example RAM may include Dynamic RAM (DRAM), dual date rate synchronous dynamic RAM (DDR SDRAM), static RAM (SRAM), thyristor RAM (T-RAM), zero capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include Mask ROM (MROM), programmable ROM (PROM), virtual programmable ROM (PEROM), electronically programmable ROM (EEPROM), compact disk (CD-ROM), and digital versatile disk ROM, among others. In some embodiments, database 150 may be implemented on a cloud platform. For example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, or the like, or any combination thereof.

Fig. 2 shows a hardware schematic of a computing device 300. In some embodiments, data or instructions for the payment server 160 and/or payment terminal 130 to perform the payment processing method may be implemented on the computing device 300. That is, a portion of the hardware structure of server 160 may be the hardware structure shown in computing device 300. A part of the hardware structure of the payment terminal 130 may also be the hardware structure shown in the computing device 300. The computing device 300 may perform the payment processing methods described herein. The payment processing method is described elsewhere in this specification.

As shown in fig. 2, computing device 300 may include at least one storage medium 330 and at least one processor 320. In some embodiments, computing device 300 may also include a communication port 350 and an internal communication bus 310. In some embodiments, computing device 300 may also include I/O component 360.

Internal communication bus 310 may connect the various system components to enable data communication among the components in computing device 300, including storage medium 330, processor 320, communication ports 350, and I/O components 360. For example, the processor 320 may send data over the internal communication bus 310 to other hardware, such as the storage medium 330 or the I/O component 360. In some embodiments, internal communication bus 310 may be an Industry Standard (ISA) bus, an Extended ISA (EISA) bus, a Video Electronics Standards (VESA) bus, a peripheral component interconnect standard (PCI) bus, and so forth.

The I/O component 360 may be used to input or output signals, data, or information. I/O component 360 supports input/output between computing device 300 and other components. In some embodiments, the I/O component 360 may include an input device and an output device. Exemplary input devices may include cameras, keyboards, mice, display screens, microphones, and the like, or any combination thereof. Exemplary output devices may include a display device, a voice playback device (e.g., speakers, etc.), a printer, a projector, etc., or any combination thereof. Exemplary display devices may include Liquid Crystal Displays (LCDs), light Emitting Diode (LED) based displays, flat panel displays, curved displays, television equipment, cathode Ray Tubes (CRTs), and the like, or any combination thereof.

Communication port 350 may connect to a network for data communication between computing device 300 and the outside world. The connection may be a wired connection, a wireless connection, or a combination of both. The wired connection may include an electrical cable, optical cable, or telephone line, or the like, or any combination thereof. The wireless connection may include bluetooth, wi-Fi, wiMax, WLAN, zigBee, a mobile network (e.g., 3G, 4G, 5G, etc.), etc., or any combination thereof. In some embodiments, the communication port 350 may be a standardized port, such as RS232, RS485, and the like. In some embodiments, communication port 350 may be a specially designed port.

Storage medium 330 may include a data storage device. The data storage device may be a non-transitory storage medium or a transitory storage medium. For example, the data storage device may include one or more of a magnetic disk 332, a read-only storage medium (ROM) 334, or a random access storage medium (RAM) 336. The storage medium 330 also includes at least one set of instructions stored in the data storage device. The instructions are computer program code that may include programs, routines, objects, components, data structures, procedures, modules, etc. that perform the payment processing methods provided herein.

The at least one processor 320 may be communicatively coupled with at least one storage medium 330 and a communication port 350 via an internal communication bus 310. The at least one processor 320 is configured to execute the at least one instruction set. When the system 100 is running, the at least one processor 320 reads the at least one instruction set and performs the payment processing methods provided herein as directed by the at least one instruction set. Processor 320 may perform all of the steps involved in the payment processing method. Processor 320 may be in the form of one or more processors, in some embodiments processor 320 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced Instruction Set Computers (RISC), application Specific Integrated Circuits (ASIC), application specific instruction set processors (ASIP), central Processing Units (CPU), graphics Processing Units (GPU), physical Processing Units (PPU), microcontroller units, digital Signal Processors (DSP), field Programmable Gate Arrays (FPGA), advanced RISC Machines (ARM), programmable Logic Devices (PLD), any circuit or processor capable of executing one or more functions, or the like, or any combination thereof. For illustrative purposes only, only one processor 320 is depicted in the computing device 300 in this specification. It should be noted, however, that computing device 300 may also include multiple processors, and thus, operations and/or method steps disclosed in this specification may be performed by one processor as described in this specification, or may be performed jointly by multiple processors. For example, if the processor 320 of the computing device 300 performs steps a and B in this specification, it should be understood that steps a and B may also be performed by two different processors 320 in combination or separately (e.g., a first processor performs step a, a second processor performs step B, or the first and second processors perform steps a and B together).

Fig. 3 shows a schematic flow chart of a payment processing method P100 according to an embodiment of the present disclosure. As previously described, the collection system 140 and the payment server 160 may perform the method P100 provided herein. Specifically, the processor 320 in the collection system 140 and the processor 320 in the payment server 160 may read the instruction set stored in their local storage media and then execute the method P100 provided in this specification according to the specification of the instruction set. The method P100 may include:

s110: the payment system 140 collects the payment code 132 of the payment terminal 130.

As previously described, the target APP of the payment terminal 130 generates and displays the payment code 132 in response to the operation of the target payer 110. The payment code 132 may be encoded with information regarding the payment account 161 of the targeted payer 110. The checkout system 140 may collect the payment code 132 via the collection device 142. Specifically, the target payer 110 may capture or scan the payment code 132 by directing the payment code 132 to a capture device 142 (camera) of the collection system 140.

S120: the payment system 140 generates a payment request based on the collected payment code 132 and sends the payment request to the payment server 160. The payment request may include the device identification of the payment system 140, the transaction amount, and the payment code 132 of the payment terminal 130 collected by the payment system 140.

S130: the payment request is identified, and it is determined whether the payment request requires verification.

Fig. 4 shows a schematic flow chart for identifying whether a payment request needs to be verified according to an embodiment of the present disclosure. Fig. 4 corresponds to step S130. Specifically, step S130 may include:

s132: the payment server 160 identifies the payment request, determines the collection account 164 associated with the device identification of the collection system 140, and identifies the payment account 161 corresponding to the payment code 132 and the device identification of the payment terminal.

As previously described, each account and the device identification associated with each account may be stored in the payment server 160. The payment server 160 may determine, based on the payment request, a payment account 162 associated with the payment system 140 and a payment account 161 corresponding to the payment code 132 and a device identification of the payment terminal. The payment request may be to transfer the same amount of virtual digital currency as the transaction amount from the payment account 161 to the collection account 164.

S134: the payment server 160 determines whether the payment request requires the verification based on the recognition result of the payment request.

Step S134 may include at least one of the following:

Comparing the payment request with the payment policy of the payment account 161, and determining that the payment request needs to be validated when the payment request does not meet the payment policy, otherwise, not needing to be validated; and

and performing risk assessment on the payment request, and determining that the payment request needs to be verified when the risk value of the payment request is higher than a risk threshold value, or else, not needing to be verified.

The target payer 110 may preset the payment policy for the payment account 161. The payment policy may include at least one of a payment amount limit policy and a collection account limit policy. The payment amount limiting policy may be to limit the maximum amount of transactions of the payment account 161 within a preset time window. When the transaction amount is lower than the transaction maximum amount, the payment request meets the payment policy without the verification; when the transaction amount exceeds the transaction maximum amount, the payment request does not satisfy the payment policy and the verification is required. The preset time window may be a single time or a single day or month, etc. The collection account restriction policy may be that the target payer 110 restricts the payee of the target transaction. For example, the targeted payer 110 may prohibit transactions with a game account or other set account, and so forth.

The risk assessment may be based on a risk assessment model preset in the payment server 160. The risk assessment model may be machine learned based on historical data. The payment server 160 may identify the device identification of the payment terminal 130 and the payment account 161 based on the payment request. The payment server 160 may also identify the current location information of the payment terminal 130. The payment server 160 may perform risk assessment on the payment request based on the risk assessment model based on historical transaction data of the target payer 110 (including, but not limited to, historical collection account, historical transaction amount, historical transaction merchandise, historical transaction time, etc.), historical transaction location, device identification of the device used by the historical transaction, etc. When the risk value of the payment request is higher than the risk threshold value, indicating that the payment request is at risk, wherein the payment request needs to be verified; when the risk value does not exceed the risk threshold, indicating that the payment request is at low risk, the payment request does not require the verification.

The method P100 may further include:

s140: the payment server 160 determines that the payment request needs to be authenticated and sends an authentication request to the payment terminal 130 and the payment receiving system 140. The payment terminal 130 and the collection system 140 receive and display the authentication request transmitted from the payment server 160. Specifically, the payment server 160 may generate the authentication request based on the payment request and transmit the authentication request to the payment terminal 130 and the payment receiving system 140, respectively.

When the payment server 160 recognizes that the payment request requires authentication of the target payer 110, the authentication request is generated and transmitted to the payment terminal 130 and the payment receiving system 140, respectively. The checkout system 140 may display the verification request via the display device 144. The authentication requests sent by the payment server 160 to the payment terminal 130 and the payment system 140 may be the same or different.

In some embodiments, the authentication request sent by the payment server 160 to the payment terminal 130 and the authentication request sent to the collection system 140 may be the same. The authentication request may be one or more of an acknowledgement request for the payment request and an authentication request for the target payer 110.

The confirmation request of the payment request may be a request for the target payer 110 to confirm transaction information in the payment request. Specifically, the confirmation request of the payment request may be a request for the target payer 110 to confirm whether the transaction information such as the payment account 161, the collection account 164, and the transaction amount is correct or is operated by the person, etc. For example, confirmation requests for the payment request are displayed on the payment terminal 130 and the payment receiving system 140 to prompt the target payer 110 to confirm whether the current transaction request is allowed. FIG. 5 illustrates an interface diagram of a checkout system 140 displaying a verification request, provided in accordance with an embodiment of the present disclosure. The validation request shown in fig. 5 may be an acknowledgement request for the payment request.

In some embodiments, the authentication request may be an authentication request for the target payer 110. The authentication request may be a request to verify the identity legitimacy of the target payer 110. The authentication request may include at least one of a payment password authentication request, a biometric authentication request, and a passcode authentication request. The biometric authentication request may include at least one of a facial image authentication request, an iris authentication request, a sclera authentication request, a fingerprint authentication request, a palmprint authentication request, a voiceprint authentication request, a skeleton projection authentication request. FIG. 6 illustrates an interface schematic diagram of a checkout system 140 displaying the verification request provided in accordance with an embodiment of the present description. The authentication request shown in fig. 6 may be an authentication request for the target payer 110. The authentication request for the target payer 110 may be to directly select one of a plurality of authentication methods for the authentication of the target payer 110. For example, one of the payment password authentication request, the biometric authentication request, and the passcode authentication request is selected directly for the identity authentication by the target payer 110. The authentication request for the target payer 110 may also be selected by listing all authentication requests by way of a list, and the authentication is performed on the target payer 110 by way of the target payer 110 selection according to the selection operation of the target payer 110. The authentication request for the target payer 110 may also be one default from a plurality of authentication request modes, and a button for "switch authentication mode" may be set aside for the target payer 110 to select.

In some embodiments, the authentication request sent by payment server 160 to payment terminal 130 and the authentication request sent to collection system 140 may be different. For convenience of description, we define the authentication request transmitted from the payment server 160 to the payment terminal 130 as a first authentication request. We define the authentication request sent by the payment server 160 to the collection system 140 as a second authentication request. The authentication request includes the first authentication request and the second authentication request.

The first authentication request may include at least one of the confirmation request for the payment request and the authentication request for the target payer 110. The confirmation request for the payment request and the authentication request for the target payer 110 are as described above, and will not be described in detail herein.

The second authentication request may include one or more of the confirmation request for the payment request, the authentication request for the target payer, and a request prompting the target payer 110 to complete the authentication through the payment terminal 130. FIG. 7 illustrates an interface diagram of a checkout system 140 displaying a verification request, provided in accordance with an embodiment of the present disclosure. The authentication request shown in fig. 7 may be a request prompting the target payer 110 to complete the authentication through the payment terminal 130. I.e., prompt the target payer 110 to complete the verification at the payment terminal 130 in time via the display device 144 of the payee system 140.

The checkout system 140 may include a variety of information delivery means for displaying the verification request via the display device 144. For example, the collection system 140 may display the verification request through the display screen of the collection system 140; the collection system 140 may also broadcast the verification request through a voice playing device of the collection system 140; the collection system 140 may also directly display the verification request on the display screen of the collection system 140, and simultaneously broadcast the verification request to the outside through the voice playing device, so as to better remind the target payer 110 of the current payment state of the payment request in the payment process.

The method P100 may further include:

s160: the payment terminal 130 or the collection system 140 receives the operation of the target payer 110 in response to the authentication request, generates the authentication result, and transmits the authentication result to the payment server 160, and the payment server 160 receives the authentication result transmitted from the payment terminal 130 or the collection system 140 in response to the authentication request.

The target payer 110 may complete the verification through either the payment terminal 130 or the payee system 140. When the authentication request received by the payment terminal 130 and the collection system 140 is one or more of a confirmation request for the payment request and an authentication request for the target payer 110, the target payer 110 may respond to the authentication request through a man-machine interaction interface of the payment terminal 130 or a man-machine interaction interface of the collection system 140. When the verification request is a confirmation request for the payment request, the target payer 110 may confirm the payment request through a man-machine interface of the payment terminal 130 or a man-machine interface of the collection system 140 to confirm that the payment request is a request that the target payer 110 is operating. When the authentication request is an authentication request for the target payer 110, the target payer 110 may input authentication information through a man-machine interface of the payment terminal 130 or a man-machine interface of the collection system 140 for authentication.

Specifically, the targeted payer 110 may respond to the verification information through a display device 144 (such as the display screen).

In the method P100, the target payer 110 may perform the verification in the payment terminal 130 or the payment system 140, so that the verification is more flexible, the target payer 110 can complete the verification faster and more conveniently, the verification speed is increased, and the payment efficiency and the user experience are improved.

The payment server 160 may identify the verification result and determine whether the verification result passes. When the verification request is a confirmation request for the payment request, the verification result is passed when the verification result is "ok". When the authentication request is an authentication for the target payer 110, the authentication result is passed when the authentication result input by the target payer 110 matches data previously stored in the payment server 160 and associated with the payment account 131. Otherwise, the verification result is not passed.

S180: when the verification is determined to pass, the payment server 160 executes the payment request and transmits a payment result to the payment system 140 and the payment terminal 130, and the payment system 140 and/or the payment terminal 130 receives and displays the payment result transmitted by the payment server 160.

Specifically, when the verification is passed, the payment server 160 may transfer the same amount of virtual digital money as the transaction amount from the payment account 161 to the collection account 164, and simultaneously transmit a payment result of "successful payment" to the collection system 140 and the payment terminal 130.

When the verification is not passed, the payment server 160 does not execute the payment request. The payment server 160 may initiate the verification request again, and the payment server 160 may not continue to execute the payment application until the verification result input by the target payer 110 passes. The payment server 160 may also directly close the payment application when the verification fails. The payment server 160 may also perform a limited number of said authentications again when said authentications are not passed, and the payment server 160 may close said payment application when all authentication results within said limited number of times are not passed. When the payment server 160 closes the payment application, the payment server 160 transmits a payment result of "payment failure" to the payment terminal 130 and the payment collecting system 140.

It should be noted that, in step S130, when the payment server 160 recognizes that the payment application does not need to be validated, the method P100 directly executes the payment request and sends a payment result to the payment system 140 and the payment terminal 130.

It should be noted that the system 001 and the method P100 may be applied not only to the scene of code scanning payment, but also to other payment scenes, such as face scanning payment, fingerprint payment, and so on.

In summary, in the payment processing method P100 and the system 100 provided in the present disclosure, the payment collecting system 140 sends a payment request to the payment server 160 after collecting the payment code 132 on the payment terminal 130; the payment server 160 identifies whether the payment request requires verification; when the payment request needs to be verified, the payment server 160 sends the verification request to the collection system 140 and the payment terminal 130 at the same time, and displays the verification request through the collection system 140, and reminds both the collection party and the payment party of the state of the payment request in the payment process, so as to remind the payment party of verifying the payment request in time. When the payer verifies the payment request, the payer may complete the payment by operating the payment terminal 130 to generate a verification result in response to the verification request, or by operating the payee system 140 to generate a verification result in response to the verification request. The payment processing method P100 and the system 100 provided by the specification can prompt the payee and the payer of the state of the payment order in the payment process timely and effectively, improve the capability of code scanning payment anti-lost bill of an offline scene and improve the payment success rate.

Another aspect of the present description provides a non-transitory storage medium storing at least one set of executable instructions for payment processing that, when executed by a processor, direct the processor to perform the steps of the payment processing method P100 described herein. In some possible implementations, aspects of the specification can also be implemented in the form of a program product including program code. The program code is for causing the computing device 300 to perform the payment processing steps described herein when the program product is run on the computing device 300. The program product for implementing the methods described above may employ a portable compact disc read only memory (CD-ROM) comprising program code and may run on computing device 300. However, the program product of this specification is not limited thereto, and in this specification, the readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system (e.g., processor 320). The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The computer readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, with readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable storage medium may also be any readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Program code for carrying out operations of the present specification may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on computing device 300, partly on computing device 300, as a stand-alone software package, partly on computing device 300, partly on a remote computing device, or entirely on a remote computing device.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can 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 are also possible or may be advantageous.

In view of the foregoing, it will be evident to a person skilled in the art that the foregoing detailed disclosure may be presented by way of example only and may not be limiting. Although not explicitly described herein, those skilled in the art will appreciate that the present description is intended to encompass various adaptations, improvements, and modifications of the embodiments. Such alterations, improvements, and modifications are intended to be proposed by this specification, and are intended to be within the spirit and scope of the exemplary embodiments of this specification.

Furthermore, certain terms in the present description have been used to describe embodiments of the present description. For example, "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present description. Thus, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined as suitable in one or more embodiments of the invention.

It should be appreciated that in the foregoing description of embodiments of the present specification, various features have been combined in a single embodiment, the accompanying drawings, or description thereof for the purpose of simplifying the specification in order to assist in understanding one feature. However, this is not to say that a combination of these features is necessary, and it is entirely possible for a person skilled in the art to extract some of them as separate embodiments to understand them upon reading this description. That is, embodiments in this specification may also be understood as an integration of multiple secondary embodiments. While each secondary embodiment is satisfied by less than all of the features of a single foregoing disclosed embodiment.

Each patent, patent application, publication of patent application, and other materials, such as articles, books, specifications, publications, documents, articles, etc., cited herein are hereby incorporated by reference. The entire contents for all purposes, except for any prosecution file history associated therewith, may be any identical prosecution file history inconsistent or conflicting with this file, or any identical prosecution file history which may have a limiting influence on the broadest scope of the claims. Now or later in association with this document. For example, if there is any inconsistency or conflict between the description, definition, and/or use of terms associated with any of the incorporated materials, the terms in the present document shall prevail.

Finally, it is to be understood that the embodiments of the application disclosed herein are illustrative of the principles of the embodiments of the present specification. Other modified embodiments are also within the scope of this specification. Accordingly, the embodiments disclosed herein are by way of example only and not limitation. Those skilled in the art can adopt alternative arrangements to implement the application in the specification based on the embodiments in the specification. Therefore, the embodiments of the present specification are not limited to the embodiments precisely described in the application.

Claims

1. A payment processing method is applied to a payment server and comprises the following steps:

receiving a payment request from a payment receiving system, wherein the payment request is sent by the payment receiving system under the condition of scanning a payment code of a payment terminal; and

and respectively sending verification requests to the payment terminal and the collection system in response to the payment requests to be verified, so as to prompt the payer and the collection party that the payment requests are in a state to be verified.

2. The method of claim 1, wherein the payment request requires verification of a payment scenario corresponding to: verification is also required to be passed in order to perform payment if the payment code is scanned successfully.

3. The method of claim 1, wherein the payment request requires verification, comprising:

the payment request does not meet a target payment policy, wherein the target payment policy comprises a payment policy of a payment account corresponding to the payment request.

4. A method according to claim 3, wherein the payment policy comprises at least one of:

payment limit policy, and

the collection account restriction policy.

5. The method of claim 1, wherein the payment request requires verification, comprising:

and the risk value corresponding to the payment request is higher than a risk threshold, wherein the risk value is obtained by carrying out risk assessment on the payment request through a preset risk assessment model.

6. The method of claim 1, wherein the authentication request comprises at least one of:

a transaction confirmation request for confirming transaction information in the payment request;

an authentication request for authenticating the identity of the payer; and

and prompting a request for prompting the payer to complete the verification request.

7. The method of claim 1, wherein the authentication request comprises a first authentication request and a second authentication request, the first authentication request and the second authentication request being different; and

The sending of the verification request to the payment terminal and the collection system respectively includes:

transmitting the first authentication request to the payment terminal, and

and sending the second verification request to the collection system.

8. The method of claim 7, wherein the first authentication request comprises at least one of:

a transaction confirmation request for confirming transaction information in the payment request; and

an authentication request for authenticating the identity of the payer.

9. The method of claim 7, wherein the second authentication request comprises at least one of:

an authentication request for authenticating the identity of the payer; and

10. The method of claim 6, 8 or 9, wherein the authentication request comprises at least one of: a payment password authentication request, a biometric authentication request, and a passcode authentication request.

11. The method of claim 1, further comprising:

receiving verification results sent by the payment terminal and/or the collection system; and

and if the verification result is that the verification is passed, executing payment to obtain a payment result, and sending the payment result to the collection system and the payment terminal.

12. The method of claim 1, further comprising:

identifying information carried in the payment request to obtain an identification result; and

based on the identification result, it is determined whether the payment request requires verification.

13. A payment processing method applied to a collection system, comprising:

transmitting a payment request to a payment server in response to scanning a payment code to the payment terminal; and

and receiving a verification request from the payment server, wherein the verification request is sent by the payment server in response to the payment request, and the verification request is used for prompting a payee that the payment request is in a state to be verified.

14. The method of claim 13, wherein the payment request requires verification of a payment scenario corresponding to: verification is also required to be passed in order to perform payment if the payment code is scanned successfully.

15. The method of claim 13, wherein the payment request requires verification, comprising:

16. The method of claim 15, wherein the payment policy comprises at least one of:

payment limit policy, and

the collection account restriction policy.

17. The method of claim 13, wherein the payment request requires verification, comprising:

18. The method of claim 13, wherein the authentication request comprises at least one of:

a transaction confirmation request for requesting confirmation of transaction information in the payment request;

an authentication request for authenticating the identity of the payer; and

19. The method of claim 18, wherein the authentication request comprises at least one of: a payment password authentication request, a biometric authentication request, and a passcode authentication request.

20. The method of claim 13, further comprising:

sending a verification result corresponding to the verification request to the payment server; and

and receiving a payment result from the payment server, wherein the payment result is obtained by the payment server by executing payment under the condition that the verification result is verification passing.

21. The method of claim 13, further comprising, after receiving the authentication request, at least one of:

displaying the verification request through a display screen; and

and broadcasting the verification request through a voice playing device.

22. A payment server, comprising:

at least one storage medium storing at least one set of instructions for payment processing; and

at least one processor in communication with the at least one storage medium, wherein the at least one processor reads the at least one instruction set to implement the method of any one of claims 1 to 12 when the payment server is running.

23. A cash collection system, comprising:

the acquisition device is configured to scan a payment code of the payment terminal;

At least one processor communicatively coupled to the at least one storage medium, wherein the at least one processor reads the at least one instruction set to implement the method of any of claims 13-21 when the checkout system is operating.

24. The payment system of claim 23, further comprising at least one of:

a display configured to display the authentication request; and

and the voice playing device is configured to broadcast the verification request.