Method for providing payment services and electronic device for carrying out the same

Abstract

A method for providing a payment service and an electronic device for performing the same are provided. According to various embodiments, a method for providing a payment service may include receiving a payment request for an item from a user, verifying whether the received payment request satisfies specified conditions, and, if the payment request satisfies the specified conditions, omitting an additional authentication step and providing payment completion information corresponding to the payment request.

Description

[Technical field]

[0001] Various embodiments of the present disclosure relate to methods of providing payment services and electronic devices for performing the same. [Background technology]

[0002] 2. Description of the Related Art With the development of electronic devices, various types of portable terminals having various functions have become widespread. In addition, as electronic commerce has become more and more popular, the number of people using terminals to perform online ordering and payment has increased.

[0003] Unlike traditional offline transactions, such online payments require increased security to authenticate the identity of the person in question, as user information can be stolen by others and used to commit fraudulent transactions. As a result, diverse and complex user authentication methods have been adopted.

[0004] However, such complex authentication methods can be a barrier to online payments, and rather than causing security concerns, they can cause more complexity and inconvenience for users, which has led to a trend toward a compromise between security and convenience. Summary of the Invention [Problem to be solved by the invention]

[0005] Various embodiments of the present disclosure are intended to provide a method and an apparatus for providing a payment service with improved security and convenience. [Means for solving the problem]

[0006] A method for providing a payment service of an electronic device according to various embodiments may include a step of acquiring a payment request for an item from a user, a step of confirming whether the acquired payment request satisfies specified conditions, and a step of omitting an additional authentication step in response to the payment request satisfying the specified conditions and providing payment completion information corresponding to the payment request.

[0007] For example, the method of providing a payment service may further include a step of transmitting a delivery request for the item in response to providing the payment completion information, and a step of performing a transaction procedure corresponding to the payment request a predetermined time after providing the payment completion information.

[0008] For example, the method of providing a payment service may further include a step of canceling performance of the transaction procedure if a cancellation request corresponding to the payment is received within the predetermined time, and a step of transmitting a request to cancel delivery of the item in response to receiving the cancellation request.

[0009] For example, providing the payment completion information may include providing a user interface for canceling the payment on at least a portion of the payment completion information for a set period of time.

[0010] For example, the specified conditions may include a condition regarding the type of payment method corresponding to the payment request.

[0011] For example, the specified conditions may be determined based on the payment request. For example, the specified conditions may include a decision tree mapped to each of the payment instrument types.

[0012] For example, the method of providing a payment service may further include requesting a predetermined additional authentication in response to the payment request not satisfying at least a portion of the specified conditions.

[0013] For example, the specified conditions may include at least one of an amount limit condition corresponding to the payment request and a risk judgment condition for the payment.

[0014] For example, the risk determination conditions may include conditions regarding at least one of type information for the item, delivery location information corresponding to the payment request, and information regarding a device that transmits the payment request.

[0015] For example, the step of requesting the predetermined additional authentication may include the step of requesting payment authentication using a pin number or biometric information.

[0016] An electronic device according to various embodiments may include a database and a processor electrically connected to the database, and the processor may acquire a payment request for an item from a user, check whether the acquired payment request satisfies specified conditions, determine an authentication method for the payment in response to the payment request satisfying the specified conditions, and provide payment authentication related information according to the determined authentication method.

[0017] For example, the processor may, in connection with providing the authentication-related information, provide notification information regarding completion of authentication of the payment, provide notification information regarding a request for additional authentication of the payment, or provide notification information regarding a failure to authenticate the payment.

[0018] For example, the processor may restrict at least some of the payment authentication methods based on user settings, and provide information related to the user setting changes based on whether the payment-related information satisfies the specified conditions.

[0019] An application stored in a computer-readable storage medium for performing a method for providing a payment service according to various embodiments may include a step of receiving a payment request input, a step of determining an authentication method for the payment based on whether payment-related information corresponding to the payment request input satisfies a specified condition, and a step of performing authentication regarding the payment according to the determined payment authentication method.

[0020] A non-transitory computer-readable recording medium having recorded thereon a program for causing a computer to execute a payment service providing method according to various embodiments, the payment service providing method including the steps of: acquiring a payment request for an item from a user; verifying whether the acquired payment request satisfies specified conditions; and, if the payment request satisfies the specified conditions, omitting an additional authentication step and providing payment completion information corresponding to the payment request. Effect of the Invention

[0021] Various embodiments may provide users with convenient and quick purchasing and payment capabilities in a safe and trusted environment by guiding them to one-touch payments with improved security.

[0022] According to various embodiments, by actively encouraging the buyer to use one-touch or simple payment, which is easy and quick, the possibility of the buyer canceling the payment and leaving the payment window during the time required for payment authentication can be minimized.

[0023] According to various embodiments, a decision tree for each type of payment method can be used to perform accurate risk assessment for each payment method selected by the user, thereby providing a payment method with improved security and user convenience. [Brief description of the drawings]

