AU2022332709A1

AU2022332709A1 - Methods and systems for resolving transactions

Info

Publication number: AU2022332709A1
Application number: AU2022332709A
Authority: AU
Inventors: Jacques Botes; Craig Cameron; Andrew Ellett; Chris Newton; Ana Petreska; Chanmony Tha; Jonathan Thia; Rowan Wilde
Original assignee: Helppay Pty Ltd
Current assignee: Helppay Pty Ltd
Priority date: 2021-08-25
Filing date: 2022-08-25
Publication date: 2024-03-14
Also published as: WO2023023782A1

Abstract

Embodiments generally relate to a method for facilitating a transaction. The method comprises receiving, from a payor device, a request to access payment data; checking access data associated with the payment data; based on the access data indicating that the payment data is accessible, updating the access data to indicate that the payment data is not accessible and subsequently providing the payment data to the payor device; receiving payment details generated at the payor device in response to receiving the payment data; causing a payment to be processed based on the received payment details; and in response to the payment being processed, further updating the access data to indicate that the payment data is accessible.

Description

"Methods and systems for resolving transactions"

Technical Field

Embodiments generally relate to methods, systems and devices for resolving transactions. Specifically, embodiments relate to methods, systems and devices for resolving electronic transactions involving multiple transacting parties.

Background

It is often desirable to have multiple parties contribute to certain payments. For example, where multiple people share a residence, they may wish to all contribute to the payment of bills for rent and utilities. Alternatively, some people may require assistance in payment of their bills from their family and friends.

When it is desirable to split the payment of a bill, the recipient of the bill may calculate the amount owing by each payor and ask them to pay the amount to the recipient’s account, so the recipient can settle the balance of the bill. However, the payors may not be sure that their payment is going to the payment of the bill, as opposed to the payee’s personal bank account. Alternatively, the recipient may ask each payor to contribute to the bill directly, by providing them with payment details. However, where multiple transacting parties are involved, they may not know how much has already been contributed and the bill may be overpaid or underpaid.

It is desired to address or ameliorate one or more shortcomings or disadvantages associated with prior devices and methods for resolving electronic transactions involving multiple transacting parties, or to at least provide a useful alternative thereto.

Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. In this document, a statement that an element may be “at least one of’ a list of options is to be understood to mean that the element may be any one of the listed options, or may be any combination of two or more of the listed options.

Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.

Summary

Some embodiments relate to a method for facilitating a transaction, the method comprising: receiving, from a payor device, a request to access payment data; checking access data associated with the payment data; based on the access data indicating that the payment data is accessible, updating the access data to indicate that the payment data is not accessible and subsequently providing the payment data to the payor device; receiving payment details generated at the payor device in response to receiving the payment data; causing a payment to be processed based on the received payment details; and in response to the payment being processed, further updating the access data to indicate that the payment data is accessible.

Some embodiments further comprise: based on the access data indicating that the payment data is not accessible, providing an error to a second payor device notifying the second payor device that the payment data is not accessible. According to some embodiments, the access data stores information indicating whether the payment data is currently being accessed, where the access data indicates that the payment data is accessible when the payment data is not currently being accessed, and the access data indicates that the payment data is not accessible when the payment data is currently being accessed.

In some embodiments, the access data comprises an access flag. In some embodiments, the access flag is set when the payment data is being accessed, and cleared when the payment data is not being accessed.

According to some embodiments, the payment data corresponds to a bill. According to some embodiments, the payment data comprises a web page hosting information associated with a bill. In some embodiments, providing the payment data to the payor device causes the payor device to display the web page data within a browser application. In some embodiments, providing the payment data to the payor device causes the payor device to display the web page data within a native application.

According to some embodiments, the payment data comprises information associated with a bill. In some embodiments, the information associated with the bill comprises a remaining bill amount. In some embodiments, in response to the payment being processed, the remaining bill amount is updated by subtracting the payment amount from the remaining bill amount to produce an updated remaining bill amount.

According to some embodiments, prior to causing a payment to be processed, a payment amount is determined based on the received payment details and the payment amount is compared to a remaining bill amount.

Some embodiments further comprise, upon determining that the payment amount is higher than the remaining bill amount, automatically adjusting the payment amount to be equal to the remaining bill amount. In some embodiments, the request to access the payment data is sent by the payor device in response to the payor device attempting to access a URL associated with the payment data. In some embodiments, the URL is provided to the payor device by a message sent on behalf of a bill recipient via a bill recipient computing device. According to some embodiments, the message is generated by a bill management application executing on the bill recipient computing device. In some embodiments, the message is generated by the bill management application in response to a user of the bill recipient computing device requesting assistance with a bill. In some embodiments, the message is generated by the bill management application in response to a bill being uploaded that is associated with the payor device. In some embodiments, the association is based on the payor having indicated that bills issued by a particular bill issuer to the bill recipient should automatically be forwarded to the payor device.

According to some embodiments, providing the payment data to the payor device causes the payor device to communicate the payment data to a user of the payor device via a user interface.

According to some embodiments, the payment data comprises information generated based on bill data retrieved from a computing system associated with a bill issuer. In some embodiments, the bill data is automatically retrieved from the computing system associated with the bill issuer via an API.

In some embodiments, the payment data comprises information generated based on bill data entered by a user of a bill recipient device. According to some embodiments, the bill data entered by a user comprises a biller identification number, and wherein the method further comprise verifying that the biller identification number corresponds to a valid biller.

Some embodiments relate to a device comprising: a memory storing executable code; a processor configured to access the memory to execute the executable code; wherein when executing the executable code, the processor is caused to perform the method of some other embodiments.

Some embodiments relate to a computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the method of some other embodiments.

Brief Description of Drawings

Embodiments are described in further detail below, by way of example and with reference to the accompanying drawings, in which:

Figure 1 shows a schematic diagram of a system for resolving electronic transactions according to some embodiments;

Figure 2 shows a flowchart illustrating a method of facilitating transactions between multiple transacting parties as performed by the system of Figure 1;

Figure 3 shows a flowchart illustrating a method of paying a bill as facilitated by the system of Figure 1 ;

Figure 4 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a login process of a bill management application;

Figure 5 shows a further screenshot shown to a user of the bill recipient device of Figure 1 during a login process of a bill management application;

Figure 6 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a registration process of a bill management application;

Figure 7 shows a screenshot of a home screen of a bill management application shown to a user of the bill recipient device of Figure 1;

Figure 8 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a bill adding process of a bill management application;

