KR102282345B1 - Transaction processing for payment of simplified and driven structure - Google Patents

Abstract

A payment transaction processing technology having a simplified and proactive structure is disclosed. The payment service method includes: providing a uniform resource locator (URL) corresponding to payment information connected to the user's service account on the service screen when a user's terminal enters a service screen related to a specific product; and directly performing payment processing using the payment information without inputting additional information when receiving the selection for the URL from the user's terminal. In this case, the step of performing the payment processing may include performing an independent authentication procedure independent of a financial company related to the payment information, and checking the user's payment risk level; and performing an identity authentication procedure for the user by applying an authentication method corresponding to the payment risk level.

Description

Payment transaction processing with a simplified and proactive structure {TRANSACTION PROCESSING FOR PAYMENT OF SIMPLIFIED AND DRIVEN STRUCTURE}

Embodiments of the present invention relate to transaction processing techniques.

As wired and wireless network infrastructure is built and Internet technology develops, the e-commerce market that enables commerce activities in the online space is also growing.

E-commerce is a generic term for transacting goods and services using electronic media such as the Internet. Transactions include general product transactions as well as trading activities that provide advertisements, marketing, and services. Representative examples of e-commerce include Internet shopping or cyber shopping in which goods are sold or services are provided by building a website or virtual shop on the Internet.

Transactions are usually paid by credit card, digital currency, or electronic payment method. For this kind of payment, a payment system for credit cards or a payment system using digital cash is required to which secure transaction technology (STT) and secure electronic payment protocol (SEPP) are applied. In addition, for transaction safety, an electronic authentication system to which SSL (Secure Socket Layer) or S-HTTP (Secure-HTTP) is applied is required.

As an example of e-commerce, in Korea Patent Application Laid-Open No. 10-1997-0049810 (published on July 29, 1997) "Online Shopping System and Payment Method", card information is not leaked and products are real-time using a computer network. Disclosed is an online shopping system that enables execution of orders and payments.

It provides a one-click payment model that makes payment easier by simplifying the payment process as much as possible using the uniform resource locator (URL) method.

It provides a payment model that can provide a notification that direct payment is possible according to a purchase pattern according to a user's transaction history or a reservation setting for regular purchase.

A payment model is provided in which the payment system can directly perform authentication led by a financial company (eg, a credit card company, a bank company, etc.) for safe transaction of payment.

It provides a payment model that can be applied by differentiating the authentication process from one-click to non-payment according to the level of risk of the user or transaction situation.

In the payment service method implemented by a computer, when a user's terminal enters a service screen related to a specific product, a uniform resource locator (URL) corresponding to payment information connected to the user's service account is provided on the service screen to do; and directly performing payment processing using the payment information without inputting additional information when receiving the selection for the URL from the user's terminal. In this case, the step of performing the payment processing may include performing an independent authentication procedure independent of a financial company related to the payment information, and checking the user's payment risk level; and performing an identity authentication procedure for the user by applying an authentication method corresponding to the payment risk level.

at least one program loaded memory; and at least one processor, wherein the at least one processor is connected to the user's service account on the service screen when the user's terminal enters a service screen related to a specific product under the control of the program. providing a uniform resource locator (URL) corresponding to payment information; and a payment system that processes a process of directly performing payment processing using the payment information without inputting additional information when receiving the selection for the URL from the user's terminal. In this case, the process of performing the payment processing includes performing an independent authentication process independent of the financial company related to the payment information, and the process of confirming the user's payment risk level; and performing an identity authentication procedure for the user by applying an authentication method corresponding to the payment risk level.

According to an embodiment of the present invention, an order step can be simplified through a simple inflow path by providing a one-click payment model that enables direct payment through a URL method by omitting unnecessary procedures.

According to an embodiment of the present invention, it is possible to maximize the convenience of a user having a regular purchase behavior by providing a notification that direct payment is possible according to a purchase pattern or reservation setting according to the user's transaction history.

According to an embodiment of the present invention, a proactive and free authentication policy can be applied by directly performing authentication in charge of a financial company in the payment system for safe transaction of payment.

According to the embodiment of the present invention, the authentication procedure is differentiated from one-click to impossible of payment according to the risk level of the user or transaction situation and applied more flexible and rational than the existing uniform method, but more stringent and strong authentication policy is applied. can do.

1 is a diagram for explaining an example of a payment service environment according to an embodiment of the present invention.
2 is a block diagram illustrating an internal configuration of a payment system according to an embodiment of the present invention.
3 is a flowchart illustrating a method of registering an account for payment according to an embodiment of the present invention.
4 to 8 exemplarily show a user interface screen related to an account registration procedure according to an embodiment of the present invention.
9 is a flowchart illustrating a method of providing a payment path according to an embodiment of the present invention.
10 to 14 exemplarily show a user interface screen related to a payment path providing procedure according to an embodiment of the present invention.
14 is a flowchart illustrating a payment processing method including an authentication procedure for each level according to an embodiment of the present invention.
15 and 16 are flowcharts illustrating a remittance processing method according to an embodiment of the present invention.
17 to 21 exemplarily show a user interface screen related to a remittance processing procedure according to an embodiment of the present invention.
22 is a flowchart illustrating a method for receiving a remittance according to an embodiment of the present invention.
23 exemplarily illustrates a user interface screen related to a remittance reception procedure according to an embodiment of the present invention.
24 is a flowchart illustrating a periodic payment notification method according to an embodiment of the present invention.
25 exemplarily illustrates a user interface screen related to a periodic payment notification procedure according to an embodiment of the present invention.
26 is a block diagram for explaining an example of an internal configuration of a computer system according to an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

The present embodiments relate to a payment model that processes payment in an online shopping environment through the Internet. Specifically, a payment procedure can be simplified using a URL method, and a user can directly perform authentication for a secure transaction of payment. B. It relates to a method, system, and recording medium that can differentially apply the authentication procedure according to the risk level of the transaction situation.

1 is a diagram for explaining an example of a payment service environment according to an embodiment of the present invention. 1 shows user terminals 101 and 102 and a payment system 100 . An arrow in FIG. 1 means that data can be transmitted and received between the components using the wired/wireless network 10 .

The user terminal 101 , 102 may execute one or more processes configured to perform one or more of the features described herein. The user terminals 101 and 102 may refer to all terminal devices capable of accessing a web/mobile site related to the payment system 100 or installing and executing a service-only application. In this case, the user terminals 101 and 102 may perform overall service operations such as service screen configuration, data input, data transmission/reception, and data storage under the control of a web/mobile site or a dedicated application.

Examples of the user terminals 101 and 102 include a personal computer (PC), a laptop computer, a laptop computer, a smart phone, a tablet, a wearable computer, and the like. may include, but are not limited to.

The user terminals 101 and 102 may be coupled directly or indirectly to the network 10 (eg, the Internet or a local area network, etc.). For example, a personal computer and a notebook computer may be directly coupled to the network 10 via a wired network connection. The laptop computer may be wirelessly coupled to the network 10 through a wireless communication channel established between the laptop computer and a wireless access point (ie, WAP). The smartphone may be wirelessly coupled to the network 10 via a wireless communication channel established between the smartphone and the cellular network/bridge. In this case, the network 10 may communicate with one or more secondary networks (not shown), and examples of the secondary networks include a local area network, a wide area network, or an intranet ( intranet), but is not limited thereto.

The user terminals 101 and 102 may interface with the payment system 100 through the network 10 described above.

The payment system 100 serves as a service platform for providing a payment service for online shopping to a client. Payment system 100 may execute one or more processes configured to perform one or more of the features described herein.

Payment system 100 corresponds to a server computer, examples of which may include, but may include, server computing devices, personal computers, server computers, a series of server computers, mini computers, and/or mainframe computers. but is not limited. The server computer may be a distributed system, and operations of the server computer may be executed concurrently and/or sequentially on one or more processors.

