WO2022163893A1 - 결제 서비스 제공 방법 및 이를 수행하는 전자 장치 - Google Patents

결제 서비스 제공 방법 및 이를 수행하는 전자 장치 Download PDF

Info

Publication number
WO2022163893A1
WO2022163893A1 PCT/KR2021/001654 KR2021001654W WO2022163893A1 WO 2022163893 A1 WO2022163893 A1 WO 2022163893A1 KR 2021001654 W KR2021001654 W KR 2021001654W WO 2022163893 A1 WO2022163893 A1 WO 2022163893A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
authentication
request
information
electronic device
Prior art date
Application number
PCT/KR2021/001654
Other languages
English (en)
French (fr)
Inventor
양정권
최보미
Original Assignee
쿠팡 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 쿠팡 주식회사 filed Critical 쿠팡 주식회사
Publication of WO2022163893A1 publication Critical patent/WO2022163893A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/01—Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices

Definitions

  • Various embodiments of the present disclosure relate to a method of providing a payment service and an electronic device performing the same.
  • Various embodiments of the present disclosure provide a method for providing a payment service with improved security and convenience, and an apparatus for performing the same.
  • a method of providing a payment service by an electronic device includes: obtaining a payment request for an item from a user; checking whether the obtained payment request satisfies a specified condition; and omitting the additional authentication step in response to the payment request satisfying a specified condition and providing payment completion information corresponding to the payment request.
  • the payment service providing method may include: transmitting a request for delivery of the item in response to providing the payment completion information; and performing a transaction procedure corresponding to the payment request after a predetermined time after providing the payment completion information.
  • the payment service providing method may include: canceling execution of the transaction procedure when a cancellation request corresponding to the payment is received within the predetermined time; and transmitting a request to cancel delivery of the item in response to receiving the cancellation request.
  • the providing of 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 time.
  • the specified condition may include a type condition of a payment method corresponding to the payment request.
  • the specified condition may be determined based on the payment request.
  • the specified condition may include decision trees mapped to each type of the payment method.
  • the payment service providing method may further include requesting a predetermined additional authentication in response to the payment request not satisfying at least some of the specified conditions.
  • the specified condition may include at least one of an amount limit condition corresponding to the payment request and a risk determination condition of the payment.
  • the risk determination condition may include a condition related to at least one of type information about the item, delivery address information corresponding to the payment request, and information about a device that transmitted the payment request.
  • the step of requesting the predetermined additional authentication may include the step of requesting payment authentication using a pin number or biometric information.
  • An electronic device may include a database; and a processor electrically connected to the database, wherein the processor obtains a payment request for an item from a user, checks whether the obtained payment request satisfies a specified condition, and the payment request satisfies a specified condition In response, an authentication method of the payment may be determined, and payment authentication related information may be provided according to the determined authentication method.
  • the processor provides notification information regarding the completion of authentication of the payment, provides notification information regarding an additional authentication request for the payment, or fails to authenticate the payment. Notification information can be provided.
  • the processor may limit at least some of the payment authentication methods based on user settings, and provide information related to the user setting change based on whether the payment related information satisfies the specified condition. .
  • An application stored in a computer-readable storage medium for performing a method of providing a payment service includes: receiving a payment request input; determining an authentication method of the payment based on whether the payment-related information corresponding to the payment request input satisfies a specified condition; and performing authentication related to the payment according to the determined payment authentication method.
  • a non-transitory computer-readable recording medium recording a program for executing a payment service providing method in a computer according to various embodiments, the payment service providing method comprising: obtaining a payment request for an item from a user; checking whether the obtained payment request satisfies a specified condition; and omitting the additional authentication step in response to the payment request satisfying a specified condition and providing payment completion information corresponding to the payment request.
  • FIG. 1 is a schematic block diagram illustrating a payment service providing system according to various embodiments of the present disclosure.
  • FIG. 2 is a schematic block diagram of an electronic device according to an embodiment of the present disclosure.
  • FIG. 3 is a flowchart illustrating a method of providing a payment service according to an embodiment of the present disclosure.
  • 4A is a flowchart of a method of providing a payment service according to an embodiment of the present disclosure.
  • 4B is a flowchart illustrating a method for providing a payment service according to an embodiment of the present disclosure.
  • FIG. 5 is a flowchart illustrating a method of providing a payment service according to an embodiment of the present disclosure.
  • FIG. 6 is a flowchart illustrating a method of providing a payment service according to an embodiment of the present disclosure.
  • FIG. 7 is a flowchart of a method of providing a payment service according to an embodiment of the present disclosure.
  • FIG. 8 is a diagram schematically illustrating a user interface related to payment service provision according to an embodiment of the present disclosure.
  • FIG. 9 is a diagram schematically illustrating a user interface related to payment service provision according to an embodiment of the present disclosure.
  • FIG. 10 is a diagram schematically illustrating a user interface related to payment service provision according to an embodiment of the present disclosure.
  • FIG. 11 is a diagram schematically illustrating a user interface related to payment service provision according to an embodiment of the present disclosure.
  • FIG. 12 is a diagram schematically illustrating a user interface related to payment service provision according to an embodiment of the present disclosure.
  • FIG. 13 is a diagram schematically illustrating a user interface related to payment service provision according to an embodiment of the present disclosure.
  • FIG. 14 is a diagram schematically illustrating a user interface related to provision of a payment service according to an embodiment of the present disclosure.
  • 15 is a diagram schematically illustrating a user interface related to payment service provision according to an embodiment of the present disclosure.
  • 16 is a flowchart illustrating a method of providing a payment service according to an embodiment of the present disclosure.
  • the "terminal” referred to below may be implemented as a computer or a portable terminal capable of accessing a server or other terminal through a network.
  • the computer includes, for example, a laptop, a desktop, and a laptop equipped with a web browser (WEB Browser), and the portable terminal is, for example, a wireless communication device that ensures portability and mobility.
  • IMT International Mobile Telecommunication
  • CDMA Code Division Multiple Access
  • W-CDMA Wide-Code Division Multiple Access
  • LTE Long Term Evolution
  • It may include a handheld-based wireless communication device.
  • each block of the flowchart diagrams and combinations of the flowchart diagrams may be performed by computer program instructions.
  • These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions performed by the processor of the computer or other programmable data processing equipment are not described in the flowchart block(s). It creates a means to perform functions.
  • These computer program instructions may also be stored in a computer-usable or computer-readable memory that may direct a computer or other programmable data processing equipment to implement a function in a particular manner, and thus the computer-usable or computer-readable memory.
  • the instructions stored in the flowchart block(s) may produce an article of manufacture containing instruction means for performing the function described in the flowchart block(s).
  • the computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to create a computer or other programmable data processing equipment. It is also possible that instructions for performing the processing equipment provide steps for performing the functions described in the flowchart block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations it is also possible for the functions recited in the blocks to occur out of order. For example, it is possible that two blocks shown in succession are actually performed substantially simultaneously, or that the blocks are sometimes performed in the reverse order according to the corresponding function.
  • FIG. 1 is a schematic block diagram illustrating a payment service providing system according to various embodiments of the present disclosure.
  • the payment authentication system may include the electronic device 100 (eg, a server), the user terminal 200 , and the network 50 .
  • the electronic device 100 is a device that performs various processing for providing a payment service, and performs various functions related to payment according to a payment request input received from at least one user terminal 200 through the network 50 . can do.
  • the electronic device 100 may include a plurality of computer systems or computer software implemented as a network server.
  • the electronic device 100 may configure and provide various information as a web page.
  • the electronic device 100 is connected to a subordinate device capable of communicating with another network server through a computer network such as an intranet or the Internet, receives a request to perform a task, performs the task, and provides an execution result It may refer to a computer system and computer software that
  • the electronic device 100 may be understood as a broad concept including a series of application programs that can operate on a network server and various databases built therein.
  • the electronic device 100 uses a network server program that is variously provided according to an operating system such as DOS, Windows, Linux, UNIX, or MacOS. can be implemented.
  • the network 50 may serve to connect the electronic device 100 and the user terminal 200 or the electronic device 100 and an external device (not shown).
  • the network 50 may provide an access path so that the user terminal 200 may be connected to the electronic device 100 to transmit/receive packet data.
  • Operations of the payment service providing system may be implemented through the electronic device 100 , and the user terminal 200 may be connected to the payment system through the network 50 .
  • the electronic device 100 may store information received from the user terminal 200 in a database (eg, the database 120 of FIG. 2 ) or transmit information stored in the database to the user terminal 200 .
  • a database eg, the database 120 of FIG. 2
  • At least some functions of the payment service providing system may be implemented through the user terminal 200 .
  • the user may install and use an application-type payment service providing system in the user terminal 200 through the network 50 .
  • the payment service providing system may be implemented as a single physical device, or may be implemented in a manner in which a plurality of physical devices are organically coupled.
  • some of the functions provided by the electronic device 100 may be implemented by any one physical device, and some of the functions may be implemented by another physical device.
  • any one physical device may be implemented as a part of the electronic device 100
  • the other physical device may be implemented as a part of the user terminal 200 or a part of an external device (not shown).
  • each component included in the payment service providing system is dispersedly disposed on different physical devices, and the distributed components are organically coupled to perform functions and operations of the payment service providing system. may be implemented.
  • FIG. 2 is a schematic block diagram of an electronic device according to an embodiment of the present disclosure.
  • the electronic device 100 may include at least one of a processor 110 and a database 120 .
  • the processor 110 may process a series of functions for performing the payment service providing method according to various embodiments of the present disclosure, and may control overall operation of other component(s) of the electronic device 100 .
  • the processor 110 may determine the payment authentication method of the payment request order based on at least a part of the user's setting information related to the payment authentication method, the payment amount limit condition information, and the payment risk determination condition information. .
  • the processor 110 may perform payment authentication according to the determined payment authentication method, and may provide authentication-related information regarding payment.
  • the processor 110 may determine the payment authentication method based on a payment risk determination condition determined based on the type of payment method specified by the user.
  • the processor 110 as a payment risk determination condition, the type information of the payment target product, the delivery address information of the payment target product, the location information of the user and / or device corresponding to the payment request, or conditions related to at least some of the payment history information Including, it is possible to determine a payment authentication method for each payment.
  • processor 110 may implement various functions related to payment service provision according to various embodiments of the present disclosure, which will be described later.
  • the database 120 is a data structure implemented in a predetermined storage space of the electronic device 100 , and functions such as storing, searching, deleting, editing, or adding data may be freely performed.
  • the database 120 may have fields or components for processing functions such as storage, retrieval, deletion, editing, or addition of data.
  • the database 120 may store data related to various functions of the electronic device 100 .
  • the database 120 may store various information related to a method of providing a payment service (eg, decision tree information corresponding to a type of payment method, etc.), and may include instructions or data can be stored.
  • the electronic device 100 may further include a communication module.
  • the communication module transmits information stored in the database 120 of the electronic device 100 or predetermined information processed by the processor 110 to another device, or transmits information from the other device to the electronic device 100 .
  • the receiving function can be performed.
  • the communication module may receive predetermined user input information (eg, payment request input, etc.) from the user terminal 200 of FIG. 1 .
  • the communication module may include a transceiver for transmitting and receiving information.
  • FIG. 3 is a flowchart illustrating a method of providing a payment service by an electronic device according to various embodiments of the present disclosure
  • 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 .
  • the electronic device 100 may perform user authentication in an initial subscription step for using a payment service. Meanwhile, when the user wants to log in to the payment service through an application or program installed in the user terminal 200 , the electronic device 100 may perform authentication in response to user identification information registered in the subscription step.
  • step 220 the electronic device 100 may perform predetermined authentication in the step of registering a payment method.
  • the user may register for a payment method that the user intends to use for payment in the payment service.
  • the payment means may include at least one of credit or debit card registration, bank account registration, and user terminal registration for use of a simple payment service.
  • the electronic device 100 may perform user authentication and store information related thereto.
  • step 230 the electronic device 100 may perform authentication in an individual payment execution step.
  • a payment for this may be requested from the electronic device 100 .
  • the electronic device 100 includes predetermined information (eg, user identification information, user login information, etc.) acquired during the registration step authentication 210 and predetermined information acquired during the payment method registration step authentication 220 (eg, card). information, bank account information, user terminal information, etc.), and individual case information for which payment is requested (eg, payment target product type information, delivery address information, payment amount information, etc.) authentication can be performed.
  • FIGS. 4A and 4B are flowcharts of a method of providing a payment service according to various embodiments of the present disclosure;
  • FIGS. 4A and 4B may correspond to diagrams for specifically explaining step 230 of FIG. 3 described above.
  • the electronic device 100 may receive a specific payment request input from the user terminal 200 in operation 310 .
  • 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 .
  • a user may perform a payment using a different payment method for each payment request, and may request delivery of a purchased product to a different delivery destination during payment. It may be transmitted to the electronic device 100 in operation 325 .
  • the electronic device 100 may check information related to the requested payment.
  • the payment-related information may include at least some of user identification information, user login information, user's payment authentication history information, payment method information, payment product information, and delivery address information.
  • the electronic device 100 may determine whether the payment related information satisfies a specified condition.
  • the electronic device 100 may perform payment authentication using the first authentication method in step 340 . Also, if it is determined that the payment related information does not satisfy at least some of the specified conditions, the electronic device 100 may perform payment authentication using the second authentication method in step 350 . As described above, the electronic device 100 may differently determine the authentication method of the corresponding payment based on whether the payment related information satisfies a specified condition.
  • the specified condition includes at least some of a limit condition for an amount corresponding to a payment request, a condition for the type of product to be paid, a condition regarding the delivery address of the product, and a condition regarding the device or user (user account) for which payment is requested. can do.
  • the electronic device 100 may determine the payment authentication method by checking whether all of the above-described conditions are satisfied in step 335, and check whether some of the above-mentioned conditions are satisfied according to the set condition to select the payment authentication method. may decide
  • the first authentication method may correspond to one-touch payment in which authentication of payment is immediately completed in response to satisfaction of the specified condition.
  • the electronic device 100 may complete payment authentication in response to satisfaction of the specified condition and may not require an additional authentication procedure.
  • the second authentication method may correspond to an authentication method that requires a predetermined additional payment authentication procedure in response to not satisfying at least some of the specified conditions.
  • payment authentication is performed using input of a pin number or biometric information (eg, fingerprint information, iris information, facial recognition information, etc.) even if the user does not enter card information or account information. It can respond to simple payment.
  • the electronic device 100 may determine to perform payment authentication using the third authentication method when the payment-related information does not satisfy a specific condition.
  • the electronic device 100 may request the user to perform payment authentication according to stricter standards, such as public authentication and user authentication through a terminal in the name of the user.
  • the electronic device 100 may decide to transmit a message indicating that payment authentication has failed to the user terminal 200 instead of determining to perform payment authentication using the third authentication method. .
  • a UI for canceling the payment immediately on the payment completion page may be provided to the user.
  • the user experience can be improved by allowing the user to immediately cancel the payment even when the payment is completed due to an incorrect input.
  • the transaction for actual payment may be performed after waiting a predetermined time. Accordingly, when the user provides a payment cancellation input within a predetermined time, the process of returning the transaction after the actual transaction has occurred by canceling the execution of the corresponding transaction in the waiting transaction list can be omitted.
  • the request for the paid product may be transmitted to the delivery-related server in response to the payment proceeding. As a result, delivery can be completed more quickly, and in the case of delivery, even if it is canceled before shipment, the cost of cancellation is relatively small, and it takes a certain amount of time to ship. Delivery may be canceled at the same time.
  • the transaction may include making a request related to payment of payment through a payment method used by the user for payment, and receiving a response corresponding thereto.
  • the transaction may include requesting payment of a payment amount to a server of a business operator that manages the corresponding account.
  • a time period for receiving the item may be determined based on the time the user paid for the item, and in the embodiment of the specification, when payment is performed through the first authentication method, although the actual transaction according to the payment can be made after a predetermined time after the payment completion information is provided, the delivery request can be performed immediately, and accordingly, the time required for delivery can be secured, providing item information to the user The item may be delivered within the delivery completion time provided by the City.
  • the electronic device 100 when a payment request having the same content is repeatedly received twice or more for a set time, the electronic device 100 receives the first payment request It is also possible to prevent duplicate payment by performing the payment process on a case-by-case basis and automatically ignoring the payment request for subsequent payment request(s). Alternatively, the electronic device 100 may prevent the duplicate payment by transmitting a reconfirmation request notification to the user for the subsequent payment request (s).
  • the payment when a payment request is made at a specific time, even if other conditions satisfy the condition of using the first authentication method, the payment may be performed using the second authentication method. More specifically, abusing can be prevented by setting a time period in which a lot of abusing occurs in a specific payment method and preventing payment using the first authentication method during that time.
  • the electronic device 100 may request payment authentication from the user terminal 200 in response to the determined authentication method (eg, the second authentication method or the third authentication method). As another example, the electronic device 100 may transmit a payment completion guide or a payment failure (or approval rejection) guide message to the user terminal 200 .
  • the electronic device 100 may manage blacklist information among users in relation to each authentication method. Such blacklist information may be prepared based on each user's existing usage history in a service operated by the electronic device 100 . When a user included in the blacklist requests payment, the electronic device 100 may provide a payment rejection message without determining whether payment information satisfies a specified condition.
  • the electronic device 100 may determine an authentication method based on delivery information in relation to an item purchased by the user. According to an example, when the user requests delivery to a delivery destination that has been delivered more than a certain number of times, the electronic device 100 may perform payment authentication using the first authentication method, and when a delivery request is made by changing the delivery address Payment authentication may be performed using the second authentication method.
  • the electronic device 100 may differently set a criterion for determining an authentication method based on at least one of type information of a payment method and a payment amount. More specifically, if the risk of theft is high or damage is expected during theft, stricter standards may be applied to determine the authentication method.
  • FIG. 5 is a flowchart illustrating a method of providing a payment service by an electronic device according to an embodiment of the present disclosure.
  • the electronic device 100 first responds to a payment request input obtained from the user terminal 200 in step 322 , and includes a payment target product included in the requested payment related information. It may be determined whether the payment amount of (or service) exceeds a preset threshold amount.
  • step 322 if the payment amount is less than the preset amount, the operation goes to step 324 to check whether the risk determination condition is satisfied, and if the payment amount exceeds the preset amount, go to step 350
  • the second authentication method eg, a simple payment authentication method by input of a pin number, etc.
  • the payment authentication method for the corresponding payment may be determined.
  • the electronic device 100 before performing the operation of step 322 , the electronic device 100 first checks whether the user is permitted to use the simple payment (and one-touch payment), and allows the user to use the simple payment. In some cases, operations 322 and below may be performed. Meanwhile, according to another embodiment, even when the user does not allow the use of simple payment, the electronic device 100 performs the operation of step 322 or less, so that the payment can be authenticated by the first authentication method. You can also check whether or not
  • the electronic device 100 may identify whether the payment-related information satisfies a specified risk determination condition.
  • the electronic device 100 may include a decision tree related to the risk determination condition and determine a payment authentication method based on the decision tree.
  • the electronic device 100 may determine a payment authentication method based on a machine learning-based learning model as a substitute for the decision tree or in addition to the decision tree.
  • the risk determination condition may include at least a condition regarding type information of a payment target product. For example, if the purchase product for which payment is requested is a gold-related product with good cashability or a data-related digital product, the electronic device 100 determines that the payment is a relatively high-risk payment, and a more secure payment authentication method may decide to apply.
  • the risk determination condition may include at least a condition regarding delivery destination information of the payment target product. For example, when the delivery address of a specific product requested for payment by a specific user is different from the delivery location of a previously paid purchase, the electronic device 100 sets a distance range in which the location of the terminal to which the user's payment request is transmitted and the delivery location are specified. In case of exceeding or different countries, it is judged as a relatively high-risk payment, and authentication can be requested using a more secure payment authentication method.
  • the risk determination condition may include at least a condition regarding the device (eg, the user terminal 200 ) from which the payment request is performed.
  • the condition may include a condition regarding at least one of a payment history and location information corresponding to a device to which the payment request is input.
  • the electronic device 100 based on the previous payment completed history information in the device to which the payment request is input, may be configured when a payment has not been performed for a recent predetermined period or a number of payment attempts have occurred during a specified time in the device.
  • a payment request is made from a device that does not have a previous login history, or when it is estimated that the payment request was entered overseas based on the IP information of the device in which the payment request was entered, a payment with a relatively high risk By judging, authentication can be requested using a more secure payment authentication method.
  • the risk determination condition is, based on the identification information of the user who has input the payment request, if the number of failures or the failure frequency of the user's existing payment is greater than or equal to a threshold, the accumulated amount of products requested for payment for a specified time is a set value. If the number of changes or frequency of changes in passwords related to login authentication of users or authentication related to individual payment cases exceeds the threshold, it is judged as a relatively high-risk payment and more secure You can request authentication as a payment authentication method.
  • the electronic device 100 determines a payment authentication method based on whether the payment-related information satisfies the risk determination condition, and completes authentication or simple payment according to whether the risk determination condition is satisfied. You can request related authentication, request detailed identity authentication, or provide authentication failure information.
  • FIG. 6 is a flowchart illustrating a method of providing a payment service by an electronic device according to an embodiment of the present disclosure.
  • the electronic device 100 may receive a payment request input from the user in step 410, and based on payment related information corresponding to the payment request input in step 420, A specified condition may be determined based on the user's payment method selection information included in the payment-related information.
  • the electronic device 100 may include one or more decision trees in the database 120 .
  • the decision trees may be set differently for each type of payment method, 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 pay by card, pay by transfer through a bank account, or pay from a pre-deposited reserve balance.
  • the electronic device 100 may determine a first condition (eg, a first decision tree) corresponding to the card payment as the aforementioned specified condition.
  • the electronic device 100 may determine a second condition (eg, a second decision tree) corresponding to the bank account transfer as a specified condition.
  • the electronic device 100 may determine a third condition (eg, a third decision tree) corresponding to the reserve balance as a specified condition.
  • the first to third conditions may be different from each other in at least some detailed conditions (eg, items of detailed conditions, a determination order of each detailed condition, and/or threshold information of each detailed condition).
  • step 430 the electronic device 100 determines whether payment related information corresponding to the payment request input in step 410 satisfies the condition determined based on the payment method type in step 420 , and pays according to whether the payment is satisfied You can decide the authentication method.
  • FIG. 7 is a flowchart illustrating a method of providing a payment service according to an embodiment of the present disclosure.
  • the electronic device 100 may receive a payment request input in step 510 , and payment related information corresponding to the payment request input and a preset condition (eg: risk determination condition) to determine at least one of a payment authentication method and a payment authentication method according to the degree of risk.
  • a preset condition eg: risk determination condition
  • the electronic device 100 may perform the operation of step 520 only when a condition related to a payment amount limit is satisfied and/or a user's simple payment (and one-touch payment) designation is satisfied. have.
  • the electronic device 100 determines a 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 provides the user terminal 200 with the second authentication method may transmit a request to perform payment authentication of Correspondingly, the user may perform payment authentication using the second authentication method. For example, the user may authenticate payment by the second authentication method through input of a pin number or input of biometric information.
  • step 540 when payment authentication by the second authentication method by the user is completed, in step 540, a risk based on payment related information related to authentication by the second authentication method The judgment conditions can be compared again.
  • step 540 even if the electronic device 100 succeeds in authentication by the second authentication method in step 530 , based on the number (or frequency) of authentication failures during user authentication using the second authentication method, etc. , the risk determination conditions may be re-compared, and in step 550 , it may be finally determined whether to approve the payment.
  • the electronic device 100 may not finally approve the payment authentication based on the risk determination condition comparison in step 550 .
  • the electronic device 100 may request the user terminal 200 to re-request authentication using a more enhanced security authentication method, or transmit a guide message related to payment approval rejection (or failure) and terminate the payment function. have.
  • whether the payment-related information satisfies the risk determination condition is payment-related information, including account information of the user who requested payment, product information to be paid, information of the terminal that transmitted the payment request, and time information at which the payment request occurred It can be determined based on at least one of Also, the priority of the information serving as the determination criterion may be set differently according to embodiments.
  • FIGS. 8 to 15 are diagrams schematically illustrating a user interface related to payment service provision according to various embodiments of the present disclosure.
  • the electronic device 100 may provide an interface screen for ordering and paying for a specific item in the user terminal 200 .
  • the user may input shipping address information and contact information to receive the payment target item, and sends the payment request information to the electronic device 100 by confirming the payment amount and pressing a payment request button (eg, a "pay" button) can provide Meanwhile, a user may set a payment method or change a preset payment method in relation to the payment, and a more detailed user interface screen is shown in FIG. 9 in this regard.
  • the user performs the corresponding payment in a bank account transfer method, in a method using a reserve balance, in a credit card (or check card) payment method, or
  • a payment method type may be selected in relation to whether to perform payment by a user terminal (eg, mobile phone) payment method.
  • the electronic device 100 encrypts payment-related information (eg, account information, card information, etc.) obtained by registering a payment method in relation to a simple payment service (eg, XX Pay) to obtain the database 120 .
  • payment-related information eg, account information, card information, etc.
  • a simple payment service eg, XX Pay
  • the risk determination result for individual payment cases if it is determined as a low-risk payment target, one-touch payment (e.g., authentication without pin number) is performed as the first authentication method, or the risk is slightly higher.
  • a payment authentication method may be determined and processed as a simple payment (eg, pin number input authentication) method as the second authentication method.
  • the electronic device 100 performs one-touch payment or simple payment based on whether a specified condition is satisfied based on information about the corresponding payment. can be identified, and when one-touch payment is permitted, the interface screen of FIG. 10 may be provided through the user terminal 200, and when simple payment is permitted, an interface screen as shown in FIG. 11 may be provided. .
  • the user repeatedly requests payment (e.g., a button to make a payment) as the user fails to check whether payment approval has been completed while determining whether the one-touch payment is approved or not. Since there is a possibility of inputting the same product and a problem of duplicate orders and duplicate payment of the same product may occur, the electronic device 100 provides a guide interface related to the payment process as shown in FIG. 10 to repeatedly attempt payment by the user errors can be minimized.
  • payment e.g., a button to make a payment
  • the electronic device 100 may provide an interface for guiding payment authentication through input of a pin number as shown in FIG. 11 .
  • the screen may be switched to the interface screen shown in FIG. 12 to provide screen information related to payment information processing progress.
  • the electronic device 100 may provide a related interface screen so that a user can designate whether to use a one-touch (or one-click) payment method.
  • the user may restrict the use of the one-touch payment method so as not to use the one-touch payment method.
  • the electronic device 100 may set to allow the use of one-touch payment through a predetermined authentication procedure (eg, authentication of input of a pin number related to a simple payment service).
  • the electronic device 100 when the user does not allow the use of one-touch payment, notifies the completion of payment approval as the user orders and pays for a specific item and goes through a predetermined payment authentication procedure.
  • notification information suggesting the use of the one-touch payment may be provided together.
  • the electronic device 100 compares information related to the corresponding user's payment with a specified condition (eg, a payment amount limit condition and/or a payment risk determination condition), and the condition under which the corresponding payment allows one-touch payment Notification information suggesting to use the one-touch payment may be provided only when it is determined that it is consistent with .
  • a specified condition eg, a payment amount limit condition and/or a payment risk determination condition
  • 16 is a flowchart illustrating a method of providing a payment service according to an embodiment of the present disclosure.
  • the electronic device 100 preferentially determines whether a user and/or a user terminal corresponding to a specific payment request input corresponds to a target listed in a black list in step 610 . can do.
  • the black list information may be previously stored 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.
  • the electronic device 100 may identify whether the corresponding user and/or the user terminal corresponds to the black list based on the user's login history or the IP address of the accessed terminal.
  • the electronic device 100 rejects the payment approval for the corresponding payment request in step 601 and provides related notification information. can do.
  • the electronic device 100 may determine whether the corresponding payment target satisfies a preset amount limit condition.
  • the electronic device 100 may branch to step 601 and reject approval for the corresponding payment.
  • the electronic device 100 may branch to step 602 and requests additional payment authentication such as a pin number input (or biometric information input or other user authentication related password input) request. It goes without saying that payment may be approved according to the additional payment authentication result.
  • the electronic device 100 may determine whether a condition related to a payment target product type is satisfied in step 630 . For example, when the product for which payment is requested 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 .
  • step 630 when the condition of step 630 is satisfied for the reason that the payment requested product does not correspond to a digital product, the electronic device 100 may determine whether other risk determination conditions are satisfied in step 640 .
  • the risk determination condition includes first risk conditions for detecting a case in which payment is attempted by stealing another person's card or passbook, and a case in which payment is attempted by stealing user account-related information (eg, ID and password) It may include second risk conditions for detecting .
  • the risk determination condition may further include third risk conditions for determining a risk for a payment case by a new user terminal without a previous payment history.
  • the electronic device 100 first determines whether payment-related information corresponding to the payment request input satisfies the first risk conditions, and then whether the second risk conditions are satisfied. It is determined whether or not the third risk condition is satisfied, and based on the determination result, immediately complete the payment authentication and approve the payment in step 603, or perform additional payment authentication in step 602 you can request
  • the electronic device 100 determines whether a device for which payment is requested (eg, a user terminal) is the same as a device for which the user has made an existing payment (eg, the initial payment), and the delivery address is Conditions regarding whether the shipping address corresponds to the original payment (e.g., initial payment), conditions regarding whether the shipping address is domestic, conditions regarding whether users and/or user terminals fall under the white list, and payment within the last N hours Conditions regarding the number or frequency of changes in authentication-related information (e.g., various passwords such as pin numbers), conditions regarding the number or frequency of failed payment authentication within the last N hours, existing payment verification history (e.g., successful one-touch payment history, (History authenticated through simple payment method or general payment method within the last N hours) Related conditions It may include at least a part of conditions related to the amount of money and conditions related to the amount/number of times that one user account has attempted to make a payment for a specified period of time. Each of the conditions may or may not have
  • the step of determining whether the risk determination condition is satisfied when the waiting time required to check whether the risk determination condition is satisfied exceeds a specified threshold time, Regardless of the final risk determination result, you can always make an additional payment authentication request.
  • the electronic device or terminal includes 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, a touch panel, and a key (key). ), user interface devices such as buttons, and the like.
  • Methods implemented as software modules or algorithms may be stored on a computer-readable recording medium as computer-readable codes or program instructions executable on the processor.
  • the computer-readable recording medium includes a magnetic storage medium (eg, read-only memory (ROM), random-access memory (RAM), floppy disk, hard disk, etc.) and an optically readable medium (eg, CD-ROM). ), DVD (Digital Versatile Disc), and the like.
  • the computer-readable recording medium is distributed among network-connected computer systems, so that the computer-readable code can be stored and executed in a distributed manner.
  • the medium may be readable by a computer, stored in a memory, and executed on a processor.
  • This embodiment may be represented by functional block configurations and various processing steps. These functional blocks may be implemented in any number of hardware and/or software configurations that perform specific functions.
  • an embodiment may be an integrated circuit configuration, such as memory, processing, logic, look-up table, etc., capable of executing various functions by the control of one or more microprocessors or other control devices.
  • this embodiment includes various algorithms implemented in a combination of data structures, processes, routines or other programming constructs, including C, C++, Java ( Java), assembler, etc. may be implemented in a programming or scripting language.
  • Functional aspects may be implemented in an algorithm running on one or more processors.
  • the present embodiment may employ the prior art for electronic environment setting, signal processing, and/or data processing.
  • Terms such as “mechanism”, “element”, “means” and “configuration” may be used broadly and are not limited to mechanical and physical configurations. The term may include the meaning of a series of routines of software in connection with a processor or the like.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Artificial Intelligence (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Human Resources & Organizations (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

다양한 실시예에 따른 결제 서비스 제공 방법은, 사용자로부터 아이템에 대한 결제 요청을 획득하는 단계; 상기 획득된 결제 요청이 지정된 조건을 만족하는지 확인하는 단계; 및 상기 결제 요청이 지정된 조건을 만족하는 것에 대응하여 추가 인증 단계를 생략하고 상기 결제 요청에 대응하는 결제 완료 정보를 제공하는 단계를 포함할 수 있다. 이밖에 다른 실시예들이 가능하다.

Description

결제 서비스 제공 방법 및 이를 수행하는 전자 장치
본 개시의 다양한 실시예는 결제 서비스 제공 방법 및 이를 수행하는 전자 장치에 관한 것이다.
전자 장치의 발전에 따라 각종 기능들을 보유한 다양한 형태의 휴대 단말기가 널리 보급되고 있다. 또한, 최근 전자 상거래가 활성화됨에 따라 단말기를 이용하여 온라인으로 주문 및 결제를 수행하는 경우가 늘고 있다.
이러한 온라인 결제는 오프라인 상의 종래의 거래와 달리 타인에 의해 사용자 정보가 탈취되어 사기 거래가 이루어질 수 있는 점에서 본인임을 인증할 수 있도록 보안성을 강화할 것이 요구되었고 이에 따라 다양하고 복잡한 사용자 인증 방식이 적용되어 왔다.
그러나 이와 같은 복잡한 인증 방식은 온라인 결제의 장벽이 될 수 있고, 보안에 대한 불안보다 오히려 사용자의 번거로움과 불편함이 더욱 대두되었고, 그에 따라 보안성과 편리성 사이에서 절충안을 마련할 필요가 요구되고 있는 추세이다.
본 개시의 다양한 실시예들은, 보안성 및 편리성을 개선한 결제 서비스 제공 방법 및 이를 수행하는 장치를 제공하고자 한다.
다양한 실시예에 따른 전자 장치의 결제 서비스 제공 방법은, 사용자로부터 아이템에 대한 결제 요청을 획득하는 단계; 상기 획득된 결제 요청이 지정된 조건을 만족하는지 확인하는 단계; 및 상기 결제 요청이 지정된 조건을 만족하는 것에 대응하여 추가 인증 단계를 생략하고 상기 결제 요청에 대응하는 결제 완료 정보를 제공하는 단계를 포함할 수 있다.
예를 들면, 상기 결제 서비스 제공 방법은, 상기 결제 완료 정보 제공에 대응하여 상기아이템의 배송 요청을 전송하는 단계; 및 상기 결제 완료 정보 제공 이후 소정의 시간 이후에 상기 결제 요청에 대응하는 트랜젝션 절차를 수행하는 단계를 더 포함할 수 있다.
예를 들면, 상기 결제 서비스 제공 방법은, 상기 소정의 시간 이내에 상기 결제에 대응하는 취소 요청을 수신하는 경우 상기 트랜젝션 절차의 수행을 취소하는 단계; 및 상기 취소 요청 수신에 대응하여 상기 아이템의 배송 취소 요청을 전송하는 단계를 더 포함할 수 있다.
예컨대, 상기 결제 완료 정보를 제공하는 단계는, 상기 결제 완료 정보 중 적어도 일부의 컨텐츠 위에 상기 결제를 취소할 수 있는 사용자 인터페이스를 설정된 시간 동안 제공하는 단계를 포함할 수 있다.
예를 들면, 상기 지정된 조건은, 상기 결제 요청에 대응하는 결제 수단의 유형 조건을 포함할 수 있다.
예컨대, 상기 지정된 조건은 상기 결제 요청을 기반으로 결정될 수 있다. 예컨대 상기 지정된 조건은 상기 결제 수단의 유형 각각에 매핑된 디시젼 트리들을 포함할 수 있다.
예를 들면, 상기 결제 서비스 제공 방법은, 상기 결제 요청이 상기 지정된 조건의 적어도 일부를 만족하지 않는 것에 대응하여 소정의 추가 인증을 요청하는 단계를 더 포함할 수 있다.
예를 들어, 상기 지정된 조건은, 상기 결제 요청에 대응하는 금액 한도 조건 및 상기 결제의 리스크 판단 조건 중 적어도 하나를 포함할 수 있다.
예컨대 상기 리스크 판단 조건은, 상기 아이템에 대한 유형 정보, 상기 결제 요청에 대응하는 배송지 정보, 및 상기 결제 요청을 전송한 장치에 관한 정보 중 적어도 하나에 관한 조건을 포함할 수 있다.
예컨대 상기 소정의 추가 인증을 요청하는 단계는, 핀 번호 또는 생체 정보를 이용한 결제 인증을 요청하는 단계를 포함할 수 있다.
다양한 실시예에 따른 전자 장치는, 데이터베이스; 및 상기 데이터베이스와 전기적으로 연결된 프로세서를 포함하고, 상기 프로세서는, 사용자로부터 아이템에 대한 결제 요청을 획득하고, 상기 획득된 결제 요청이 지정된 조건을 만족하는지 확인하고, 상기 결제 요청이 지정된 조건을 만족하는 것에 대응하여 상기 결제의 인증 방식을 결정하고, 및 상기 결정된 인증 방식에 따라 결제 인증 관련 정보를 제공할 수 있다.
예컨대, 상기 프로세서는, 상기 인증 관련 정보의 제공과 관련하여, 상기 결제의 인증 완료에 관한 알림 정보를 제공하거나, 상기 결제의 추가 인증 요청에 관한 알림 정보를 제공하거나, 또는 상기 결제의 인증 실패에 관한 알림 정보를 제공할 수 있다.
예컨대, 상기 프로세서는, 사용자 설정에 기반하여 상기 결제 인증 방식 중 적어도 일부를 제한하고, 상기 결제 관련 정보가 상기 지정된 조건을 만족하는지 여부에 기초하여, 상기 사용자 설정 변경과 관련된 정보를 제공할 수 있다.
다양한 실시예에 따른 결제 서비스 제공 방법을 수행하도록 하는 컴퓨터 판독 가능한 저장매체에 저장된 애플리케이션은, 결제 요청 입력을 수신하는 단계; 상기 결제 요청 입력에 대응하는 결제 관련 정보가 지정된 조건을 만족하는지 여부에 기초하여, 상기 결제의 인증 방식을 결정하는 단계; 및 상기 결정된 결제 인증 방식에 따라 상기 결제에 관한 인증을 수행하는 단계를 포함할 수 있다.
다양한 실시예에 따른 결제 서비스 제공 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 비일시적인 기록매체로서, 상기 결제 서비스 제공 방법은, 사용자로부터 아이템에 대한 결제 요청을 획득하는 단계; 상기 획득된 결제 요청이 지정된 조건을 만족하는지 확인하는 단계; 및 상기 결제 요청이 지정된 조건을 만족하는 것에 대응하여 추가 인증 단계를 생략하고 상기 결제 요청에 대응하는 결제 완료 정보를 제공하는 단계를 포함할 수 있다.
다양한 실시예에 따르면, 보안성이 개선된 원터치 결제를 사용자에게 유도함으로써 안전하고 신뢰받는 환경에서 편리하고 신속한 구매 및 결제 기능을 제공할 수 있다.
다양한 실시예에 따르면, 구매자에게 결제가 쉽고 빠른 원터치 결제 또는 간편 결제를 적극적으로 유도함으로써, 결제 인증에 소요되는 시간 동안 구매자가 결제를 취소하고 결제창을 이탈하는 가능성을 최소화할 수 있다.
다양한 실시예에 따르면, 결제 수단 유형 별로 마련된 디시젼 트리들을 이용하여 사용자가 선택한 결제 수단에 대응하여 각각의 결제에 대한 정확한 리스크 판단을 수행할 수 있다. 이를 통해 보안성 및 사용자 편리성이 개선된 결제 방식을 제공할 수 있다.
도 1은 본 개시의 다양한 실시예에 따른 결제 서비스 제공 시스템을 나타내는 개략적인 구성 블록도이다.
도 2는 본 개시의 일 실시예에 따른 전자 장치의 개략적인 구성 블록도이다.
도 3은 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 4a는 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 4b는 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 5는 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 6은 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 7은 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 8은 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 9는 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 10은 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 11은 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 12는 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 13은 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 14는 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 15는 본 개시의 일 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 16은 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
실시 예들에서 사용되는 용어는 본 개시에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.
명세서 전체에서 어떤 부분이 어떤 구성요소를 “포함”한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있음을 의미한다. 또한, 명세서에 기재된 “...부”, “...모듈” 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.
명세서 전체에서 기재된 “a, b, 및 c 중 적어도 하나”의 표현은, ‘a 단독’, ‘b 단독’, ‘c 단독’, ‘a 및 b’, ‘a 및 c’, ‘b 및 c’, 또는 ‘a,b,c 모두’를 포괄할 수 있다.
이하에서 언급되는 "단말"은 네트워크를 통해 서버나 타 단말에 접속할 수 있는 컴퓨터나 휴대용 단말로 구현될 수 있다. 여기서, 컴퓨터는 예를 들어, 웹 브라우저(WEB Browser)가 탑재된 노트북, 데스크톱(desktop), 랩톱(laptop) 등을 포함하고, 휴대용 단말은 예를 들어, 휴대성과 이동성이 보장되는 무선 통신 장치로서, IMT(International Mobile Telecommunication), CDMA(Code Division Multiple Access), W-CDMA(W-Code Division Multiple Access), LTE(Long Term Evolution) 등의 통신 기반 단말, 스마트폰, 태블릿 PC 등과 같은 모든 종류의 핸드헬드(Handheld) 기반의 무선 통신 장치를 포함할 수 있다.
아래에서는 첨부한 도면을 참고하여 본 개시의 실시 예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.
이하, 본 발명의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 발명이 속하는 기술 분야에 익히 알려져 있고 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
도 1은 본 개시의 다양한 실시예에 따른 결제 서비스 제공 시스템을 나타내는 개략적인 구성 블록도이다.
다양한 실시예에 따르면 결제 인증 시스템은, 전자 장치(100)(예: 서버), 사용자 단말(200), 및 네트워크(50)를 포함할 수 있다.
전자 장치(100)는, 결제 서비스를 제공하기 위한 다양한 처리를 수행하는 장치로서 적어도 하나의 사용자 단말(200)로부터 네트워크(50)를 통해 수신되는 결제 요청 입력에 따라, 결제와 관련된 각종 기능들을 수행할 수 있다.
전자 장치(100)는, 네트워크 서버로 구현되는 다수의 컴퓨터 시스템 또는 컴퓨터 소프트웨어를 포함할 수 있다. 전자 장치(100)는 다양한 정보를 웹 페이지로 구성하여 제공할 수 있다.
예를 들면, 전자 장치(100)는, 인트라넷 또는 인터넷과 같은 컴퓨터 네트워크를 통해 다른 네트워크 서버와 통신할 수 있는 하위 장치와 연결되어 작업 수행 요청을 접수하고, 그에 대한 작업을 수행하여 수행 결과를 제공하는 컴퓨터 시스템 및 컴퓨터 소프트웨어를 지칭할 수 있다. 이외에도, 상기 전자 장치(100)는, 네트워크 서버 상에서 동작할 수 있는 일련의 응용 프로그램과, 내부에 구축되어 있는 각종 데이터베이스를 포함하는 광의의 개념으로 이해될 수 있다. 예컨대, 전자 장치(100)는, 도스(DOS), 윈도우(Windows), 리눅스(Linux), 유닉스(UNIX), 또는 맥OS(MacOS) 등의 운영 체제에 따라 다양하게 제공되는 네트워크 서버 프로그램을 이용하여 구현될 수 있다.
네트워크(50)는, 전자 장치(100)와 사용자 단말(200), 또는 전자 장치(100)와 외부 장치(미도시)를 연결하는 역할을 할 수 있다. 예를 들어, 네트워크(50)는, 사용자 단말(200)이 상기 전자 장치(100)와 연결되어 패킷 데이터를 송수신할 수 있도록 접속 경로를 제공할 수 있다.
본 개시의 일 실시예에 따른 결제 서비스 제공 시스템의 동작들은, 전자 장치(100)를 통해 구현될 수 있으며, 사용자 단말(200)은 네트워크(50)를 통해 상기 결제 시스템에 연결될 수 있다.
전자 장치(100)는 사용자 단말(200)로부터 수신한 정보를 데이터베이스(예: 도 2의 데이터베이스(120))에 저장하거나, 상기 데이터베이스에 저장된 정보를 사용자 단말(200)에 전송할 수 있다.
다른 실시예에 따르면 결제 서비스 제공 시스템의 적어도 일부 기능은 사용자 단말(200)을 통해 구현될 수도 있다. 예를 들면, 사용자는 네트워크(50)를 통해, 사용자 단말(200)에 애플리케이션 형식의 결제 서비스 제공 시스템을 설치하여 사용할 수 있다.
다양한 실시예에 따른 결제 서비스 제공 시스템은, 단일의 물리적 장치로 구현될 수 있으며, 복수의 물리적 장치가 유기적으로 결합된 방식으로 구현될 수도 있다. 예를 들어, 전자 장치(100)에서 제공하는 기능 중 일부는 어느 하나의 물리적 장치에 의해 구현되고, 나머지 일부는 다른 물리적 장치로 구현될 수 있다. 예컨대, 어느 하나의 물리적 장치는, 전자 장치(100)의 일부로 구현될 수 있으며, 다른 물리적 장치는, 사용자 단말(200)의 일부 또는 외부 장치(미도시)의 일부로 구현될 수 있다. 경우에 따라, 결제 서비스 제공 시스템에 포함된 각각의 구성요소들은 각각 서로 다른 물리적 장치에 분산되어 배치되고, 상기 분산 배치된 구성요소들이 유기적으로 결합되어, 결제 서비스 제공 시스템의 기능 및 동작을 수행하도록 구현될 수도 있다.
도 2는 본 개시의 일 실시예에 따른 전자 장치의 개략적인 구성 블록도이다.
도 2를 참조하면, 다양한 실시예에 따른 전자 장치(100)(예: 서버)는, 프로세서(110) 및 데이터베이스(120) 중 적어도 하나를 포함할 수 있다.
프로세서(110)는, 본 개시의 다양한 실시예에 따른 결제 서비스 제공 방법을 수행하기 위한 일련의 기능들을 처리할 수 있으며, 전자 장치(100)의 다른 구성요소(들)의 동작을 전반적으로 제어할 수 있다.
예를 들면, 프로세서(110)는, 결제 인증 방식과 관련된 사용자의 설정 정보, 결제 금액 한도 조건 정보, 결제 리스크 판단 조건 정보 중 적어도 일부에 기반하여, 결제 요청된 주문의 결제 인증 방식을 결정할 수 있다.
예를 들면, 프로세서(110)는, 결정된 결제 인증 방식에 따라 결제 인증을 수행할 수 있으며, 결제에 관한 인증 관련 정보를 제공할 수 있다.
예를 들면, 프로세서(110)는, 사용자가 지정한 결제 수단의 유형을 기초로 결정되는 결제 리스크 판단 조건을 기반으로 결제 인증 방식을 결정할 수 있다.
예컨대, 프로세서(110)는 결제 리스크 판단 조건으로서, 결제 대상 상품의 유형 정보, 결제 대상 상품의 배송지 정보, 결제 요청에 대응하는 사용자 및/또는 장치의 위치 정보나 결제 이력 정보 중 적어도 일부에 관한 조건을 포함하여, 각각의 결제에 대한 결제 인증 방식을 결정할 수 있다.
프로세서(110)는, 이외에도 후술하는 본 개시의 다양한 실시예에 따른 결제 서비스 제공과 관련된 다양한 기능들을 구현할 수 있다.
데이터베이스(120)는, 전자 장치(100)의 소정의 저장 공간에 구현된 데이터 구조로서, 데이터의 저장, 검색, 삭제, 편집, 또는 추가 등의 기능이 자유롭게 수행될 수 있다. 예컨대, 데이터베이스(120)는 데이터의 저장, 검색, 삭제, 편집, 또는 추가 등의 기능을 처리하기 위한 필드 또는 구성요소들을 가질 수 있다.
데이터베이스(120)는 전자 장치(100)의 다양한 기능과 관련된 데이터를 저장할 수 있다. 예를 들면, 데이터베이스(120)는, 결제 서비스 제공 방법과 관련된 다양한 정보(예: 결제 수단 유형에 대응하는 디시젼 트리 정보 등)를 저장할 수 있으며, 프로세서(110)의 실행 동작을 위한 명령어들 또는 데이터들을 저장할 수 있다.
한편 도시되지 않았지만, 전자 장치(100)는 통신 모듈을 더 포함할 수 있다. 예를 들면, 통신 모듈은 전자 장치(100)의 데이터베이스(120)에 저장된 정보 또는 프로세서(110)에 의해 처리된 소정의 정보를 다른 장치로 전송하거나, 다른 장치로부터 전자 장치(100)로 정보를 수신하는 기능을 수행할 수 있다. 예컨대, 통신 모듈은 도 1의 사용자 단말(200)로부터 소정의 사용자 입력 정보(예: 결제 요청 입력 등)를 수신할 수 있다. 예를 들면, 상기 통신 모듈은 정보를 송수신하기 위한 트랜시버를 포함할 수 있다.
도 3은 본 개시의 다양한 실시예에 따른 전자 장치의 결제 서비스 제공 방법에 관한 흐름도이다.
도 3을 참조하면, 전자 장치(100)는 사용자 단말(200)에 설치되는 결제 관련 애플리케이션 또는 프로그램을 통해 결제 서비스의 제공과 관련된 사용자 인증을 수행할 수 있다.
예를 들면, 전자 장치(100)는 우선, 단계 210에서, 결제 서비스 이용을 위한 최초 가입 단계에서 사용자 인증을 수행할 수 있다. 한편 사용자가 사용자 단말(200)에 설치된 애플리케이션 또는 프로그램을 통해 결제 서비스에 로그인하고자 하는 경우, 전자 장치(100)는 가입 단계에서 등록한 사용자 식별 정보에 대응하여 인증을 수행할 수 있다.
다음으로, 전자 장치(100)는, 단계 220에서, 결제 수단을 등록하는 단계에서 소정의 인증을 수행할 수 있다.
예를 들면, 사용자는 결제 서비스에서 본인이 결제 시 이용하고자 하는 결제 수단에 대해 등록을 수행할 수 있다. 예컨대, 상기 결제 수단은 간편 결제 서비스 이용을 위한 신용카드 또는 체크카드 등록, 은행 계좌 등록, 사용자 단말기 등록 중 적어도 하나를 포함할 수 있다. 전자 장치(100)는 상기 결제 수단을 등록하는 단계에서 사용자 본인 인증을 수행하고 이와 관련된 정보를 보관할 수 있다.
다음으로, 전자 장치(100)는, 단계 230에서, 개별적인 결제 수행 단계에서의 인증을 수행할 수 있다.
다양한 실시예에서 사용자가 특정 상품이나 서비스를 구매 결정하는 경우, 이에 대한 결제를 전자 장치(100) 측에 요청할 수 있다. 전자 장치(100)는, 가입 단계 인증(210) 시 획득한 소정의 정보(예: 사용자 식별 정보, 사용자 로그인 정보 등)와 결제 수단 등록 단계 인증(220) 시 획득한 소정의 정보(예: 카드 정보, 은행 계좌 정보, 사용자 단말기 정보 등), 그리고 결제 요청된 개별 케이스 정보(예: 결제 대상 상품의 유형 정보, 배송지 정보, 결제 금액 정보 등) 중 적어도 일부에 기초하여, 각각의 결제 요청 건에 대한 인증을 수행할 수 있다.
도 4a 및 도 4b는 본 개시의 다양한 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다. 예를 들면, 도 4a 및 도 4b는 전술한 도 3의 단계 230을 구체적으로 설명하기 위한 도면에 해당할 수 있다.
도 4a 및 도 4b를 참조하면, 다양한 실시예에 따른 전자 장치(100)는, 단계 310에서, 사용자 단말(200)로부터 특정 결제 요청 입력을 수신할 수 있다.
예를 들면, 단계 315에서 사용자는 사용자 단말(200)에 설치된 결제 서비스 관련 애플리케이션 또는 프로그램을 이용하여 하나 이상의 구매 물품에 대한 결제를 요청할 수 있다. 예컨대 사용자는 각각의 결제 요청 건마다 다른 결제 수단을 이용하여 결제를 수행할 수 있으며, 결제 시 다른 배송지로 구매 물품에 대한 배송을 요청할 수도 있으므로, 상기 각각의 결제 요청에 대응하여 상이한 결제 관련 정보가 단계 325에서 전자 장치(100)에 전송될 수 있다.
단계 320에서, 전자 장치(100)는 상기 요청된 결제와 관련된 정보를 확인할 수 있다. 여기서 결제 관련 정보에는 사용자 식별 정보, 사용자 로그인 정보, 사용자의 결제 인증 이력 정보나, 결제 수단 정보, 결제 상품 정보, 배송지 정보 중 적어도 일부를 포함할 수 있다.
다음으로, 전자 장치(100)는, 단계 330 및 단계 335에서, 결제 관련 정보가 지정된 조건을 만족하는지 여부를 판단할 수 있다.
예를 들어, 전자 장치(100)는, 결제 관련 정보가 지정된 조건을 만족하는 것으로 판단하면, 단계 340에서 제1 인증 방식으로 결제 인증을 수행할 수 있다. 또한, 전자 장치(100)는 결제 관련 정보가 지정된 조건 중 적어도 일부를 만족하지 않는 것으로 판단하면, 단계 350에서 제2 인증 방식으로 결제 인증을 수행할 수 있다. 이와 같이 전자 장치(100)는, 결제 관련 정보가 지정된 조건을 만족하는지 여부에 기초하여 해당 결제의 인증 방식을 다르게 결정할 수 있다.
예를 들면, 상기 지정된 조건은, 결제 요청에 대응하는 금액 한도 조건, 결제할 상품의 유형 조건, 상품의 배송지에 관한 조건, 결제 요청된 장치나 사용자(사용자 계정)에 관한 조건 중 적어도 일부를 포함할 수 있다. 예컨대 전자 장치(100)는 단계 335에서 전술한 조건들을 전부 만족하는지 여부를 확인함으로써 결제 인증 방식을 결정할 수 있으며, 설정된 조건에 따라 전술한 조건들 중 일부를 만족하는지 여부를 확인하여 결제 인증 방식을 결정할 수도 있다.
예컨대, 제1 인증 방식은, 상기 지정된 조건의 만족에 대응하여 결제의 인증이 즉시 완료되는 원터치 결제에 대응할 수 있다. 예를 들어, 전자 장치(100)는 상기 제1 인증 방식으로 결제 인증 방식을 결정하는 경우, 상기 지정된 조건의 만족에 대응하여 결제 인증을 완료하고, 추가적인 인증 절차를 요구하지 않을 수 있다.
예컨대, 제2 인증 방식은, 상기 지정된 조건 중 적어도 일부를 만족하지 않는 것에 대응하여, 소정의 추가 결제 인증 절차를 요구하는 인증 방식에 대응할 수 있다. 예를 들면, 제2 인증 방식은, 사용자가 카드 정보나 계좌 정보를 기입하지 않더라도 핀 번호 입력 또는 생체 정보(예: 지문 정보, 홍채 정보, 안면 인식 정보 등)의 입력을 이용하여 결제 인증이 수행되는 간편 결제에 대응할 수 있다.
도시되지 않았지만, 전자 장치(100)는 상기 결제 관련 정보가 특정 조건을 만족하지 않는 경우 제3 인증 방식으로 결제 인증을 수행하도록 결정할 수도 있다. 이 경우, 전자 장치(100)는 사용자에게 공인 인증, 본인 명의의 단말기를 통한 사용자 인증 등과 같은 보다 엄격한 기준의 결제 인증을 수행하도록 요구할 수 있다. 한편, 또 다른 실시예에 따르면, 전자 장치(100)는 상기 제3 인증 방식으로 결제 인증을 수행하도록 결정하는 대신, 결제 인증이 실패하였음을 알리는 메시지를 사용자 단말(200)에 전송하도록 결정할 수도 있다.
한편 실시 예에서 추가적인 인증을 요구하지 않는 제1 인증 방식으로 결제가 진행된 경우, 결제 완료 페이지에서 결제 취소를 바로 할 수 있는 UI를 사용자에게 제공할 수 있다. 이를 통해 사용자가 오입력으로 결제가 완료된 경우에도 결제 취소를 바로 할 수 있도록 함으로써 사용자 경험을 향상 시킬 수 있다.
또한 실시 예에서 제1 인증 방식으로 결제가 진행되는 경우, 실제 결제를 위한 트랜젝션은 소정의 시간을 대기한 이후 진행될 수 있다. 이에 따라 사용자가 소정의 시간 내에 결제 취소 입력을 제공하는 경우, 대기하는 트랜젝션 리스트에서 해당 트랜젝션 수행을 취소함으로써 실제 트랜젝션이 발생한 이후 반환하는 절차를 생략할 수 있다. 다만 트랜젝션이 수행되지 않은 경우에도 결제된 상품의 요청은 결제 진행에 대응하여 배송 관련 서버에 전송할 수 있다. 이에 따라 보다 신속히 배송을 완료할 수 있으며, 배송의 경우 출고 이전에 취소되는 경우에도 취소에 따른 비용이 상대적으로 크지 않고, 출고까지 일정 시간이 소요되는 바, 상기 소정의 시간 대기 내에 취소가 발생할 경우 출고도 동시에 취소될 수 있다. 한편 실시 예에서 트랜젝션은 사용자가 결제에 사용한 결제 수단을 통해 결제 대금 지급과 관련된 요청을 하고, 이에 대응한 응답을 수신하는 것을 포함할 수 있다. 일 예로 트랜젝션은 특정 계좌를 사용한 결제의 경우 해당 계좌를 관리하는 사업자의 서버에 결제 대금의 지급을 요청하는 것을 포함할 수 있다. 이와 같은 트랜젝션과 배송 요청 방식을 통해 트랜젝션 취소에 따른 추가 비용 발생은 줄일 수 있으며, 결제 완료 정보 제공에 대응하여 배송 요청을 함으로써 사용자는 결제 완료 정보를 제공 받은 시간을 기준으로 결제한 아이템을 수신할 시간을 포함할 수 있다. 보다 구체적으로 전자 장치가 제공하는 서비스는 사용자가 아이템을 결제한 시간을 기준으로 상기 아이템을 배송 받을 수 있는 시구간이 결정될 수 있으며, 명세서의 실시 예에서 제1 인증 방식을 통해 결제를 수행한 경우에 결제에 따른 실제 트랜젝션은 결제 완료 정보를 제공한 이후 소정의 시간 이후에 이루어 질 수 있으나, 배송 요청은 바로 수행될 수 있으며, 이에 따라 배송에 소요된 시간을 확보할 수 있어, 사용자에게 아이템 정보 제공 시 제공한 배송 완료 시점 내에 아이템을 제공할 수 있다.
다만, 위와 같은 실시예에 한정되는 것은 아니며, 본 개시의 다른 실시예에 따르면, 전자 장치(100)는 설정된 시간 동안 동일한 내용의 결제 요청이 두 번 이상 반복적으로 수신되는 경우, 처음 수신된 결제 요청 건을 기준으로 결제 프로세스를 진행하고, 이후의 결제 요청 건(들)에 대해서는 자동으로 결제 요청을 무시함으로써 중복 결제를 방지할 수도 있다. 또는, 전자 장치(100)는 상기 이후의 결제 요청 건(들)에 대하여 사용자에게 재확인 요청 알림을 전송하는 방식으로 상기 중복 결제를 방지할 수도 있다.
한편 실시 예에서 특정 시간에 결제 요청이 되는 경우, 다른 조건들이 제1 인증 방식을 사용하는 조건을 만족하는 경우에도 제2 인증 방식으로 결제를 진행하도록 할 수 있다. 보다 구체적으로 특정 결제 방식으로 어뷰징이 다수 일어나는 시간대를 설정하고 해당 시간동안에는 제1 인증 방식을 사용하는 결제를 진행하지 못하게 함으로써 어뷰징을 방지할 수 있다.
전자 장치(100)는, 단계 345에서, 상기 결정된 인증 방식(예: 제2 인증 방식 또는 제3 인증 방식)에 대응하여 사용자 단말(200) 측으로 결제 인증을 요청할 수 있다. 다른 예로, 전자 장치(100)는, 상기 사용자 단말(200) 측으로 결제의 완료 안내 또는 결제의 실패(또는, 승인 거절) 안내 메시지를 전송할 수도 있다.
한편 실시 예에서 전자 장치(100)는 각 인증 방식과 관련하여 사용자 중 블랙리스트 정보를 관리할 수 있다. 이와 같은 블랙리스트 정보는 전자 장치(100)가 운영하는 서비스에서 각 사용자의 기존 사용 히스토리를 기반으로 작성될 수 있다. 이와 같은 블랙리스트에 포함되는 사용자가 결제를 요청하는 경우 전자 장치(100)는 결제 정보가 지정된 조건을 만족하는지 판단하지 않고, 결제 거절 메시지를 제공할 수 있다.
또한 실시 예에서 전자 장치(100)는 사용자가 구입하는 아이템과 관련하여 배송 정보를 기반으로 인증 방식을 결정할 수 있다. 일 예에 따르면, 사용자가 기존에 일정 횟수 이상 배송한 배송지로 배송을 요청하는 경우, 전자 장치(100)는 제1 인증 방식으로 결제 인증을 수행할 수 있으며, 배송지를 변경하여 배송 요청을 하는 경우 제2 인증 방식으로 결제 인증을 수행할 수 있다.
또한 실시 예에서 전자 장치(100)는 결제 수단의 유형 정보 및 결제 금액 중 적어도 하나를 기반으로 인증 방식을 결정하는 기준을 다르게 설정할 수 있다. 보다 구체적으로 도용의 위험이 높거나 도용 시 피해가 예상되는 경우, 보다 엄격한 기준을 적용하여 인증 방식을 결정할 수 있다.
도 5는 본 개시의 일 실시예에 따른 전자 장치의 결제 서비스 제공 방법에 관한 흐름도이다.
도 5를 참조하면, 일 실시예에 따른 전자 장치(100)는, 우선 단계 322에서, 사용자 단말(200)로부터 획득한 결제 요청 입력에 대응하여, 요청된 결제와 관련된 정보에 포함된 결제 대상 상품(또는 서비스)의 결제 금액이 미리 설정된 임계 금액을 초과하는지 여부를 판단할 수 있다.
예컨대, 단계 322에서 상기 결제 금액이 미리 설정된 금액 이하인 경우에는 단계 324로 이동하여 리스크 판단 조건의 만족 여부를 확인하는 동작이 수행되며, 결제 금액이 미리 설정된 금액을 초과하는 경우에는 단계 350으로 이동하여 제2 인증 방식(예: 핀 번호 입력 등에 의한 간편 결제 인증 방식)으로 해당 결제 건에 대한 결제 인증 방식을 결정할 수 있다.
어떤 실시예에 따르면, 전자 장치(100)는, 단계 322의 동작을 수행하기 이전에, 사용자의 간편 결제(및 원터치 결제) 사용의 허용 여부를 먼저 확인하고, 사용자가 간편 결제를 사용하도록 허용한 경우에 한하여 단계 322 이하의 동작을 수행할 수도 있다. 한편, 또 다른 실시예에 따르면, 전자 장치(100)는, 사용자가 간편 결제 사용을 허용하지 않은 경우라 하더라도 단계 322 이하의 동작을 수행함으로써, 해당 결제가 제1 인증 방식으로 결제 인증이 가능한 결제에 해당하는지 여부를 확인할 수도 있다.
단계 324에서, 전자 장치(100)는 결제 관련 정보가 지정된 리스크 판단 조건을 만족하는지 여부를 식별할 수 있다
예를 들면, 전자 장치(100)는 상기 리스크 판단 조건과 관련된 디시젼 트리를 포함하고, 상기 디시젼 트리에 기반하여 결제 인증 방식을 결정할 수 있다. 다른 예를 들면, 전자 장치(100)는, 상기 디시젼 트리를 대체하거나 상기 디시젼 트리에 추가적으로, 머신러닝 기반의 학습 모델에 기반하여 결제 인증 방식을 결정할 수 있다.
일 실시예에 따르면 상기 리스크 판단 조건은, 결제 대상 상품의 유형 정보에 관한 조건을 적어도 포함할 수 있다. 예를 들어 전자 장치(100)는 결제가 요청된 해당 구매 상품이 환금성이 좋은 금 관련 제품이거나 데이터와 관련된 디지털 상품인 경우, 상대적으로 리스크가 높은 결제로 판단하여 보다 보안성이 강화된 결제 인증 방식을 적용하도록 결정할 수 있다.
다른 실시에에 따르면 리스크 판단 조건은, 결제 대상 상품의 배송지 정보에 관한 조건을 적어도 포함할 수도 있다. 예컨대, 전자 장치(100)는, 특정 사용자에 의해 결제 요청된 특정 상품의 배송지가 이전에 결제한 구매 건의 배송지와 상이한 경우, 사용자의 결제 요청이 전송된 단말기의 위치와 배송지 위치가 지정된 거리 범위를 초과하거나 서로 다른 국가인 경우, 상대적으로 리스크가 높은 결제로 판단하여 보다 보안성이 강화된 결제 인증 방식으로 인증을 요청할 수 있다.
또 다른 실시예에 다르면 리스크 판단 조건은, 결제 요청이 수행된 장치(예: 사용자 단말(200))에 관한 조건을 적어도 포함할 수 있다. 예를 들면, 상기 조건은 상기 결제 요청이 입력된 장치에 대응하는 결제 이력 및 위치 정보 중 적어도 하나에 관한 조건을 포함할 수 있다. 예컨대, 전자 장치(100)는, 결제 요청이 입력된 장치에서 기존 결제 완료된 이력 정보에 기반하여, 최근 소정 기간 동안 결제가 수행된 적이 없었던 경우, 또는 해당 장치에서 지정된 시간 동안 다수의 결제 시도가 발생한 경우, 또는 기존에 로그인 이력이 없는 장치에서 결제 요청이 발생한 경우, 결제 요청이 입력된 장치의 IP 정보에 기반하여 결제 요청이 국외에서 입력된 것으로 추정되는 경우 등에는, 상대적으로 리스크가 높은 결제로 판단하여 보다 보안성이 강화된 결제 인증 방식으로 인증을 요청할 수 있다.
다른 예에 따르면, 리스크 판단 조건은, 결제 요청을 입력한 사용자의 식별 정보에 기반하여, 사용자의 기존 결제 실패 횟수나 실패 빈도가 임계치 이상인 경우, 지정된 시간 동안 결제 요청된 상품의 누적 금액이 설정값을 초과하는 경우, 사용자의 로그인 인증과 관련된 비밀번호 또는 개별 결제 건에 대한 인증과 관련된 비밀번호의 변경 횟수 또는 변경 빈도가 임계치 이상인 경우 등에도, 상대적으로 리스크가 높은 결제로 판단하여 보다 보안성이 강화된 결제 인증 방식으로 인증을 요청할 수 있다.
이와 같은 방식으로, 전자 장치(100)는, 결제 관련 정보가 리스크 판단 조건을 만족하는지 여부에 기반하여 결제 인증 방식을 결정하고, 상기 리스크 판단 조건을 만족하는지 여부에 따라, 인증을 완료하거나 간편 결제와 관련된 인증을 요청하거나 상세 본인 인증을 요청하거나 또는 인증 실패 안내를 제공할 수 있다.
도 6은 본 개시의 일 실시예에 따른 전자 장치의 결제 서비스 제공 방법에 관한 흐름도이다.
도 6을 참조하면, 일 실시예에 따른 전자 장치(100)는, 단계 410 에서, 사용자로부터 결제 요청 입력을 수신할 수 있으며, 단계 420에서 상기 결제 요청 입력에 대응하는 결제 관련 정보에 기반하여, 상기 결제 관련 정보에 포함된 사용자의 결제 수단 유형의 선택 정보를 기반으로 지정된 조건을 결정할 수 있다.
예를 들어, 전자 장치(100)는, 데이터베이스(120)에 하나 이상의 디시젼 트리들을 포함할 수 있다. 상기 디시젼 트리들은 각각의 결제 수단 유형 별로 다르게 설정될 수 있으며, 사용자가 입력한 결제 수단의 유형에 따라 결정될 수 있다. 일 예를 들면, 사용자는 카드로 결제할지, 은행 계좌를 통한 이체 방식으로 결제할지, 미리 예금한 적립금 잔고에서 결제할지 여부 등과 관련된 결제 수단 유형을 선택할 수 있다. 전자 장치(100)는 사용자가 결제 수단 유형을 카드 결제 타입으로 선택한 경우, 상기 카드 결제에 대응하는 제1 조건(예: 제1 디시젼 트리)을 전술한 지정된 조건으로 결정할 수 있다. 또한, 사용자가 결제 수단 유형을 은행 계좌 이체 타입으로 선택한 경우, 전자 장치(100)는 상기 은행 계좌 이체에 대응하는 제2 조건(예: 제2 디시젼 트리)을 지정된 조건으로 결정할 수 있다. 또한, 사용자가 결제 수단 유형을 적립금 잔고 타입으로 선택한 경우에는 전자 장치(100)는 상기 적립금 잔고에 대응하는 제3 조건(예: 제3 디시젼 트리)을 지정된 조건으로 결정할 수 있다. 상기 제1 내지 제3 조건은 적어도 일부의 세부 조건들(예: 세부 조건들의 항목, 각 세부 조건들의 판단 순서, 및/또는 각 세부 조건들의 임계치 정보)이 서로 상이할 수 있다.
단계 430에서, 전자 장치(100)는 단계 410에서의 결제 요청 입력에 대응하는 결제와 관련된 정보가 단계 420에서 상기 결제 수단 유형을 기반으로 결정된 조건을 만족하는지 여부를 판단하고, 만족 여부에 따라 결제 인증 방식을 결정할 수 있다.
도 7은 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 7을 참조하면, 일 실시예에 따르면, 전자 장치(100)는 단계 510에서 결제 요청 입력을 수신할 수 있으며, 단계 520에서 상기 결제 요청 입력에 대응하는 결제 관련 정보와 미리 설정된 조건(예: 리스크 판단 조건)을 비교하여, 리스크 정도에 따라 결제 인증 방식 및 결제 인증 여부 중 적어도 하나를 결정할 수 있다. 다양한 실시예에 따르면, 전자 장치(100)는 결제 금액 한도와 관련된 조건의 만족 여부 및/또는 사용자의 간편 결제(및 원터치 결제) 지정 여부를 만족하는 경우에 한하여 상기 단계 520의 동작을 수행할 수 있다.
단계 530에서, 전자 장치(100)는 상기 리스크 판단 조건에 기반하여 결제 요청 입력에 대응하는 해당 결제에 대한 결제 인증 방식을 제2 인증 방식으로 결정하고, 사용자 단말(200)로 상기 제2 인증 방식의 결제 인증 수행 요청을 전송할 수 있다. 이에 대응하여, 사용자는 상기 제2 인증 방식으로 결제 인증을 수행할 수 있다. 예컨대 사용자는 핀 번호 입력 또는 생체 정보 입력 등을 통해 제2 인증 방식으로 결제를 인증할 수 있다.
한편, 일 실시에에 따른 전자 장치(100)는 상기 사용자에 의한 제2 인증 방식으로의 결제 인증이 완료된 경우, 단계 540에서, 상기 제2 인증 방식에 의한 인증과 관련된 결제 관련 정보를 기반으로 리스크 판단 조건을 다시 비교할 수 있다.
예컨대, 전자 장치(100)는, 상기 단계 530에서 제2 인증 방식에 의한 인증에 성공한 경우라 하더라도, 단계 540에서, 제2 인증 방식으로의 사용자 인증 시 인증 실패 횟수(또는 빈도) 등을 기반으로, 리스크 판단 조건을 재비교할 수 있으며, 단계 550에서 최종적으로 결제의 승인 여부를 결정할 수 있다.
예를 들어, 전자 장치(100)는 사용자가 제2 인증 방식에 의한 인증에 성공하였더라도, 단계 550에서의 리스크 판단 조건 비교에 기반하여, 최종적으로 결제 인증을 승인하지 않을 수 있다. 이 경우, 전자 장치(100)는 사용자 단말(200) 측으로 보다 강화된 보안 인증 방식으로의 인증을 재요청하거나, 또는 결제 승인 거부(또는 실패)와 관련된 안내 메시지를 전송하고 결제 기능을 종료할 수 있다.
한편 실시 예에서 결제 관련 정보가 리스크 판단 조건을 만족하는지 여부는, 결제 관련 정보로서, 결제 요청한 사용자의 계정 정보, 결제 되는 상품 정보, 결제 요청을 전송한 단말의 정보, 및 결제 요청이 발생한 시간 정보 중 적어도 하나를 기반으로 판단할 수 있다. 또한 실시 예에 따라 상기 판단 기준이 되는 정보의 우선 순위는 다르게 설정될 수 있다.
도 8 내지 도 15는 본 개시의 다양한 실시예에 따른 결제 서비스 제공과 관련된 사용자 인터페이스를 개략적으로 도시한 도면들이다.
도 8을 참조하면, 일 실시예에 따른 전자 장치(100)는 사용자 단말(200)에서 특정 물품을 주문 및 결제할 수 있는 인터페이스 화면을 제공할 수 있다. 사용자는 결제 대상 물품을 배송 받을 배송지 정보 및 연락처 정보를 입력할 수 있으며, 결제 금액을 확인하고 결제 요청 버튼(예: "결제하기" 버튼)을 누름에 따라 결제 요청 정보를 전자 장치(100) 측으로 제공할 수 있다. 한편, 사용자는 상기 결제와 관련하여 결제 수단을 설정하거나 기 설정된 결제 수단을 변경할 수 있으며, 이와 관련하여 보다 구체적인 사용자 인터페이스 화면이 도 9에 도시된다.
도 9에 도시된 바와 같이, 사용자는 해당 결제를 은행 계좌 이체 방식으로 수행할지, 적립금 잔고(balance)를 사용하는 방식으로 결제를 수행할지, 신용카드(또는 체크카드) 결제 방식으로 수행할지, 또는 사용자 단말(예: 휴대폰) 대금 결제 방식으로 결제를 수행할지 등과 관련하여, 결제 수단 유형을 선택할 수 있다.
예를 들어 전자 장치(100)는, 간편 결제 서비스(예: XX 페이)와 관련하여 결제 수단을 등록함에 따라 획득한 결제 관련 정보(예: 계좌 정보, 카드 정보 등)를 암호화하여 데이터베이스(120)에 보관할 수 있으며, 개별 결제 건에 대한 리스크 판단 결과에 따라, 리스크가 낮은 결제 대상으로 판단할 경우 제1 인증 방식으로서, 원터치 결제(예: 핀번호 미입력 인증) 인증을 수행하거나, 또는 리스크가 다소 낮은 결제 대상으로 판단할 경우 제2 인증 방식으로서 간편 결제(예: 핀 번호 입력 인증) 방식으로 결제 인증 방식을 결정하여 처리할 수 있다.
예컨대, 도 8의 화면에서 사용자가 결제하기 버튼을 클릭함으로써 결제 요청을 입력하면, 전자 장치(100)는 해당 결제에 관한 정보에 기초하여 지정된 조건의 만족 여부에 기반하여 원터치 결제 또는 간편 결제의 수행이 가능한지 식별할 수 있으며, 원터치 결제가 허용된 경우에는 도 10의 인터페이스 화면이 사용자 단말(200)을 통해 제공될 수 있고, 간편 결제가 허용된 경우에는 도 11과 같은 인터페이스 화면이 제공될 수 있다.
예컨대 원터치 결제가 허용된 경우로서 추가 결제 인증 절차 없이 결제가 완료되는 경우, 사용자는 원터치 결제의 승인 여부 판단 동안 결제 승인이 완료되었는지 확인하지 못함에 따라 반복적으로 결제 요청(예: 결제하기 버튼)을 입력할 가능성이 있으며, 그에 따른 동일 상품의 중복 주문 및 중복 결제 문제가 발생할 수 있으므로, 전자 장치(100)는 도 10에 도시된 것과 같은 결제 진행과 관련된 안내 인터페이스를 제공하여 사용자에 의한 반복 결제 시도 오류를 최소화할 수 있다.
한편, 간편 결제가 허용된 경우의 일 실시예로서 전자 장치(100)는 도 11에 도시된 것과 같이 핀 번호 입력을 통해 결제 인증을 수행하도록 안내하는 인터페이스를 제공할 수 있다. 또한, 사용자가 핀 번호를 입력하면 도 12에 도시된 인터페이스 화면으로 전환되어 결제 정보 처리 진행과 관련된 화면 정보를 제공할 수 있다.
도 13 내지 도 15를 참조하면, 일 실시예에 따른 전자 장치(100)는, 사용자가 원터치(또는, 원클릭) 결제 방식을 사용할지 여부에 관해 지정할 수 있도록 관련 인터페이스 화면을 제공할 수 있다.
예를 들면, 도 13에 도시된 것과 같이 사용자는 원터치 결제 방식의 사용을 하지 않도록 사용을 제한할 수 있으며, 사용자가 도 15에 도시된 것과 같이 다시 원터치 결제 방식을 사용할 수 있도록 사용 제한을 해제하고자 하는 경우, 전자 장치(100)는 소정의 인증 절차(예컨대, 간편 결제 서비스와 관련된 핀 번호 입력 인증)를 통해 원터치 결제 사용을 허용하도록 설정할 수 있다.
본 개시의 일 실시예에 따르면, 전자 장치(100)는 사용자가 원터치 결제의 사용을 허용하지 않은 경우, 사용자가 특정 물품을 주문 및 결제하고 소정의 결제 인증 절차를 거침에 따라 결제 승인 완료 알림을 제공하는 단계에서 상기 원터치 결제의 사용을 제안하는 알림 정보를 함께 제공할 수 있다. 예를 들면, 전자 장치(100)는 해당 사용자의 결제 건과 관련된 정보를 지정된 조건(예: 결제 금액 한도 조건 및/또는 결제 리스크 판단 조건)과 비교하고 해당 결제가 원터치 결제를 허용할 수 있는 조건에 부합하는 것으로 판단되는 경우에 한하여, 상기 원터치 결제의 사용을 제안하는 알림 정보를 제공할 수도 있다.
도 16은 본 개시의 일 실시예에 따른 결제 서비스 제공 방법에 관한 흐름도이다.
도 16을 참조하면, 일 실시예에 따른 전자 장치(100)는, 단계 610에서 특정 결제 요청 입력에 대응하는 사용자 및/또는 사용자 단말이 블랙 리스트로 등재되어 있는 대상에 해당하는지 여부를 우선적으로 판단할 수 있다. 상기 블랙 리스트 정보는 전자 장치(100)의 데이터베이스(120)에 미리 저장되어 있을 수 있으며, 결제 인증과 관련된 문제 발생 시마다 상기 데이터베이스(120)에 업데이트될 수 있다. 예컨대 전자 장치(100)는 상기 사용자의 로그인 이력이나 접속한 단말기의 IP 주소 등에 기반하여 해당 사용자 및/또는 사용자 단말이 블랙 리스트에 해당하는지 여부를 식별할 수 있다.
전자 장치(100)는, 상기 결제 요청 입력에 대응하는 사용자나 사용자 단말이 블랙 리스트 대상에 해당하는 것으로 판단될 경우, 단계 601에서 해당 결제 요청 건에 대한 결제 승인을 거절하고 이와 관련된 알림 정보를 제공할 수 있다.
한편, 상기 블랙 리스트와 관련이 없는 결제 요청에 해당하는 것으로 판단될 경우에는, 단계 620에서, 전자 장치(100)는 해당 결제 대상이 미리 설정된 금액 한도 조건을 만족하는지 여부를 판단할 수 있다.
예컨대, 전자 장치(100)는 결제 요청된 금액이 미리 설정된 금액 한도를 초과하는 경우, 단계 601으로 분기하여, 해당 결제에 대한 승인을 거절할 수 있다. 다만 이러한 실시예에 한정되는 것은 아니며 상기 금액 한도를 초과하는 결제 대상 건의 경우 단계 602로 분기하여, 핀 번호 입력(또는, 생체 정보 입력이나 기타 본인 인증 관련 비밀번호 입력) 요청과 같은 추가 결제 인증을 요청할 수 있으며 상기 추가 결제 인증 결과에 따라 결제가 승인될 수 있음은 물론이다.
또한, 전자 장치(100)는 결제 요청된 금액이 상기 미리 설정된 금액 한도 범위 이하인 경우, 단계 630에서 결제 대상 상품 유형과 관련된 조건 만족 여부를 판단할 수 있다. 예컨대, 결제 요청된 상품이 디지털 상품(또는 금 관련 상품)에 해당하는 경우, 전자 장치(100)는 단계 602에서 상기 결제에 대한 추가 결제 인증을 요청할 수 있다.
예컨대, 상기 결제 요청된 상품이 디지털 상품에 해당하지 않는 등의 이유로 단계 630의 조건을 만족하는 경우, 전자 장치(100)는 단계 640에서 그 외의 리스크 판단 조건을 만족하는지 여부를 판단할 수 있다.
예를 들면, 상기 리스크 판단 조건은, 타인의 카드 또는 통장을 탈취하여 결제를 시도한 케이스를 검출하기 위한 제1 리스크 조건들과 사용자 계정 관련 정보(예: 아이디 및 패스워드)를 탈취하여 결제를 시도한 케이스를 검출하기 위한 제2 리스크 조건들을 포함할 수 있다. 또한, 상기 리스크 판단 조건은, 이전의 결제 이력이 없는 새로운 사용자 단말에 의한 결제 케이스에 대한 리스크를 판단하기 위한 제3 리스크 조건들을 더 포함할 수 있다. 일 실시예에 따르면, 전자 장치(100)는 단계 640에서, 결제 요청 입력에 대응하는 결제 관련 정보가 상기 제1 리스크 조건들을 만족하는지 여부를 우선 판단하고, 다음으로 상기 제2 리스크 조건들을 만족하는지 여부를 판단하고, 다음으로 상기 제3 리스크 조건들을 만족하는지 여부를 판단할 수 있으며, 판단 결과에 기반하여, 단계 603에서 즉시 결제 인증을 완료하고 결제를 승인하거나, 또는 단계 602에서 추가적인 결제 인증을 요청할 수 있다.
다양한 실시예에 따르면, 전자 장치(100)는 상기 리스크 판단 조건으로서, 결제 요청된 장치(예: 사용자 단말)가 사용자가 기존 결제(예: 최초 결제)한 장치와 동일한지에 관한 조건, 배송 주소지가 기존 결제(예: 최초 결제) 시의 배송 주소지에 대응하는지에 관한 조건, 배송 주소지가 국내인지 여부에 관한 조건, 사용자 및/또는 사용자 단말이 화이트 리스트에 해당하는지에 관한 조건, 최근 N시간 이내에 결제 인증 관련 정보(예: 핀 번호 등의 각종 비밀번호)를 변경한 횟수 또는 빈도에 관한 조건, 최근 N시간 이내에 결제 인증에 실패한 횟수 또는 빈도에 관한 조건, 기존 결제 인증 이력(예: 원터치 결제 성공 이력, 최근 N시간 내에 간편 결제 방식 또는 일반 결제 방식을 통해 인증한 이력) 관련 조건, 하나의 사용자 단말에서 둘 이상의 사용자 계정에 의해 로그인된 이력 관련 조건, 하나의 장치(사용자 단말)에서 지정된 시간 동안 결제 시도한 금액 관련 조건, 하나의 사용자 계정에서 지정된 시간 동안 결제 시도한 금액/횟수 관련 조건 중 적어도 일부를 포함할 수 있다. 상기 각각의 조건들은 소정의 우선순위를 갖거나 갖지 않을 수 있으며, 결제 수단 별로 다른 조건들을 포함하는 디시젼 트리를 가질 수 있다.
한편, 또 다른 실시예에 따르면, 전자 장치(100)는 리스크 판단 조건의 만족 여부를 확인하는 단계에서, 상기 리스크 판단 조건을 만족하는지 확인하는데 소요되는 대기 시간이 지정된 임계 시간을 초과하는 경우에는, 최종적인 리스크 판단 결과와 관계없이 항상 추가 결제 인증 요청을 수행하도록 할 수 있다.
한편, 본 명세서와 도면에는 본 발명의 바람직한 실시 예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 발명의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예 외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.
전술한 실시예들에 따른 전자 장치 또는 단말은, 프로세서, 프로그램 데이터를 저장하고 실행하는 메모리, 디스크 드라이브와 같은 영구 저장부(permanent storage), 외부 장치와 통신하는 통신 포트, 터치 패널, 키(key), 버튼 등과 같은 사용자 인터페이스 장치 등을 포함할 수 있다. 소프트웨어 모듈 또는 알고리즘으로 구현되는 방법들은 상기 프로세서상에서 실행 가능한 컴퓨터가 읽을 수 있는 코드들 또는 프로그램 명령들로서 컴퓨터가 읽을 수 있는 기록 매체 상에 저장될 수 있다. 여기서 컴퓨터가 읽을 수 있는 기록 매체로 마그네틱 저장 매체(예컨대, ROM(read-only memory), RAM(random-Access memory), 플로피 디스크, 하드 디스크 등) 및 광학적 판독 매체(예컨대, 시디롬(CD-ROM), 디브이디(DVD: Digital Versatile Disc)) 등이 있다. 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템들에 분산되어, 분산 방식으로 컴퓨터가 판독 가능한 코드가 저장되고 실행될 수 있다. 매체는 컴퓨터에 의해 판독가능하며, 메모리에 저장되고, 프로세서에서 실행될 수 있다.
본 실시 예는 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어 또는/및 소프트웨어 구성들로 구현될 수 있다. 예를 들어, 실시 예는 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직(logic), 룩 업 테이블(look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다. 구성 요소들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 본 실시 예는 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바(Java), 어셈블러(assembler) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다. 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 본 실시 예는 전자적인 환경 설정, 신호 처리, 및/또는 데이터 처리 등을 위하여 종래 기술을 채용할 수 있다. “매커니즘”, “요소”, “수단”, “구성”과 같은 용어는 넓게 사용될 수 있으며, 기계적이고 물리적인 구성들로서 한정되는 것은 아니다. 상기 용어는 프로세서 등과 연계하여 소프트웨어의 일련의 처리들(routines)의 의미를 포함할 수 있다.
전술한 실시예들은 일 예시일 뿐 후술하는 청구항들의 범위 내에서 다른 실시예들이 구현될 수 있다.

Claims (15)

  1. 전자 장치의 결제 서비스 제공 방법에 있어서,
    사용자로부터 아이템에 대한 결제 요청을 획득하는 단계;
    상기 획득된 결제 요청이 지정된 조건을 만족하는지 확인하는 단계; 및
    상기 결제 요청이 지정된 조건을 만족하는 것에 대응하여 추가 인증 단계를 생략하고 상기 결제 요청에 대응하는 결제 완료 정보를 제공하는 단계를 포함하는, 결제 서비스 제공 방법.
  2. 제 1 항에 있어서,
    상기 결제 완료 정보 제공에 대응하여 상기 아이템의 배송 요청을 전송하는 단계; 및
    상기 결제 완료 정보 제공 이후 소정의 시간 이후에 상기 결제 요청에 대응하는 트랜젝션 절차를 수행하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  3. 제 2 항에 있어서,
    상기 소정의 시간 이내에 상기 결제에 대응하는 취소 요청을 수신하는 경우 상기 트랜젝션 절차의 수행을 취소하는 단계; 및
    상기 취소 요청 수신에 대응하여 상기 아이템의 배송 취소 요청을 전송하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  4. 제 1 항에 있어서,
    상기 결제 완료 정보를 제공하는 단계는,
    상기 결제 완료 정보 중 적어도 일부의 컨텐츠 위에 상기 결제를 취소할 수 있는 사용자 인터페이스를 설정된 시간 동안 제공하는 단계를 포함하는, 결제 서비스 제공 방법.
  5. 제 1 항에 있어서,
    상기 지정된 조건은, 상기 결제 요청에 대응하는 결제 수단의 유형 조건을 포함하는, 결제 서비스 제공 방법.
  6. 제 1 항에 있어서,
    상기 결제 요청이 상기 지정된 조건의 적어도 일부를 만족하지 않는 것에 대응하여 소정의 추가 인증을 요청하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  7. 제 1 항에 있어서,
    상기 지정된 조건은, 상기 결제 요청에 대응하는 금액 한도 조건 및 상기 결제의 리스크 판단 조건 중 적어도 하나를 포함하는, 결제 서비스 제공 방법.
  8. 제 7 항에 있어서,
    상기 리스크 판단 조건은,
    상기 아이템에 대한 유형 정보, 상기 결제 요청에 대응하는 배송지 정보, 및 상기 결제 요청을 전송한 장치에 관한 정보 중 적어도 하나에 관한 조건을 포함하는, 결제 서비스 제공 방법.
  9. 제 6 항에 있어서,
    상기 소정의 추가 인증을 요청하는 단계는,
    핀 번호 또는 생체 정보를 이용한 결제 인증을 요청하는 단계를 포함하는, 결제 서비스 제공 방법.
  10. 제 5 항에 있어서,
    상기 지정된 조건은 상기 결제 수단의 유형 각각에 매핑된 디시젼 트리들을 포함하는, 결제 서비스 제공 방법.
  11. 전자 장치에 있어서,
    데이터베이스; 및
    상기 데이터베이스와 전기적으로 연결된 프로세서를 포함하고,
    상기 프로세서는,
    사용자로부터 아이템에 대한 결제 요청을 획득하고,
    상기 획득된 결제 요청이 지정된 조건을 만족하는지 확인하고,
    상기 결제 요청이 지정된 조건을 만족하는 것에 대응하여 상기 결제의 인증 방식을 결정하고, 및
    상기 결정된 인증 방식에 따라 결제 인증 관련 정보를 제공하는, 전자 장치.
  12. 제 11 항에 있어서,
    상기 프로세서는, 상기 인증 관련 정보의 제공과 관련하여,
    상기 결제의 인증 완료에 관한 알림 정보를 제공하거나,
    상기 결제의 추가 인증 요청에 관한 알림 정보를 제공하거나, 또는
    상기 결제의 인증 실패에 관한 알림 정보를 제공하는, 전자 장치.
  13. 제 11 항에 있어서,
    상기 프로세서는,
    사용자 설정에 기반하여 상기 결제 인증 방식 중 적어도 일부를 제한하고,
    상기 결제 관련 정보가 상기 지정된 조건을 만족하는지 여부에 기초하여, 상기 사용자 설정 변경과 관련된 정보를 제공하는, 전자 장치.
  14. 결제 요청 입력을 수신하는 단계;
    상기 결제 요청 입력에 대응하는 결제 관련 정보가 지정된 조건을 만족하는지 여부에 기초하여, 상기 결제의 인증 방식을 결정하는 단계; 및
    상기 결정된 결제 인증 방식에 따라 상기 결제에 관한 인증을 수행하는 단계를 포함하는, 결제 서비스 제공 방법을 수행하도록 하는 컴퓨터 판독 가능한 저장매체에 저장된 애플리케이션.
  15. 결제 서비스 제공 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 비일시적인 기록매체로서, 상기 결제 서비스 제공 방법은,
    사용자로부터 아이템에 대한 결제 요청을 획득하는 단계;
    상기 획득된 결제 요청이 지정된 조건을 만족하는지 확인하는 단계; 및
    상기 결제 요청이 지정된 조건을 만족하는 것에 대응하여 추가 인증 단계를 생략하고 상기 결제 요청에 대응하는 결제 완료 정보를 제공하는 단계를 포함하는, 비일시적 기록매체.
PCT/KR2021/001654 2021-01-26 2021-02-08 결제 서비스 제공 방법 및 이를 수행하는 전자 장치 WO2022163893A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020210010767A KR102340340B1 (ko) 2021-01-26 2021-01-26 결제 서비스 제공 방법 및 이를 수행하는 전자 장치
KR10-2021-0010767 2021-01-26

Publications (1)

Publication Number Publication Date
WO2022163893A1 true WO2022163893A1 (ko) 2022-08-04

Family

ID=79033988

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/001654 WO2022163893A1 (ko) 2021-01-26 2021-02-08 결제 서비스 제공 방법 및 이를 수행하는 전자 장치

Country Status (5)

Country Link
US (1) US20220237615A1 (ko)
JP (2) JP7176704B2 (ko)
KR (3) KR102340340B1 (ko)
TW (2) TW202418178A (ko)
WO (1) WO2022163893A1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102503470B1 (ko) 2022-08-10 2023-02-23 장규오 다양한 형태의 콘텐츠를 변형한 변형정보를 이용한 간편결제/인증 서비스 시스템 및 방법
KR102662344B1 (ko) * 2023-07-19 2024-05-03 쿠팡 주식회사 전자 장치 및 그의 결제 지원 방법

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160122653A (ko) * 2015-04-14 2016-10-24 삼성전자주식회사 모바일 장치에서 부정사용 방지에 대한 장치 및 방법
KR20170045676A (ko) * 2015-10-19 2017-04-27 엘지전자 주식회사 이동 단말기 및 그의 동작 방법
KR20170049481A (ko) * 2015-04-08 2017-05-10 네이버 주식회사 간소화되고 주도적인 구조를 가진 결제 트랜잭션 처리
KR20170139332A (ko) * 2016-06-09 2017-12-19 네이버 주식회사 결제를 처리하는 방법 및 시스템
JP2020057291A (ja) * 2018-10-03 2020-04-09 エヌ・ティ・ティ・コミュニケーションズ株式会社 認証システムおよび認証方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001009806A1 (fr) 1999-08-02 2001-02-08 E-Mark Systems Inc. Systeme de reglement electronique, dispositif et terminal de reglement
KR20000030577A (ko) * 2000-03-07 2000-06-05 장성동 전자상거래용 신용카드 서비스 시스템 및 서비스 방법
KR20010091548A (ko) * 2000-03-16 2001-10-23 김정호 가결제에 의한 반품 용이성을 구현한 전자 상거래 사이트운영 방법
JP2002269479A (ja) 2001-03-09 2002-09-20 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム
JP2005107592A (ja) 2003-09-26 2005-04-21 Bank Of Tokyo-Mitsubishi Ltd 認証方式選択システムおよび方法
US20140324692A1 (en) 2013-04-26 2014-10-30 Joel Yarbrough Systems and methods for implementing instant payments on mobile devices
CN104599130A (zh) * 2013-12-23 2015-05-06 腾讯科技（深圳）有限公司 支付验证方法及装置、系统
US9342831B1 (en) * 2014-12-16 2016-05-17 Facebook, Inc. Facilitating same day payment transactions
KR102586443B1 (ko) * 2016-03-24 2023-10-11 삼성전자주식회사 전자 결제 기능을 제공하는 전자 장치 및 그 동작 방법
JP6681968B1 (ja) 2018-12-21 2020-04-15 ＬＩＮＥ Ｐａｙ株式会社 プログラム、認証方法、端末
US11727403B2 (en) * 2019-05-20 2023-08-15 Samsung Electronics Co., Ltd. System and method for payment authentication

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170049481A (ko) * 2015-04-08 2017-05-10 네이버 주식회사 간소화되고 주도적인 구조를 가진 결제 트랜잭션 처리
KR20160122653A (ko) * 2015-04-14 2016-10-24 삼성전자주식회사 모바일 장치에서 부정사용 방지에 대한 장치 및 방법
KR20170045676A (ko) * 2015-10-19 2017-04-27 엘지전자 주식회사 이동 단말기 및 그의 동작 방법
KR20170139332A (ko) * 2016-06-09 2017-12-19 네이버 주식회사 결제를 처리하는 방법 및 시스템
JP2020057291A (ja) * 2018-10-03 2020-04-09 エヌ・ティ・ティ・コミュニケーションズ株式会社 認証システムおよび認証方法

Also Published As

Publication number Publication date
JP2022114410A (ja) 2022-08-05
KR20220107923A (ko) 2022-08-02
KR102681782B1 (ko) 2024-07-03
US20220237615A1 (en) 2022-07-28
TWI833067B (zh) 2024-02-21
KR20240107077A (ko) 2024-07-08
JP2022153563A (ja) 2022-10-12
TW202418178A (zh) 2024-05-01
TW202230248A (zh) 2022-08-01
JP7176704B2 (ja) 2022-11-22
KR102340340B1 (ko) 2021-12-20

Similar Documents

Publication Publication Date Title
US20200304491A1 (en) Systems and methods for using imaging to authenticate online users
WO2017188610A1 (ko) 인증 방법 및 시스템
WO2018074902A2 (en) System and method for mobile wallet remittance
WO2022163893A1 (ko) 결제 서비스 제공 방법 및 이를 수행하는 전자 장치
US10063538B2 (en) System for secure login, and method and apparatus for same
WO2014069777A1 (en) Transit control for data
JP2003526857A (ja) パーソナルデジタル識別を用いてオンライン不正を低減させる方法および装置
WO2017209513A1 (ko) 모바일 결제 방법 및 그 장치
WO2018026109A1 (ko) 네트워크를 사용하여 게이트에 대한 액세스 허용 여부를 결정하는 방법, 서버 및 컴퓨터 판독 가능한 기록 매체
US8656468B2 (en) Method and system for validating authenticity of identity claims
WO2018026108A1 (ko) 네트워크를 사용하여 게이트에 대한 액세스 허용 여부를 결정하는 방법, 권한자 단말 및 컴퓨터 판독 가능한 기록 매체
WO2022114290A1 (ko) 비대면 본인인증 시스템 및 그 방법
WO2018199576A1 (en) Method and apparatus for performing authentication based on biometric information
US20230315890A1 (en) Call location based access control of query to database
US11336667B2 (en) Single point secured mechanism to disable and enable the access to all user associated entities
WO2013073780A1 (ko) 자동 로그인 기능을 제공하는 방법 및 서버
WO2011074878A2 (ko) 서비스 보안 시스템 및 그 방법
WO2015170847A1 (ko) 휴대 단말의 자세를 이용한 유효 세션 관리 방법 및 시스템
WO2017145273A1 (ja) ユーザ認証装置
KR20120128529A (ko) Ｕｉｐ를 이용한 사용자 인증 방법 및 인증 시스템
KR102198150B1 (ko) 발신자 확인 전화 인증 서비스를 제공하는 방법 및 시스템
KR20020041354A (ko) 회원전화번호인증식 인터넷 사이트 로그인 서비스 방법 및시스템
WO2012128514A2 (ko) 모바일 전화번호를 이용한 카드결제 제공방법 및 그 시스템
JP7563187B2 (ja) 個人情報管理装置及び個人情報管理システム
JP7571488B2 (ja) 情報管理サーバ、情報管理方法、及びプログラム

Legal Events

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

Ref document number: 21923325

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21923325

Country of ref document: EP

Kind code of ref document: A1