Figure 9 shows a further screenshot shown to a user of the bill recipient device of Figure 1 during a bill adding process of a bill management application;

Figure 10 shows a screenshot of a bill management screen of a bill management application shown to a user of the bill recipient device of Figure 1; Figure 11 shows a screenshot shown to a user of the bill recipient device of Figure 1 during a process of requesting assistance with a bill using a bill management application;

Figure 12 shows a further screenshot shown to a user of the bill recipient device of Figure 1 during a process of requesting assistance with a bill using a bill management application;

Figure 13 shows a screenshot shown to a user of the payor device of Figure 1 during a process of attempted bill payment using a bill management application;

Figure 14 shows a further screenshot shown to a user of the payor device of Figure 1 during a process of attempted bill payment using a bill management application;

Figure 15 shows a further screenshot shown to a user of the payor device of Figure 1 during a process of attempted bill payment using a bill management application;

Figure 16 shows a screenshot shown to a user of the payor device of Figure 1 after a successful bill payment using a bill management application; and

Figure 17 shows a computing device according to some embodiments.

Detailed Description

Figure 1 shows a transaction system 100 according to some embodiments. Transaction system 100 may allow a bill recipient to share the payment of one or more bills between one or more payors. In some embodiments, transaction system 100 may allow a bill recipient to share the payment of one or more bills with any number of payors, who may each be able to select whether or not to contribute to the bill, and how much, if any, funds to contribute. According to some embodiments, the system 100 may allow the payors to remain anonymous to each other and/or to the bill recipient, so that each payor and/or the bill recipient is unaware of who else has contributed, or how much each payor has contributed. Due to the fact that any number of payors can contribute any amount to the bill, it is not necessary for the bill recipient to work out the number of payors who should contribute or an amount that each payor should contribute, such as by splitting the bill between a known number of payors. Instead, system 100 allows a series of payors to sequentially contribute to a single bill without overpaying, as described below.

Transaction system 100 includes a bill recipient device 110 in communication with a transaction facilitation server system 130, over a network 120. Transaction system 100 may further include at least one biller server system 140., and at least one payor device 150.

Bill recipient device 110 may be a smart phone, tablet, laptop, PC or other computing device. Bill recipient device 110 comprises a processor 111 and a memory 113 accessible to processor 111. Processor 111 may be configured to access data stored in memory 113, to execute instructions stored in memory 113, and to read and write data to and from memory 113. Processor 111 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.

Memory 113 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 113 may be configured to store executable applications for execution by processor 111. For example, memory 113 may store at least one bill management application 114 configured to allow a user to manage their bills, and to share their bills with multiple payors. According to some embodiments, bill management application 114 may be a native application. According to some embodiments, bill management application 114 may be a browser application configured to perform bill management functions via a web based platform.

Bill recipient device 110 further comprises user input and output peripherals 116 to allow a user to communication with bill recipient device 110. User I/O 116 may comprise a display screen 117, which may be a touchscreen display, as well as one or more of a keyboard, a mouse, a camera, a microphone, a speaker, buttons, sliders, and LEDs.

To facilitate communication with remote devices, bill recipient device 110 further comprises a communications module 112. Communications module 112 may allow for wired and/or wireless communication between bill recipient device 110 and external computing devices and components. Communications module 112 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 112 may facilitate communication with external devices and systems, such as transaction facilitation server system 130, via network 120.

Network 120 may comprise one or more local area networks or wide area networks that facilitate communication between elements of system 100. For example, according to some embodiments, network 120 may be the internet. However, network 120 may comprise at least a portion of any one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, some combination thereof, or so forth. Network 120 may include, for example, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a packet- switched network, a circuit- switched network, an ad hoc network, an infrastructure network, a public- switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fibre-optic network, or some combination thereof.

Transaction facilitation server system 130 may comprise one or more computing devices and/or server devices, such as one or more servers, databases, and/or processing devices in communication over a network. Transaction facilitation server system 130 may be configured to host an transaction facilitation platform that can be used by a user of device 110 to allow for management and sharing of bills among multiple payors. Transaction facilitation server system 130 comprises a processor 131 and a memory 133 accessible to processor 131. Processor 131 may be configured to access data stored in memory 133, to execute instructions stored in memory 133, and to read and write data to and from memory 133. Processor 131 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.

Memory 133 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 133 may be configured to store executable applications for execution by processor 131. For example, memory 133 may store program code 134 configured to cause processor 131 to perform transaction facilitation actions as described in further detail below. Memory 133 may also store data, such as user account data 135. Account data 135 may store user account details such as names, authentication details, contact details, and billers associated with the user account.

To facilitate communication with external devices and systems, transaction facilitation server system 130 further comprises a communications module 132. Communications module 132 may allow for wired and/or wireless communication between authentication server system 130 and external computing devices and components. Communications module 132 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 132 may facilitate communication with external devices and systems such as bill recipient device 110 and biller server system 140 via network 120.

Biller server system 140 may comprise one or more computing devices and/or server devices, such as one or more servers, databases, and/or processing devices in communication over a network. Biller server system 140 may be operated by a bill issuer, which may be a service or utilities provider that generates bills for payment by a bill recipient, such as the user of device 110. For example, biller server system 140 may be operated by an electricity provider, insurance company, landlord, water utility, internet provider or another provider of goods and/or services.

Biller server system 140 comprises a processor 141 and a memory 143 accessible to processor 141. Processor 141 may be configured to access data stored in memory 143, to execute instructions stored in memory 143, and to read and write data to and from memory 143. Processor 141 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.

Memory 143 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 143 may be configured to store executable applications for execution by processor 141. For example, memory 143 may store program code 144 configured to cause processor 141 to perform billing actions as described in further detail below.

Memory 143 may also store data, such as user account data 145, which may store details of one or more user accounts including account names and contact details, as well as billing details such as bill amount and due dates.

To facilitate communication with external devices and systems, biller server system 140 further comprises a communications module 142. Communications module 142 may allow for wired and/or wireless communication between biller server system 140 and external computing devices and components. Communications module 142 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 142 may facilitate communication with external devices and systems such as transaction facilitation server system 130 via network 120. According to some embodiments, biller server system 140 may be integrated with transaction facilitation server system 130 by way of an API, which may automatically cause billing data from biller server system 140 to be transmitted to transaction facilitation server system 130 via communications module 142.