The payment system 100 may provide a payment environment for online shopping by using a user identifier related to a payment service. In this specification, a user identifier identifies a user registered in a payment service, and in particular, may refer to any information that can connect payment information (eg, account information, card information, etc.) registered by the user, for example, the service It may include, but is not limited to, an account (ID), phone number, email, and the like. In this case, the service account is a user ID registered in the payment service, and a user registered in other services linked to the payment service (eg, portal service, integrated search service, shopping service, map service, community service, social network service, etc.) IDs, and the like, but are not limited thereto.

When using automatic transfer through remittance as an example of a payment method, the user identifier is applied as information that can specify the sender and the recipient instead of the account number for real-time remittance between the seller and the buyer. As an example, the payment system 100 may provide a remittance processing process for individuals, such as home banking, when remittances between individuals. As another example, when remittance between individuals, the payment system 100 may first deposit the remittance amount into the mother account on the remittance service, and then process the remittance from the mother account to the recipient's account. In other words, the payment system 100 may perform remittance processing between individuals through firm banking using the mother account.

In particular, the payment system 100 can directly provide a simplified payment procedure using the URL method based on the user identifier, and authenticate according to the risk level of the user or transaction situation while directly performing the authentication led by the financial company. Procedures can be applied differentially.

The payment system 100 may interface with a financial company server (eg, a server computer of a financial company side such as a credit card company or a bank company) 103 through the network 10 to perform one or more processes required in the payment process. At this time, the payment system 100 may be configured as one system combined with the financial company server 103 or as a separate system from the financial company server 103 to provide a payment service by interworking with the financial company server 103 . However, the present invention is not limited thereto, and the form or method of constructing the payment system 100 may be changed in any case. When the payment system 100 is configured as a separate system from the financial company server 103 , some components of the payment system 100 may reside on the financial company server 103 side according to system implementation or service type. In addition, the payment system 100 may be constructed in the form of a one-to-one system for each bank company, or may be separately configured as an integrated system for services targeting multiple bank companies.

The payment system 100 is implemented as one system with at least one service platform among services requiring a payment function, such as a portal service, an integrated search service, a shopping service, a map service, a community service, and a social network service, or a separate system. It is implemented as a system and can provide payment services through linkage between services.

The payment system 100 may provide a web-based online shopping environment by itself of the service platform, and may be implemented in a form included in a service platform that provides a payment service in a client-server environment. The payment system 100 may be implemented in a form included in a platform of a shopping system that provides an Internet-based shopping environment, but is not limited thereto, and is constructed as a separate system from the shopping system to interwork with the shopping system. It is also possible to be implemented in the form of providing a payment service through As another example of the implementation form of the payment system 100, the payment system 100 may be implemented in the form of a client device application, such as a mobile-only application installed on the user terminal 101 and/or 102, but only with this It is not limited.

2 is a block diagram illustrating an internal configuration of a payment system according to an embodiment of the present invention.

As shown in FIG. 2 , the payment system 200 according to the present embodiment may include a processor 210 , a bus 220 , a network interface 230 , and a memory 240 and a database 250 . . The memory 240 may include an operating system 241 and a payment processing routine 242 . The processor 210 may include a registration unit 211 , a provision unit 212 , a payment unit 213 , and a monitor unit 214 . In other embodiments, the payment system 200 may include more components than those of FIG. 2 .

The memory 240 is a computer-readable recording medium and may include a random access memory (RAM), a read only memory (ROM), and a permanent mass storage device such as a disk drive. In addition, program codes for the operating system 241 and the payment processing routine 242 may be stored in the memory 240 . These software components may be loaded from a computer-readable recording medium separate from the memory 240 using a drive mechanism (not shown). The separate computer-readable recording medium may include a computer-readable recording medium (not shown) such as a floppy drive, a disk, a tape, a DVD/CD-ROM drive, and a memory card. In another embodiment, the software components may be loaded into the memory 240 through the network interface 230 instead of a computer-readable recording medium.

The bus 220 may enable communication and data transfer between components of the payment system 200 . Bus 220 may be configured using a high-speed serial bus, parallel bus, storage area network (SAN), and/or other suitable communication technology.

The network interface 230 may be a computer hardware component for connecting the payment system 200 to a computer network. The network interface 230 may connect the payment system 200 to a computer network through a wireless or wired connection.

