KR102499237B1 - A method for recovering payment failure and a system therefor - Google Patents

Abstract

A method for recovering payment failure according to an embodiment of the present specification includes, when payment failure occurs in a user terminal, receiving payment failure information of the user terminal from a payment target server, payment failure based on the payment failure information. Determining the cause, generating a recovery message related to the cause of the payment failure, and transmitting the recovery message to the user terminal. The recovery message includes at least one recovery link related to a recovery operation of the payment failure, and the recovery link is linked to a dedicated page related to at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment. to be characterized
The present invention is a technology developed through "AI-based smart payment recovery solution 'Step Cover'" of the Seoul Business Agency (2020 4th Seoul Innovation Challenge Qualifier) (SC200022).

Description

A method for recovering payment failure and a system therefor}

The present invention relates to a payment failure recovery method and system for suggesting an appropriate payment recovery method according to a user's payment failure situation. More specifically, in the event of payment failure such as non-payment, it is not just a notification notification, but by analyzing the cause of non-payment and providing the most optimal payment recovery process, quickly changing the failed payment to another payment method, charging the payment method, and changing the payment date. It relates to a method and system that can quickly recover payment failure. In addition, in order to promote payment recovery, it includes a method to increase the payment recovery rate by notifying users who meet certain conditions of discounts and a function to automate the payment recovery process without human intervention by using payment recovery scenarios.

Today, with the development of the Internet and smartphones, various payment methods are being actively used. The number of simple payment methods has increased, making it more convenient for consumers to make payments and simplifying authentication and payment process steps. At the same time as simple payments are increasing, in repetitive payments and subscription services, payment failures due to simple reasons such as non-payment account for as much as 20% of average monthly sales, and payment failures are also increasing.

Payment failure means increased costs for the business. The process after payment failure, the so-called dunning process, has been used the same process without any development for 10 years. In case of non-payment, the enterprise should use the labor cost to contact the non-payment user. In addition, the dunning process involves various processes, such as: People perform various processes such as issuing bills, sending text messages requesting deposit, attempting random withdrawals, and calling by phone, which consumes expensive customer service costs.

In addition, in all processes, all customers are regarded as one, and all customers are notified and contacted in the same way at the same time or at a fixed time period and period, so the actual convenience and circumstances of customers are not promoted at all.

In addition, the payment failure and recovery process are inconvenient from the user's point of view. Current users have to recover payment through complicated processes such as 1) to 4) below.

1) Receive a payment failure notification message or phone call;

2) After accessing the service related to the failed payment, log in and perform the authentication process;

3) Access the payment recovery page;

4) Enter the payment page and complete the payment.

The above process is a very inconvenient process for the user. Such payment failure can be fatal to places such as regular payment, subscription payment, reservation payment, and CMS payment. Not only regular payments, but also regular payments and offline payments have a problem in that payment failure can lead to consumer abandonment. Accordingly, it is necessary to introduce a more progressive payment recovery method, rather than the existing dunning process, depending on the user's payment failure situation.
The present invention is a technology developed through "AI-based smart payment recovery solution 'Step Cover'" of the Seoul Business Agency (2020 4th Seoul Innovation Challenge Qualifier) (SC200022).

An object of the present invention is to improve the dunning process after payment failure to promote user convenience and corporate cost reduction through a more progressive recovery process for various payment failure situations.

Another object of the present invention is to provide a method for automating a dunning process after payment failure to reduce costs of a company and promote user convenience without human intervention.

Another object of the present invention is to personalize the process of the dunning process that everyone receives uniformly, to deliver a more suitable recovery process, and to induce a user's payment recovery rate to increase.

Another object of the present invention is to reduce the payment recovery time by simplifying the payment process when the user recovers the payment, and to promote the convenience of the user who can easily change the payment time point or replace the payment method according to the user's circumstances.

Another object of the present invention is to establish an automated recovery scenario when a user's payment is not recovered even after a payment failure to perform an automatic payment recovery process without human intervention, thereby reducing the cost of the company.

Another object of the present invention is to ultimately further activate e-commerce and general commerce by simplifying the payment recovery process like a more simplified payment process such as simple payment.

The technical problems to be achieved in this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below. You will be able to.

A method for recovering payment failure according to an embodiment of the present specification includes, when payment failure occurs in a user terminal, receiving payment failure information of the user terminal from a payment target server, payment failure based on the payment failure information. Determining the cause, generating a recovery message related to the cause of the payment failure, and transmitting the recovery message to the user terminal.

The recovery message includes at least one recovery link related to a recovery operation of the payment failure, and the recovery link is linked to a dedicated page related to at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment. to be characterized

The dedicated page may be a page indicating payment information output after user authentication is completed.

The payment failure information may include at least one of i) a payment failure code related to any one of predefined payment failure causes, ii) user information, iii) product information, iv) payment information, or v) affiliated store information. .

The payment failure code may be one of predefined payment failure codes according to the type of the payment target server.

The type of the payment target server may be determined according to the type of payment company related to the payment of the user terminal.

It may be generated based on at least one of the payment failure code, an API (Application Program Interface) related to the payment service of the payment company, or the user information.

The user information includes user identification information related to the payment failure;

The identification information of the user may include at least one of a user terminal ID, an email address, a phone number, an operating system (OS) of the user terminal, or an IP address.

The recovery link may be configured to connect the user terminal to the dedicated page on the basis that a preset condition is satisfied.

The preset condition is at least i) whether or not to read a specific mail transmitted to the e-mail address or ii) whether access environment information of the user terminal related to the recovery link matches access environment information based on the user information. can relate to one.