[0024] [Figure 1] FIG. 1 is a schematic block diagram illustrating a payment service providing system according to various embodiments of the present disclosure. [Diagram 2] FIG. 1 is a schematic block diagram of an electronic device according to an embodiment of the present disclosure. [Diagram 3] 1 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure. [Figure 4a] 1 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure. [Figure 4b] 1 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure. [Diagram 5] 1 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure. [Figure 6] 1 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure. [Figure 7] 1 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure. [Figure 8] 1 is a diagram illustrating a user interface related to the provision of a payment service according to an embodiment of the present disclosure. [Figure 9] 1 is a diagram illustrating a user interface related to providing a payment service according to an embodiment of the present disclosure. [Figure 10] 1 is a diagram illustrating a user interface related to providing a payment service according to an embodiment of the present disclosure. [Figure 11] 1 is a diagram illustrating a user interface related to providing a payment service according to an embodiment of the present disclosure. [Figure 12] 1 is a diagram illustrating a user interface related to providing a payment service according to an embodiment of the present disclosure. [Figure 13] 1 is a diagram illustrating a user interface related to providing a payment service according to an embodiment of the present disclosure. [Figure 14]1 is a diagram illustrating a user interface related to providing a payment service according to an embodiment of the present disclosure. [Figure 15] 1 is a diagram illustrating a user interface related to providing a payment service according to an embodiment of the present disclosure. [Figure 16] 1 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] The terms used in the embodiments are currently used as widely as possible while taking into consideration the functions in the present disclosure, but these may change depending on the intentions or precedents of the technicians in the field, the emergence of new technologies, etc. In addition, in certain cases, the applicant may arbitrarily select some terms, and in such cases, the meanings of these terms will be described in detail in the relevant description. Therefore, the terms used in the present disclosure should be defined based on the meanings of the terms and the overall content of the present disclosure, rather than simply the names of the terms.

[0026] Throughout the specification, when a part "includes" a certain element, this does not mean excluding other elements, but means that other elements may be further included, unless otherwise specified. Furthermore, the terms "unit...", "module..." and the like described in the specification mean a unit that processes at least one function or operation, which may be realized in hardware or software, or a combination of hardware and software.

[0027] Throughout the specification, the expression "at least one of a, b, and c" may encompass "a alone," "b alone," "c alone," "a and b," "a and c," "b and c," or "all of a, b, and c."

[0028] The "terminal" referred to below may be realized as a computer or a portable terminal that can connect to a server or other terminals through a network. Here, the computer may be, for example, a notebook computer, a desktop computer, or a laptop computer equipped with a web browser, and the portable terminal may be, for example, a wireless communication device that ensures portability and mobility, and may include communication-based terminals such as IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), LTE (Long Term Evolution), etc., and all kinds of handheld-based wireless communication devices such as smartphones and tablet PCs.

[0029] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily carry out the present disclosure. However, the present disclosure may be embodied in many different forms and is not limited to the embodiments described herein.

[0030] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0031] In describing the embodiments, technical content that is widely known in the technical field to which the present invention pertains and is not directly related to the present invention will be omitted in order to more clearly convey the gist of the present invention without obscuring it.

[0032] For the same reason, some components in the accompanying drawings are exaggerated, omitted, or illustrated in a schematic manner. Also, the size of each component does not entirely reflect the actual size. The same reference numerals are given to the same or corresponding components in each drawing.

[0033] The advantages and features of the present invention, and the method of achieving them, will become clear from the detailed description of the embodiments with accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, and may be embodied in various different forms, but the present embodiments are provided to complete the disclosure of the present invention and to fully inform those skilled in the art of the present invention of the scope of the invention, and the present invention is only defined by the scope of the claims. The same reference numerals refer to the same elements throughout the specification.

[0034] It will be understood that each block of the process flow chart diagram and the combination of the flow chart diagrams can be implemented by computer program instructions. These computer program instructions can be loaded into a processor of a general purpose computer, special purpose computer, or other programmable data processing device, such that the instructions executed by the processor of the computer or other programmable data processing device create means for performing the functions described in the flow chart block(s). These computer program instructions can also be stored in a computer usable or computer readable memory that can direct the computer or other programmable data processing device to implement the functions in a particular manner, such that the instructions stored in the computer usable or computer readable memory can produce an article of manufacture that includes instruction means for performing the functions described in the flow chart block(s). The computer program instructions may be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on the computer or other programmable data processing device to produce a computer implemented process, and the instructions that cause the computer or other programmable data processing device to provide steps for performing the functions described in the flowchart block(s).

[0035] Also, each block may represent a module, segment, or portion of code that includes one or more executable instructions for performing the specified logical function(s). Also, it should be noted that in some alternative implementations, the functions noted in the blocks may occur out of order. For example, two blocks shown in succession may actually be performed substantially simultaneously, or the blocks may sometimes be performed in reverse order depending on the corresponding functions.

[0036] FIG. 1 is a schematic block diagram illustrating a payment service providing system according to various embodiments of the present disclosure.

[0037] According to various embodiments, the payment authentication system may include an electronic device 100 (eg, a server), a user terminal 200 , and a network 50 .

[0038] The electronic device 100 is a device that performs various processes to provide payment services, and can perform various functions related to payment based on a payment request input received from at least one user terminal 200 via a network 50.

[0039] The electronic device 100 may include a number of computer systems or computer software implemented in a network server. The electronic device 100 may provide various information by configuring it as a web page.

[0040] For example, the electronic device 100 may refer to a computer system and computer software that is connected to a subordinate device that can communicate with other network servers through a computer network such as an intranet or the Internet, receives a request to perform a task, performs the task, and provides the result of the task. In addition, the electronic device 100 may be understood as a broad concept including a series of applications that can run on a network server and various databases built therein. For example, the electronic device 100 may be embodied using a network server program provided in various ways by operating systems such as DOS, Windows, Linux, UNIX, or Mac OS.