Payor device 150 may be a smart phone, tablet, laptop, PC or other computing device. According to some embodiments, payor device 150 may be any internet connected device, such as a whitegoods product, smart home display, or car. Bill recipient device 150 comprises a processor 151 and a memory 153 accessible to processor 151. Processor 151 may be configured to access data stored in memory 153, to execute instructions stored in memory 153, and to read and write data to and from memory 153. Processor 151 may comprise one or more microprocessors, microcontrollers, central processing units (CPUs), application specific instruction set processors (ASIPs), or other processor capable of reading and executing instruction code.

Memory 153 may comprise one or more volatile or non-volatile memory types, such as RAM, ROM, EEPROM, or flash, for example. Memory 153 may be configured to store executable applications for execution by processor 111. For example, memory 113 may store at least one browser application 154 configured to interpret and display web page content. According to some embodiments, memory 153 may alternatively or additionally also store a bill management application configured to allow a user to contribute toward the payment of bills. According to some embodiments, the bill management application may be substantially similar to bill management application 114 as described above with reference to bill recipient device 110.

Payor device 150 further comprises user input and output peripherals 156 to allow a user to communication with payor device 150. User I/O 156 may comprise a display screen 157, which may be a touchscreen display, as well as one or more of a keyboard, a mouse, a camera, a microphone, a speaker, a microphone, buttons, sliders, and LEDs. According to some embodiments, user I/O 156 may not include display screen 157, and may instead include alternative input and/or output peripherals to allow for communication with a user. For example, user I/O 156 may comprise a speaker and microphone to allow for audio communication with a user by way of voice commands.

To facilitate communication with remote devices, payor device 150 further comprises a communications module 152. Communications module 152 may allow for wired and/or wireless communication between payor device 150 and external computing devices and components. Communications module 152 may facilitate communication via Bluetooth, USB, WiFi, Ethernet, or via a telecommunications network, for example. According to some embodiments, communication module 152 may facilitate communication with external devices and systems, such as transaction facilitation server system 130, via network 120.

Figure 2 shows a flowchart illustrating a method 200 performed by system 100 to facilitate a transaction involving multiple transacting parties. In particular, method 200 relates to an example scenario where a user uses bill recipient device 110 to receive data related to, view details of, manage, and request assistance with a bill generated by biller server system 140, and a second user uses payor device 150 to partially pay the bill. Transaction facilitation server system 130 facilitates in the management and payment of the bill. Method 200 illustrates one example of how a user may interact with bill management application 114, but the displayed steps may not be performed each time a user accesses bill management application 114. Furthermore, the steps may be performed in an order that differs to the order displayed in Figure 2.

Method 200 starts at step 205, at which processor 111 is caused to initiate bill management application 114. This may be in response to a user interacting with user I/O 116 to request that bill management application 114 is initiated. For example, the user may interact with a virtual button or icon representing bill management application 114 using display screen 117.

At step 210, processor 111 executing bill management application 114 is caused to request authentication details to allow the user to login to bill management application 114. According to some embodiments, the request may be for the user to enter a username and/or password log in. In some embodiments, the request may alternatively or additionally be for a contact number or address associated with the user account. According to some embodiments, processor 111 executing bill management application 114 may be further caused to send a verification code to a contact number or address associated with the user account, and to ask the user to enter the verification code to authenticate their account. In some embodiments, the user may be requested to log in using a biometric authentication process, such as using a fingerprint, retina scan, or facial recognition. In some embodiments, the user may be able to log in using a linked account, which may be a social media or email account such as a Google® or Facebook® account, that has previously been linked to the user account for the bill management application 114. According to some embodiments, bill management application 114 may use a third party authentication service to facilitate the log in process, which may be by authenticating a user or user account. According to some embodiments, a third party authentication service such as Okta® or Azure AD® may be used, for example.

Where the user does not have an existing account, processor 111 executing bill management application 114 may provide the user with an opportunity to create an account, by providing their contact details and setting an authentication method.

At step 215, the user provides the requested authentication details.

Once the user has provided authentication details in response to the request, at step 220 processor 111 via communications module 112 communicates the received details to transaction facilitation server system 130. Processor 131 executing program code 134 receives the details via network 120 using communications module 132, and authenticates the user by comparing the received details to those stored in account data 135. According to some alternative embodiments, the received details may be processed by an authentication system such as Okta®, for example. Having verified the authentication details, processor 131 executing program code 134 sends a response to bill recipient device 110 via network 120 and using communications module 132 indicating whether the user was authenticated. At step 225, processor 111 executing bill management application 114 receives the response from transaction facilitation server system 130. At step 232, processor 111 executing bill management application 114 interprets the response from transaction facilitation server system 130 to determine whether the user was authenticated.

If the user was not authenticated, at step 234 processor 111 may request that the user re-enter their authentication details, and return to step 215..

If the user was authenticated, at step 230 processor 111 executing bill management application may load a graphical user interface associated with bill management application 114 and cause this to be displayed on display screen 117. The graphical user interface may present virtual buttons, options, tabs, and other graphical user interface elements that a user can interact with to perform various actions. For example, the graphical user interface may present user interface elements that allow the user to perform tasks such as managing their associated billers, viewing bills received from billers, making payments towards bills, requesting assistance with payment of bills, managing their contacts, and managing their account details and preferences.

At step 235, processor 111 executing bill management application 114 receives a request from the user of bill recipient device 110 to view their bills. This may be by a user interacting with a graphical user interface element displayed on display screen 117 that represents a “view bills” action. Alternatively, bill management application 114 may default to displaying the user’s existing bills when the user first logs on to their account.

At step 240, processor 111 executing bill management application 114 processes the request by retrieving bill information. According to some embodiments, processor 111 communicates with transaction facilitation server system 130 to retrieve information associated with bills stored in account data 135. The information may include one or more of bill amount, bill due date, biller details, and/or other data associated with the bill. According to some embodiments, processor 111 executing bill management application 114 may additionally or alternatively retrieve biller information associated with the user account from account data 135, and may then communicate with an associated biller server system 140 to retrieve bill information associated with the user account.

The bill information retrieved by processor 111 may include a biller code, bill amount and a due date. The biller code may be a code corresponding to an existing bill processing or transaction system, such as BPAY®, in some embodiments, or another bill management, bill payment, or biller authentication system. All retrieved bills associated with the user account may be displayed on display screen 117. According to some embodiments, the bills may be listed by ascending due date, and may be grouped by month in some embodiments. According to some embodiments, bills that are nearing or past their due data may be visually emphasised. For example, overdue bills may be displayed with a red background in some embodiments.

