KR102189507B1 - System for dutch pay - Google Patents

Abstract

The present invention relates to a Dutch pay system.
The Dutch pay system according to an aspect of the present invention receives payment request information from at least one user terminal in response to a request to execute a Dutch pay for a user terminal requesting execution of a Dutch pay and a total payment amount corresponding to the input order information. And characterized in that it comprises a payment server for authenticating the payment.

Description

Dutch pay system {SYSTEM FOR DUTCH PAY}

The present invention relates to a Dutch pay system.

The mobile payment market provides convenient payment methods to both users and affiliates with the development of related technologies.

There has been a proposal for a method of embedding card information in the user terminal and performing payment using it, but when several people gather together to eat and divide the cost of the meal to make payment (i.e., if you want to make a Dutch pay) , There was an inconvenience in that each user had to express his intention to pay a certain amount of payment to the clerk, and each present a card to perform the payment.

In addition, when payment is to be performed in accordance with a Dutch Pay request at the affiliated store, it is inconvenient to individually input the payment information and reconfirm whether the payment for the total payment amount has been completed.

The present invention has been proposed in order to solve the above-described problem, and by performing a Dutch pay by a plurality of user terminals through each payment or designation of a payer in an application, the user does not need to present his or her card directly to the affiliated store. Its purpose is to provide a Dutch pay system that allows convenient Dutch pay.

The Dutch pay system according to an aspect of the present invention receives payment request information from at least one user terminal in response to a request to execute a Dutch pay for a user terminal requesting execution of a Dutch pay and a total payment amount corresponding to the input order information. And it characterized in that it comprises a payment server for authenticating the payment.

In the Dutch Pay system according to the present invention, a plurality of users who have received goods or services perform payment by entering their own payment amount, or by designating the amount to be paid by the user terminal that leads the Dutch Pay and paying for it. By performing, there is an effect that a quick and reliable Dutch pay is possible.

According to the present invention, users can intuitively check the status of the Dutch Pay payment through their terminal, increasing the convenience of entering or allocating the payment amount, and also from the perspective of a merchant providing goods or services. There is an effect of solving the problem that the payment waiting time is increased by complicatedly individually performing input and payment for the Dutch Pay payment amount separately.

According to the present invention, it is possible for users to perform Dutch Pay using a mobile terminal according to their own choice, or to pay the amount to be paid by cash or plastic card among the amount subject to Dutch Pay. Providing infrastructure has a possible effect.

According to the present invention, a payment request is made not only to the person who shared the goods or services, but also to the person who shared the goods or service by sharing the bill (payment request information) for order information, thereby making a third party payment by making a payment request to the person who has shared the goods or services. There is an effect that can perform Dutch pay through.

The effects of the present invention are not limited to those mentioned above, and other effects that are not mentioned will be clearly understood by those skilled in the art from the following description.

1 is a block diagram showing a Dutch pay system according to an embodiment of the present invention.
2 to 4 are diagrams showing each payment process according to the first embodiment of the present invention.
5 to 10 are diagrams illustrating a payment process for specifying a payer according to the second embodiment of the present invention.
11 to 14 are diagrams illustrating an error message pop-up screen according to an embodiment of the present invention.

The above-described objects and other objects, advantages, and features of the present invention, and methods of achieving them will become apparent with reference to the embodiments described below in detail together with the accompanying drawings.

However, the present invention is not limited to the embodiments disclosed below, but may be implemented in a variety of different forms, and only the following embodiments are for the purpose of the invention to those of ordinary skill in the art, It is only provided to easily inform the composition and effect, and the scope of the present invention is defined by the description of the claims.

Meanwhile, terms used in the present specification are for explaining embodiments and are not intended to limit the present invention. In this specification, the singular form also includes the plural form unless specifically stated in the phrase. As used in the specification, "comprises" and/or "comprising" refers to the presence of one or more other components, steps, actions and/or elements in which the recited component, step, operation and/or element is Or does not preclude addition.

Hereinafter, before describing the embodiments of the present invention, the background from which the present invention is derived will be described first in order to aid understanding of those skilled in the art.

During lunch on weekdays, when an office worker visits a restaurant with a colleague to have lunch and pays with Dutch Pay (Officer A at table 1 orders a kimchi stew worth 7,000 won, and B with a colleague orders 8,000 won If you ordered grilled mackerel), it is described as an example.

In the first case, if each person wants to pay for the food they ordered separately, the affiliated store clerk receives 7,000 won from A, 8,000 won from B, and in the second case, divides the total payment amount to A If both of B and B want to request a payment of 7,500 won each, the affiliated store clerk must make a payment for 7,500 won to two customers, respectively.