The recovery link may be configured to connect the user terminal to a page for performing authentication related to payment based on the fact that the preset condition is not satisfied.

The recovery message may include information related to the cause of the payment failure.

Information related to the reason for the payment failure above is i) insufficient balance, ii) insufficient card limit, iii) expiration date of card, iv) insufficient account balance, v) account transfer error, vi) payment by payment gateway (PG) error or vii) CMS (Cash Management Service) error.

The method may further include retransmitting the recovery message to the user terminal when access to the recovery link is not performed for a predetermined period of time.

A payment recovery system for performing a method for recovering payment failure according to another embodiment of the present specification controls the communication unit to transmit and receive information related to a communication unit for transmitting and receiving wireless signals and payment, and recovery for recovering the payment failure. It includes a control unit that generates a message.

The control unit receives payment failure information of the user terminal from a payment target server when payment failure occurs in the user terminal, determines the cause of payment failure based on the payment failure information, and generates a recovery message related to the cause of payment failure. and transmit the recovery message to the user terminal.

The recovery message includes at least one recovery link related to a recovery operation of the payment failure, and the recovery link is linked to a dedicated page related to at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment. to be characterized

A computer readable medium according to another embodiment of the present specification includes instructions that, when executed by an electronic device, cause the electronic device to perform an operation.

The instructions include a program code for receiving payment failure information of the user terminal from a payment target server when payment failure occurs in the user terminal, a program code for determining a cause of payment failure based on the payment failure information, the cause of payment failure, and It includes program code for generating a related recovery message and program code for transmitting the recovery message to the user terminal.

The recovery message includes at least one recovery link related to a recovery operation of the payment failure, and the recovery link is linked to a dedicated page related to at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment. to be characterized

According to the existing method, in order to recover the failed payment, the user must directly log in to the corresponding service page and go through several steps, such as performing payment-related authentication. However, according to an embodiment of the present specification, when payment failure occurs, a recovery message including a recovery link is transmitted to the user terminal. The recovery link is linked to a dedicated page related to at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment.

Since the user can access a dedicated page for payment recovery through the recovery link without going through complicated steps, user convenience for using payment related services can be improved. In addition, since failed payments can be quickly recovered through a simpler method than the existing method, costs associated with payment recovery for companies providing payment-related services can be reduced and user departure due to payment failure can be prevented.

According to an embodiment of the present specification, the recovery link is generated based on at least one of a payment failure code, an API (Application Program Interface) related to a payment service of a payment company, or user information. Thus, payment recovery can be performed in a manner more suitable for situations involving payment failure.

According to an embodiment of the present specification, the recovery link is set to connect the user terminal to the dedicated page based on a preset condition being satisfied. The preset condition is at least i) whether or not to read a specific mail transmitted to the e-mail address or ii) whether access environment information of the user terminal related to the recovery link matches access environment information based on the user information. related to one Accordingly, it is possible to minimize security risks due to omission of an existing authentication procedure related to payment recovery.

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

1 is a flowchart illustrating a payment failure recovery method according to a user's payment failure situation according to an embodiment of the present specification.
2 is a diagram illustrating payment failure information transmitted by a payment target server after payment failure according to an embodiment of the present specification.
3 is a diagram illustrating a screen related to a payment recovery service according to an embodiment of the present specification.
4 is a diagram for explaining an operation in which a payment recovery method is selected based on a payment failure code according to an embodiment of the present specification.
5 is a diagram illustrating an example of payment recovery according to an embodiment of the present specification.
6 is a diagram illustrating another example of payment recovery according to an embodiment of the present specification.
7 is a diagram illustrating another example of payment recovery according to an embodiment of the present specification.
8 is a flowchart illustrating an operation of a unique user substitute authentication process according to an embodiment of the present specification.
9 is a diagram illustrating a recovery message according to an embodiment of the present specification.
10 is a diagram illustrating an operation related to a payment date change in payment recovery according to an embodiment of the present specification.
11 is a diagram illustrating an operation related to a notification function in payment recovery according to an embodiment of the present specification.
12 is a diagram illustrating an example of an editing screen of a scenario related to generation of a recovery message according to an embodiment of the present specification.
13 is a flowchart illustrating a process of editing a scenario related to generation of a recovery message according to an embodiment of the present specification.
14 is a diagram illustrating an example of a progress status of a payment recovery scenario for each user according to an embodiment of the present specification.
15 is a flowchart for explaining a method for recovering payment failure according to an embodiment of the present specification.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings. The detailed description set forth below in conjunction with the accompanying drawings is intended to describe exemplary embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The following detailed description includes specific details for the purpose of providing a thorough understanding of the present invention. However, one skilled in the art recognizes that the present invention may be practiced without these specific details.

According to one aspect of the present invention, as a method for performing a payment recovery process after a payment failure, a bank, credit card company, PG, simple payment, PoS payment (Van payment), and other payment interworking services receiving the failure code and payment failure information from the company, generating and managing users for payment information management and analysis in the company's recovery module after receiving the information, and payment failure codes and reasons transmitted using the information A step of selecting an appropriate recovery method, a step of generating a message including a code that can create and manage a payment interlocking link that can execute the payment recovery process selected above without logging in, and a code that can change the payment date, etc.; Requesting the generated message code to be sent to the message sending server to send to the user, and requesting payment completion to the e-commerce page or payment page by the user clicking the payment recovery link in the recovery message and proceeding with payment; Or requesting convenience functions such as recharging the balance of the payment method or changing the payment date according to the user's request rather than payment recovery, recording the payment recovery completed in the user information on the e-commerce page or payment page, or requesting convenience functions There is provided a payment failure recovery method that proposes an appropriate payment recovery method according to the user's payment failure situation, comprising the step of transmitting the payment completion result to the user.