[0041] The network 50 may function to connect the electronic device 100 and the user terminal 200, or the electronic device 100 and an external device (not shown). For example, the network 50 may provide a connection path so that the user terminal 200 can be connected to the electronic device 100 to transmit and receive packet data.

[0042] The operation of the payment service providing system according to an embodiment of the present disclosure may be implemented through an electronic device 100, and a user terminal 200 may be connected to the payment system through a network 50.

[0043] The electronic device 100 can store the information received from the user terminal 200 in a database (eg, database 120 in FIG. 2) or transmit the information stored in the database to the user terminal 200 .

[0044] According to another embodiment, at least some functions of the payment service providing system may be implemented through the user terminal 200. For example, a user may install and use the payment service providing system in the form of an application on the user terminal 200 through the network 50.

[0045] The payment service providing system according to various embodiments may be implemented as a single physical device or as a system in which multiple physical devices are organically combined. For example, some of the functions provided by the electronic device 100 may be implemented by one physical device, and the remaining functions may be implemented by another physical device. For example, one physical device may be implemented as a part of the electronic device 100, and the other physical device may be implemented as a part of the user terminal 200 or an external device (not shown). In some cases, each component included in the payment service providing system may be distributed and disposed in different physical devices, and the distributed components may be organically combined to perform functions and operations of the payment service providing system.

[0046] FIG. 2 is a schematic configuration block diagram of an electronic device according to an embodiment of the present disclosure.

[0047] With reference to FIG. 2, an electronic device 100 (eg, a server) according to various embodiments may include at least one of a processor 110 and a database 120.

[0048] The processor 110 can process a series of functions for performing methods for providing payment services according to various embodiments of the present disclosure and can generally control the operation of other component(s) of the electronic device 100.

[0049] For example, the processor 110 may determine the payment authentication method for the order requested for payment based on at least a portion of the user's setting information related to the payment authentication method, the payment amount limit condition information, and the payment risk judgment condition information.

[0050] For example, the processor 110 may perform payment authentication according to a determined payment authentication method and may provide authentication-related information regarding the payment.

[0051] For example, the processor 110 may determine the payment authentication method based on a payment risk judgment condition determined based on the type of payment method designated by the user.

[0052] For example, the processor 110 may determine a payment authentication method for each payment by using conditions related to at least some of the following as payment risk judgment conditions: type information of the product to be paid for, delivery location information of the product to be paid for, location information of the user and / or device corresponding to the payment request, and payment history information.

[0053] The processor 110 may also embody various functions related to providing a payment service according to various embodiments of the present disclosure, which will be described later.

[0054] The database 120 is a data structure embodied in a predetermined storage space of the electronic device 100, and functions such as storing, searching, deleting, editing, and adding data can be freely performed. For example, the database 120 may have fields or components for processing functions such as storing, searching, deleting, editing, and adding data.

[0055] The database 120 may store data related to various functions of the electronic device 100. For example, the database 120 may store various information related to a method of providing a payment service (e.g., decision tree information corresponding to a payment method type, etc.) and may store instructions or data for the processor 110 to execute operations.

[0056] Meanwhile, although not shown, the electronic device 100 may further include a communication module. For example, the communication module may perform a function of transmitting information stored in the database 120 of the electronic device 100 or predetermined information processed by the processor 110 to another device, or receiving information from another device to the electronic device 100. For example, the communication module may receive predetermined user input information (e.g., payment request input, etc.) from the user terminal 200 of Fig. 1. For example, the communication module may include a transceiver for transmitting and receiving information.

[0057] FIG. 3 is a flow chart of a method for providing payment services in an electronic device according to various embodiments of the present disclosure.

[0058] Referring to FIG. 3, the electronic device 100 may perform user authentication related to the provision of a payment service through a payment-related application or program installed in the user terminal 200.

[0059] For example, the electronic device 100 may first perform user authentication in an initial subscription stage for using a payment service in step 210. Meanwhile, when a user attempts to log in to a payment service through an application or program installed in the user terminal 200, the electronic device 100 may perform authentication according to user identification information registered in the subscription stage.

[0060] Next, the electronic device 100 can perform a predetermined authentication in a step 220 to register the payment method.

[0061] For example, a user can register a payment method that the user intends to use when making a payment in a payment service. For example, the payment method can include at least one of a credit card or check card registration, a bank account registration, and a user terminal registration for using a simple payment service. The electronic device 100 can perform user authentication in the step of registering the payment method and store related information.

[0062] Next, the electronic device 100 can perform authentication at a separate payment execution step in step 230 .

[0063] In various embodiments, when a user decides to purchase a particular product or service, the user can request payment for the product or service from the electronic device 100. The electronic device 100 can perform authentication for each payment request based on at least a part of predetermined information (e.g., user identification information, user login information, etc.) acquired during the subscription step authentication 210, predetermined information (e.g., card information, bank account information, user terminal information, etc.) acquired during the payment method registration step authentication 220, and individual case information for which payment is requested (e.g., type information of the product to be paid for, delivery location information, payment amount information, etc.).