In the second case described above, the payment amount is not automatically calculated according to the menu input on the affiliate store terminal (POS), so the affiliate store clerk directly enters the amount subject to payment of 7,500 won directly into the affiliate store terminal (POS) to proceed with payment. There is a more inconvenient problem because it should be done.

That is, as a member store, a menu or amount to be requested for payment from each customer is separately entered into the POS for the order information on the table, and the amount requested for payment is paid using cash, a physical plastic card, or payment using a user's mobile terminal (pay Application), etc., causes the hassle of having to separately perform the corresponding payment, and this causes a problem that the satisfaction of the customer drops sharply despite the increase in the labor of the clerk due to the increase in the payment waiting time.

Hereinafter, an embodiment of the present invention proposed to solve this problem will be described with reference to FIGS. 1 to 14.

1 is a block diagram illustrating a Dutch pay system according to an embodiment of the present invention.

The Dutch pay system according to an embodiment of the present invention includes at least two user terminals 100 requesting the execution of Dutch pay and at least two user terminals 100 according to the request of executing the Dutch pay with respect to the total payment amount corresponding to the input order information. ) And a payment server 400 that receives payment request information from and authenticates payment.

The user terminal 100 executes a payment app to request a Dutch pay execution, and the Dutch pay execution and its payment status are shared between the affiliated store POS 200, the affiliated store server 300, and the payment server 400.

The payment server 400 receiving a payment approval request for Dutch Pay from the user terminal 100 transmits the request to the financial institution server 500, receives the approval result from the financial institution server 500, and receives the approval result from the user terminal 100 and the affiliated store. It is delivered to the server 300 and the affiliated store POS (200).

Hereinafter, with reference to FIGS. 2 to 4, a description will be given of each payment process, which is a first embodiment of the present invention.

Hereinafter, in order to aid the understanding of those skilled in the art, a case where there are a total of three users as A, B, and C is described as an example, but the number of users executing Dutch Pay is not limited thereto.

Referring to FIGS. 2A to 2C, first, when a user (A, B, C) orders a menu, the affiliated store POS 200 inputs a table number and order details on which the user sits.

User A is connected to a mobile bill of a tag (including a unique table number) received through an NFC function or by recognizing a QR code using his user terminal 100a.

QR code recognition or NFC recognition is a recognition means for accessing order information for a tag, that is, a Dutch pay, and covers wireless communication methods such as BLE Beacon, Sound, and RF tags, and the scope of the present invention regarding the recognition means is It is not limited by this description.

As shown in Figure 2a, (a-1) through the NFC smartphone touch or QR code scan on the table through the user terminal (100a), a mobile bill is called.

An order list is displayed on the user terminal 100a as shown in (b-1), and when a selection for "Dutch Pay" and a click for "Payment" are made through the user terminal, (c-1) screen Go to.

In the (c-1) screen, user A enters the amount to be paid (8,000 won) through the input screen of his terminal 100a, then selects the "Dutch Pay" button, and selects (d- 1) After entering the payment mobile phone number on the screen, (e-1) Dutch Pay is performed through a payment app provided from the payment server 400.

In this embodiment, the sum of the order amount, that is, the total payment amount is 21,000 won, and the remaining amount 13,000 won after user A's 8,000 won payment is updated as the payment target amount, and the affiliated store POS (200) is The status is changed from "waiting for payment" to "Dutch Pay in progress" through the screen of and displayed.

The affiliated store POS 200 according to the embodiment of the present invention is capable of expressing the remaining amount according to the execution of Dutch Pay, and also displays the total amount of payment as it is on the POS screen, but only the status is "waiting for payment" to "Dutch Pay. It is also possible to mark the change as "in progress" and then "payment completed".

At this time, if some of the users who have shared the goods or services have difficulty in proceeding with the Dutch pay using the mobile terminal, the affiliated store POS 200 selects the "Other payment processing" button to , It is possible to perform payment processing using cash or plastic card.

For example, in a situation where three users are provided with a service corresponding to a mobile bill of 30,000 won and want to pay 10,000 won each for a Dutch Pay payment, two of them complete the Dutch pay using their own mobile terminal. Then, on the merchant POS 200 screen, "Dutch Pay is in progress, the balance subject to payment of 10,000 won" is displayed, and after performing the balance payment using cash or plastic card from the remaining one according to the selection of the "Other payment processing" button "Payment completed" is displayed.

In (d-1) of FIG. 2(a), the mobile phone number for payment only needs to be input once, and the input information is stored in the web browser cache data.

