TWI692734B - Bill payment checking system and method thereof - Google Patents

Abstract

Present disclosure relates to a bill payment checking system. The system includes a user agent device and a financial institution server. The user agent device is configured to recognize a graphical payment medium to generate a payment request. The financial institution server is configured to receive the payment request and extract a consumer behavior from the payment request. The financial institution server sends the consumer behavior to an enterprise server for verification. If the consumer behavior being verified as an unpaid bill, the financial institution server sends a transaction instruction to the user agent device. When the user agent device completes a payment based on transaction instruction, the financial institution server generates a transaction confirmation accordingly. The financial institution then sends the transaction confirmation to the enterprise server for account reconciliation.

Description

Payment check system and method

This case relates to a payment verification system and method, especially a system and method for instantly confirming payment information and real-time charge-off.

In today's highly digitalized services, most users have become dependent on the digital financial services provided by bankers. However, regarding the online payment service, the current technology still has several defects. For example, none of the current online payment services can confirm the consumption content in real time, nor can they quickly pay and complete the charge-off operation. In this way, it will be easy to extend the problems of repeated payment of users or repeated accounting of enterprises.

Therefore, it is obvious that the current online payment service system still has defects and needs to be improved urgently.

An implementation form of the case involves a payment verification system. The payment verification system includes a client device and a financial institution server. The user terminal device is used to identify a graphical payment medium to generate a payment message. The financial institution server is communicatively coupled to the client device and an enterprise server. The The financial institution server is used to receive the payment message. The financial institution server obtains a consumption behavior from the payment message. The financial institution server further transmits the consumption behavior to the enterprise server for verification. If the consumption behavior is verified as unpaid by the enterprise server, the financial institution server returns a payment instruction to the client device. When the client device completes payment according to the payment instruction, the financial institution server generates a transaction completion message, and the financial institution server further sends the transaction completion message to the enterprise server for write-off.

Another implementation form of the case involves a method for checking payment. The payment checking method includes the following steps: identifying a graphical payment medium through a client device to generate a payment message; receiving the payment message through a server of a financial institution; and obtaining the payment message from the payment message through a server of the financial institution A consumption behavior; send the consumption behavior to the enterprise server through the financial institution server for verification; if the consumption behavior is verified as unpaid by the enterprise server, return a payment instruction to the enterprise through the financial institution server A client device; when the client device completes payment according to the payment instruction, a transaction completion message is generated through the financial institution server; and the transaction completion message is sent to the enterprise server through the financial institution server for sales account.

Therefore, according to the technical content of this case, the embodiments of this case provide a payment verification system and a payment verification method, so as to improve the problem of double payment and double entry in the prior art.

100‧‧‧Client device

101‧‧‧Verification device

200‧‧‧Financial institution server

201‧‧‧ Front-end application subserver

202‧‧‧ Mid-range system subserver

203‧‧‧Back-end accounting sub-server

300‧‧‧Enterprise Server

400‧‧‧Mobile device

400D‧‧‧Display screen

S201~S207‧‧‧Step flow

PB‧‧‧Payment notice

QRC‧‧‧Quick response barcode

ICON1‧‧‧ First option

ICON2‧‧‧Second option

Figure 1 is a schematic diagram of a payment verification system based on an embodiment of the case; Figure 2 is a flowchart of steps of a payment verification method based on an embodiment of the case; Figure 3 is a drawing based on an embodiment of the case Figure 4 is a schematic diagram of the identification situation based on an embodiment of the case; Figure 5 is a schematic diagram of the payment situation based on an embodiment of the case; and Figure 6 is a schematic diagram based on the case The schematic diagram of the payment scenario shown in the embodiment.

The following will clearly illustrate the spirit of the case with diagrams and detailed descriptions. Anyone with ordinary knowledge in the technical field who understands the embodiments of the case will be able to change and modify the techniques taught in the case without departing from the case. Spirit and scope.

As used herein, "coupled" or "connected" can refer to two or more elements or devices making direct physical contact with each other, or indirectly making physical contact with each other, or can refer to two or more elements or devices making mutual contact Operation or action.

As used herein, "and/or" includes any or all combinations of the things described.

Regarding the terms used in this article, unless otherwise noted, they usually have the ordinary meaning that each term is used in this field, in the content of this case, and in special content. Certain terms used to describe this case will be discussed below or elsewhere in this specification to provide those skilled in the art with regard to this case. Describe additional guidance.