[0064] 4A and 4B are flowcharts illustrating a method for providing a payment service according to various embodiments of the present disclosure. For example, FIG. 4A and FIG. 4B may correspond to a diagram for specifically illustrating step 230 of FIG. 3 described above.

[0065] 4a and 4b, an electronic device 100 according to various embodiments may receive a specific payment request input from a user terminal 200 in step 310.

[0066] For example, in step 315, the user may request payment for one or more purchased items using a payment service-related application or program installed in the user terminal 200. For example, the user may perform payment using a different payment method for each payment request, and may also request delivery of the purchased items to a different delivery location during payment, so different payment-related information may be transmitted to the electronic device 100 in step 325 in response to each payment request.

[0067] In step 320, the electronic device 100 may check information related to the requested payment. Here, the payment-related information may include at least one of user identification information, user login information, and user payment authentication history information, payment method information, payment product information, and delivery location information.

[0068] The electronic device 100 may then determine whether the payment-related information satisfies specified conditions in steps 330 and 335 .

[0069] For example, if the electronic device 100 determines that the payment-related information satisfies the specified conditions, it may perform payment authentication using a first authentication method in step 340. Also, if the electronic device 100 determines that the payment-related information does not satisfy at least some of the specified conditions, it may perform payment authentication using a second authentication method in step 350. In this way, the electronic device 100 may determine different authentication methods for a corresponding payment depending on whether the payment-related information satisfies the specified conditions.

[0070] For example, the specified conditions may include at least some of the following: an amount limit condition corresponding to the payment request, a condition on the type of product to be paid for, a condition on the delivery location of the product, and a condition on the device or user (user account) for which the payment is requested. For example, the electronic device 100 may determine the payment authentication method by checking whether all of the above-mentioned conditions are satisfied in step 335, or may determine the payment authentication method by checking whether some of the above-mentioned conditions are satisfied according to the set conditions.

[0071] For example, the first authentication method may correspond to a one-touch payment in which the authentication of the payment is immediately completed in response to the satisfaction of the specified condition. For example, when the electronic device 100 determines the payment authentication method as the first authentication method, the electronic device 100 may complete the payment authentication in response to the satisfaction of the specified condition and may not require an additional authentication procedure.

[0072] For example, the second authentication method may correspond to an authentication method that requests a predetermined additional payment authentication procedure in response to not satisfying at least some of the specified conditions. For example, the second authentication method may correspond to a simplified payment in which payment authentication is performed by inputting a PIN number or biometric information (e.g., fingerprint information, iris information, facial recognition information, etc.) without the user having to enter card information or account information.

[0073] Although not shown, the electronic device 100 may determine to perform payment authentication using a third authentication method if the payment-related information does not satisfy a specific condition. In this case, the electronic device 100 may request the user to perform payment authentication with stricter standards such as public authentication, user authentication through a terminal in the user's name, etc. Meanwhile, according to another embodiment, the electronic device 100 may determine to transmit a message to the user terminal 200 notifying that the payment authentication has failed, instead of determining to perform payment authentication using the third authentication method.

[0074] Meanwhile, in the embodiment, when the payment is made using the first authentication method that does not require additional authentication, a UI that allows the user to immediately cancel the payment on the payment completion page can be provided to the user, thereby improving the user experience by allowing the user to immediately cancel the payment even if the payment is completed with an incorrect input.

[0075] In addition, in the embodiment, when the payment is made using the first authentication method, the transaction for the actual payment may proceed after waiting for a predetermined time. Accordingly, if the user provides a payment cancellation input within a predetermined time, the transaction can be canceled in the waiting transaction list, and the procedure of returning the item after the actual transaction occurs can be omitted. However, even if the transaction is not performed, the request for the paid item can be transmitted to the delivery-related server in response to the payment progress. Accordingly, the delivery can be completed more quickly, and in the case of delivery, even if the cancellation occurs before delivery, the cost of cancellation is relatively small, and although a certain time is required until delivery, if the cancellation occurs within the predetermined waiting time, delivery can also be canceled at the same time. Meanwhile, in the embodiment, the transaction may include making a request related to the payment of the payment amount through the payment means used by the user for the payment and receiving a response corresponding thereto. For example, in the case of payment using a specific account, the transaction may include requesting the payment of the payment amount to the server of the business that manages the account. Through such a transaction and delivery request method, it is possible to reduce additional costs due to transaction cancellation, and by making a delivery request in response to the provision of payment completion information, the user can include a time to receive the paid item based on the time when the payment completion information is provided. More specifically, the service provided by the electronic device may determine the time period during which the user can receive delivery of the item based on the time when the user pays for the item, and in an embodiment of the specification, when payment is performed through the first authentication method, the actual transaction due to the payment may be performed a predetermined time after the payment completion information is provided, but the delivery request may be performed immediately, and thus the time required for delivery may be secured, so that the item may be provided to the user within the delivery completion time provided when the item information was provided.

[0076] However, without being limited to the above embodiment, according to another embodiment of the present disclosure, when the electronic device 100 receives the same payment request twice or more within a set time, the electronic device 100 may prevent duplicate payments by proceeding with the payment process based on the first received payment request and automatically ignoring the payment requests for the subsequent payment request(s). Alternatively, the electronic device 100 may prevent the duplicate payments by transmitting a reconfirmation request notification to the user for the subsequent payment request(s).