According to another aspect of the present invention, as a method for inducing repeated and periodic notification and payment recovery due to continuous payment failure, setting the message content, cycle, and time of a reservation message to be transmitted in case of payment failure; After delivery, there is provided a method of configuring an automated payment recovery system comprising the step of receiving information such as whether the corresponding message has been read, the number of times of transmission, and the transmission channel.

According to another aspect of the present invention, as a method for performing a function of inducing recovery by automatically providing a discount when a specific condition is met based on information of a requesting user, the condition for presenting a discount to a user who has failed to pay There is provided a method of configuring a customer-customized discount providing system for payment recovery, comprising the step of setting a step and the step of determining whether a discount condition exists based on the received user information.

In this specification, payment failure is due to various reasons such as insufficient card balance, insufficient card limit, expiration of card validity, insufficient account balance, CMS transfer account abnormality, and payment error of bank, card, or PG. may refer to a phenomenon in which is not completed.

Hereinafter, a payment failure recovery method and system for presenting an appropriate payment recovery method according to a user's payment failure situation according to a preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 is a flowchart illustrating a payment failure recovery method according to a user's payment failure situation according to an embodiment of the present specification. Specifically, FIG. 1 shows a flow chart of a payment failure recovery method for presenting an appropriate payment recovery method according to the user's payment failure situation.

Referring to FIG. 1, each operation of the payment recovery method will be described.

In step S110, the payment target server transmits payment failure information to the user and the payment recovery system. The payment target server may be different according to the type of payment company related to the payment related to the user's payment failure. The type of payment company may include a credit card company, a payment gateway (PG), a payment agency, or an operating company of an e-commerce site. The user may mean a user terminal. The user terminal may be a desktop or a smart phone. However, it is not limited thereto, and the user terminal may include a notebook, a tablet, and other electronic devices having a communication function.

Not only banks and credit card companies that maintain direct payment services, but also payment destination servers, which are payment methods such as PG, simple payment, and PoS, transmit information about the payment failure to merchants and users according to the payment failure situation. Detailed payment failure information is delivered to the affiliated store and a brief notification message is delivered to the user. The payment failure information received by the affiliate store may include user (buyer) information, affiliate store information, product information, and payment information.

A specific example of the payment failure information will be described with reference to FIG. 2 . 2 is a diagram illustrating payment failure information transmitted by a payment target server after payment failure according to an embodiment of the present specification. Referring to FIG. 2 , the user information may include a user name, user ID, e-mail address, payment method information, phone number, gender, address, and age. The user information may further include user additional information related to a software development kit (SDK). The user additional information may include access time and date, stay time, payment frequency, total payment amount, specific page exposure, shopping cart information, date of service, browsing information by channel, access device, and access OS (Operating System).

The affiliate store information may include an affiliate store name, an affiliate store identification ID, an affiliate store address, an affiliate store website address, and an affiliate store phone number.

The product information may include a product name, a product price, a product identification code, and a product stock quantity. At this time, the product includes not only tangible products but also service products.

The payment information may include a payment identification code (transaction identification value), a payment method identification code, a payment request amount, a payment failure code, a reason for payment failure, and an order number.

However, the payment failure information of FIG. 2 is only an example, and the payment failure information is not limited to the listed information. Specifically, the payment failure information may further include related information collected through a separate collection tool. The separate collection tool may refer to a web/app analysis service such as Google Analytics or Flurry.

On the other hand, in the case of offline payment, there may be no user information, and there may be a difference between the collected information of an e-commerce site, user information, and product information. User information for offline payment can be supplemented through a process in which an offline affiliate store utilizes user's collected information in advance or uses a separate device and device to input a channel through which the user can receive a message.

The affiliated store information informs an identifiable payment destination and, if necessary, provides access information to the affiliated store. It is possible to check which product has failed in payment through information such as product name, price, option, and identification code included in the product information.

The payment information includes a payment failure code and reason set for each payment company, a transaction identification value, and the like. This may be different depending on the structure of the payment service, and since there is no standard value, it is possible to speed up the operation of the payment recovery service by building a separate server in the recovery server and pre-saving the corresponding value.

Next, in step S120, the payment recovery system creates user information for managing the corresponding information in the recovery server based on the received information and stores it. The payment recovery system may be configured to include a communication unit for transmitting and receiving wireless signals and a control unit for controlling the communication unit to transmit and receive information related to payment and generating a recovery message for recovering the payment failure. However, the configuration of the payment recovery system is only an example, and may be implemented to include fewer or more configurations.

The reason why user information is separately stored in the payment recovery system is to provide a recovery function even for payment failure related to an e-commerce program for which a payment management service is not established. Through this, even if the corresponding e-commerce program does not support the payment recovery process or if only a general recovery system such as repeated payment attempts is established in the credit card company related to the payment failure, each user through the payment recovery method according to the embodiment of the present specification Customized alerts and payment recovery processes can be performed. The provision of an automated recovery service will be described with reference to FIG. 3 below.

3 is a diagram illustrating a screen related to a payment recovery service according to an embodiment of the present specification. Specifically, FIG. 3 shows an information providing screen for checking an automated recovery service according to an embodiment of the present invention.

Referring to FIG. 3, analysis data (e.g., name, customer segment, product name, amount, date, status) of users who have failed payment and recovery progress after failed payment are divided into stages (e.g., 1st to 4th) and displayed. .

As described above, a higher level of payment failure analysis can be provided through the storage of user information.