Figure 1 is a schematic diagram of a payment check system based on an embodiment of this case. As shown in FIG. 1, in this embodiment, the payment verification system includes a client device 100 and a financial institution server 200. The client device 100 is communicatively coupled to the financial institution server 200. It should be noted that the communication coupling referred to herein may be physical or non-physical coupling. For example, the client device 100 and the financial institution server 200 can be connected to a network through wireless communication technology (Wi-Fi), so that the client device 100 and the financial institution server 200 can pass through the network Way for two-way message exchange. Alternatively, the client device 100 and the financial institution server 200 can be connected to the network through a physical line. Similarly, the client device 100 and the financial institution server 200 can exchange messages in both directions through the network . In FIG. 1, an enterprise server 300 is further illustrated. Similarly, the financial institution server 200 is communicatively coupled with the enterprise server 300. The communication coupling referred to here can refer to the above explanation, and will not be repeated here.

In this embodiment, the client device 100 in the data transfer system 100 is further coupled to a verification device 101. The coupling relationship between the verification device 101 and the client device 100 is to realize certain functions of this case. The actual content of these functions will be described in detail later. In this embodiment, the client device 100 may be a software application program that is adapted to cooperate with the financial institution server 200 to implement the payment verification function in this case. It should be noted that in some embodiments, the user device 100 is installed (or installed) on an electronic device with input equipment, output equipment, and a display screen, whereby the user can Input equipment or output equipment to operate the user equipment By setting 100, the user can also instantly understand where the payment verification function of the case is going through the display screen of the electronic device, and the client device 100 utilizes the processor in the electronic device to perform its function. In some embodiments, the client device 100 is the electronic device itself, and is adapted to cooperate with the financial institution server 200 to implement the payment verification function in this case. For example, the electronic device may be a notebook computer, a smart mobile device, a tablet computer, etc. However, the electronic device must have a function to connect to the network in order to achieve the technical purpose of this case.

In this embodiment, the financial institution server 200 belongs to a specific financial institution, such as a cooperative vault bank. As shown in the figure, the financial institution server 200 further includes three parts, namely a front-end application sub-server 201, a mid-end system sub-server 202, and a back-end accounting sub-server 203. The front-end application sub-server 201 is mainly used to exchange information with the client device 100 so that the content of the information exchange can be correctly displayed on the display screen of the electronic device. Wherein, the mid-end system sub-server 202 is coupled between the front-end application server 201 and the back-end accounting sub-server 203. The mid-end system sub-server 202 is mainly used to exchange information between the front-end application sub-server 201 and the financial institution server 200. When certain conditions are met, the mid-end system sub-server 202 can exchange information with the back-end accounting sub-server 203. It should be noted that the above servers are all equipped with corresponding processors and memory to perform their intended functions.

In this embodiment, the enterprise server 200 belongs to a certain enterprise or company line number, especially an enterprise or company line number with financial commodities, consumer goods or consumer products as its main business. In the embodiment of this case, the operation should be used The user of the client device 100 has traded with the above-mentioned enterprise or company line number, so the enterprise server 200 stores at least one piece of consumer behavior data related to the user of the client device 100, and each of these consumer behavior data Should correspond to at least one consumption amount. It should be noted that this server is also equipped with a corresponding processor and memory to perform its intended function.

Figure 2 is a flow chart of the steps of the payment verification method based on an embodiment of the present case. In this embodiment, the payment checking method can be executed by the client device 100, the financial institution server 200, and the enterprise server 300 in the embodiment of FIG. For the configuration of the client device 100, the financial institution server 200, and the enterprise server 300, please refer to FIG. 1 together. In this embodiment, the steps included in the payment verification method will be described in detail in the following paragraphs.

In this embodiment, the user who operates the client device 100 once made a policy transaction with the life company that owns the enterprise server 300, so the enterprise server 200 stores a piece of consumer behavior data corresponding to the policy transaction. The correspondent bank of the user of the user terminal device 100 is a cooperative vault bank. The cooperative vault bank can provide an application program for generating a quick response barcode (QR code) of the company or company bank number that owns the enterprise server 300. Through this application, the life company can convert this consumer behavior data into an encrypted fast-response barcode. The life insurance company can also print the encrypted quick response barcode on the payment notice, and then mail the payment notice to the user of the user device 100.

It should be noted that the above background context is only an example to facilitate the description of the technical features of this case, rather than to limit the implementation of this case. In the field It should be understood that through the description of the context of this case, the payment verification system and payment verification method of this case can be implemented into various feasible transaction processes.