[0077] Meanwhile, in an embodiment, when a payment is requested at a specific time, the payment can be made to proceed using the second authentication method even if other conditions are met for using the first authentication method. More specifically, abusive behavior can be prevented by setting a time period during which a lot of abuse occurs using a specific payment method and not allowing payments using the first authentication method to proceed during that time period.

[0078] The electronic device 100 may request the user terminal 200 to perform payment authentication in response to the determined authentication method (e.g., the second authentication method or the third authentication method) in step 345. As another example, the electronic device 100 may transmit a payment completion notification message or a payment failure (or approval refusal) notification message to the user terminal 200.

[0079] Meanwhile, in an embodiment, the electronic device 100 may manage blacklist information of users in relation to each authentication method. Such blacklist information may be created based on the existing usage history of each user in the service operated by the electronic device 100. When a user included in such a blacklist requests a payment, the electronic device 100 may provide a payment rejection message without determining whether the payment information satisfies a specified condition.

[0080] In addition, in an embodiment, the electronic device 100 may determine an authentication method based on delivery information related to an item purchased by a user. For example, when a user requests delivery to a delivery location where the user has already delivered a certain number of times, the electronic device 100 may perform payment authentication using a first authentication method, and when a user requests delivery to a different delivery location, the electronic device 100 may perform payment authentication using a second authentication method.

[0081] In addition, in an embodiment, the electronic device 100 may set different criteria for determining an authentication method based on at least one of the type information of the payment method and the payment amount. More specifically, if there is a high risk of theft or damage is expected in the event of theft, the electronic device 100 may apply stricter criteria to determine the authentication method.

[0082] FIG. 5 is a flow chart illustrating a method for providing a payment service for an electronic device according to one embodiment of the present disclosure.

[0083] Referring to FIG. 5, the electronic device 100 according to one embodiment may first, in step 322, determine whether the payment amount of the product (or service) to be paid for, included in information related to the requested payment, in response to a payment request input acquired from the user terminal 200, exceeds a preset critical amount.

[0084] For example, if the payment amount is less than a preset amount in step 322, the process proceeds to step 324 to check whether the risk judgment condition is satisfied, and if the payment amount exceeds the preset amount, the process proceeds to step 350 to determine the payment authentication method for the corresponding payment item as a second authentication method (e.g., a simple payment authentication method such as entering a PIN number).

[0085] According to an embodiment, the electronic device 100 may first check whether the user has given permission to use simple payment (and one-touch payment) before performing the operation of step 322, and perform operations following step 322 only if the user has given permission to use simple payment. Meanwhile, according to yet another embodiment, the electronic device 100 may check whether the corresponding payment corresponds to a payment that can be authenticated by the first authentication method by performing operations following step 322 even if the user has not given permission to use simple payment.

[0086] In step 324, the electronic device 100 may identify whether the payment-related information satisfies a specified risk determination condition.

[0087] For example, the electronic device 100 may include a decision tree associated with the risk determination conditions and determine a payment authentication method based on the decision tree. As another example, the electronic device 100 may determine a payment authentication method based on a machine learning-based learning model instead of or in addition to the decision tree.

[0088] According to an embodiment, the risk determination condition may include at least a condition related to type information of the product to be paid for. For example, if the product to be purchased for which payment is requested is a gold-related product that is easily convertible into cash or a digital product related to data, the electronic device 100 may determine that the payment is relatively high risk and may determine to apply a payment authentication method with enhanced security.

[0089] In another embodiment, the risk determination condition may include at least a condition related to delivery location information of the product to be paid for. For example, if the delivery location of a product requested for payment by a specific user is different from the delivery location of a previously paid purchase, or if the location of the terminal to which the user's payment request is transmitted and the delivery location are beyond a specified distance range or are in different countries, the electronic device 100 may determine that the payment is relatively risky and request authentication using a payment authentication method with enhanced security.

[0090] According to another embodiment, the risk determination condition may include at least a condition related to a device (e.g., the user terminal 200) on which the payment request is made. For example, the condition may include a condition related to at least one of a payment history and location information corresponding to the device on which the payment request is input. For example, the electronic device 100 may determine that the payment is relatively high risk and request authentication using a payment authentication method with enhanced security when, based on existing payment completion history information on the device on which the payment request is input, a payment has not been made for a recent predetermined period of time, or when multiple payment attempts have occurred on the device for a specified period of time, or when a payment request has occurred on a device that does not have an existing login history, or when a payment request is estimated to have been input from outside the country based on IP information of the device on which the payment request is input, etc.

[0091] According to another example, the risk judgment condition may be based on the identification information of the user who inputs the payment request, and may include cases where the number of existing payment failures or frequency of failures of the user is above a threshold, where the cumulative amount of products requested for payment during a specified period of time exceeds a set value, or where the number of changes or frequency of changes of the password related to the user's login authentication or the password related to the authentication of individual payment items is above a threshold, and the payment may be judged to be relatively high risk and authentication may be requested using a payment authentication method with enhanced security.

[0092] In this manner, the electronic device 100 determines a payment authentication method based on whether the payment-related information satisfies a risk judgment condition, and depending on whether the risk judgment condition is satisfied, can complete authentication, request authentication related to simple payment, request detailed identity authentication, or provide an authentication failure notification.

[0093] FIG. 6 is a flow chart illustrating a method for providing a payment service for an electronic device according to one embodiment of the present disclosure.