The browser requests payment through the payment app with the payment mobile number, and after refreshing, the mobile bill is changed to a Dutch Pay status.

Referring to Figure 2 (b), as shown in Figure 2 (b), (a-2) through the user terminal (100b) through the NFC smartphone touch or QR code scan on the table, mobile The bill is called or the mobile bill is called through a message URL received according to the execution of the Dutch pay of the user terminal 100a.

User B's user terminal 100b displays an order list and Dutch pay progress as shown in (b-2).

When the user terminal 100b selects "Dutch Pay" and clicks "Payment", the screen moves to (c-2).

In the screen (c-2), the user B inputs the amount to be paid (9,000 won) through the input screen of his terminal 100b, and then selects the "Dutch Pay" button, and (d- 2) After entering the payment mobile phone number on the screen, (e-2) Dutch Pay is performed through the payment app provided from the payment server 400.

At this time, it is also possible for the user to directly key-in the payment amount, but after checking the currently ordered menu information and its price, the payment amount can be entered by clicking the "Add to Payment Amount" button. Do.

After user B's payment of 9,000 won, the remaining amount of 4,000 won is updated to the payment target amount, and the affiliated store POS 200 displays the status as "Dutch Pay in Progress".

As described above, the affiliated store POS 200 can display the remaining amount (for example, 4,000 won in the current stage) according to the Dutch Pay execution, and also the total payment amount (for example, 21,000 won in the case of this embodiment) on the POS screen. It is also possible to express it as it is and display its status as "Dutch Pay in progress".

As described above, the mobile phone number for payment in (d-2) of FIG. 2B only needs to be input once, and the input information is stored in the web browser cache data.

Referring to Figure 2c, the user C (a-3) calls the mobile bill through the NFC smartphone touch or QR code scan on the table through the user terminal (100c), or the Dutch pay execution of the user terminal (100a). The mobile bill is called through the received message URL.

On the user terminal 100c of the user C, as shown in (b-3), the order list and the Dutch pay progress (the sum of the order amount, the amount already paid, and the amount required to be paid) are displayed.

When the user terminal 100c selects "Dutch Pay" and clicks "Payment", the screen moves to (c-3).

On the screen (c-3), the user C inputs the amount to be paid (4,000 won) through the input screen of his terminal 100c, selects the "Dutch Pay" button, and selects the (d- 3) After entering the payment mobile phone number on the screen, (e-3) Dutch Pay is performed through the payment app provided from the payment server 400.

Upon completion of the payment of the last user C, the payment for the total amount of payment ordered by the users A, B, and C is completed, and the affiliated store POS 200 displays the current payment situation as "Dutch" as shown in (f-3). Change the display from "Pay in progress" to "Payment completed".

As described above, payment request information (invoice) including the table ID is shared in real time between terminals of users A, B, and C who have shared the service, and the invoice amount information is updated in real time.

In addition, the bill sent by mobile messenger (e.g. KakaoTalk) or text message, rather than directly tagging the table with a QR code, contains a unique order number in the URL, and this unique order number is It is automatically discarded, and when re-viewing the discarded message, other users cannot access the order/payment table order and payment request information.

In addition, the above-described FIGS. 2A to 2C illustrate a process in which users A, B, and C sharing a service each perform a Dutch Pay payment using their own terminal, but according to the present invention, only users who directly use the service Rather, it is also possible to provide a Dutch Pay payment service through a third party payment.

As described above, the mobile bill is shared through a URL, and this URL contains a unique order number.

For example, among users who have shared the service, C does not perform payment directly with his or her payment method, and requests for transaction information including the amount of money to be paid by himself to the mobile terminal of a third party (its parent). It is possible.

That is, the third-party terminal (payer terminal) that receives the proxy payment request information from the purchaser terminal (user C) performs payment on the transaction details, and the payment completion information is transmitted to the affiliated store POS (200).

3 is a diagram illustrating a process of sending a bill according to an embodiment of the present invention.

User A's user terminal 100a (a) calls a mobile bill through the NFC smartphone touch or QR code scan on the table, and (b) sends the order information to a mobile messenger (eg KakaoTalk) friend The button is clicked.

(c) User A's user terminal 100a selects a friend to share through the mobile messenger friend list, and (d) transmits the mobile messenger message including the URL.

(e) After receiving the message, the user terminals 100b and 100c click on the URL and execute the mobile web browser to display the mobile bill.

As described above, the process of sending the bill is performed between people who share the service, and it is also possible for the person who shares the service to transmit the mobile bill to request a proxy payment to a third party.

4 shows a mobile bill for each payment according to the first embodiment of the present invention.