In step S130, the payment recovery system (eg, the control unit) generates a payment recovery message. The payment recovery message may be configured/generated with a combination of codes for presenting an appropriate and simple recovery method according to the user's payment failure situation.

To present the recovery method, the payment recovery system may operate as follows. A payment recovery system (eg, communication unit) receives payment failure information including a payment failure code. The payment recovery system derives the optimal recovery method through the payment failure code storage of the payment target server. For example, a payment recovery system (eg, a controller) may determine a cause of payment failure from a payment failure code and generate a recovery link related to the cause of payment failure. Hereinafter, the payment failure code will be described in detail with reference to FIG. 4 .

4 is a diagram for explaining an operation in which a payment recovery method is selected based on a payment failure code according to an embodiment of the present specification. Referring to FIG. 4 , payment failure codes may be defined/set differently for each payment company. For example, in the case of exceeding the limit, it may be set differently for each payment company, such as 3536, 2031, or 8326. That is, each payment company (payment target server) has a payment failure code defined/set differently.

The payment recovery system generates a recovery message indicating a payment recovery method (and an associated recovery link) based on the received payment failure code. Accordingly, a recovery message including a payment recovery method (recovery link) suitable for the corresponding payment failure may be generated for each user. Specifically, since different payment recovery methods may be selected according to payment failure codes such as A110 to A130, a more suitable payment recovery method may be presented to the user according to the reason for payment failure.

Referring to FIGS. 5 to 7 , examples of an appropriate recovery method (recovery link) delivered differently according to the user's payment failure will be described.

As an example of the present invention, when payment fails due to exceeding the limit of a credit card, a window for inputting a credit card number is immediately transmitted, so that the step of selecting a payment method can be omitted. That is, the recovery message may include a recovery link connected to a dedicated page for inputting the credit card number. It will be described with reference to FIG. 5 below.

5 is a diagram illustrating an example of payment recovery according to an embodiment of the present specification.

Specifically, FIG. 5 shows an example of a credit card number replacement screen accessed directly with a single click, omitting a payment method selection. FIG. 5 shows a screen according to a recovery link when replacement of a payment method (A120) is selected as a recovery method for credit card payment failure in FIG. 4 . That is, when the user clicks the recovery link included in the recovery message, a credit card information input window for directly replacing a payment method may be provided without other authentication or login procedures.

As another example according to the present invention, when a credit card expires or is lost, retrying payment with the same card has no recovery effect, so the payment recovery system has a recovery link linked to a window (eg, dedicated page) that can be replaced with another payment method. You can create a recovery message that includes Through this, it is possible to reduce indiscriminate retry costs and user inconvenience notification costs.

As another example according to the present invention, in case of payment failure for simple payment, a recovery message may be generated as follows, assuming that the user prioritizes using simple payment or other payment methods. The payment recovery system may generate a recovery message including a recovery link connected to a screen (or dedicated page) where various payment methods can be replaced.

6 is a diagram illustrating another example of payment recovery according to an embodiment of the present specification.

Specifically, FIG. 6 is an example of a recovery method provided when a payment failure occurs in a user terminal using simple payment (A110). When the user clicks the recovery link included in the recovery message, a screen for replacing with various payment methods may be provided. That is, the recovery link may be set to be connected to a dedicated page for selecting one of a plurality of payment methods in order to change the payment method.

As another example according to the present invention, when a payment failure occurs due to a lack of account balance, the user may be provided with an option of charging the balance or replacing a payment method. In the case of balance charging, it can be performed directly without moving between apps by utilizing open banking API and API functions of banks and card companies, reducing the user's payment recovery time.

As another example according to the present invention, when the user's credit card expiration date approaches, the payment recovery system may send a reminder message (recovery message) one month before the expiration date. The recovery message may include a recovery link to a dedicated page for direct credit card replacement. As described above, the recovery message may be delivered in advance as a notification message before payment failure occurs, and may be used as a preliminary measure for payment failure (A120 in FIG. 4).

As another example of the present invention, in order to eliminate such a payment retry, since failure may occur due to a system check time error of a credit card company, bank, etc., when the next scheduled payment date is selected, payment retry should be executed by avoiding the check can be implemented (A130 in FIG. 4). For example, the recovery message may be transmitted to the user terminal while avoiding the inspection time period. As another example, the recovery message may include a recovery link that is activated outside the inspection period, and the corresponding recovery link may be set to be connected to a dedicated page for retrying payment.

Through this, unnecessary payment retry costs of credit card companies, banks, and PG companies can be reduced. In addition, these notifications can be utilized as the following application technologies to increase the convenience of users and companies.

As an example of application of the present invention, credit card companies and banks periodically open events to provide financial benefits to promote card use, so that the highest discount among cards and payment methods owned by the user is obtained before the payment date or when payment fails. Repayment may be induced by recommending a payment method or providing information on a credit card company holding a discount event. For example, the recovery message may include a recovery link connected to a dedicated page for performing (re)payment based on a payment method that provides the largest discount among payment methods according to the user information. As another example, the recovery message may include information on a card company that provides a discount event before a payment date or when payment fails, and a recovery link for allowing payment to be made through the corresponding card company.

7 is a diagram illustrating another example of payment recovery according to an embodiment of the present specification. Specifically, FIG. 7 illustrates a screen on which card company event information is provided when payment fails through the recovery message.