[0094] Referring to FIG. 6, an electronic device 100 according to an embodiment may receive a payment request input from a user in step 410, and may determine specified conditions based on the user's payment method type selection information included in the payment-related information based on payment-related information corresponding to the payment request input in step 420.

[0095] For example, the electronic device 100 may include one or more decision trees in the database 120. The decision tree may be set differently for each payment method type and may be determined according to the type of payment method input by the user. For example, the user may select a payment method type related to whether to make a payment by card, by a transfer method through a bank account, or by a balance of a previously deposited reward points. When the user selects the payment method type as a card payment type, the electronic device 100 may determine a first condition (e.g., a first decision tree) corresponding to the card payment according to the above-mentioned specified condition. When the user selects the payment method type as a bank transfer type, the electronic device 100 may determine a second condition (e.g., a second decision tree) corresponding to the bank transfer according to the specified condition. When the user selects the payment method type as a reward points balance type, the electronic device 100 may determine a third condition (e.g., a third decision tree) corresponding to the reward points balance according to the specified condition. The first to third conditions may differ from each other in at least some of the detailed conditions (eg, items of the detailed conditions, a judgment order of each detailed condition, and / or critical value information of each detailed condition).

[0096] In step 430, the electronic device 100 determines whether the payment-related information corresponding to the payment request input in step 410 satisfies the conditions determined based on the payment method type in step 420, and can determine a payment authentication method depending on whether or not the conditions are satisfied.

[0097] FIG. 7 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure.

[0098] 7, according to one embodiment, the electronic device 100 may receive a payment request input in step 510, and may compare payment-related information corresponding to the payment request input with preset conditions (e.g., risk determination conditions) in step 520, and may determine at least one of a payment authentication method and whether or not to authenticate the payment depending on the level of risk. According to various embodiments, the electronic device 100 may perform the operation of step 520 only if conditions related to a payment amount limit are satisfied and / or if a user designates easy payment (and one-touch payment) are satisfied.

[0099] In step 530, the electronic device 100 may determine the payment authentication method for the corresponding payment corresponding to the payment request input as the second authentication method based on the risk determination condition, and transmit a payment authentication performance request of the second authentication method to the user terminal 200. In response, the user may perform the payment authentication using the second authentication method. For example, the user may authenticate the payment using the second authentication method by inputting a PIN number or biometric information, etc.

[0100] Meanwhile, in one embodiment, when payment authentication by the user using a second authentication method is completed, the electronic device 100 may again compare risk judgment conditions based on payment-related information related to authentication using the second authentication method in step 540.

[0101] For example, even if authentication using the second authentication method is successful in step 530, the electronic device 100 can re-compare the risk judgment conditions based on the number (or frequency) of authentication failures when authenticating the user using the second authentication method in step 540, and can finally determine whether to approve the payment in step 550.

[0102] For example, even if the user has been successfully authenticated using the second authentication method, the electronic device 100 may ultimately not approve the payment authentication based on the risk determination condition comparison in step 550. In this case, the electronic device 100 may re-request authentication using an enhanced security authentication method from the user terminal 200, or may transmit a notification message related to the denial (or failure) of the payment approval and terminate the payment function.

[0103] Meanwhile, in an embodiment, whether the payment-related information satisfies the risk determination condition may be determined based on at least one of the following payment-related information: account information of a user who has made a payment request, product information to be paid for, information of a terminal that has transmitted the payment request, and time information of when the payment request occurred. Also, the priority of the information serving as the determination criterion may be set differently depending on the embodiment.

[0104] 8 to 15 are diagrams illustrating user interfaces related to providing a payment service according to various embodiments of the present disclosure.

[0105] 8, the electronic device 100 according to an embodiment may provide an interface screen for ordering and paying for a specific item on the user terminal 200. The user may input delivery address information and contact information for the item to be paid for, confirm the payment amount, and press a payment request button (e.g., "Pay" button) to provide payment request information to the electronic device 100. Meanwhile, the user may set a payment method in relation to the payment or change a previously set payment method, and a more specific user interface screen in relation to this is shown in FIG. 9.

[0106] As shown in FIG. 9, the user can select the payment method type, such as whether to make the payment by bank account transfer, by using the balance of the savings account, by credit card (or check card), or by user terminal (e.g. mobile phone) payment.

[0107] For example, the electronic device 100 can encrypt payment-related information (e.g., account information, card information, etc.) acquired by registering a payment method in relation to a convenient payment service (e.g., XX Pay) and store it in the database 120. If the payment target is determined to be low risk based on the risk assessment result for an individual payment item, the electronic device 100 can perform one-touch payment (e.g., authentication without entering PIN number) authentication as the first authentication method, or if the payment target is determined to be somewhat low risk, the electronic device 100 can determine and process the payment authentication method using a convenient payment (e.g., authentication by entering PIN number) method as the second authentication method.

[0108] For example, when a user inputs a payment request by clicking the "Pay" button on the screen of FIG. 8, the electronic device 100 can determine whether one-touch payment or simple payment can be performed based on whether or not specified conditions are satisfied based on information about the corresponding payment. If one-touch payment is permitted, the interface screen of FIG. 10 can be provided through the user terminal 200, and if simple payment is permitted, the interface screen of FIG. 11 can be provided.