Where a user has contacts that have asked for the user’s assistance with their bills, any such shared bills may also be displayed on display screen 117. According to some embodiments, these may be displayed in a separate area of the user interface to the user’s personal bills.

At step 245, processor 111 receives a request to add a new bill to the user’s account. The request may be generated in response to a user interacting with a graphical user interface element that represents an “add bill” action.

In response to the request, at step 250, processor 111 executing bill management application 114 presents a page to the user via display screen 117 that allows the user to enter details relating to the bill and the biller that issued the bill. For example, the page may request that the user select the biller user enters a biller code and a customer reference number associated with that biller. According to some embodiments, the biller code may be a BPAY® biller code, for example. According to some embodiments, the page may request or provide the user with an option to scan a copy of their bill, which may be done by taking a photograph or screenshot of their bill. Processor 111 may be configured to receive the scanned data and to extract bill information such as bill amount, due date and biller details, for example.

At step 255, processor 111 receives the biller details from the user via user I/O 116.

At step 260, processor 111 executing bill management application 114 is caused to forward the biller details to transaction facilitation server system 130 via network 120 using communications module 112.

Having received the biller details, where the biller details include a biller code processor 131 executing program code 134 may be caused to compare the received biller code with stored biller codes associated with biller server systems 140 that are integrated with transaction facilitation server system 130, in which case billing data generated by the associated biller server system 140 may be caused to automatically be transmitted to transaction facilitation server system 130 on a periodic or ad-hoc basis. According to some embodiments, biller server system 140 may be integrated with transaction facilitation server system 130 by way of an API, which may automatically cause billing data from biller server system 140 to be transmitted to transaction facilitation server system 130. According to some embodiments, data from biller server system 140 may be integrated with transaction facilitation server system 130 by way of a batch upload of billing data from biller server system 140 to transaction facilitation server system 130, which may occur on a periodic basis.

If a corresponding biller is found, processor 131 executing program code 134 may be caused to associate the biller with the user account, and to store the relationship in account data 135. Processor 131 may further be caused to retrieve bill data corresponding to the user account from biller server system 140, and to forward that data to bill recipient device 110 via network 120 at step 265. Bill recipient device 110 receives the retrieved bill information, and determines that the bill corresponds to a known biller at step 267. Processor 111 executing bill management application 114 is caused to display the retrieved bill information to the user via display screen 117 at step 270.

Alternatively, where an associated biller is not found or no biller code is provided, transaction facilitation server system 130 may be caused to send a notification to bill recipient device 110 that no associated biller with that biller code exists in the system at step 265. Having received the notification, processor 111 determines that no known biller exists at step 267. Further at step 269, processor 111 is caused to notify the user that that biller does not exist in the system, and request that the user manually enter the bill details. The user may enter the details by interacting with user VO 116. For example, the user may use a physical or virtual keyboard to enter details such as the bill amount and due date. Alternatively or additionally, the user may upload an electronic copy of the bill or an electronic copy of data from a bill to bill management application 114, and processor 111 executing bill management application 114 may parse the electronic document to extract information such as the payment amount and due date. Further alternatively or additionally, the user may use a camera to capture an image of the bill, and processor 111 executing bill management application 114 may use optical character recognition processes to translate the image to text, and then parse the text to extract information such as the payment amount and due date.

Once the bill information has been input by the user, processor 111 may communicate the information to transaction facilitation server system 130 for storing in account data 135 associated with the user account. According to some embodiments, transaction facilitation server system 130 may verify that the entered details relate to a biller account, and not to a personal bank account, such as by checking that a valid biller identification number has been entered, before storing the details. Once the bill details have been stored, at step 270, the updated bill information is displayed to the user within the list of bills associated with their account. At step 275, processor 111 executing bill management application 114 receives a request from the user via user I/O 116 to make a payment against a bill. The request may include the bill to be paid, and an amount to be paid.

At step 280, processor 111 may cause the payment to be processed, such as by sending details of the request to transaction facilitation server system 130 for processing. Processor 131 executing program code 134 receives the details of the transaction including the bill details and the payment amount. According to some embodiments, payment method details, such as credit card details, may be stored by a user in association with their user account. Processor 131 may retrieve payment method details from account data 135, and cause the payment to be processed for the required amount. In some alternative embodiments, the user may have entered their payment details at the time of submitting the payment request using user I/O 116, and processor 131 may receive the details from bill recipient device 110 via communications module 132. Processor 131 may receive the payment method details and cause the payment to be processed for the required amount. According to some embodiments, processor 131 may cause the payment to be processed by sending the transaction details to a payment processing service, such as Stripe®, for example, which may also store the user’s payment details in some embodiments. Processor 131 may then send confirmation to bill recipient device 110 confirming that the transaction has been successfully carried out.

Where the payment amount was less than the amount owing on the specified bill, processor 131 determines the amount remaining on the bill by subtracting the payment amount from the bill amount. An updated bill amount is stored in account data 135. According to some embodiments, details of the transaction and the new bill amount may also be forwarded to bill server system 140 associated with the issuer of the bill, for storing in account data 145 in association with the user’s account details. At step 285, processor 111 receives confirmation that the payment has been successfully processed, and displays the completed transaction to the user, including the updated bill amount reflecting the amount still owing on the bill.

At step 290, processor 111 executing bill management application 114 receives a request from the user via user I/O 116 to ask for assistance to pay a bill. The request may include information relating to the bill to be paid, and contact details relating to a person that the user wishes to ask for assistance. The contact details may include the name of the contact that the user wishes to request assistance from, for example. According to some embodiments, the contact details may be of an existing contact of the user that are stored in account data 135. Existing contacts may be ones that the user has previously manually entered as contacts via bill management application 114, or may have been automatically populated based on a contact list stored in memory 113 of bill recipient device 110. Processor 111 may retrieve the contact details by communication with transaction facilitation server system 130. Processor 131 executing program code 134 may receive a name or other reference relating to the desired contact, and be caused to retrieve the contact details from account data 135 and send them to bill recipient device 110 via network 120 using communications module 152. According to some embodiments, the user may use user I/O 116 to enter directly contact details of a person they wish to ask for assistance.

At step 292, processor 111 executing bill management application 114 generates a URL that facilitates payment of the bill by payors other than the user of bill recipient device 110, such as the user of a payor device 150. The URL may be a mini URL, and accessing the URL may cause the payor device 150 to retrieve data from a server relating to a request for assistance with a bill. According to some embodiments, the data may be displayed on a web browser of payor device 150 as a web page that allows for a visitor to the page to make a payment toward the specified bill. According to some embodiments, the data may be communicated to a user of payor device 150 in another manner via user I/O 156. For example, the data may be presented via a native application on display screen 157, or communicated to the user in audible form. The data may include a request for a payment amount to put toward the bill, and payment method details. According to some embodiments, the data may be hosted by transaction facilitation server system 130.