As another application example of the present invention, payment recovery technology can be utilized even when payment fails in offline payment. When paying offline, it is possible to change the payment method immediately, such as paying in cash or replacing the card, but you must own a physical medium such as a card and cash. However, payment methods using smartphones and electronic methods are preferred by today's users. Therefore, even if offline payment fails, payment can be restored by sending a payment recovery message to the user and replacing the payment method. That is, the user can proceed with payment recovery without a physical medium. In the case of offline payment, user information may not be available, so in case of payment failure, collect information such as user contact information directly from the user using PoS, tablet screen, or phone number input tool, and then send a payment recovery message or manage previously collected members. You can use the program's information to deliver a payment recovery message. Also, in this case, online payment fees may be higher, so a vanless payment method linked to offline van payment or directly connected to a credit card company can be used. Alternatively, after the secondary payment method is stored in advance, when the payment fails, the stored secondary payment method is automatically replaced and payment can be made, and smart authentication can be used for user authentication.

In addition to selecting an appropriate recovery method, a payment recovery link creation process is required to create a payment recovery message. The conventional payment recovery process required cumbersome tasks such as receiving a payment failure message, entering a site, logging in, entering a payment page, and replacing a payment method. However, according to the embodiments of the present specification, payment recovery is possible through a more simplified process of receiving a payment recovery message, clicking a link in the message, and replacing a payment method.

Hereinafter, a payment progress method in which the authentication step is shortened will be described in detail. In order to shorten authentication steps such as login during payment recovery, an alternative verification method for unique users is needed. To this end, it is necessary to be able to authenticate the integrity of the unique user other than using unique values such as login ID and password.

According to an embodiment of the present specification, the e-mail and phone number previously entered by the user in the e-commerce page and member information can be used as a user-specific channel. The payment recovery system embeds and sends a specific code to the corresponding channel, and when a user action occurs for the specific code, it is regarded as a unique action in the channel owned by the user. Through identification of user behavior through the specific code, it can be determined that alternative verification (alternative authentication) for the unique user has been performed even if there is no log-in activity. The code for unique user substitution authentication can be implemented in the form of a unique link so that link clicks can be judged as a unique action. Alternatively, in the case of an e-mail, whether or not to read the e-mail may be determined as a unique action by receiving a load signal of a hidden pixel value rather than a link. Unique action authentication for a user's own channel can be seen as similar to the existing OTP text message authentication process.

In addition, if necessary, it is possible to prepare for security incidents by introducing a secondary authentication method for the above unique behavior. It may be determined that alternative authentication has been performed in the case of the same device and access environment by using the device-specific value and connection environment information used by the user to access e-commerce or a specific service. Values used for device-specific values and access environment information may include information collected through web communication, such as device ID, device OS, device language, access country using access IP, and access time. When the previous access value and the current access value are different using the above information, authentication means such as additional PIN code authentication or login may be used.

8 is a flowchart illustrating an operation of a unique user substitute authentication process according to an embodiment of the present specification.

Specifically, FIG. 8 illustrates a process for unique user authentication through an alternative authentication process without log-in.

The target location for that unique link (e.g. the recovery link) is a payment-only page where payment is available. The payment-only page may include a payment page used in an existing e-commerce site or a unique page exclusively for payment.

As in the process of FIG. 8, when a recovery message including a unique link (recovery link) is transmitted to the user terminal, and the user of the user terminal touches (clicks) the corresponding unique link, it will be considered that user-specific authentication has been completed. can Accordingly, a login procedure is omitted and a payment-only page including information that can directly lead to payment can be output to the user (ie, the user terminal can access the payment-only page). The payment-only page links APIs of payment companies, PG companies, simple payment companies, etc., so that when a link is clicked, a payment service can be entered immediately. The payment method may include cash payment, credit card payment, mobile phone payment, simple payment, CMS payment, and other electronic payment methods.

The information displayed on the payment-only page may include payment amount, payment details, payment transaction code, product code, product name, product details, product price, order number, orderer information (name, contact number, address, ID), etc. there is.

Through the above process, the user can receive a link that enables payment recovery immediately without logging in.

In step S140, the payment recovery system (eg, communication unit) transmits the generated recovery message to the user. The recovery message may be transmitted through various message channels that have been previously used. As an example of the message channel, a text message, MMS, e-mail, messenger message such as KakaoTalk, in-app push, web push notification, and the like may be included. For example, the recovery message may be sent through a separately constructed message server. As another example, the recovery message may be sent by requesting transmission to another message sending server as in step S150.

9 is a diagram illustrating a recovery message according to an embodiment of the present specification. Specifically, FIG. 9 illustrates a payment recovery message sent to KakaoTalk Messenger AlimTalk.

In step S160, the user performs direct payment by clicking the recovery link of the received recovery message. In the next step (S170), the user requests payment progress to the payment target server.

In step S180, the payment target server transmits information related to payment completion to the payment recovery system. The payment recovery system will record the payment recovery completion. The pre-payment completion record may use different information for each e-commerce program used by the affiliate store, PoS management program, and programs managed by electronic media, but may include the following basic information. Payment recovery records include payment product, payment method, replacement method, payment amount, payment time, payment unique transaction code, product code, product name, product details, product price, order number, orderer information (name, contact number, address, ID) ) and the like. Programs managed by most electronic media return to the order completion process on the existing system when payment recovery is completed.

Finally, in step S190, the payment recovery system delivers information about the payment recovery completion result to the user. This process can be replaced with the payment completion notification process of the merchant's e-commerce program and PoS management program.

As an example of the present invention, the user may select a convenience function such as payment date change rather than payment recovery. User-friendly features may include changing payment dates, receiving notifications later, and pausing payments. The user can make reasonable and planned consumption according to his or her financial situation through this convenience function, and the affiliate store can reduce the cost consumption for dunning without missing the customer.

Hereinafter, the user's use of a user convenience function other than payment recovery will be described in detail with reference to FIGS. 10 and 11 . The code used to generate the payment recovery link may include functions such as payment recovery, payment date change, notification later, and payment pause request.