[0109] For example, if one-touch payment is permitted and payment is completed without additional payment authentication procedures, the user may repeatedly input a payment request (e.g., pressing the "Pay" button) because the user cannot confirm whether payment authorization has been completed while determining whether the one-touch payment has been approved. This may result in problems such as duplicate orders for the same product and duplicate payments. Therefore, the electronic device 100 may provide a guidance interface related to the payment progress as shown in FIG. 10 to minimize errors in repeated payment attempts by the user.

[0110] Meanwhile, in one embodiment where simple payment is permitted, the electronic device 100 may provide an interface that guides the user to perform payment authentication through input of a PIN number as shown in Fig. 11. Also, when the user inputs the PIN number, the interface screen may be switched to that shown in Fig. 12, and screen information related to the progress of payment information processing may be provided.

[0111] 13 to 15, the electronic device 100 according to an embodiment may provide a related interface screen to allow a user to specify whether to use a one-touch (or one-click) payment method.

[0112] For example, as shown in FIG. 13, a user may be restricted from using the one-touch payment method, and when the user attempts to lift the restriction so that the one-touch payment method can be used again as shown in FIG. 15, the electronic device 100 may be set to allow the use of one-touch payment through a predetermined authentication procedure (e.g., PIN number input authentication related to a simple payment service).

[0113] According to an embodiment of the present disclosure, when the user does not permit the use of one-touch payment, the electronic device 100 may provide notification information suggesting the use of the one-touch payment when the user orders and pays for a specific item and goes through a predetermined payment authentication procedure to provide a payment approval completion notification. For example, the electronic device 100 may compare information related to the user's payment item with specified conditions (e.g., payment amount limit conditions and / or payment risk judgment conditions) and provide notification information suggesting the use of the one-touch payment only when it is determined that the payment meets the conditions for allowing one-touch payment.

[0114] FIG. 16 is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure.

[0115] 16, the electronic device 100 according to an embodiment may preferentially determine whether a user and / or a user terminal corresponding to a specific payment request input is a target registered on a blacklist in operation 610. The blacklist information may be stored in advance in the database 120 of the electronic device 100, and may be updated in the database 120 whenever a problem related to payment authentication occurs. For example, the electronic device 100 may identify whether a corresponding user and / or a user terminal is a target on the blacklist based on the login history of the user, the IP address of the connected terminal, etc.

[0116] If the electronic device 100 determines that the user or user terminal corresponding to the payment request input is blacklisted, it can deny payment approval for the corresponding payment request in step 601 and provide related notification information.

[0117] On the other hand, if it is determined that the payment request is not related to the blacklist, in step 620, the electronic device 100 may determine whether the corresponding payment object satisfies a preset amount limit condition.

[0118] For example, if the requested amount of payment exceeds a preset amount limit, the electronic device 100 may branch to step 601 and deny approval of the payment. However, the present invention is not limited to this embodiment, and if the payment subject exceeds the amount limit, the electronic device 100 may branch to step 602 and request additional payment authentication such as inputting a PIN number (or inputting biometric information or other password related to personal authentication), and the payment may be approved depending on the result of the additional payment authentication.

[0119] Also, if the requested amount of payment is below the preset amount limit range, the electronic device 100 may determine whether or not a condition related to the type of product to be paid for is satisfied in step 630. For example, if the requested product corresponds to a digital product (or a gold-related product), the electronic device 100 may request additional payment authentication for the payment in step 602.

[0120] For example, if the condition of step 630 is satisfied because the product for which the payment is requested is not a digital product, the electronic device 100 may determine whether other risk determination conditions are satisfied in step 640 .

[0121] For example, the risk determination conditions may include a first risk condition for detecting a case where a payment is attempted by stealing another person's card or bankbook and a second risk condition for detecting a case where a payment is attempted by stealing user account related information (e.g., ID and password). In addition, the risk determination conditions may further include a third risk condition for determining a risk for a payment case by a new user terminal that has no previous payment history. According to an embodiment, in step 640, the electronic device 100 may first determine whether payment related information corresponding to a payment request input satisfies the first risk condition, then determine whether the second risk condition is satisfied, and then determine whether the third risk condition is satisfied. Based on the determination result, the electronic device 100 may complete immediate payment authentication and approve the payment in step 603, or request additional payment authentication in step 602.

[0122] According to various embodiments, the electronic device 100 may include, as the risk determination conditions, at least some of the following: a condition regarding whether the device (e.g., user terminal) for which a payment is requested is the same as the device for which the user has made an existing payment (e.g., first payment), a condition regarding whether the delivery address corresponds to the delivery address of the existing payment (e.g., first payment), a condition regarding whether the delivery address is domestic, a condition regarding whether the user and / or user terminal corresponds to a whitelist, a condition regarding the number or frequency of changes to payment authentication related information (e.g., various passwords such as PIN number) within the last N hours, a condition regarding the number or frequency of payment authentication failures within the last N hours, a condition related to an existing payment authentication history (e.g., a history of one-touch payment success, a history of authentication through a simple payment method or a general payment method within the last N hours), a condition related to a history of logins by two or more user accounts on one user terminal, a condition related to the amount of payment attempted during a specified time on one device (user terminal), and a condition related to the amount / number of payment attempts during a specified time on one user account. Each of the above conditions may or may not have a predetermined priority, and a decision tree including other conditions for each payment method may be formed.