In order to better understand the case, please refer to Figure 3 of the case. Figure 3 is a schematic diagram of a payment notice based on an embodiment of the case. As shown in the figure, the payment notice PB is the payment notice provided by the life insurance company in the foregoing embodiment. In the payment notice PB, the name of the life insurance company, the details of the policy purchased by the user, the amount owed, etc. are recorded. It should be noted that, in the upper right corner of the payment notice PB, the quick response barcode QRC is printed, and the quick response barcode QRC is an image-based payment medium converted from the consumption behavior data.

Step S201: Identify an imaged payment medium through a client device to generate a payment message. As shown in FIG. 1, in an embodiment, after the user of the client device 100 receives the payment notice, the user can scan and print on the payment notice through the electronic device installed with the client device 100 Quick response barcode. In order to better understand the case, please refer to Figure 4 of the case. Figure 4 is a schematic diagram of the recognition situation based on an embodiment of the case. In this embodiment, the user device 100 is installed on a mobile device 400, and the user can shoot the quick response barcode QRC as shown in FIG. 3 through the optical sensor of the mobile device 400. As shown in the figure, the user aligns the quick response barcode QRC through the optical sensor of the mobile device 400, and the quick response barcode QRC is displayed on a display screen 400D of the mobile device 400. In this way, the user terminal device 100 can recognize the quick response barcode, thereby generating a payment message. The payment message can be understood as a payment request. Generally speaking, the payment message can be a preset URL, and the preset URL will be directed to the financial institution The front-end application subserver 201 in the server 200 is configured.

Step S202: Receive the payment message through a financial institution server. As shown in FIG. 1, in this embodiment, when the client device 100 is connected to the front-end application subserver 201 through the default URL, the front-end application subserver 201 forwards the payment message to the Mid-end system subserver 202.

Step S203: Obtain a consumption behavior from the payment message through the server of the financial institution. As shown in FIG. 1, in this embodiment, the mid-end system subserver 202 of the financial institution server 200 receives the payment message generated by the quick response barcode. It should be noted that since the application program used to generate the quick response barcode is provided by the cooperative vault bank, the mid-end system sub-server 202 should be provided with a decryption algorithm corresponding to this application, by which the mid-end The system sub-server 202 can decrypt the payment message through a decryption algorithm to obtain the consumption behavior from the payment message.

Step S204: Send the consumption behavior to the enterprise server through the financial institution server for verification. As shown in FIG. 1, in this embodiment, the mid-end system subserver 202 of the financial institution server 200 forwards the payment message to the enterprise server 300, so that the enterprise server 300 responds to the consumption behavior Verify. First, the enterprise server 300 will verify whether the consumption behavior is true. If the consumption behavior transmitted by the mid-end system sub-server 202 does indeed correspond to the consumption behavior recorded in the enterprise server 300, then the consumption is judged The behavior is true.

Step S205: If the consumption behavior is verified as unpaid by the enterprise server, a payment instruction is returned to the user terminal through the financial institution server Set. As shown in FIG. 1, in this embodiment, if the consumption behavior is true, the enterprise server 300 will verify whether the consumption behavior is unpaid, and if the enterprise server 300 determines that the consumption behavior is indeed unpaid, the enterprise The server 300 will return a payment instruction to the mid-end system sub-server 202. If the enterprise server 300 determines that the consumption behavior has been paid, the enterprise server 300 will return a paid message to the mid-end system sub-server SERVER 202. It should be noted that if the user of the client device 100 meets certain preferential plan options, certain marketing product options, or certain service options, the payment instruction or the paid message will include the preferential plan options, the marketing Product option or the service option. Successively, when the mid-end system sub-server 202 receives the billing instruction or the billed message, the mid-end system sub-server 202 will forward the billing instruction or the billed payment through the front-end application sub-server 201 Message to the client device 100.

It should be noted that in some embodiments, the preferential solution option may be a preferential content that matches the user's consumption behavior, for example: the consumption behavior can be discounted after a certain condition is met, and the consumption behavior can be obtained after a certain condition is met Giveaways and so on. In some embodiments, the marketing product option may be marketing content that matches the user's consumption behavior, such as: other products that are homogenous with the consumption behavior, other products that have complementary properties with the consumption behavior, and so on. In some embodiments, the service option may be service content that matches the consumer's consumption behavior, for example: online customer service about the consumption behavior, accounting confirmation service about the consumption behavior, and so on. However, it should be understood that the implementation of this case is not limited to this.