At step 294, processor 111 causes the URL to be sent to the payor via a contact number, address, or other contact information of the payor. For example, the URL may be sent to the payor via a text message, email, an in-app message or other messaging service. According to some embodiments, transaction facilitation server system 130 may use a messaging service such as Twilio® or SendGrid® to send the URL to payor device 150. According to some embodiments, the generated URL may instead be displayed on display screen 117 as a shareable link, and the user of bill recipient device 110 may be able to copy the link and share it with their contacts via a message, email, or social media platform. The message may be received by payor device 150, and allow a user of payor device 150 to access the data pointed to by the URL, and make a payment as described in further detail below with reference to Figure 3. Once the payment has been processed, processor 131 updates the bill data stored in account data 135 in association with the paid bill. Where the payment was a partial payment of the bill, processor 131 determines a new bill amount, being the previous bill amount minus the payment amount.

At step 296, processor 111 may receive a confirmation from transaction facilitation server system 130 confirming that a payment was made. According to some embodiments, processor 111 may generate a notification to inform the user of bill recipient device 110 that a payment has been made against the specified bill. According to some embodiments, the notification may be a push notification or real-time alert that is displayed by user I/O 116. According to some embodiments, the notification may be sent via bill management application 114, email SMS, voice, or other messaging services. In some embodiments, the notification may be a message that is asynchronously displayed to the user of bill recipient device 110 when the user next initiates bill management application 114. According to some embodiments, details of who made the payment may not be displayed to the user of bill recipient device 110. Steps 290 to 296 may be repeated for any number of additional payors each having a payor device 150.

Figure 3 shows a method 300 performed by transaction facilitation server system 130 to facilitate payment of a bill by one or more payor devices 150. Specifically, method 300 may be performed by processor 131 executing program code 134, and may be performed after step 294 of method 200 as described above with reference to Figure 2.

At step 305, transaction facilitation server system 130 receives a request from payor device 150 via network 120 to access bill payment data hosted by transaction facilitation server system 130. The bill payment data may be in the form of a web page, in some embodiments. The request may be in the form of a URI request, for example. The request may be generated by payor device 150 in response to a user of payor device 150 navigating to a URL generated by transaction facilitation server system 130 and sent to payor device 150, as described with respect to steps 292 and 294 of method 200.

At step 310, processor 131 executing program code 134 checks access data associated with the bill payment data to determine whether an alternative payor device 150 is currently viewing bill payment data. This may be by checking a location in memory 133 associated with the requested bill payment data, to determine whether an access flag has been set.

At step 315, processor 131 determines whether the requested bill payment data is currently being viewed by a different payor device 150, based on the retrieved access flag information. If processor 131 determines that the bill payment data is already being viewed, at step 320 processor 131 may send instructions to payor device 150 to cause an error, notification, warning or exception to be communicated to the user via user I/O 156 of payor device 150. For example, the error, notification, warning or exception may be displayed via display screen 157. The error may note that a payment is currently in progress, and ask the user of payor device 150 to try again later. According to some embodiments, a “try again” virtual button may be displayed to the user. The user may attempt to access the bill payment data again, which may be by interacting with the “try again” virtual button in some embodiments. Processor 131 receives the request at step 322 and continues to execute method 300 from step 310.

If processor 131 determines that no other payor devices are currently viewing the requested bill payment data, then at step 325 processor 131 may be caused to update the access data associated with the requested bill payment data. For example, processor 131 may be caused to set a flag in memory 133, indicating that the bill payment data is currently being viewed.

Once the access data has been updated, at step 330 processor 131 is caused to send the bill payment data to payor device 150 via network 121, using communications module 132. The bill payment data may be retrieved from memory 133, and may comprise a HTML page in some embodiments. According to some embodiments, the bill payment data may comprise executable client-side language scripts, such as CSS and/or JavaScript scripts, for example. Payor device 150 may receive the bill payment data, and in some embodiments processor 151 executing browser application 154 may be caused to interpret the bill payment data and display an associated web page on display screen 157. According to some embodiments, processor 151 may be caused to communicate the bill payment data to the user via alternative means, such as by displaying the data via display screen 157 in a native application or by communicating the data audibly. The bill payment data may include details relating to a bill to be paid, such as details of the original bill recipient, the type of bill, the bill issuer, and the remaining bill amount, being the amount still owning on the bill.

The bill payment data may request that the user of payor device 150 enter payment details to allow a payment to be processed, which may include a payment amount, payment method information, and payor contact details in some embodiments. According to some embodiments, the payment may be made by way of direct deposit, credit card payment, or payment with a cryptocurrency, for example. According to some embodiments, the payor may be able to optionally add their name to the payment, which may be sent to the bill recipient so that the bill recipient is made aware of who contributed to the payment of the bill. In some embodiments, the payor may be able to submit their payment anonymously. According to some embodiments, the payor may be able to optionally a description to the payment, which may include an identifiable or non-identifiable description, for example.

At step 335, transaction facilitation server system 130 receives a payment amount from payor device 150. The payment amount may be transmitted by payor device 150 after a user enters a payment amount via user I/O 156 and processor 151 executing browser application 154 is caused to transmit the entered amount to transaction facilitation server system 130 via network 120 using communications module 152.

At step 340, processor 131 executing program code 134 is caused to compare the received payment amount with the remaining bill amount associated with the bill which the user of payor device 150 has been asked to contribute to. Processor 131 may retrieve the remaining bill amount from memory 133.

At step 345, processor 131 executing program code 134 determines whether the received payment amount is greater than the retrieved remaining bill amount. If the payment amount entered by the user of payor device 150 is greater than the remaining bill amount, then at step 350 processor 131 is caused to send instructions to payor device 150 to cause processor 151 executing browser application 154 to display a message on display 157, suggesting a smaller payment amount. When a new payment amount is received, such as by the user accepting the suggestion, method 300 continues from step 335.