The database 250 serves to store and maintain all information necessary to provide a payment service. In this case, the database 250 includes basic personal information (eg, name, gender, nationality, date of birth, etc.) for each user, a user identifier related to a payment service (service account, mobile phone number, email, etc.), registered on the payment service. Payment information (eg, account information, card information, electronic payment means (eg, points, etc.), order and/or payment related history, authentication information required for payment authentication (eg, password, voice, fingerprint, etc.) We may retain personal information, including Although FIG. 2 shows that the database 250 is included in the payment system 200, it is also possible to exist as an external database built on a separate system.

The processor 210 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations of the payment system 200 . The instructions may be provided to the processor 210 by the memory 240 or network interface 230 and via the bus 220 . The processor 210 may be configured to execute program codes for the registration unit 211 , the provision unit 212 , the payment unit 213 , and the monitor unit 214 . Such program codes may be stored in a recording device such as the memory 240 .

The registration unit 211 , the provision unit 212 , the payment unit 213 , and the monitor unit 214 may be configured to perform steps of a remittance method to be described below.

Hereinafter, automatic debit through remittance is described as an example of a payment method, but it is not limited thereto, and all payment methods capable of real-time payment such as card payment, mobile phone payment, electronic money, payment using electronic payment means (point payment), etc. One or more of these may apply.

3 is a flowchart illustrating a method of registering an account for payment according to an embodiment of the present invention. In the account registration method according to the present invention, each step may be performed by the registration unit 211 described with reference to FIG. 2 .

In step 301 , the registration unit 211 may perform user identity authentication for a user requesting service subscription. In this case, the registration unit 211 may perform a self-authentication procedure through one or more of several known authentication methods, such as a mobile phone authentication method, a real-name authentication method, an authentication method using a public certificate, an authentication method using an ARS, and the like.

FIG. 4 is a diagram illustrating an example of the user authentication screen 400 displayed on the user terminal as a user interface related to the identity authentication procedure of the registration unit 211 . As an example, the user authentication screen 400 represents a user authentication screen according to a mobile phone authentication method, and may include a user interface for requesting input of personal information for mobile phone authentication. Accordingly, the registration unit 211 is the user's identity for the user by going through the mobile phone authentication based on the personal information (eg, name, gender, nationality, date of birth, mobile phone number, telecommunication company, etc.) input through the identity authentication screen 400 A verification process can be performed.

In steps 302 and 303, the registration unit 211 determines whether user authentication is successful according to a result of user authentication using a mobile phone authentication method or the like, and when user authentication fails, the registration of the payment service may be restricted.

In steps 302 and 304, the registration unit 211 may perform a password registration procedure for registering a user's password when user authentication through the user authentication procedure is successful. In this case, the password may be used for authentication for safe payment when payment is made using a registered account, which will be described below.

5 is a diagram illustrating an example of a password input screen 500 displayed on a user terminal as a user interface related to the password registration procedure of the registration unit 211 . As an example, the password input screen 500 may include a user interface that requests input of a password used for authentication during remittance or payment. The password input screen 500 may include a keypad area and a character input area in which characters (eg, numbers, etc.) selected through the keypad are input, in which case the keypad area is automatically activated when the password input screen 500 is approached. It can be configured as a security keypad, such as exposed, the keyboard layout is changed every time, or when the keyboard is pressed, the actual input value is converted into a random number.

The registration unit 211 may register the characters inputted through the password input screen 500 as the password for authentication of the user, and further, repeatedly requests the password to be re-entered at least once at least once so that all passwords identical to the previously entered password are the same. When a character is input, a method of registering the corresponding password may be applied.

Then, the registration unit 211 may perform a procedure for agreeing to the terms and conditions for use of the payment service before or after performing the password registration procedure. In this case, the terms and conditions of use may include all terms and conditions necessary for the use of the payment service, for example, service member terms and conditions, electronic financial transaction terms and conditions, personal information collection and use agreements, and payment information agreement to third parties.

In steps 305 , 306 , 307 , and 308 , the registration unit 211 may perform an account registration procedure for registering an account to be used as a payment method. For example, the registration unit 211 may register only one account in the form of one account per person and, in order to change the account, delete the existing registered account and then register a new account. As another example, the registration unit 211 does not limit the number of registered accounts, and it is also possible to register a plurality of accounts in the form of N accounts per person.

As an example, the registration unit 211 may perform the account registration procedure in the following order: account information input -> withdrawal agreement of the input account -> test deposit authentication -> registration completion. 6 is a diagram illustrating an example of an account input screen 600 displayed on a user terminal as a user interface related to an account registration procedure of the registration unit 211 . As an example, the account input screen 600 may include a user interface that requests input of account information such as a bank and an account number. In a user interface that requires selection of a bank, the bank may be exposed as a selected state when a bank is selected. If characters other than numbers are input when inputting the account number, an alert message (eg, 'only numbers can be input') may be exposed on the account input screen 600 . The user's basic personal information (name, date of birth, mobile phone number, etc.) required for account registration is not entered separately, but personal information pre-registered in the payment service or other services related to the payment service (eg, portal service including payment service) It can be utilized, and can be automatically displayed on the account input screen 600 .

The registration unit 211 may perform an account name verification procedure for the input account to register only the account in the user's own name during the account information input process, and if the account is not in the user's name, an alert message (eg, 'Account registration failed because it was not verified as an account in your name.') can be provided.

The registration unit 211 may perform an automatic debit withdrawal agreement procedure using the ARS when the user requests account registration for the input account ( 305 ). 6 and 7 , when the user inputs account information on the account input screen 600 and then inputs the registration button 601 , the registration unit 211 confirms the automatic debit withdrawal agreement through the ARS guidance screen 710 . In order to provide guidance on receiving an ARS call for this purpose, if the user requests ARS guidance on the ARS guidance screen 710, the ARS call can be connected to the mobile phone number included in the user's personal information. In this case, when the user receives a call, the ARS may provide a notice related to the automatic debit agreement for the account entered by the user.

After confirming the user's consent to direct debit withdrawal through the ARS (306), the registration unit 211 checks the user's intention to withdraw by direct debit, and when the user does not agree to direct debit withdrawal, an alert message according to account registration failure (for example, 'Do not agree to direct debit account registration failed.') can be provided (307). On the other hand, the registration unit 211 registers the input account as a remittance account to be used as a payment method when the user agrees to the direct debit withdrawal (308) and sends an alert message according to the completion of the account registration (for example, 'according to 'direct debit withdrawal agreement'). Account registration is complete.'). In this case, the registration unit 211 may register the user's account by matching with personal information including the user identifier.

The registration unit 211 may perform an authentication procedure using a test deposit for input account authentication. As an example, the registration unit 211 uses the remittance identification number or some information (eg, transfer amount, transfer date and time, summary, etc.) included in the account transfer details provided by the bank of the corresponding account when the test deposit is made to the user's input account. can be authenticated. As another example, the registration unit 211 may perform an account authentication procedure using processing information generated when the test deposit is completed. For example, the registration unit 211 uses the remittance identification number randomly generated for the test deposit to the account input by the user as the sender information, and after remitting a certain amount (eg, KRW 1) to the corresponding account, the remittance identification number can be used to authenticate the user's input account. The user can check the account deposit details provided by the bank of the input account through SMS or ARS, and can authenticate the input account using some information based thereon. Although it is limited to using the transfer-related brief or separate processing information in the above account authentication procedure, it is not limited thereto.

8 is a diagram illustrating an example of the account authentication screens 810 and 820 displayed on the user terminal as a user interface related to the test deposit authentication procedure of the registration unit 211 . For example, the account authentication screen 810 may include a user interface that requests input of a remittance identification number confirmed by the user in the test deposit details of the input account. As another example, the account authentication screen 820 may include a user interface that requests input of a test deposit amount deposited in the user's input account. Accordingly, when the remittance identification number input by the user matches the remittance identification number generated during the test deposit of the input account, or the amount input by the user matches the amount remitted during the test deposit to the input account, The input account can be normally registered as a remittance account. In this case, the registration unit 211 may guide a path (eg, ARS phone number, etc.) through which the account deposit details for the test deposit can be checked through the account authentication screens 810 and 820, and for a certain period of time (eg, 24 hours). If the remittance identification number is entered within ), the input account is registered as a remittance account, and the account registration can be canceled after a certain period of time has elapsed.

Accordingly, the registration unit 211 may register the user's payment information in advance through the registration procedure of the above process and connect it with the corresponding user identifier. In addition, the registration unit 211 may connect the registered delivery address information or the latest delivery address information through the pre-registration process with the user identifier.

As another example, in the present invention, separately from setting up a remittance account, payment information and a password may be set as a dedicated payment method for simple payment using the URL method. For example, when a user wants to use a card as a means for URL-based simple payment, the registration unit 211 pre-registers card information (eg, card number, etc.) through a separate registration procedure, and You can set a password together. Accordingly, when authentication is required for simple payment through a URL, payment can be processed immediately after user authentication using a password set for simple payment.

In order not to expose payment information for simple payment, that is, card number or account number, payment information may be replaced with a virtual number to be registered and used. A card number or account number registered as payment information may be masked when exposed. For example, in the case of a card, the card company does not provide an actual card number, but provides a virtual number (eg, token) mapped to the card number, and thus at least some number (eg, the first four digits) is exposed to the user. The remaining numbers may be exposed in a masking form. Before simple payment is used in a state in which payment information is registered, the entire payment information is not exposed, and if payment occurs even once after that, some numbers of payment information may be masked and exposed.

9 is a flowchart illustrating a method of providing a payment path according to an embodiment of the present invention. In the method of providing a payment path according to the present invention, each step may be performed by the providing unit 212 described with reference to FIG. 2 .

In step 901, the user terminal may be provided with a service page in which a specific product is exposed. In this case, the service page includes a shopping service, an integrated search service, a community service, a cafe/blog service, a social network service, and the like, and the seller's product. It may refer to various service screens that can be provided by the platform in which the information is registered The service page is a service screen where the seller's product is exposed, for example, a product detail page where detailed information of a specific product is exposed, and a post related to a specific product It may include an in-community page, a chat page related to a specific product, etc. For example, the service page may be provided directly from the payment system 200 or may be provided from another service that can be linked to the payment system 200 .

In step 902, when the user terminal enters a service page related to a specific product, the providing unit 212 is an interaction for providing a payment path for the product on the service page. Payment including a payment URL Provides UI. In the present invention, the payment URL refers to a shortened URL of a shortcut function that can directly pay for a specific product without inputting additional information for ordering and payment, and in particular, a plurality of procedures (eg, writing an order form, inputting a delivery address, The existing method of selecting a payment method, entering payment information, verifying a financial institution, etc.) can be used to directly enter the payment environment in one step.

To this end, the provider 212 generates a shortened URL corresponding to payment information connected to the service account based on the service account of the user accessing the service page, and then applies the generated shortened URL to a specific product on the service page. It is provided as a payment URL for As another example, the payment URL may be generated by including delivery address information (eg, a recent delivery address, a preset delivery address, etc.) connected to the user's service account together with the payment information.

In step 903, when a selection for a payment UI (ie, a payment request) is received from the user terminal through the service page of a specific product, the providing unit 212 displays a payment screen in which an order and payment for a specific product can be made at the same time. to provide. In particular, the providing unit 212 may provide a payment screen including payment information connected to the user's service account according to the payment URL configured in the payment UI. As another example, when the payment URL includes shipping address information, when accessing the payment URL, a payment screen including payment information linked to the user's service account and shipping address information may be provided.

10 to 13 are diagrams illustrating exemplary service pages displayed on the user terminal as a user interface related to the payment path providing procedure of the providing unit 212 .

10 illustrates a product detail page 1000 in which detailed information of product 1 sold by the seller AAA is exposed. The user may enter the product detail page 1000 by selecting a specific product through various paths such as a shopping service, an integrated search service, a community service, a cafe/blog service, and a social network service.

As shown in FIG. 10 , detailed information (product image, product price, product description, seller information, category, etc.) of product 1 is exposed on the product detail page 1000 , and an order and payment for product 1 are immediately possible. The payment UI 1001 of the shortcut function may be exposed together.

11 shows a posting screen 1100 related to a specific product posted on the Internet. The user can enter the posting screen 1100 on which information of product 1 is posted and created by others (eg, seller) through various routes such as integrated search service, community service, cafe/blog service, social network service, etc. there is.

As shown in FIG. 11 , at least a part of detailed information of product 1 is exposed on the posting screen 1100 , and a shortcut function that enables immediate ordering and payment of product 1 is attached when the posting is written. of the payment UI 1101 may be exposed together.

12 shows a chatting screen 1200 in which product inquiry is possible through one-on-one chatting with the seller AAA with respect to product 1 sold by the seller AAA. The user may enter the one-to-one chatting screen 1200 with the seller AAA for Product 1 through various routes such as an integrated search service, a community service, a cafe/blog service, and a social network service. In addition, it is also possible for the user to directly register the seller AAA in the chat target list to enter the one-to-one chatting screen 1200 with the seller AAA.

As shown in FIG. 12 , through the one-to-one chatting screen 1200 between the seller AAA and the user, the user can inquire about the product 1 and place an order for the product. On the one-to-one chatting screen 1200 , a payment UI 1201 having a shortcut function that enables immediate ordering and payment of product 1 in response to a user's order request may be exposed. For example, the provider 212 generates a payment URL when receiving a separate request, such as a request to write an order form from the seller AAA in response to the user's order request in a chat environment between the seller AAA and the user, and generates a payment URL on the one-to-one chatting screen 1200. may be exposed as the payment UI 1201 in the .

As described above, the shortcut UIs 1001, 1101, and 1201 of the payment function are exposed on the service page related to a specific product, such as the product detail page 1000, the posting screen 1100, and the chatting screen 1200 with the seller. can be

When the selection of the payment UI exposed on the service page is received from the user terminal, the providing unit 212 may provide the payment screen 1300 directly from the service page as shown in FIG. 13 . In this case, the payment screen 1300 may automatically include and display the payment information 1310 and the delivery address information 1320 connected to the user's service account as information corresponding to the payment URL.

Accordingly, the providing unit 212 can simplify the ordering step by omitting the information input and confirmation steps for ordering and payment and directly entering the payment environment using the URL method.

14 is a flowchart illustrating a payment processing method according to an embodiment of the present invention. In the payment processing method according to the present invention, each step may be performed by the payment unit 213 described with reference to FIG. 2 .

In step 1401, when a payment request for a specific product is received from the user terminal, the payment unit 213 may check a payment risk level for the corresponding user. In the payment service according to the present invention, users may be classified by payment risk level, the authentication procedure may be omitted as much as possible for users belonging to a safe level, and a stricter authentication policy may be applied to users belonging to a high risk level.

For example, the payment unit 213 may classify the payment risk level into a safety level belonging to the white list, a high risk level belonging to the black list, a general level not belonging to both the white list and the black list, and the like. For example, payment risk assessment conditions: (1) In case of safety rating, when a number of normal transactions are performed for a certain period (eg, 3 months), (2) When using a dedicated application for a payment service, (3) The latest delivery address In the case of requesting payment to (or preset shipping address), (4) the mobile phone number that executed the dedicated application for the payment service matches the mobile phone number used for payment, etc., it can be classified as a safety level. And, if all payment risk evaluation conditions are satisfied except for some evaluation conditions (for example, (3) delivery destination conditions, etc.), the main evaluation conditions among the payment risk evaluation conditions (e.g., (4) mobile phone number condition, etc.) If they are not met, they can be classified as high-risk. In the case of a general grade, it may be divided into two or more detailed grades (eg, general grade 1, general grade 2, ) according to unmet evaluation conditions.

In addition, the payment unit 213 checks the identity authentication history in a specific application interworking with the payment service (eg, a dedicated application such as a portal service, an integrated search service, a shopping service, a map service, a community service, a social network service) as a payment risk It can be used as an evaluation condition for classifying grades. For example, if the payment unit 213 is introduced through a dedicated app of the portal service, whether or not the identity authentication completed in the corresponding app is valid at the time of inflow, the number of failures of identity authentication for a certain period (eg, 3 months) is constant. The payment risk level may be classified based on whether the number of times (eg, 10 times) is exceeded.

The payment unit 213 may classify payment risk grades based on user media environment information, search/payment/transaction type information, accident type information, and the like. The user media environment information is collected by the monitor unit 214, which will be described below, and includes a payment method, terminal information, access information, etc. used by the user for payment, for example, MAC, IP, S/N, etc. It can be collected by synthesizing and hashing them. Search/payment/transaction type information is also collected and analyzed by the monitor unit 214, and may include transaction patterns or tendencies that can be analyzed from the user's overall behavior from product search to product order on the Internet. Incident type information can be collected through relevant organizations, domestic and foreign trends, and malicious code analysis. In the present invention, criteria for classifying payment risk grades can be prepared based on user media environment information, search/payment/transaction type information, accident type information, etc. grades can be classified.

In step 1402, when the user belongs to the safety level, the payment unit 213 omits or minimizes the authentication process and directly processes the order and payment for a specific product using payment information and shipping address information corresponding to the payment URL. can For example, in the case of a safety rating user, the payment unit 213 may perform payment processing immediately after receiving only the intention to agree to payment information corresponding to the payment URL and the delivery address information with respect to the user's payment request.

In step 1403 , when the user belongs to the high risk level, the payment unit 213 may treat the user's payment request as payment impossible and provide an alert message according to the payment failure to the user terminal. If a user belonging to a high-risk class wants to make a payment, upgrade to a payable level can be permitted after going through a separate procedure such as an outcall to the customer center or verification of identity documents.

In step 1404, when the user belongs to the general level, the payment unit 213 may perform a user authentication procedure through one or more authentication methods. The payment unit 213 is an authentication method using a password, an authentication method using an OTP (one time password), an authentication method using a fingerprint, an authentication method using a voice, an authentication method using an ARS, an authentication method using a public certificate, mobile phone authentication At least one authentication method among known authentication methods, such as a method and a real name authentication method, may be used.

When the general grade is subdivided into a plurality of grades, the payment unit 213 can differentiate and apply the identity authentication procedure according to the grade, for example, when the general grade is subdivided into a first grade and a second grade, the first grade The user applies the primary authentication method using a password or OTP, and the second level user can additionally apply the secondary authentication using a fingerprint, voice, or ARS along with the primary authentication. For example, when performing the simple payment using the URL method, the payment unit 213 may perform user authentication using the password for simple payment described above according to the user level.

In step 1405, when the user authentication is successful for the user belonging to the general level, the payment unit 213 may immediately process an order and payment for a specific product using payment information corresponding to the payment URL and delivery address information. As an example, the payment unit 213 may process payment by automatic transfer using a remittance account or immediately process payment using payment information (eg, card number, etc.) registered for URL-based simple payment only. there is.

The payment unit 213 may complete the payment process by transmitting a payment approval request including payment information corresponding to the payment URL to the financial company server during payment processing and transferring the payment approval result of the financial company server to the user terminal.

Therefore, the payment unit 213 directly performs the authentication led by the existing financial company for the user who requested payment, but applies the authentication policy differentially from authentication pass to payment impossible according to the user's risk level, making it flexible and more powerful. You can proceed with the payment processing process as an authentication method.

In addition, the payment unit 213 may process the remittance process between individuals using account information connected to the user's service account. Hereinafter, the remittance process will be described in detail.

15 and 16 are flowcharts illustrating a remittance processing method according to an embodiment of the present invention. In the remittance processing method according to the present invention, each step may be performed by the payment unit 213 described with reference to FIG. 2 .

In step 1501, when a service request for remittance is received from the user terminal, the payment unit 213 may determine whether a remittance account is registered for the user.

In step 1502 , the payment unit 213 may request an account registration process for the user from the registration unit 211 to register a remittance account first in the case of a user whose remittance account is not registered.

In steps 1503 to 1507, in the case of a user whose remittance account is already registered, the payment unit 213 may perform a recipient selection procedure for receiving an identifier and real name of a recipient for remittance from the user. Examples of the identifier may include a service account, phone number, e-mail, and the like, and in addition, any information that can identify a recipient may be used. In the present specification, the real name may mean the user's real name, but is not limited thereto, and may include a name actually used by the user in the remittance service, for example, a name pre-registered on the remittance service when signing up for the service.

As an example, the payment unit 213 may select a recipient by using the recipient's service account (eg, a user ID registered in a payment service, a user ID registered in another service interworking with the payment service, etc.) ( 1504). As another example, the payment unit 213 may select a recipient using the recipient's mobile phone number ( 1505 ). The payment unit 213 may receive a selected recipient using a service account or a mobile phone number, and then input the real name of the selected recipient together ( 1506 ). In this case, the real name of the recipient may be input through a direct input method.

When the recipient is selected using the service account and mobile phone number, the payment unit 213 may provide a direct input method to directly receive the recipient's service account or mobile phone number. Alternatively, after exposing the address book stored on the user terminal, the payment unit 213 may receive an input of a service account or mobile phone number of a recipient selected from the corresponding address book. Alternatively, the payment unit 213 exposes the address book on the address book app in conjunction with a separate application having the address book (hereinafter referred to as the 'address book app'), and then inputs the service account or mobile phone number of the recipient selected from the address book can receive

As another example, the payment unit 213 may specify a recipient selected from the remittance friend list after exposing a remittance friend list having a recent remittance history or set by the user ( 1507 ). To this end, in the register 211, the user automatically registers as a remittance friend, including the service account and/or mobile phone number and real name of the subject that the user has recently sent or received, or the service account of the subject directly entered by the user in the pre-registration environment and/or you can register as a remittance friend by including your mobile phone number and real name. In this case, when the recipient is selected using the remittance friend list, the payment unit 213 may omit the real name input procedure because the remittance friend list includes a real name.

17 is a diagram illustrating an example of the remittance information input screen 1700 displayed on the user terminal as a user interface related to the remittance processing procedure of the payment unit 213 . As an example, the remittance information input screen 1700 may include a user interface that requests input of remittance information including a recipient, a remittance amount, and a remittance related message. On the remittance information input screen 1700 , at least part of information about the remittance account registered by the user may be exposed. In addition, the remittance information input screen 1700 may further include a user interface for requesting consent to provide personal information to a third party. The payment unit 213 may provide a recipient selection page when an interface for recipient selection is input on the remittance information input screen 1700 .

18 is a diagram illustrating an exemplary recipient selection screen 1800 for selecting a recipient as a user interface related to the remittance processing procedure of the payment unit 213 . For example, the recipient selection screen 1800 may include a first user interface for selecting a recipient using at least one of identifiers such as a service account, a mobile phone number, and an email.

When the first user interface is selected on the recipient selection screen 1800, the payment unit 213 is an input page for inputting a real name together with any one of identifiers such as a service account, a mobile phone number, and an email, as shown in FIG. 19 . (1910, 1920) can be provided.

When the first user interface is selected on the recipient selection screen 1800, the payment unit 213 accesses the address book on the user terminal or the address book on the address book app as shown in FIG. 20, and a selection page including the address book (2010) When a specific recipient is selected on the selection page 2010 after providing , an input page 2020 for inputting the real name of the corresponding recipient may be provided.

The payment unit 213 provides input pages 1910 and 1920 for inputting the recipient's identifier and real name as shown in FIG. 19 in a remittance environment through a web browser in consideration of the service provision environment, and a remittance environment implemented as a mobile-only application may provide a selection page 2010 using the address book in conjunction with the address book as shown in FIG. 20 .

Referring to FIG. 18 , when a remittance friend list exists, the recipient selection screen 1800 may further include a second user interface for selecting a recipient using the remittance friend list. A profile image, service account, real name, etc. may be exposed in the remittance friend list of the recipient selection screen 1800 .

When the recipient selection is completed, the payment unit 213 may expose information on the recipient selected by the user on the remittance information input screen 2100 as shown in FIG. 21 . In this case, the information of the recipient exposed on the remittance information input screen 2100 may include an identifier (service account, phone number, email, name, etc.) corresponding to the recipient selection method, along with the real name input by the user. .

In step 1508 , the payment unit 213 may request the user to input the remittance amount, and thus may receive the remittance amount input by the user through the remittance information input screen 2100 . For example, the remittance information input screen 2100 may include an area for directly inputting an amount in won, an amount button for automatically inputting a predetermined amount, and the like.

The following procedure after the remittance processing procedure described with reference to FIG. 15 will be described next with reference to FIG. 16 .

In step 1609 , the payment unit 213 may check the remittance limit per unit period of the user when a recipient is selected and a remittance amount input is completed and a remittance request is received from the user. For example, the remittance limit per unit period may be automatically set as a default or may be set directly by the user, for example, may be set at 500,000 won per ID per day. As another example, the remittance limit per unit period may be differentially set depending on whether a person is a minor, for example, 500,000 won per 1 ID for an adult, and 100,000 won per 1 ID for a minor. In addition to the remittance limit per unit period, the minimum remittance limit may also be preset to a certain amount (eg, 1,000 won).

In step 1610, the payment unit 213 adds the recently requested remittance amount with the existing remittance amount remitted in a unit period, and when the sum exceeds the remittance limit per unit period, the payment unit 213 stops the remittance processing process and an alert indicating the limit is exceeded message can be provided.

In step 1611, the payment unit 213 may check the balance of the parent account related to the remittance account when the sum of the recently requested remittance amount and the existing remittance amount remitted in a unit period does not exceed the remittance limit. The parent account balance limit may be set automatically or may be set directly by the user, for example, the balance limit may be set to 2 million won when remittance.

The payment unit 213 may add the recently requested remittance amount with the remittance amount waiting to be received, and provide an alert message indicating that the limit is exceeded when the total amount exceeds the balance limit of the mother account ( 1610 ).

In step 1612 , the payment unit 213 may request the user to input a password for authentication when the sum of the recently requested remittance amount and the remittance amount waiting to be received and the total amount does not exceed the balance limit of the parent account.

In step 1613 , the payment unit 213 may compare the password input by the user with the previously registered password to check whether the two passwords match, and if the two passwords do not match, an alert message indicating a password error may be provided.

In step 1614 , the payment unit 213 may check the balance of the remittance account when the password input by the user matches the previously registered password.

In step 1615 , the payment unit 213 provides an alert message indicating insufficient balance when the recently requested remittance amount exceeds the balance of the remittance account, and when the remittance account does not exceed the balance of the remittance account, the payment unit 213 provides a recipient selected by the user You can send remittance details for the remittance amount.

In steps 1616 and 1617, the payment unit 213 may provide a function to cancel the remittance before the recipient receives the remittance amount for the remittance pending reception, and the user requests cancellation of the remittance in the reception standby state. In this case, the transfer may be canceled.

In steps 1618 and 1617 , if the recipient does not receive the amount sent by the user within the preset remittance acceptance deadline, the payment unit 213 may cancel the remittance when the remittance acceptance deadline elapses. A remittance acceptance deadline (for example, 3 days) may be set as a deadline for the recipient to receive the remittance amount. In this case, the remittance acceptance deadline may be automatically set as a default or may be set directly by the user who is the sender of the remittance. .

In steps 1619, 1620, and 1617, the payment unit 213 may check whether the real name input by the user together with the identifier matches the real real name corresponding to the identifier, and the real name input by the user is different from the real real name. In this case, you can provide an alert message indicating a real name error and cancel the remittance.

The payment unit 213 can verify the real name by comparing the identifier and real name of the recipient included in the remittance information with the identifier in the personal information registered in the database and the real name. This may be performed when a recipient is selected using the method, and may be omitted when a recipient is selected from the remittance friend list.

The payment unit 213 completes the remittance processing process by transferring the amount to the recipient when the recipient requests to receive the amount sent by the user within the remittance acceptance deadline and when the real name included in the user's remittance information matches the recipient's real name can do.

In steps 1621, 1622, and 1623, the payment unit 213 checks whether the user's original account has an issue when remittance is canceled, and if there is no specific issue, returns the canceled remittance amount to the original account, and if a specific issue occurs, in advance You can return the canceled remittance amount to the set refund balance.

22 is a flowchart illustrating a method for receiving a remittance according to an embodiment of the present invention. In the method for receiving remittance according to the present invention, each step may be performed by the payment unit 213 described with reference to FIG. 2 .

In step 2201, when the sender's remittance details are received, the payment unit 213 may provide a reception notification to the user along with the remittance details. As an example, the payment unit 213 sends a text message including the remittance reception details (sender information, remittance date, remittance amount, etc.) to the user terminal through a text service (eg, SMS, etc.) for remittance to a user as a recipient. can be transmitted. As another example, the payment unit 213 may expose the remittance reception details through a user's notification page associated with a payment service for remittance to a user as a recipient. As another example, the payment unit 213 may simultaneously apply the two remittance reception notification methods described above. The remittance reception notification may include a link capable of moving to a remittance reception detail screen where the sender can receive the remittance amount.

Furthermore, the payment unit 213 may determine the remittance reception notification method according to the recipient selection method by the sender. For example, when the sender selects a recipient using a mobile phone number, the recipient can be notified of the receipt of remittance through a text message, and when a recipient is selected using a service account, the recipient can be notified of the receipt of the remittance through a notification page related to the payment service; When a recipient is selected using the remittance friend list, the remittance receipt can be notified using both a text message and a notification page.

The payment unit 213 may provide a remittance reception notification through a text message even if the user selected by the sender as the recipient is not a registered member of the payment service (or other services linked to the payment service), and then proceeds with the remittance reception step In order to do this, you can additionally proceed with the procedures necessary for receiving remittance, including the procedure for membership registration and the procedure for agreeing to the terms and conditions for using the payment service.

In steps 2202 and 2203, if the user receives a remittance cancellation request from the sender before the user receives the sender's remittance, the payment unit 213 may cancel the remittance of the case, and at this time, provide a text message service and/or payment to the user. Through the notification page associated with the service, it is possible to provide a remittance cancellation notification indicating that the remittance has been canceled by the sender.

In steps 2204 and 2203, if the user does not receive the sender's remittance within the set remittance acceptance deadline, the payment unit 213 similarly cancels the remittance of the case and provides the user with a text message service and/or a notification page associated with the payment service. A remittance cancellation notification can be provided to notify that the remittance has been canceled due to the elapse of a deadline.

In steps 2205, 2206, and 2203, the payment unit 213 may check whether the real name of the user who received the remittance reception notification for the sender's remittance matches the real name included in the sender's remittance history, and the two real names In this other case, you can provide an alert message indicating a real-name error and cancel the transfer. The real name verification procedure is performed when the sender selects the recipient using a service account or mobile phone number, and may be omitted when the recipient is selected from the remittance friend list.

In step 2207 , the payment unit 213 may perform a remittance receiving method selection procedure when the user requests to receive the amount sent by the sender within the remittance acceptance deadline and real-name authentication is normally processed.

23 is a diagram illustrating an example of a remittance reception detailed screen 2300 displayed on a user terminal as a user interface related to the remittance reception procedure of the payment unit 213 . For example, on the remittance reception detail screen 2300 , the sender's remittance detailed information (eg, sender name, remittance date, remittance amount, remittance related message, etc.) is exposed, and the remittance reception method for receiving the remittance amount sent by the sender A user interface requesting the selection of may be included. Accordingly, the user may select a remittance receiving method in which the sender receives the remittance amount after checking the remittance detailed information displayed on the remittance reception detailed screen 2300 .

The remittance receiving method may include, but is not limited to, a method of receiving a remittance through a bank account, a method of receiving through an electronic payment means (eg, points) related to a payment service, and the like. In order to receive a bank account, it is necessary to register an account on the payment service, and in the case of points, it is possible to receive remittance without a registered account.

In steps 2208 and 2209 , when the user selects a bank account receiving method as a remittance receiving method, the payment unit 213 may check whether a bank account registered in the payment service exists for the corresponding user.

In steps 2210 and 2211, the payment unit 213 requests whether to proceed with the account registration procedure from the user when the user's account registered on the payment service does not exist, and receives the remittance when the user does not proceed with the account registration procedure You can provide an alert message indicating an error. In this case, if the user does not proceed with the account registration procedure, the payment unit 213 may suspend the remittance reception of the case or request reselection of the remittance reception method.

In steps 2209 , 2210 , and 2212 , the payment unit 213 determines whether an account registered on the payment service already exists or if a new account is registered through the account registration procedure, whether the state of the registered account is a receivable normal state can be checked. At this time, the payment unit 213 provides an alert message indicating a remittance reception error when the user's registered account is not in the remittance receiving state, and, on the other hand, ensures that the sender's remittance amount is deposited into the user's registered account in the normal state. By doing so, the remittance receiving process can be completed.

In steps 2213 and 2214 , the payment unit 213 may check the limit of the user's balance when the user selects an electronic payment method as a remittance receiving method. The balance limit may be automatically set or may be set directly by the user, for example, the point balance limit may be set to 2 million won.

The payment unit 213 adds up the remittance amount received from the sender and the current balance of the user's electronic payment means, and converts the sender's remittance amount to an electronic payment means to be credited to the user if the sum does not exceed the balance limit By doing so, the remittance receiving process can be completed.

The payment unit 213 may perform the user authentication procedure using the authentication password registered on the payment service, but may omit the authentication procedure using the password in the remittance receiving procedure.

Meanwhile, the payment unit 213 may provide an alert message indicating a remittance reception error when the sum of the remittance amount received from the sender and the current balance of the user's electronic payment means exceeds the balance limit. In this case, when the sum total amount exceeds a predetermined limit of the balance of the electronic payment means, the payment unit 213 may suspend reception of the relevant case or request reselection of the remittance reception method.

In the above description, the sender's remittance amount is fully received through either a bank account or an electronic payment method, but the present invention is not limited thereto, and the remittance receiving method may be applied differently or expanded. For example, it is possible to provide a complex reception method in which the remittance reception can be received by dividing the remittance reception into a bank account and an electronic payment method. It is also possible to receive by means.

Accordingly, the payment unit 213 can process a direct remittance between the individual who has signed up for the service using the service account and real name of the recipient, and, in addition to receiving the amount received from another person into the user's bank account, electronic payment such as points It can be converted into a means. The payment unit 213 can provide a payment environment that can be used immediately as payment for online commerce (eg, Internet shopping, etc.) after the user receives the amount sent by the sender through an account or electronic payment means. . In addition, when the simple payment is registered, the payment unit 213 may provide a convenient payment environment even during offline face-to-face payment. For example, an electronic payment method may be used as a payment method based on short-range wireless communication such as a barcode or NFC.

Furthermore, the payment unit 213 applies various rules for detecting abnormal transactions by comprehensively analyzing the variously collected information (user media environment information, search/payment/transaction type information, accident type information, etc.) This rule can be used to determine whether there is an abnormal financial transaction and support an appropriate response (eg, notification, card suspension, illegal transaction report, etc.). For example, the payment unit 213 may change the delivery address through individual contact with the seller after placing an order to a recent delivery address, transfer or use an electronic payment method directly, attempt a large amount payment after a small payment, consume different from usual It is possible to detect various abnormal transactions including a case of attempting a form of payment.

24 is a flowchart illustrating a periodic payment notification method according to an embodiment of the present invention. In the periodic payment notification method according to the present invention, each step may be performed by the monitor unit 214 described with reference to FIG. 2 .

In step 2401, the monitor unit 214 may collect payment type information related to the user. As an example, the payment type information may include product order information (eg, product name, product category, order date, number of orders, etc.) that the user actually purchased two or more times, ie, made payment.

In step 2402, the monitor unit 214 may analyze the user's regular purchase pattern based on the payment type information. In other words, the monitor unit 214 may analyze the products that the user regularly purchases and the purchase cycle for each product according to the product order history. For example, if a user orders bottled water 30 days after the initial order and then orders another 28 days later, the user's bottled water purchase cycle may be analyzed as an average purchase cycle of 29 days.

In steps 2403 and 2404, the monitor 214 may provide a periodic purchase notification to the corresponding user terminal according to the product purchase cycle analyzed based on the user's payment type information. The periodic purchase notification may include product information targeted for periodic purchase. As an example, the monitor unit 214 may provide a notification about the regular purchase product at a certain point in time (eg, one week before, one day before, the same day, etc.) according to the user's product purchase cycle.

25 is a diagram illustrating an example of the periodic payment notification screen 2500 displayed on the user terminal as a user interface related to the periodic payment notification procedure of the monitor unit 214 . For example, the periodic payment notification screen 2500 may include a message indicating a periodic payment notification, and may include a payment UI including information on a periodic purchase product and a payment URL for a periodic purchase product. In this case, the payment URL may correspond to payment information and delivery address information connected to the user's service account, or may be a shortened URL corresponding to payment information and delivery address information used for payment when a recent order for the product is made. When the user selects the payment UI exposed on the periodic payment notification screen 2500, the user can directly enter the payment screen (eg, the payment screen described with reference to FIG. 13) and proceed directly with the payment.

In the above description, it is described that the periodic payment notification is automatically provided by analyzing the product purchase pattern of the user, but the present invention is not limited thereto, and in some cases, it is also possible to provide the periodic payment notification through a preset setting by the user. For example, the product (eg, bottled water, diaper, wet tissue, etc.) and the product purchase cycle that the user purchases regularly may be set in advance, and the monitor unit 214 may set the product and product purchase cycle set by the user in advance. In this way, a periodic payment notification for each product can be provided to the corresponding user terminal.

Accordingly, the monitor unit 214 may provide a notification that direct payment for a regular purchase is possible according to a purchase pattern or reservation setting according to the user's transaction history.

The above-described payment service method may include shortened operations or additional operations based on the details of the payment system described with reference to FIGS. 1 to 25 . In addition, two or more operations may be combined, and the order or position of the operations may be changed.

4 to 8, 10 to 13, 17 to 22, 23, and 25 are exemplary screens for better understanding of the invention and convenience of explanation, and the configuration or order of the screens can be changed as much as possible. .

26 is a block diagram for explaining an example of an internal configuration of a computer system according to an embodiment of the present invention. The computer system 2600 includes at least one processor 2610 , a memory 2620 , a peripheral interface 2630 , and an I/O subsystem 2640 . , a power circuit 2650 and a communication circuit 2660 may be included at least. In this case, the computer system 2600 may correspond to a user terminal.

The memory 2620 may include, for example, a high-speed random access memory, a magnetic disk, an SRAM, a DRAM, a ROM, a flash memory, or a non-volatile memory. there is. The memory 2620 may include a software module, an instruction set, or other various data necessary for the operation of the computer system 2600 . In this case, access to the memory 2620 from other components such as the processor 2610 or the peripheral interface 2630 may be controlled by the processor 2610 .

Peripheral interface 2630 may couple input and/or output peripherals of computer system 2600 to processor 2610 and memory 2620 . The processor 2610 may execute a software module or an instruction set stored in the memory 2620 to perform various functions for the computer system 2600 and process data.

Input/output subsystem 2640 may couple various input/output peripherals to peripheral interface 2630 . For example, input/output subsystem 2640 may include a controller for coupling peripherals such as monitors, keyboards, mice, printers, or, if desired, touch screens or sensors to peripheral interface 2630 . According to another aspect, input/output peripherals may be coupled to peripheral interface 2630 without going through input/output subsystem 2640 .

The power circuit 2650 may supply power to all or some of the components of the terminal. For example, power circuit 2650 may include a power management system, one or more power sources, such as batteries or alternating current (AC), charging systems, power failure detection circuits, power converters or inverters, power status indicators or power sources. It may include any other components for creation, management, and distribution.

The communication circuit 2660 may enable communication with another computer system using at least one external port. Alternatively, as described above, if necessary, the communication circuit 2660 may include an RF circuit to transmit and receive an RF signal, also known as an electromagnetic signal, to enable communication with another computer system.

This embodiment of FIG. 26 is only an example of the computer system 2600 , and the computer system 2600 may omit some components shown in FIG. 26 , or further include additional components not shown in FIG. 26 , or 2 It may have a configuration or arrangement that combines two or more components. For example, a computer system for a communication terminal in a mobile environment may further include a touch screen or a sensor in addition to the components shown in FIG. 26 , and various communication methods (WiFi, 3G, LTE) are provided in the communication circuit 2660 . , Bluetooth, NFC, Zigbee, etc.) may include a circuit for RF communication. The components that may be included in the computer system 2600 may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing or application-specific integrated circuits.