① If you select the Make Payment button after checking the Make Dutch Pay check box, you will be directed to the Dutch Pay page. If you select the Make Payment button after unchecking, the payment mobile phone number input pop-up is called.

② The dedicated Dutch Pay page is a dedicated page that is exposed when the Make Dutch Pay and Pay button is clicked on the mobile bill.

③ relates to tab division, and relates to a tab for selecting "individual payment" corresponding to the first embodiment described above and "designating a payer" corresponding to the second embodiment to be described later.

④ The payment amount input box is an input box for entering the payment request amount that you wish to pay.

⑤ The currently ordered menu price exposes the order list menu of the mobile bill. ⑥ In addition to the amount to be paid, when the button is selected, the amount of the menu selected in the input box of the amount to be paid is added.

⑦ is a Dutch Pay button. When selected, the payment mobile phone number input window pops up.

⑧ is a refresh button. When the button is selected, the page is refreshed, and ⑨ is to send the URL of the mobile bill to the aforementioned mobile messenger friend.

Hereinafter, a payment process designated by a payer according to a second embodiment of the present invention will be described with reference to FIGS. 5 to 10.

First, when a user (A, B, C) orders a menu, a table number and order details are input to the affiliated store POS.

User A is connected to a mobile bill of a tag (including a unique table number) received through an NFC function or by recognizing a QR code using his user terminal 100a.

As described in the first embodiment, QR code recognition or NFC recognition is a recognition means for accessing the tag, that is, order information for Dutch pay, and the scope of the present invention is not limited by this description.

As shown in FIG. 5, (a) the user terminal 100a calls the mobile bill through the NFC smartphone touch or QR code scan on the table.

The user terminal 100a displays an order list as shown in (b), and when a selection for "Dutch Pay" and a click for "Payment" are made through the user terminal 100a, the screen is displayed (c). Go ahead.

On the screen (c), when the "payer designation" tab is selected, the mobile phone number of the payer is input through the input screen of the user terminal 100a as shown in (d), and the payment amount for each mobile phone number is input.

When the input is complete, a confirmation message for the payment request information is displayed on the user terminal 100a as shown in (e), and (f) a Dutch pay of the user A is performed through the payment server 400 (payment of 8,000 won, The remaining amount is 13,000 won).

User B's user terminal (100b) and User C's user terminal (100c) designated as payers confirm the payment request Push as shown in (f), and the payment request respectively received through the payment server 400 as shown in (g) Payment for the amount (User B is 9,000 won, User C is 4,000 won).

6 shows a screen of a user terminal 100a of a user A, which is a user terminal leading Dutch pay through designation of a payer.

① The amount to be divided indicates the order amount or the amount required to be paid. ② The total amount entered indicates the sum of the amount requested for payment of the mobile phone number of each payer designated as the payer. Display the remaining amount after subtracting.

④ The payer's representative is a flag, which corresponds to the user terminal leading the Dutch Pay. ⑤ The payment request amount input box enters the payment request amount, and the sum is expressed as the total input amount.

⑥ When selecting the Add Payer Mobile Number button, the payer mobile phone number and the payment request amount input box are additionally created. Is automatically entered.

At this time, it is possible to divide 1/N by cutting in units of 100 won and add up the remaining balance to the payer's representative according to a preset method.

⑧Dutch Pay calls up the payment request information confirmation pop-up screen when the button is selected, and the ⑨Paste button corresponds to a function to paste the number copied from the mobile phone contact information.

As shown in FIG. 7, when the input of the payer's mobile phone number and the payment request amount is completed and confirmation of the confirmation message for the payment request information is made, a Dutch pay is performed through the payment app 410, The mobile web browser 110 refreshes the mobile bill and changes the state.

8 to 11 are diagrams illustrating a 1/N division process according to an embodiment of the present invention.

As shown in FIG. 8, when 1/N division is selected in the user terminal 100a leading the Dutch Pay, the "payer designation" tab is displayed, and the amount to be divided is divided by the number of mobile phone numbers of the payer This payment request amount is automatically entered.

At this time, as shown in FIG. 9, 1/N division is performed in a manner in which the remaining amount is added to the payment request amount of the representative user terminal by cutting in units of, for example, 100 won according to a preset allocation method, and payment The sum of the requested amount will be equal to the amount to be divided.

As shown in FIG. 10, when confirmation of the confirmation message for payment request information through 1/N division is made, Dutch pay is performed at each user terminal through the payment app 410 accordingly, and mobile web The browser 110 refreshes the mobile bill and changes the state.