If the payment amount entered by the user of payor device 150 is not greater than the remaining bill amount, then at step 350 processor 131 is caused to process the payment amount. According to some embodiments, the payment may be processed using payment method details entered by the user of payor device 150. According to some embodiments, the payment may be processed via a payment platform or payment gateway such as Stripe®. According to some embodiments, the processed funds may be held by an account operated by transaction facilitation server system 130, before being transmitted to an count of the biller server system 140 associated with the bill. In some embodiments, processor 131 may be caused to send a notification or payment receipt to payor device 150 or to contact details provided by the payor once the transaction is successfully processed.

At step 360, having processed the payment transaction, processor 131 executing program code 134 is caused to update the remaining bill amount stored in memory 133 associated with the bill being paid. According to some embodiments, the updated remaining bill amount may be the previous remaining bill amount minus the processed payment amount. This updated remaining bill amount may be displayed to users of other payment devices 150 who subsequently access the bill payment data.

At step 365, processor 131 executing program code 134 receives a notification from payor device 150 that the user has closed, navigated away, or is otherwise no longer viewing the bill payment data.

In response to receiving the notification, at step 370 processor 131 updates the access data stored in memory 133. For example, processor 131 may clear a flag, indicating that no devices are currently accessing the bill payment data.

While method 300 has been described with reference to a payor device 150 executing a browser application 154, according to some embodiments method 300 may be executed with reference to a payor device 150 executing a bill management application, such as bill management application 114, for example. In such embodiments, navigating to the URL provided to payor device 150 at step 294 of method 200 may cause processor 151 to present a page corresponding to the requested bill payment data within a user interface of the bill management application stored on payor device 150. Furthermore, according to some embodiments, payment method details may be stored by transaction facilitation server system 130 in association with the user account of payor device 150, so that the user does not need to provide their payment method details during method 300.

Figure 4 shows an example screenshot 400 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 400 may be displayed when a user first causes bill management application 114 to be initiated, as described above with reference to step 205 of method 200. Screenshot 400 includes a sign in button 410 and a register button 420. A user of bill recipient device 110 may be able to sign in to an existing user account associated with bill management application 114 by interacting with button 410, and may be able to register for a new user account associated with bill management application 114 by interacting with button 420.

Figure 5 shows an example screenshot 500 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 500 may be displayed when a user interacts with button 410 of screen 400, indicating that they wish to sign in to an existing user account associated with bill management application 114. Screen 500 may be displayed as a request for authentication details, as described above with reference to step 210 of method 200. Screen 500 includes graphical user interface elements via which a user can enter authentication details. For example, the illustrated embodiment includes an email address text box 510 and a password text box 520, allowing a user to enter an email and password pair that they have registered as their authentication details. Once the user has entered their details, they can interact with button 530 to cause the authentication details to be processed, as described above with reference to steps 215 to 230 of method 200. Alternatively, a user may log in using a connected social media account using buttons 540. For example, according to some embodiments a user may be able to sign in to their account via their Facebook®, Google®, or Apple® account.

Figure 6 shows an example screenshot 600 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 600 may be displayed when a user interacts with button 420 of screen 400, indicating that they wish to create a new user account associated with bill management application 114, as described above with reference to step 210 of method 200. Screen 600 includes buttons 610 that allow a user to register for a user account associated with application 114 using an existing social media account. For example, in the illustrated embodiment, a user may be able to create a new user account using an existing Facebook®, Google®, or Apple® account. Alternatively, a user may register for a new user account without using an existing social media account by interacting with button 620, which allows them to register for a new account with an email address.

Figure 7 shows an example screenshot 700 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 700 may be displayed when a user has successfully logged in to their user account, and once their bill information has been retrieved and displayed, as described above with reference to step 240 of method 200.

Screen 700 includes a banner 710 highlighting a particular selected time period associated with the displayed bills. For example, in the illustrated embodiment, banner 710 shows ‘October’ highlighted, indicating that the displayed bills are due in October. According to some embodiments, bills may be displayed in ascending order of due date, and banner 710 may be automatically updated as a user scrolls through their bills.

Screen 700 may further display a number of bills 730. Each bill may be displayed with a summary of information associated with the bill. For example, each bill may show the biller 731, a due date 732, how many payors have been requested to assist with the bill at 733, an amount of the bill still outstanding at 734, and a number of contributors 735. Screen 700 may also provide a button 740 allowing a user to add a new bill, as described above with reference to steps 245 to 270 of method 200.

Screen 700 may also include a number of navigation buttons, allowing a user to access various functions within bill management application 114. These may include a “bills” navigation button 750, a “help others” navigation button 760, a “contacts” navigation button 770 and a “profile” navigation button 780. Interacting with “bills” navigation button 750 may allow a user to manage their personal bills by adding new bills, paying existing bills, editing bills, deleting bills, and requesting assistance with payment of bills. Interacting with “help others” navigation button 760 may allow a user to assist other users with the payment of bills by causing bill recipient device 110 to act as a payor device 150 and execute a method such as method 300. Interacting with “contacts” navigation button 770 may allow a user to manage contacts associated with their user profile, such as by adding new contacts, editing contacts and deleting contacts. Interacting with “profile” navigation button 780 may allow a user to make changes to their profile settings, such as editing their authentication details, adding or editing payment method details, managing notifications and managing privacy preferences, for example.

Figure 8 shows an example screenshot 800 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 800 may be displayed when a user has requested to add a new bill by interacting with button 740, as described above with reference to step 245 of method 200. Screen 800 includes a pop-up 810 directing the user to either link a new biller or provider to their account by interacting with button 820, or to add a bill by interacting with button 830. Interacting with button 820 may allow the user to link a biller with their account, such that all bills generated by that biller and associated with the user account are automatically populated within bill management application 114, as described above with reference to steps 250 to 270 of method 200. Interacting with button 830 may allow the user to manually add a single bill to their user account, as described above with reference to steps 269 to 270 of method 200.

Figure 9 shows an example screenshot 900 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 900 may be displayed when a user has requested to add a new bill manually by interacting with button 830. Screen 900 includes a number of graphical user interface elements allowing a user to enter various details associated with the bill they wish to add. For example, in the illustrated embodiment, screen 900 includes a biller code text box 910, a biller name text box 920, a reference number text box 930, and a bill type drop-down box 940. Other details, such as a bill amount and a due date, may be enterable by scrolling down screen 900.