As such, according to an embodiment of the present invention, an order step can be simplified through a simple inflow path by providing a one-click payment model that enables direct payment through a URL method by omitting unnecessary procedures. Furthermore, according to an embodiment of the present invention, it is possible to maximize the convenience of users with regular purchasing behavior by providing a notification that direct payment is possible according to a purchase pattern or reservation setting according to the user's transaction history. And, according to an embodiment of the present invention, a proactive and free authentication policy can be applied by directly performing authentication in charge of a financial company in the payment system for safe transaction of payment. In addition, according to an embodiment of the present invention, the authentication procedure is differentiated from one-click to impossible of payment according to the risk level of the user or transaction situation and applied, so that the authentication policy is more flexible and reasonable compared to the existing uniform method, but more stringent and strong authentication policy can be applied.

Methods according to embodiments of the present invention may be implemented in the form of program instructions that can be executed through various computer systems and recorded in computer-readable media.

The program according to the present embodiment may be configured as a PC-based program or an application dedicated to a mobile terminal. The app related to the payment service in this embodiment is implemented in the form of a program that operates independently, or is configured in the form of an in-app of a specific application (eg, a portal service app, a search service app, etc.) It may be implemented to enable operation on a specific application.

In addition, the methods according to an embodiment of the present invention may be performed by controlling the user terminal by an application associated with a server system providing a payment service. As an example, such an application may execute one or more processes configured to perform one or more of the features described herein. In addition, such an application may be installed in the user terminal through a file provided by the file distribution system. For example, the file distribution system may include a file transmission unit (not shown) that transmits the file in response to a request from the user terminal.