[0123] Meanwhile, according to yet another embodiment, the electronic device 100 may be configured to always perform a request for additional payment authentication regardless of the final risk judgment result if the waiting time required to determine whether the risk judgment condition is satisfied exceeds a specified critical time in the step of determining whether the risk judgment condition is satisfied.

[0124] Meanwhile, the present specification and drawings disclose preferred embodiments of the present invention, and although specific terms are used, these are used in a general sense merely to easily explain the technical contents of the present invention and to aid in understanding the invention, and are not intended to limit the scope of the present invention. It is obvious to those skilled in the art to which the present invention pertains that in addition to the embodiments disclosed herein, other modifications based on the technical ideas of the present invention can be implemented.

[0125] The electronic device or terminal according to the above-described embodiments may include a processor, a memory for storing and executing program data, a permanent storage such as a disk drive, a communication port for communicating with an external device, and a user interface device such as a touch panel, keys, buttons, etc. A method embodied in a software module or algorithm may be stored on a computer-readable recording medium as computer-readable code or program instructions executable on the processor. Here, examples of the computer-readable recording medium include magnetic storage media (e.g., read-only memory (ROM), random-access memory (RAM), floppy disk, hard disk, etc.) and optically readable media (e.g., CD-ROM, DVD (Digital Versatile Disc)). The computer-readable recording medium may be distributed among computer systems coupled to a network, so that the computer-readable code may be stored and executed in a distributed manner. The medium may be computer readable, stored in the memory, and executed by the processor.

[0126] The present embodiment may be illustrated in terms of functional blocks and various processing steps. Such functional blocks may be embodied in any number of hardware and / or software components that perform a particular function. For example, the embodiment may employ direct circuitry such as memory, processing, logic, look-up tables, etc., that may perform various functions under the control of one or more microprocessors or other control devices. Just as components may be implemented in software programming or software elements, the present embodiment may include various algorithms embodied in a combination of data structures, processes, routines, or other programming components, and may be embodied in programming or scripting languages ​​such as C, C++, Java, assembler, etc. Functional aspects may be embodied in algorithms executed by one or more processors. Additionally, the present embodiment may employ conventional techniques for electronic configuration, signal processing, and / or data processing. Terms such as "mechanism," "element," "means," and "component" may be used broadly and are not limited to mechanical and physical components. The terms may include a series of software routines in conjunction with a processor or the like.

[0127] The above-described embodiments are by way of example only and other embodiments may be practiced within the scope of the following claims. [Explanation of symbols]

[0128] 50 Network 100 Electronic equipment 110 Processor 120 Databases 200 User terminal

Claims

1. 1. A method for providing a payment service executed by an electronic device, comprising: receiving a payment request for the item from a user; determining whether the acquired payment request satisfies a specified condition; omitting an additional authentication step in response to the payment request satisfying the specified condition, and providing payment completion information corresponding to the payment request; transmitting a delivery request for the item to an immediate delivery-related server in response to the payment completion information before proceeding with a transaction procedure related to payment corresponding to the payment request; and if a request for canceling the payment for the item is not received from the user's terminal within a set time before delivery of the item is completed after providing the payment completion information, proceeding with the transaction procedure related to payment of the payment corresponding to the payment request.

2. 2. The method of claim 1, further comprising the step of transmitting a request to cancel delivery of the item to the delivery-related server when a request to cancel payment for the item is received from the user's terminal within the set time.

3. providing the payment completion information to the user's terminal, the payment completion information including providing a page displaying information related to the payment completion to the user's terminal; 2. The method of claim 1, wherein the providing the page includes providing a user interface for canceling the payment on at least a portion of content of information related to the completion of the payment displayed on the page for the set time.

4. The method of claim 1 , wherein the specified conditions include a condition regarding a type of payment method corresponding to the payment request.

5. The method of claim 1 , further comprising the step of requesting a predetermined additional authentication in response to the payment request not satisfying at least a portion of the specified conditions.

6. The method of claim 1 , wherein the specified conditions include at least one of an amount limit condition corresponding to the payment request and a risk judgment condition for the payment.

7. The risk judgment condition is: The method of claim 6, further comprising a condition regarding at least one of type information for the item, delivery location information corresponding to the payment request, and information regarding a device that transmits the payment request.

8. The step of requesting the predetermined additional authentication includes: The method of claim 5, further comprising the step of requesting payment authentication using a pin number or biometric information.

9. The method of claim 4 , wherein the specified conditions include a decision tree mapped to each of the payment method types.

10. A method of providing a payment service as described in Claim 9, wherein each of the multiple decision trees differs from the others in at least one of the detailed conditions, the decision order of each detailed condition, and the critical value information of each detailed condition.

11. 2. The method of claim 1, further comprising: ignoring at least a portion of the repeatedly requested payment requests when the same payment request is repeatedly received from the user's terminal for a specified time period.

12. 1. An electronic device comprising: A communication module; a processor, the processor comprising: Obtain a payment request for the item from the user, Check whether the received payment request satisfies the specified conditions; omitting an additional authentication step in response to the payment request satisfying the specified condition, and providing payment completion information corresponding to the payment request; transmit a delivery request for the item to an immediate delivery-related server in response to the payment completion information before proceeding with a transaction procedure related to payment corresponding to the payment request; and an electronic device configured to proceed with the transaction procedure related to the payment of the payment request if, after providing the payment completion information, a payment cancellation request for the item is not received from the user's terminal for a set time before delivery of the item is completed.

Images