Figure 10 shows an example screenshot 1000 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 1000 may be displayed when a user has requested to view the details of a particular bill by interacting with a bill listing such as bill 730 as displayed on screen 700. Screen 900 shows more information about a selected bill, including a biller 1010, a due date 1020, an amount left to pay 1030, and an original bill amount 1040. Screen 1000 also includes a button 1060 to allow a user to request assistance with payment of the bill, as described above with reference to step 290 of method 200; and a button 1050 to allow a user to make a payment to the bill, as described above with reference to step 275 of method 200. Screen 1000 further includes information such as a list 1070 displaying contacts that have already been asked to contribute to payment of the bill. Screen 1000 further allows a user to perform bill management actions such as marking the bill as paid by interacting with button 1080, or updating the bill details by interacting with button 1090.

Figure 11 shows an example screenshot 1100 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 1100 may be displayed when a user has requested assistance with payment of a bill, such as by interacting with button 1060 of screen 1000, as described above with reference to step 290 of method 200. Screen 1100 shows a pop-up 1110 displaying a unique URL 1120 generated at step 292 of method 200. A user may be able to share the link by copying it using button 1130, allowing the user to share it in a message, email, social media post or other communication. Alternatively, a user may interact with button 1140 to cause the link 1120 to be sent directly to one of the contacts associated with their user account.

Figure 12 shows an example screenshot 1200 that may be displayed on display screen 117 of biller recipient device 110 when processor 111 is executing bill management application 114. In particular, screenshot 1200 may be displayed when a user has interacted with button 1120 of screen 1100 to cause a generated URL 1120 to be sent to one of their contacts, as described above with reference to step 294 of method 200. Screen 1100 shows details of the bill to be paid, including a biller 1210, a due date 1220, and a remaining bill amount 1230. Screen 1200 also includes a text box 1240 for a user to enter the contact to which they wish the URL 1120 to be sent. According to some embodiments, processor 111 executing bill management application 114 may cause contact names to be autocompleted as the user starts typing on text box 1240. According to some embodiments, a user may be able to select multiple contacts to whom the request for assistance will be sent.

Screen 1200 further includes a checkbox 1250, allowing the user to indicate whether they wish future bills from the biller 1210 to be automatically forwarded to the selected contact or contacts. Once the user has entered the required data, they may interact with button 1260 to cause the request for assistance to be sent to the selected contact or contacts, as described above with reference to step 294 of method 200.

Figure 13 shows an example screenshot 1300 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154. In particular, screenshot 1300 may be displayed when a user of payor device 150 is attempting to access bill payment data via a URL sent by a bill recipient device 110 as described above with reference to step 294 of method 200, and when a different payor device is already accessing the URL, as described above with reference to step 320 of method 300. Screen 1300 displays a pop-up 1310 indicating that another user is already trying to make a payment, and requesting that the user of payor device 150 try again. Screen 1300 includes a “try again” button 1320, which may cause the payor device 150 to re-attempt access of the bill payment data, as described above with reference to step 322 of method 300.

Figure 14 shows an example screenshot 1400 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154. In particular, screenshot 1400 may be displayed when a user of payor device 150 successfully accesses bill payment data via a URL sent by a bill recipient device 110, as described above with reference to step 330 of method 300. Screen 1400 displays a message 1410 thanking the user for contributing to the bill, and provides some bill details such as the due date 1420 and total amount due 1430. According to some embodiments, the displayed total amount due 1430 may be the remaining bill amount taking into account any payments already processed against the bill. Screen 1400 further provides a button 1440 allowing a user to log in if they have an existing account with bill management application 114. Alternatively, the user is provided an opportunity to make a manual payment, by entering a payment amount in text box 1450.

Figure 15 shows an example screenshot 1500 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154. In particular, screenshot 1500 may be displayed when a user of payor device 150 attempts to make a payment that is higher than an amount remaining on the bill, as described above with reference to step 350 of method 300. Screen 1500 displays a pop-up 1510 notifying the user that the entered amount was higher than the amount owing, and indicating that the payment amount has been adjusted to the total amount owing on the bill. The user can indicate agreement with the suggested lower payment amount by interacting with button 1520.

Figure 16 shows an example screenshot 1600 that may be displayed on display screen 157 of payor device 150 when processor 151 is executing browser application 154. In particular, screenshot 1600 may be displayed when a user of payor device 150 has successfully made a payment against a bill, as described above with reference to step 360 of method 300. Screen 1600 displays a message 1610 indicating that the payment was successful, and provides some details of the payment made at 1620, such as the amount paid and the biller that the payment was sent to. Screen 1600 further provides a button 1630 allowing a user to view their contact’s other bills, to see which other bills they are able to contribute to.

Figure 17 illustrates an example computer system 1700. In particular embodiments, one or more computer systems 1700 perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems 1700 provide functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems 1700 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 1700. Herein, reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate. The bill recipient device 110, transaction facilitation server system 130, biller server system 140, and/or payor device 150 may each incorporate a subset or all of the computing components described with reference to the computer system 1700 to provide the functionality described in this specification.

This disclosure contemplates any suitable number of computer systems 1700 to implement each of the bill recipient device 110, transaction facilitation server system 130, biller server system 140, and/or payor device 150. Computer system 1700 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on- module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these. Where appropriate, computer system 1700 may include one or more computer systems 1700; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 1700 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 1700 may perform in real-time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 1700 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

In particular embodiments, computer system 1700 includes a processor 1702, memory 1704, storage 1706, an input/output (I/O) interface 1708, a communication interface 1710, and a bus 1712. Memory 1704 may be equivalent to, comprise, or form part of one or more of memory 113, memory 133, memory 143 or memory 153. Storage 1706 may be equivalent to, comprise, or form part of one or more of memory 113, memory 133, memory 143 or memory 153. I/O interface 1708 may be equivalent to, comprise, or form part of one or more of user I/O 116 or user I/O 156. Communication interface 1710 may be equivalent to, comprise, or form part of one or more of communications module 112, communications module 132, communications module 142 or communications module 152.

Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