The device described above may be implemented as a hardware component, a software component, and/or a combination of the hardware component and the software component. For example, devices and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA). , a programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions, may be implemented using one or more general purpose or special purpose computers. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, although one processing device is sometimes described as being used, one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that can include For example, the processing device may include a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as parallel processors.

Software may comprise a computer program, code, instructions, or a combination of one or more of these, which configures a processing device to operate as desired or is independently or collectively processed You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device, to be interpreted by or to provide instructions or data to the processing device. , or may be permanently or temporarily embody in a transmitted signal wave. The software may be distributed over networked computer systems, and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

The embodiment according to the present invention described above may be implemented in the form of a computer program that can be executed through various components on a computer, and such a computer program may be recorded in a computer-readable medium. In this case, the medium may be to continuously store the program executable by the computer, or to temporarily store the program for execution or download. In addition, the medium may be various recording means or storage means in the form of a single or several hardware combined, it is not limited to a medium directly connected to any computer system, and may exist distributed on a network. Examples of the medium include a hard disk, a magnetic medium such as a floppy disk and a magnetic tape, an optical recording medium such as CD-ROM and DVD, a magneto-optical medium such as a floppy disk, and those configured to store program instructions, including ROM, RAM, flash memory, and the like. In addition, examples of other media may include recording media or storage media managed by an app store that distributes applications, sites that supply or distribute various other software, and servers.