As shown in (a) of FIG. 11, when the sum of the payment request amount in the user terminal leading the Dutch Pay does not match the amount to be divided, an error message (error information) pops up on the user terminal as shown in (b) of FIG. 11 Is expressed.

In addition, as shown in Figs. 12 to 14, when the Dutch pay for the total amount of payment is completed (when another payer has paid all the remaining amount), the payment server requests payment for the corresponding order information thereafter. A message informing that payment has already been completed to the user terminal 100 is transmitted and displayed.

According to another embodiment of the present invention, when the payment server performs payment for the total amount of payment using its own payment method, the payment server is a payer terminal designated by the first user terminal (the second It is possible to generate and transmit an account transfer request message for Dutch Pay to a user terminal or a third user terminal.

For example, User A receives a service with a total payment amount of KRW 21,000 with User B and User C, and after performing payment for the total payment amount using his terminal (first user terminal), User B and User C Sends an account transfer request message for Dutch Pay to the terminal.

At this time, the account transfer request message includes the account information of User A and the amount of the transfer request (if divided, requesting 7,000 won for both B and C / 9,000 won for B and 5,000 won for C when User A designates, etc.) .

According to another embodiment of the present invention, the payment server 400 communicates with the affiliated store server 300 to transmit discount or accumulation target information for the total payment amount to a user terminal (a terminal to perform payment, 100), and , Point discount or accumulation is performed upon payment authentication from the user terminal 100.

Accordingly, the user terminal 100 to perform payment may perform payment by selecting a payment method having a high discount rate among a plurality of built-in payment methods.

According to another embodiment of the present invention, after checking the mobile bill (total payment amount: 30,000 won), users A, B, and C have the highest discount payment method (Hyundai Card, 30% discount). Receives a discount on the total payment amount and performs the entire payment (total payment amount after the discount of 21,000 won), and a message requesting users B and C to transfer the account to the user A account (in the case of the same division, B, It is possible to create and deliver 7,000 won to all C requests/When user A is designated, 9,000 won to B and 5,000 won to C request).

In addition, User A, B, and C check the mobile bill (total payment amount: KRW 30,000), and then User A who has a payment method that can use points (Hyundai Card, 30% point discount) points for the total payment amount. A message asking users B and C to transfer the account to User A's account after receiving a discount and performing the entire payment (total payment amount after the discount of 21,000 won) Requesting 10,000 won for the same percentage of the total payment amount before discount of 30,000 won to both B and C/or requesting 7,000 won to B, 7,000 won to C, etc.) It is possible.

So far, we have looked at the center of the embodiments of the present invention. Those of ordinary skill in the art to which the present invention pertains will be able to understand that the present invention can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments should be considered from an illustrative point of view rather than a limiting point of view. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

100: user terminal 200: affiliated store POS
300: affiliated store server 400: payment server
500: financial company server

Claims (10)

A plurality of user terminals that display order information and request execution of a Dutch pay; And
With respect to the total payment amount corresponding to the input order information, including a payment server for receiving payment request information from the plurality of user terminals and authenticating payment in response to a request for executing the Dutch pay,
The user terminal receives and displays a list including an order menu and price information included in the order information subject to the Dutch pay, and pays the Dutch pay request information including the payment amount input by referring to the list. To the server,
Each of the plurality of user terminals performs a Dutch pay through a payment app installed therein,
When the price for each order menu in the list is added as a payment target amount, the first user terminal transmits the Dutch pay request information for the payment target amount, and receives discount target information from the payment server communicating with the affiliate store server. , When payment is performed by selecting a payment method with a high discount rate among a plurality of built-in payment methods, a message requesting the same amount for the total payment amount before or after the discount is delivered to other user terminals subject to Dutch Pay. Alternatively, a message requesting a Dutch pay is transmitted by specifying a Dutch pay amount for each other user terminal, and the second user terminal receiving the message receives a payment request message including information on the amount subject to payment from the first user terminal. And performing payment on the payment app accordingly
In Dutch Pay System.
The method of claim 1,
The payment server updates the amount information required for payment by subtracting the corresponding amount information from the total payment amount after completing the corresponding payment according to payment authentication with the first user terminal.
In Dutch Pay System.
delete The method of claim 1,
The payment server communicates with the affiliated store server and the affiliated store POS to receive the payment request information and share the Dutch Pay payment status information according to payment authentication
In Dutch Pay System.
delete delete delete delete delete The method of claim 1,
The order information and the total payment amount are shared between the user terminals through a URL in the form of a mobile bill including a unique order number, and the mobile bill is automatically discarded after payment is completed.
In Dutch Pay System.

Images