US-20260127617-A1 - SYSTEM AND METHOD FOR MAKING PURCHASE PAYMENTS AFTER PAYMENT FAILURES

US20260127617A1US 20260127617 A1US20260127617 A1US 20260127617A1US-20260127617-A1

Abstract

When a loan payment failure occurs, a loan server can retry a payment from a client's financial institution sources rather than immediately charging the client for the payment failure. The payment retry is scheduled on a Friday that is at least three days after the payment failure. If a payment failure from the financial institution sources to the loan server occurs between a Friday and the following Monday the payment retry by the loan server to the financial institution sources will occur on the first following Friday and if the payment failure occurs on Tuesday, Wednesday or Thursday, the payment retry will occur on the second following Friday which is the Friday of the following week from the failure date.

Inventors

Youyou Yang
Daniel Kaufman
Edward Oistacher

Assignees

AFFIRM, INC.

Dates

Publication Date: 20260507
Application Date: 20251222

Claims (18)

1 . A server for managing payment rescheduling associated with a loan of a buyer to be repaid via a financial source associated with the buyer, the server comprising: a memory storing a rule table and program instructions; a high-speed communication interface operably coupling the server to an external communication port to enable the server to communicate with external devices including a buyer computing device and a financial source computing device via wired or wireless communication; and a processor configured to execute the program instructions and manage message processing for inbound and outbound messages via the high-speed communication interface, wherein the program instructions, when executed by the processor, configure the server to: receive an inbound message from the financial source computing device providing notice of a failed payment on a failure date, the failed payment being a scheduled payment from the financial source associated with the loan, determine whether a payment retry condition is satisfied, determine a payment retry date based on the rule table in response to the payment retry condition being satisfied, and communicate the payment retry date as an outbound message to the buyer computing device via the external communication port, wherein the payment retry date is determined based on comparing a recurring predetermined preferred payment date to the failure date and selecting a next instance of the recurring predetermined preferred payment date that is greater than a minimum delay period from the failure date, wherein the outbound messages include a message provided to the buyer computing device to direct the buyer computing device to display a retry cancel button, the retry cancel button being selectable by the buyer to cancel the payment retry date, wherein the program instructions further configure the server to add the failed payment to a tracked number of prior failed payments associated with the loan to determine a total number of failed payments, wherein the payment retry condition comprises a retry limit, wherein the payment retry condition is satisfied responsive to the total number of failed payments being less than the retry limit, and wherein the payment retry condition comprises the failure date being within a predetermined time period.
2 . The server of claim 1 , wherein the payment retry condition comprises the failed payment being determined to be associated with a scheduled payment or an autopay function.
3 . The server of claim 1 , wherein the recurring predetermined preferred payment date is Friday, and wherein the minimum delay period is three days.
4 . The server of claim 1 , wherein the recurring predetermined preferred payment date is the 15th day of a month or a last day of the month, and wherein the minimum delay period is three days.
5 . The server of claim 1 , wherein outbound messages further include instructions to the buyer computing device to direct the buyer computing device to remove the retry cancel button within a predetermined time before the payment retry date to remove an ability of the buyer to cancel the payment retry date.
6 . The server of claim 1 , further comprising modifying the communicating the payment retry date to include a suggested resolution to the buyer along with the payment reentry date.
7 . The server of claim 1 , wherein the program instructions include instructions to modify the determining the payment retry date based on an error code.
8 . The server of claim 7 , wherein modifying the determining the payment retry date comprises determining no payment retry date and canceling the communicating the payment retry date based on the error code.
9 . The server of claim 1 , wherein the rule table is constructed based on research regarding characteristics of consumers.
10 . The server of claim 1 , wherein the program instructions further configure the server to conduct a payment retry on the payment retry date via the financial source.
11 . The server of claim 10 , wherein the program instructions further configure the server to check a status of the loan after the communicating the payment retry date and prior to the payment retry date, and cancel the payment retry based on the status of the loan.
12 . The server of claim 11 , wherein the status of the loan indicates a change in a loan amount since the failure date.
13 . The server of claim 10 , wherein the program instructions further configure the server to communicate with the financial source computing device to check a balance of an account of the buyer at the financial source after the communicating the payment retry date and prior to the payment retry date, and cancel the payment retry based on the balance of the account.
14 . The server of claim 1 , wherein the program instructions further configure the server to conduct a payment retry on the payment retry date via a first financial instrument associated with the buyer.
15 . The server of claim 14 , wherein the program instructions further configure the server to conduct an additional payment retry on the payment retry date via a second financial instrument associated with the buyer.
16 . The server of claim 15 , wherein the program instructions further configure the server to conduct a payment retry on the payment retry date, and schedule a subsequent retry date if the payment retry is not successful on the payment retry date.
17 . The server of claim 16 , wherein the program instructions further configure the server to limit a number of retries per payment instrument in a given period of time.
18 . The server of claim 16 , wherein the program instructions further configure the server to limit a number of retries in a given period of time.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. patent application Ser. No. 18/590,209 filed Feb. 28, 2024, which is a continuation of U.S. patent application Ser. No. 17/841,216 filed Jun. 15, 2022 (now patented as U.S. Pat. No. 11,948,152 which issued Apr. 2, 2024), which is a continuation of U.S. patent application Ser. No. 16/244,062 filed Jan. 9, 2019 (now patented as U.S. Pat. No. 11,397,951 which issued on Jul. 26, 2022), which claims priority to U.S. Provisional Patent Application No. 62/615,153, “System And Method For Making Payments After Payment Failures” filed on Jan. 9, 2018 which is hereby incorporated by reference in its entirety. BACKGROUND When customers make purchases from merchants, the typical transaction involves selecting the goods or services and paying for them with traditional means such as cash, checks, and fund transfers. For some larger purchases, a consumer may require multiple payments to pay for the purchases. A consumer may make monthly payments until the loan amount is paid off. These payments may include loan interest payments. When there is a payment failure, many loan providers issue late fees for these payment failures. These late fees can be very unpopular to consumers. What is needed is an alternative system and method for automatically obtaining payments after a payment failure without charging late fees to customers. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 illustrates a block diagram of a computer system for making purchase payments. FIG. 2 illustrates an embodiment of a user interface on a computing device showing a payment failure message. FIG. 3 illustrates an embodiment of a user interface on a computing device showing a payment retry failure message. FIG. 4 illustrates an embodiment of a user interface on a computing device showing a payment retries canceled message. FIG. 5 illustrates an embodiment of a user interface on a computing device showing a payment retries canceled message. FIG. 6 illustrates a block diagram of a computer system for making purchase payments after payment failures. DETAILED DESCRIPTION Mobile computing payment systems such as Affirm have made it easier for system users to purchase goods without cash or credit cards. With reference to FIG. 1, a payment system can include a computer loan system server 101 that provides an online payments system for purchasing goods by users' computing device 103. The payment loan system server 101 can communicate and transfer funds with financial institution servers 105 of the loan holders and loan holder users computing devices 103. The loan system server 101 can run software that provides the financial services through a network to system users through the user computing devices running payment software such as app software running on a mobile computing devices 103. The computing device software can be configured by system users through a software user interface. Alternatively, the user's computing device 103 can have an Internet browser program which can access a user portal to communicate with the loan system server 101. The user computing device can have a login screen to access the user's data stored on the loan system server 101. Users can use the app software on the computing device 103 to take out loans from a loan system server 101 to pay a merchant or service provider for goods or services at a point of sale (POS) computing device 105 which can communicate with a merchant server 107. The user can receive the goods or services and the user's computing device 103 can instruct their bank or other financial source 109 to make payments to the loan system server 101 to pay off the loan for the received goods or services. In general, the loans can be configured with payments made to the loan system server 101 on specific time intervals such as monthly (or other time increment) payments from the financial source 109 which can be a bank. The financial source 109 can be instructed to make scheduled payments on designated dates from the users account by utilizing and actuating auto pay (or future pay) payment controls on the user's mobile computing device 103. The auto pay can use financial information such as checking account, savings account, or debit card as a source of funds for the financial source 109 to pay the loan server 101. In traditional credit card system, the loan server can be a credit card company (e.g., VISA, MasterCard, Discover) and the scheduled payments for the loan can be automatically made from the financial source 109 (user's bank) to the credit card company loan server. However, problems can arise when there are insufficient funds at the financial source 109 to make the payments to the credit card company's loan server. If there are insufficient funds at the financial source 109 the scheduled payment is not made and there can be financial penalties for insufficient funds for the user from both the financial source 109 and the credit card company