Step S206: After the user terminal device completes payment according to the payment instruction, a transaction completion message is generated through the financial institution server. As before As mentioned, in this embodiment, the mid-end system sub-server 202 will forward the billing instruction or the billed message to the client device 100 through the front-end application sub-server 201. Generally speaking, when the user terminal device 100 receives the payment instruction or the paid message, it will present the payment instruction or the paid message to the user through graphical or voice expression. In order to better understand this case, please refer to Figure 5 of this case. Figure 5 of this case is a schematic diagram of a payment scenario based on an embodiment of this case. Similar to the embodiment of FIG. 4, in this scenario, the user device 100 receives the payment instruction, and the user device 100 can display the payment instruction through the display screen 400D of the mobile device 400. As shown in the figure, the display screen 400D displays the consumption behavior content confirmed by the enterprise server 300.

It is worth noting that on the display screen 400D, a first option ICON1 and a second option ICON2 are displayed, wherein the first option ICON1 displays "confirm payment", and the second option ICON2 The one shown is "Contact Customer Service". It should be understood that, because the user's consumption behavior conforms to a certain service option, the service instruction is included in the payment instruction, and the client device 100 may present the service option on the display screen 400D for the user select. In this embodiment, if the user selects the second option ICON2, the client device 100 can be connected to the customer service webpage of the life insurance company through the network, so that the user can perform subsequent enquiries, consumer behavior denial/confirmation, etc. service. In this embodiment, if the user selects the first option ICON1, the client device 100 can be connected to the front-end application sub-server 201 through the network to perform the payment action.

As mentioned above, if the user selects the first option ICON1, a Generally speaking, the front-end application sub-server 201 can provide a number of different payment options for users to choose, such as: credit card swipe, debit, deduction from account, etc., the front-end application sub-server 201 can return the options to the client device 100, the client device 100 can display the options through the display screen 400D, and the user can choose which payment option to pay through. It should be noted that, because this procedure involves the security of transaction confirmation, this case further provides a reliable verification mechanism. In some embodiments, as shown in FIG. 1, the client device 100 can be further coupled to the verification device 101. Through the verification device 101, the client device 100 and the financial institution server 200 can The user device 100 is currently authenticated by the user. In some embodiments, the verification device 101 is a device for obtaining user identity verification information. For example, the client device 100 can obtain a credential message, a facial feature, One or more of an iris feature, a voiceprint feature, or a fingerprint feature, the client device 100 returns these messages or features to the front-end application subserver 201, and the front-end application sub The server 201 or the mid-end system sub-server 202 has stored these messages or characteristics about the user, so that the financial institution server 200 can compare these messages or characteristics about the user to The user's identity is verified or stored. Therefore, in this embodiment, the client device 100 and the financial institution server 200 can increase the security of the payment process through the verification device 101 and provide users with more diversified financial services, such as online account opening, The identity verification mechanism required for online credit card application, online application financing and other financial services can also be realized through this case.

As mentioned above, the client device 100 does After the fee option completes payment, the mid-end system sub-server 202 in the financial institution server 200 will generate a transaction completion message about the consumption behavior. Since the payment procedure has been completed, the front-end application sub-server 201 also feeds back the transaction completion message to the client device 100 to notify the user of the successful payment. In order to better understand the case, please refer to Figure 6 of the case. Figure 6 is a schematic diagram of a payment scenario based on an embodiment of the case. As shown in the figure, when the client device 100 receives the transaction completion message, the client device 100 can display the transaction completion message through the display screen 400D of the mobile device 400.

It should be noted that in some embodiments, if the preferential solution option, the marketing product option, or the service option presented through the display screen 400D is selected, the financial institution server 200 further depends on the corporate preferential option, The marketing product option or the service option generates the transaction completion message. For example, if the user is interested in other products in the marketing product options, the user also selects other products in the marketing content on the client device 100 when performing the payment operation according to the payment instruction. The institutional server 200 will generate the transaction completion message according to the marketing product option.

Step S207: Send the transaction completion message to the enterprise server through the financial institution server for write-off. As shown in FIG. 1, in this embodiment, the mid-end system sub-server 202 will also send the transaction completion message to the enterprise server 200. After the enterprise server 200 receives the transaction completion message, the enterprise server 200 can immediately execute the write-off operation for the user's consumption behavior. After the enterprise server 200 completes the write-off operation for the consumption behavior, it can solve the double payment problem to be solved in this case. For example, if the user In the future, it is forgotten that the payment has been completed. When the user executes the above steps S201-S204 again, in step S204, the enterprise server 200 will return the paid information to avoid the user from paying repeatedly.