First, the payment date change function allows the merchant to designate a range of allowable dates that can be changed when payment fails to the user. For example, if an affiliate designates a payment date change date of 30 days, the user can use the existing service as it is or receive a product or service after payment is completed if the payment is restored within 30 days from the date of payment failure.

10 is a diagram illustrating an operation related to a payment date change in payment recovery according to an embodiment of the present specification. Specifically, FIG. 10 shows a screen providing information for a user to designate a change date after selecting a payment date change function. The user can directly input a date to be changed, or designate a payment change date such as 3 days later through numeric input, or designate a date by directly looking at a calendar using a calendar display screen.

11 is a diagram illustrating an operation related to a notification function in payment recovery according to an embodiment of the present specification. In detail, FIG. 11 shows a screen for receiving snooze message information at a time changed to a notification later function. The user can proactively use the notification message re-delivery function, so the user's convenience can be promoted. In the screen shown in FIG. 11, a transmission function after a specific time is provided in advance to increase user convenience, but the user may directly set the recovery message snoozing time using a separate numeric input value field.

The payment suspension function is a way for affiliates to temporarily suspend existing customers without missing them because the cost of attracting new customers is higher than the cost of retaining existing customers. Users may not receive payment attempts or notification messages during the payment suspension period. Merchants can set the maximum period and number of payment pauses and notify users. Accordingly, it is possible to prevent the user from unreasonably extending or abusing the pause period. The payment pause function is more suitable for services such as recurring payments, subscription payments, and regular payments, and can be used in various ways depending on the content of the business.

As another example of the present invention, the affiliate store may set a payment recovery scenario in advance to automate the payment recovery process and automatically perform the recovery process without human intervention. The purpose of the payment recovery scenario function is to set a cycle when a user's continuous payment failure occurs, deliver a payment recovery message, and put a different payment recovery message in each message to facilitate the user's payment recovery.

The payment recovery scenario consists of the payment recovery attempt setting value and the payment recovery message, and the setting for this can be performed by the merchant himself or by selecting a pre-made scenario. In addition, in the payment recovery scenario, all customers can receive a payment recovery message according to one scenario through the entire set value (global setting value) set by the merchant, and different scenarios depending on gender, age group, membership level, number of purchases, usability, etc. may be set and payment recovery may be performed accordingly.

The payment recovery attempt settings of the payment recovery scenario consist of the maximum number of recovery message transmissions, transmission period, transmission day, transmission time, and transmission channel. The maximum number of transmissions may mean the maximum number of transmissions of messages to be transmitted after considering payment failure as the start of scenario execution. For example, if the merchant sets the number of transmissions up to 10 times as the maximum number of transmissions, the recovery message is delivered to the user up to 10 times according to the corresponding payment recovery scenario. The transmission period means a period between transmission of each message, which can be set differently for each message. For example, it is possible to set the cycle such that the first message is sent after 3 days, the second message is sent after 5 days, and the third message is sent after 10 days. The delivery day and time can be sent by designating a specific day and time or excluding a specific day and time. For example, Sundays may be excluded from transmission days so as not to interfere with users' holidays. The transmission channel may include the aforementioned message channels (text message, MMS, e-mail, messenger message such as KakaoTalk, in-app push, web push notification, etc.). As the transport channel, the affiliate store's most preferred transport channel and secondary auxiliary channel may be selected. For example, if the merchant selects KakaoTalk AlimTalk as the 1st channel and text message as the 2nd channel, the 2nd scenario (2nd recovery message) is sent by text message.

Next, the number of payment recovery messages according to the payment recovery scenario is determined according to the maximum number of transmissions set by the merchant in the payment recovery attempt setting value. For example, if the maximum number of times is set to 10, 10 payment recovery messages are generated. Each of the payment recovery messages can be edited so that different contents can be sent for each message.

12 is a diagram illustrating an example of an editing screen of a scenario related to generation of a recovery message according to an embodiment of the present specification. Specifically, FIG. 12 illustrates an editing screen of a payment recovery message in which the maximum number of transfers is set to three. 12 is an example of a screen configuration designed to simplify payment recovery scenario settings and to be easily applied by non-experts. Accordingly, the merchant can send a characteristic message by taking advantage of the nature of the business, and can induce payment recovery by changing the contents of the message as the number of payment recovery increases.

13 is a flowchart illustrating a process of editing a scenario related to generation of a recovery message according to an embodiment of the present specification. Specifically, FIG. 13 shows a GUI editing tool that allows more professional marketers to set and send detailed sending conditions. The function of the corresponding GUI editing tool may include a function of subdividing the above payment recovery attempt settings and visually adding them step by step. The corresponding setting value can be added/modified later. The corresponding setting value may include information on delivery conditions. The information on the delivery condition may be related to any one of whether or not a link in the message is clicked, waiting time, transmission channel setting, payment recovery scenario selection, or whether each channel is opened. In addition, web collection data additionally collected through SDK can be set as a delivery condition. You can add conditions to classify users who have signed up for 30 days or more, users who have purchased a specific item, and so on.

As another example of the present invention, payment recovery may be promoted by providing a discount to a specific user when payment fails. This discount providing function can use the discount function of the e-commerce program used by the merchant or the PoS management program, and can send a discount coupon enclosed in a message in a specific payment failure scenario step as shown in step B110 of FIG. 13. .