In particular embodiments, processor 1702 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 1702 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 1704, or storage 1706; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 1704, or storage 1706. In particular embodiments, processor 1702 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 1702 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 1702 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 1704 or storage 1706, and the instruction caches may speed up retrieval of those instructions by processor 1702. Data in the data caches may be copies of data in memory 1704 or storage 1706 for instructions executing at processor 1702 to operate on; the results of previous instructions executed at processor 1702 for access by subsequent instructions executing at processor 1702 or for writing to memory 1704 or storage 1706; or other suitable data. The data caches may speed up read or write operations by processor 1702. The TLBs may speed up virtual-address translation for processor 1702. In particular embodiments, processor 1702 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 1702 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 1702 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 1702. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor. In particular embodiments, memory 1704 includes main memory for storing instructions for processor 1702 to execute or data for processor 1702 to operate on. As an example and not by way of limitation, computer system 1700 may load instructions from storage 1706 or another source (such as, for example, another computer system 1700) to memory 1704. Processor 1702 may then load the instructions from memory 1704 to an internal register or internal cache. To execute the instructions, processor 1702 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 1702 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 1702 may then write one or more of those results to memory 1704. In particular embodiments, processor 1702 executes only instructions in one or more internal registers or internal caches or in memory 1704 (as opposed to storage 1706 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 1704 (as opposed to storage 1706 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 1702 to memory 1704. Bus 1712 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 1702 and memory 1704 and facilitate accesses to memory 1704 requested by processor 1702. In particular embodiments, memory 1704 includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 1704 may include one or more memories 1704, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

In particular embodiments, storage 1706 includes mass storage for data or instructions. As an example and not by way of limitation, storage 1706 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 1706 may include removable or non-removable (or fixed) media, where appropriate. Storage 1706 may be internal or external to computer system 1700, where appropriate. In particular embodiments, storage 1706 is non-volatile, solid-state memory. In particular embodiments, storage 1706 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 1706 taking any suitable physical form. Storage 1706 may include one or more storage control units facilitating communication between processor 1702 and storage 1706, where appropriate. Where appropriate, storage 1706 may include one or more storages 1706. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

In particular embodiments, VO interface 1708 includes hardware, software, or both, providing one or more interfaces for communication between computer system 1700 and one or more I/O devices. Computer system 1700 may include one or more of these I/O devices, where appropriate. One or more of these VO devices may enable communication between a person and computer system 1700. As an example and not by way of limitation, an VO device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An I/O device may include one or more sensors. This disclosure contemplates any suitable I/O devices and any suitable I/O interfaces 1708 for them. Where appropriate, VO interface 1708 may include one or more device or software drivers enabling processor 1702 to drive one or more of these I/O devices. VO interface 1708 may include one or more VO interfaces 1708, where appropriate. Although this disclosure describes and illustrates a particular VO interface, this disclosure contemplates any suitable VO interface. In particular embodiments, communication interface 1710 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 1700 and one or more other computer systems 1700 or one or more networks. As an example and not by way of limitation, communication interface 1710 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 1710 for it. As an example and not by way of limitation, computer system 1700 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 1700 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WLMAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 1700 may include any suitable communication interface 1710 for any of these networks, where appropriate. Communication interface 1710 may include one or more communication interfaces 1710, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

In particular embodiments, bus 1712 includes hardware, software, or both coupling components of computer system 1700 to each other. As an example and not by way of limitation, bus 1712 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 1712 may include one or more buses 1712, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application- specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

38 CLAIMS:

1. A method for facilitating a transaction, the method comprising: receiving, from a payor device, a request to access payment data; checking access data associated with the payment data; based on the access data indicating that the payment data is accessible, updating the access data to indicate that the payment data is not accessible and subsequently providing the payment data to the payor device; receiving payment details generated at the payor device in response to receiving the payment data; causing a payment to be processed based on the received payment details; and in response to the payment being processed, further updating the access data to indicate that the payment data is accessible.

2. The method of claim 1, further comprising: based on the access data indicating that the payment data is not accessible, providing an error to a second payor device notifying the second payor device that the payment data is not accessible.

3. The method of claim 1 or claim 2, wherein the access data stores information indicating whether the payment data is currently being accessed, where the access data indicates that the payment data is accessible when the payment data is not currently being accessed, and the access data indicates that the payment data is not accessible when the payment data is currently being accessed.

4. The method of any one of claims 1 to 3, wherein the access data comprises an access flag.

5. The method of claim 4, wherein the access flag is set when the payment data is being accessed, and cleared when the payment data is not being accessed. 39

6. The method of any one of claims 1 to 5, wherein the payment data corresponds to a bill.

7. The method of any one of claims 1 to 6, wherein the payment data comprises a web page hosting information associated with a bill.

8. The method of claim 7, wherein providing the payment data to the payor device causes the payor device to display the web page data within a browser application.

9. The method of claim 7, wherein providing the payment data to the payor device causes the payor device to display the web page data within a native application.

10. The method of any one of claims 6 to 9, wherein the payment data comprises information associated with a bill.

11. The method of claim 10, wherein the information associated with the bill comprises a remaining bill amount.

12. The method of claim 11, wherein in response to the payment being processed, the remaining bill amount is updated by subtracting the payment amount from the remaining bill amount to produce an updated remaining bill amount.

13. The method of claim 11 or claim 12, wherein prior to causing a payment to be processed, a payment amount is determined based on the received payment details and the payment amount is compared to a remaining bill amount.

14. The method of claim 13, further comprising, upon determining that the payment amount is higher than the remaining bill amount, automatically adjusting the payment amount to be equal to the remaining bill amount. 40

15. The method of any one of claims 1 to 14, wherein the request to access the payment data is sent by the payor device in response to the payor device attempting to access a URL associated with the payment data.

16. The method of claim 15, wherein the URL is provided to the payor device by a message sent on behalf of a bill recipient via a bill recipient computing device.

17. The method of claim 16, wherein the message is generated by a bill management application executing on the bill recipient computing device.

18. The method of claim 17, wherein the message is generated by the bill management application in response to a user of the bill recipient computing device requesting assistance with a bill.

19. The method of claim 18, wherein the message is generated by the bill management application in response to a bill being uploaded that is associated with the payor device.

20. The method of claim 19, wherein the association is based on the payor having indicated that bills issued by a particular bill issuer to the bill recipient should automatically be forwarded to the payor device.

21. The method of any one of claims 1 to 20, wherein providing the payment data to the payor device causes the payor device to communicate the payment data to a user of the payor device via a user interface.

22. The method of any one of claims 1 to 21, wherein the payment data comprises information generated based on bill data retrieved from a computing system associated with a bill issuer.

23. The method of claim 22, wherein the bill data is automatically retrieved from the computing system associated with the bill issuer via an API.

24. The method of any one of claims 1 to 21, wherein the payment data comprises information generated based on bill data entered by a user of a bill recipient device.

25. The method of claim 24, wherein the bill data entered by a user comprises a biller identification number, and wherein the method further comprise verifying that the biller identification number corresponds to a valid biller.

26. A device comprising: a memory storing executable code; a processor configured to access the memory to execute the executable code; wherein when executing the executable code, the processor is caused to perform the method of any one of claims 1 to 25.

27. A computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 25.