As mentioned above, in some embodiments, if the financial institution server 200 generates the transaction completion message according to the marketing product option, when the enterprise server 200 receives the transaction completion message. Life Insurance Company can contact the users to explain the marketing product options and marketing operations.

In this embodiment, when the mid-end system sub-server 202 sends the transaction completion message to the enterprise server 200, the mid-end system sub-server 202 can also send the transaction completion message to the back-end accounting child The server 203, so that the back-end accounting sub-server 203 can store the transaction completion message to facilitate subsequent checking operations. In addition, as mentioned above, since the enterprise server 200 has completed the online write-off operation immediately when the user completes the payment process, when the life insurance company and the cooperating vault bank reconcile, it will be possible to avoid possible double entry Account issues.

As can be seen from the above embodiment of the present case, by providing a payment verification system and payment verification method, the embodiment of the case allows the user to confirm the consumption behavior online and complete the payment action in real time, and the financial institution server and the enterprise server can be real-time Confirm the transaction completion message. With this, the case improves the problem of double payment and double entry in the prior art.

Although the case is disclosed as above with examples, it is not used to limit the case. Anyone who is familiar with this skill can make various changes and retouching without departing from the spirit and scope of the case, so the scope of protection of the case should be attached Application The scope defined by the patent shall prevail.

100‧‧‧Client device

101‧‧‧Verification device

200‧‧‧Financial institution server

201‧‧‧ Front-end application subserver

202‧‧‧ Mid-range system subserver

203‧‧‧Back-end accounting sub-server

300‧‧‧Enterprise Server

Claims (6)

A payment verification system includes: a client device for identifying a graphical payment medium to generate a payment message; and a financial institution server, communicatively coupled to the client device and an enterprise server, the financial The institution server is used to receive the payment message and obtain a consumption behavior from the payment message. The financial institution server further transmits the consumption behavior to the enterprise server for verification, wherein if the consumption behavior is passed by the enterprise server After verifying that the payment has not been made, the server of the financial institution returns a payment instruction to the client device. After the client device completes the payment according to the payment instruction, the server of the financial institution generates a transaction completion message and the server of the financial institution The device also sends the transaction completion message to the enterprise server for charge-off, where the payment instruction further includes a preferential plan option, a marketing product option or a service option, if the preferential plan option, the marketing product or the service The option option is selected, and the server of the financial institution generates the transaction completion message according to the corporate preferential option, the marketing product option, or the service option, wherein the graphical payment medium is an encrypted quick response barcode, when the financial institution When the server receives the payment message, the financial institution server decrypts the payment message to obtain the consumption behavior. The payment verification system as described in claim 1, wherein if the consumption behavior is verified as paid by the enterprise server, the financial institution server returns a paid message to the client device. The payment verification system according to claim 1, wherein the client device is communicatively coupled to a verification device, and when the client device executes the payment instruction for payment, the client device obtains a certificate message through the verification device , At least one of a facial feature, an iris feature, a voiceprint feature, and a fingerprint feature is returned to the server of the financial institution for verification or storage. A payment verification method, including: identifying a graphical payment medium through a client device to generate a payment message; receiving the payment message through a financial institution server; and obtaining a consumption from the payment message through the financial institution server Behavior; send the consumption behavior to the enterprise server through the financial institution server for verification; if the consumption behavior is verified as unpaid by the enterprise server, return a payment instruction to the client through the financial institution server Device, wherein the payment instruction further includes a preferential plan option, a marketing product option, or a service option; when the client device completes payment according to the payment instruction, a transaction completion message is generated through the financial institution server; through the financial The institution server sends the transaction completion message to the enterprise server for write-off; and if the preferential plan option, the marketing product option, or the service option is selected, the financial institution server is based on the enterprise preferential option, the The marketing product option or the service option generates the transaction completion message, The image payment medium is an encrypted quick response barcode, and the payment verification method further includes: when the financial institution server receives the payment message, decrypt the payment message through the financial institution server to obtain the consumption behavior . The payment check method as described in claim 4 further includes: if the consumption behavior is verified as paid by the enterprise server, returning a paid message to the client device through the financial institution server. The payment verification method as described in claim 4, further includes: when the user device executes the payment instruction to perform payment, the user device obtains a credential message, a facial feature, an iris feature through the verification device, At least one of a voiceprint feature and a fingerprint feature; and at least one of the ID message, the facial feature, the iris feature, the voiceprint feature, and the fingerprint feature is returned to the user via the client device Financial institution server for verification or storage.

Images