As described above, although the embodiments have been described with reference to the limited embodiments and drawings, various modifications and variations are possible for those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

200: payment system
211: register
212: provider
213: payment department
214: monitor unit

Claims (20)

In the payment service method implemented by a computer,
providing a uniform resource locator (URL) corresponding to payment information stored in a database connected to the user's service account on the service screen when the user's terminal enters a service screen related to a specific product; and
Upon receiving the selection of the URL from the user's terminal, the user enters the payment environment directly without going through an order form and payment information input procedure, and is stored in the database without inputting additional information about the payment information and receiving the corresponding information. Including the step of directly performing payment processing using the payment information,
The step of performing the payment processing,
By performing an independent authentication process independent of the financial company related to the payment information,
confirming a payment risk level that evaluates the risk of the user's payment by using one or more of user media environment information, search, payment, transaction type information, and accident type information for the user; and
A payment service method comprising a; applying an authentication method corresponding to the payment risk level among several authentication methods to perform a self-authentication procedure for the user. According to claim 1,
The step of providing the URL includes:
providing the URL including shipping address information linked to the user's service account;
The step of performing the payment processing,
Directly performing payment processing using the payment information and the delivery address information
Payment service method characterized in that. According to claim 1,
The step of performing the payment processing,
When receiving the selection of the URL from the user's terminal, providing a payment screen in which the payment information is automatically entered to the user's terminal
Payment service method characterized in that. According to claim 1,
The step of performing the identity authentication procedure is,
If the user's payment risk level is a safety level belonging to the white list, performing the payment processing without a separate authentication procedure
Payment service method characterized in that. According to claim 1,
The step of performing the identity authentication procedure is,
If the delivery address included in the payment request information is the same as the delivery address connected to the user's service account or the delivery location where the latest payment was successful, performing the payment processing without a separate authentication process
Payment service method characterized in that. According to claim 1,
The step of performing the identity authentication procedure is,
Performing primary authentication using at least one authentication method according to the user's payment risk level, or additionally performing secondary authentication using at least another authentication method together with the primary authentication
Payment service method characterized in that. According to claim 1,
The step of confirming the payment risk level is,
The payment risk using at least one of the user's past normally processed payment history, whether or not the service-only application is used, the recently successful delivery address, the mobile phone number used for payment, and the identity verification history in a specific application linked to the payment service checking the grade
Payment service method characterized in that. According to claim 1,
The step of confirming the payment risk level is,
Confirming the payment risk level using user media environment information including at least one of a payment method, terminal information, and access information used by the user in the past payment
Payment service method characterized in that. According to claim 1,
analyzing a purchase cycle for each periodic purchase product and the periodic purchase product by using the user's past payment information; and
providing a payment notification for the periodic purchase product to the user's terminal according to the purchase cycle;
A payment service method further comprising a. 10. The method of claim 9,
The step of providing the payment notification to the user's terminal comprises:
Providing a notification message including information on the periodic purchase product and a URL corresponding to payment information connected to the user's service account
Payment service method characterized in that. A computer-readable storage medium, characterized in that a program for executing the method of any one of claims 1 to 10 is recorded. at least one program loaded memory; and
at least one processor
including,
The at least one processor, according to the control of the program,
providing a uniform resource locator (URL) corresponding to payment information stored in a database connected to the user's service account on the service screen when the user's terminal enters a service screen related to a specific product; and
Upon receiving the selection of the URL from the user's terminal, the user enters the payment environment directly without going through an order form and payment information input procedure, and is stored in the database without inputting additional information about the payment information and receiving the corresponding information. Process the process of direct payment processing using the payment information in the
The process of performing the payment processing is,
By performing an independent authentication process independent of the financial company related to the payment information,
a process of confirming a payment risk level that evaluates the risk of the user's payment by using one or more of user media environment information, search, payment, transaction type information, and accident type information for the user; and
performing a self-authentication procedure for the user by applying an authentication method corresponding to the payment risk level among various authentication methods;
A payment system that includes 13. The method of claim 12,
The process of providing the URL is:
providing the URL including shipping address information linked to the user's service account;
The process of performing the payment processing is,
Directly performing payment processing using the payment information and the delivery address information
A payment system characterized by 13. The method of claim 12,
The process of performing the payment processing is,
When receiving the selection of the URL from the user's terminal, providing a payment screen in which the payment information is automatically entered to the user's terminal
A payment system characterized by 13. The method of claim 12,
The process of performing the identity authentication process is,
If the delivery address included in the payment request information is the same as the delivery address connected to the user's service account or the delivery location where the latest payment was successful, performing the payment processing without a separate authentication process
A payment system characterized by 13. The method of claim 12,
The process of performing the identity verification process is,
Performing primary authentication using at least one authentication method according to the user's payment risk level, or additionally performing secondary authentication using at least another authentication method together with the primary authentication
A payment system characterized by 13. The method of claim 12,
The process of checking the payment risk level is,
The payment risk using at least one of the user's past normally processed payment history, whether or not the service-only application is used, the recently successful delivery address, the mobile phone number used for payment, and the identity verification history in a specific application linked to the payment service checking the grade
A payment system characterized by 13. The method of claim 12,
The process of checking the payment risk level is,
Confirming the payment risk level using user media environment information including at least one of a payment method, terminal information, and access information used by the user in the past payment
A payment system characterized by 13. The method of claim 12,
The at least one processor, according to the control of the program,
analyzing a purchase cycle for each periodic purchase product and the periodic purchase product by using the user's past payment information; and
A process of providing a payment notification for the periodic purchase product to the user's terminal according to the purchase cycle
payment system that handles 20. The method of claim 19,
The process of providing the payment notification to the user's terminal is,
Providing a notification message including information on the periodic purchase product and a URL corresponding to payment information connected to the user's service account
A payment system characterized by

Images