14 is a diagram illustrating an example of a progress status of a payment recovery scenario for each user according to an embodiment of the present specification. Specifically, FIG. 14 illustrates a screen providing individual user information in which an automated payment recovery scenario is being executed. Referring to FIG. 14 , the affiliate store can check restoration scenarios in progress for each individual user and can manipulate whether or not to execute each recovery scenario. Through this, merchants can check the automated payment recovery process of individual users and directly intervene in the middle to present more suitable customer services to users. In addition, by introducing a filtering function to the list of users whose payment recovery process is in progress, affiliates can separately classify users who have failed to pay by company. For example, an affiliate store that executes a total of 5 payment recovery scenarios can classify unrecovered users even after the 5 payment recovery scenarios have been executed and directly perform phone CS only for the corresponding customers. Through this, the franchisee can save a significant amount of the CS that was previously executed by a person directly and execute it only to the necessary customers.

Embodiments of the invention include computer-readable media containing various computer-based programs and program instructions. Computer-readable media include hardware devices that store and execute specific program instructions, such as hard disks, CD-Roms, DVDs, and ROMs, RAMs, and flash memories. Program instructions also include language codes that can be executed on a computer along with various machine language codes.

The present invention is designed with a structure that can operate inclusive of all cases where a failure occurs when attempting payment in an online or offline situation. Accordingly, it is a structure that can be applied to payment failure signals and payment methods of various payment means and payment servers and can be operated. In the case of direct payment, such as credit card companies and PG companies, the technology can be applied to the payment server side to be used as a payment recovery function, and payment interlocking services can also be used as a payment recovery function through a process such as API interworking. Executors attempting conventional recurring payments are not performed by specific card companies and PG companies. Repetitive payment or reservation payment is performed by a signal from an affiliated store system such as an e-commerce page, and the corresponding technology operates appropriately for this structure. The technology includes a method of executing a specific command for executing payment including a billing key structure responsible for repeated payment attempts by the affiliated store system. In addition, it can be operated regardless of the location of the server where the billing key is stored, so it is designed in a structure that can be used even if the merchant directly stores the billing key or a payment agency and recovery server on behalf of the merchant store the billing key. It can be used flexibly for various payments.

Hereinafter, a method for recovering payment failure in terms of the operation of the payment recovery system based on the embodiments described above with reference to FIGS. 1 to 14 will be described in detail with reference to FIG. 15 .

15 is a flowchart for explaining a method for recovering payment failure according to an embodiment of the present specification.

Referring to FIG. 15 , the method for recovering payment failure according to an embodiment of the present specification includes a payment failure information receiving step (S1510), a payment failure cause determination step (S1520), a recovery message generation step (S1530), and a recovery message A transmission step (S1540) may be included.

As described above, the payment recovery system may be implemented in various configurations, but for convenience of explanation, a recovery message for controlling the communication unit to transmit and receive information related to the communication unit and payment related to transmission and reception of wireless signals and recovering the payment failure. It will be described assuming that it is implemented to include a control unit that generates.

In S1510, when payment failure occurs in the user terminal, the controller receives payment failure information of the user terminal from the payment target server. Specifically, the control unit controls the communication unit to receive the payment failure information from the payment target server.

According to an embodiment, the payment failure information includes at least one of i) a payment failure code related to any one of predefined payment failure causes, ii) user information, iii) product information, iv) payment information, or v) affiliated store information. may include one (see FIG. 2).

The payment failure code may be one of predefined payment failure codes according to the type of the payment target server (see FIG. 4). The type of the payment target server may be determined according to the type of payment company related to the payment of the user terminal.

According to an embodiment, the user information may include user identification information related to the payment failure. The identification information of the user may include at least one of a user terminal ID, an email address, a phone number, an operating system (OS) of the user terminal, or an IP address. The user information may include the user information of FIG. 2 and additional user information.

In S1520, the controller determines the cause of payment failure based on the payment failure information. The payment failure cause may be determined based on the payment failure code.

In S1530, the control unit generates a recovery message related to the cause of the payment failure.

According to one embodiment, the recovery message may include at least one recovery link related to a recovery operation of the payment failure. The recovery link may be set to be connected to a dedicated page related to at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment.

According to an embodiment, the dedicated page may be a page indicating payment information output after user authentication (eg, user login, payment-related authentication, etc.) is completed. That is, through the recovery link, the user can recover the payment through a simplified procedure without going through login or other authentication.

According to an embodiment, the recovery link may be generated based on at least one of the payment failure code, an API (Application Program Interface) related to the payment service of the payment company, or the user information.

According to an embodiment, the recovery link may be configured to connect the user terminal to the dedicated page based on a pre-set condition being satisfied. This embodiment may be based on the operation related to FIG. 8 .

The preset condition is at least i) whether or not to read a specific mail transmitted to the e-mail address or ii) whether access environment information of the user terminal related to the recovery link matches access environment information based on the user information. can relate to one.

The recovery link may be configured to connect the user terminal to a page for performing authentication related to payment based on the fact that the preset condition is not satisfied.

According to one embodiment, the recovery message may include information related to the cause of the payment failure. Information related to the reason for the payment failure above is i) insufficient balance, ii) insufficient card limit, iii) expiration date of card, iv) insufficient account balance, v) account transfer error, vi) payment by payment gateway (PG) error or vii) CMS (Cash Management Service) error.

Steps S1520 and S1530 may be performed as one step. That is, the control unit may generate the recovery message based on the payment failure information.

In S1540, the control unit transmits the recovery message to the user terminal. Specifically, the controller controls the communication unit to transmit the recovery message to the user terminal.

The method may further include sending the repair message again. Specifically, in the above step, the control unit transmits the recovery message to the user terminal again when access to the recovery link is not performed for a predetermined period. Retransmission of the recovery message may be performed based on the above-described recovery scenario.

The embodiments described above are those in which elements and features of the present invention are combined in a predetermined form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented in a form not combined with other components or features. In addition, it is also possible to configure an embodiment of the present invention by combining some components and/or features. The order of operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment, or may be replaced with corresponding components or features of another embodiment. It is obvious that claims that do not have an explicit citation relationship in the claims can be combined to form an embodiment or can be included as new claims by amendment after filing.

An embodiment according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In the case of hardware implementation, one embodiment of the present invention provides one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, etc.

In the case of implementation by firmware or software, an embodiment of the present invention may be implemented in the form of a module, procedure, or function that performs the functions or operations described above. The software code can be stored in memory and run by a processor. The memory may be located inside or outside the processor and exchange data with the processor by various means known in the art.

It is apparent to those skilled in the art that the present invention can be embodied in other specific forms without departing from the essential characteristics of the present invention. Accordingly, the foregoing detailed description should not be construed as limiting in all respects and should be considered illustrative. The scope of the present invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the present invention are included in the scope of the present invention.

Claims (15)

In the method for recovering payment failure,
When payment failure occurs in the user terminal, receiving payment failure information and user information of the user terminal from a payment target server;
determining a cause of payment failure based on the payment failure information;
In order to replace user authentication in the user terminal, determining whether a user substitution authentication condition is satisfied;
generating a recovery message related to the cause of the payment failure; and
Transmitting the recovery message to the user terminal,
The user substitution authentication condition is i) whether or not a specific mail transmitted to the e-mail address included in the user information is read or ii) access environment information of the user terminal related to the recovery message is based on the user information contains at least one of whether or not matches
The recovery message includes at least one recovery link related to a recovery operation of the payment failure;
The recovery link is characterized in that it is set to connect the user terminal to a dedicated page without the user authentication procedure based on the satisfaction of the user substitution authentication condition,
The method for recovering from payment failure, characterized in that the dedicated page is related to at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment. delete According to claim 1,
The payment failure information includes at least one of i) a payment failure code related to any one of predefined payment failure causes, ii) product information, iii) payment information, or iv) affiliated store information. way to recover. According to claim 3,
The method for recovering from payment failure, characterized in that the payment failure code is one of predefined payment failure codes according to the type of the payment target server. According to claim 4,
The method for recovering payment failure, characterized in that the type of the payment target server is determined according to the type of payment company related to the payment of the user terminal. According to claim 5,
The recovery link is
The method for recovering payment failure, characterized in that generated based on at least one of the payment failure code, an API (Application Program Interface) related to the payment service of the payment company, or the user information. According to claim 1,
The user information includes at least one of a user terminal ID, a phone number, an operating system (OS) of the user terminal, or an IP address. delete delete According to claim 1,
The recovery link is
The method for recovering from payment failure, characterized in that it is set to connect the user terminal to a page for performing the user authentication based on the fact that the user substitution authentication condition is not satisfied. According to claim 1,
The method for recovering from payment failure, characterized in that the recovery message includes information related to the cause of the payment failure. According to claim 11,
Information related to the cause of the payment failure,
i) Insufficient balance, ii) Insufficient card limit, iii) Expiration of card validity, iv) Insufficient account balance, v) Account transfer error, vi) Payment error by Payment Gateway, or vii) CMS (Cash Management) Service) method for recovering from payment failure, characterized in that it indicates at least one of the errors. According to claim 1,
and re-transmitting the recovery message to the user terminal when access to the recovery link is not performed for a predetermined period of time. In a payment recovery system that performs a method for recovering payment failure,
Communication unit for transmitting and receiving radio signals; and
A control unit controlling the communication unit to transmit/receive information related to payment and generating a recovery message for recovering the payment failure;
The control unit,
When payment failure occurs in the user terminal, receiving payment failure information and user information of the user terminal from the payment target server;
Determine the cause of payment failure based on the payment failure information;
In order to substitute user authentication in the user terminal, it is determined whether the user substitution authentication condition is satisfied,
generating a recovery message related to the cause of the payment failure;
It is set to transmit the recovery message to the user terminal,
The user substitution authentication condition is i) whether or not a specific mail transmitted to the e-mail address included in the user information is read or ii) access environment information of the user terminal related to the recovery message is based on the user information Associated with at least one of whether or not it matches,
The recovery message includes at least one recovery link related to a recovery operation of the payment failure;
The recovery link is characterized in that it is set to connect the user terminal to a dedicated page without the user authentication procedure based on the satisfaction of the user substitution authentication condition,
The payment recovery system, characterized in that the dedicated page is related to at least one operation of charging amount, changing payment date, changing payment method or retrying payment. A computer-readable medium containing instructions that, when executed by an electronic device, cause the electronic device to perform an operation,
These commands are
Program code for receiving payment failure information and user information of the user terminal from a payment target server when payment failure occurs in the user terminal;
Program code for determining a cause of payment failure based on the payment failure information;
Program code for determining whether a user substitution authentication condition is satisfied in order to replace user authentication in the user terminal;
Program code for generating a recovery message related to the cause of the payment failure; and
Including program code for transmitting the recovery message to the user terminal,
The user substitution authentication condition is i) whether or not a specific mail transmitted to the e-mail address included in the user information is read or ii) access environment information of the user terminal related to the recovery message is based on the user information Associated with at least one of whether or not it matches,
The recovery message includes at least one recovery link related to a recovery operation of the payment failure;
The recovery link is characterized in that it is set to connect the user terminal to a dedicated page without the user authentication procedure based on the satisfaction of the user substitution authentication condition,
The computer-readable medium, characterized in that the dedicated page is associated with at least one operation of charging money, changing a payment date, changing a payment method, or retrying payment.

Images