The present invention relates to a system and method for initiating bill payment, and in one example, to a system and method for initiating bill payment when performing another transaction.
Description of the Prior Art
The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.
It is known to perform transactions using terminals, such as point of sales terminals, automatic teller machines (ATMs) or the like, as well as performing online transactions with e-commerce merchants. Whilst such processes are useful for ad-hoc transactions performed on demand, these are less suitable for scheduled payments, such as bill payments, or the like. Whilst mechanisms have been established to allow users to pay bills online, this is typically achieved either via a portal hosted by the biller or the user’s own financial institution. This therefore requires the user to consciously access the respective sites in order to make a payment, and can result in bill payments being missed or overlooked.
Summary of the Present Invention
In one broad form the present invention seeks to provide a method of initiating a bill payment in a transaction system including a transaction device in communication with one or more payment processing devices, via a communications network, the method including, in the payment processing devices:
a) receiving a transaction message indicative of a transaction;
b) determining an identifier from the transaction message, the identifier being at least partially indicative of at least one of:
i) an identity of the user; and,
ii) an identity of an account of the user;
c) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of users, the at least one bill being determined at least partially in accordance with the identifier; and,
d) causing a bill indication indicative of the bill to be displayed using the transaction device to thereby allow a user to selectively initiate a bill payment process.
In one broad form the present invention seeks to provide a method of initiating a bill payment, the method including, in one or more payment processing devices:
e) receiving a transaction message indicative of a transaction, the transaction being performed at least in part using a transaction device;
f) determining an identifier from the first transaction message, the identifier being at least partially indicative of at least one of:
i) an identity of the user; and,
ii) an identity of an account of the user;
g) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of user, the at least one bill being determined at least partially in accordance with the identifier; and,
h) causing a bill indication to be displayed using the transaction device to thereby selectively initiate a bill payment process.
In one broad form the present invention seeks to provide a transaction system for initiating a bill payment, the transaction system including:
i) a transaction device;
j) one or more payment processing devices in communication with the transaction device via a communications network, wherein the one or more payment processing devices initiate a bill payment by:
i) receiving a transaction message indicative of a transaction;
ii) determining an identifier from the transaction message, the identifier being at least partially indicative of at least one of:
(1) an identity of the user; and,
(2) an identity of an account of the user;
iii) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of users, the at least one bill being determined at least partially in accordance with the identifier; and,
iv) causing a bill indication indicative of the bill to be displayed using the transaction device to thereby allow a user to selectively initiate a bill payment process.
In one broad form the present invention seeks to provide a transaction system for initiating a bill payment, the transaction system including one or more payment processing devices in communication with a transaction device via a communications network that initiate a bill payment by:
k) receiving a transaction message indicative of a transaction;
l) determining an identifier from the transaction message, the identifier being at least partially indicative of at least one of:
i) an identity of the user; and,
ii) an identity of an account of the user;
m) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of users, the at least one bill being determined at least partially in accordance with the identifier; and,
n) causing a bill indication indicative of the bill to be displayed using the transaction device to thereby allow a user to selectively initiate a bill payment process.
It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting.
Brief Description of the Drawings
An example of the present invention will now be described with reference to the accompanying drawings, in which: -
Figure 1 is a flowchart of an example of a method of initiating a bill payment;
Figure 2 is a schematic diagram of an example of a transaction system for initiating a bill payment;
Figure 3 is a schematic diagram of a payment processing system of the transaction system of Figure 2;
Figure 4 is a schematic diagram of an example of a transaction device of the transaction system of Figure 2;
Figure 5 is a schematic diagram of an example of a client device of the transaction system of Figure 2;
Figure 6 is a schematic diagram of an example of the entities involved in the method of initiating a bill payment;
Figure 7 is a flowchart of an example of a process for creating billing data; and,
Figures 8A to 8C are a flowchart of a specific example of a method of initiating a bill payment.
Detailed Description of the Preferred Embodiments
An example of initiating a bill payment will now be described with reference to Figure 1.
For the purpose of this example, it is assumed that the process is performed utilising a transaction system including a transaction device, such as a transaction terminal or client device and one or more payment processing devices. The transaction terminals could include any form of transaction terminal and could include a point of sale terminal, ATM (Automatic Teller Machine), mobile point of sale (MPOS) device, credit card reader or the like. The payment processing device(s) are typically part of one or more processing systems, such as one or more servers, and may form part of a payment network backend, or similar. Whilst reference may be made generally to a single processing device, this is for the purpose of ease of explanation only and it will be appreciated that in practice functionality could be distributed across multiple processing devices, and the term should not be considered as limiting. The client device is typically a suitably programmed mobile communications device, such as a mobile phone, tablet or the like, which can be connected to the payment processing device(s) via a communications network.
In this example, the process involves receiving a transaction message indicative of a transaction at step 100. The transaction message is typically received from a transaction device, such as a transaction terminal or client device, as part of the process of performing a transaction. The transaction could be any form of transaction, which is typically performed in respect of a user account, and could include a payment to a merchant or other third party, balance enquiry, deposit or withdrawal of funds, funds transfer or the like. The nature of the transaction message will depend on the transaction being performed, and the transaction device used to perform the transaction, but will typically include at least some of the information required to perform the transaction, such as a transaction amount, receipt details, account details or the like.
At step 110 an identifier is determined from the transaction message, the identifier being at least partially indicative of an identity of the user or an identity of an account of the user. Accordingly, it will be appreciated that this could include information, such as a user name, a Primary Account Number (PAN), account number, credit card number, or the like.
At step 120 the payment processing device determines at least one bill to be paid from billing data indicative of nominated bills for each of a number of users. In particular, the processing device uses the identifier obtained from the transaction message in order to access an indication of at least one bill to be paid from the billing data. In this regard, the billing data typically includes details of due bills for multiple users, with each user nominating one or more billers, allowing information regarding due bills to be retrieved or otherwise received from respective billers, as will be described in more detail below.
At step 130, the processing device causes a bill indication indicative of the bill to be displayed to the user, using the transaction device, thereby allowing a user to selectively initiate a bill payment process at step 140. For example, the user could simply select the displayed indication of the bill and an associated bill pay option, thereby causing a bill payment to be processed by the payment processing device.
Accordingly, the above described process operates to determine whether there are bills to be paid on the basis of transaction data received in respect of an independent transaction. As part of this process, the payment processing device can determine an identity of either the user performing the transaction, or a user account associated with the user, utilising this in order to retrieve information regarding bills to be paid. This information can then be provided to the user using the transaction device, thereby alerting the user to the fact that a bill is due.
This process enables users to be alerted to bill payments when performing day-to-day transactions. For example, this can be performed by an acquirer associated with a party to the transaction, such as a merchant, or ATM service provider, who is otherwise unrelated to an account of the user. This ensures that users are alerted to bills in a wide range of circumstances, even if they are not accessing a platform hosted by a biller or account holder, increasing the likelihood that the user will be made aware of the bill in a timely fashion, reducing the chance of the bill being accidentally overlooked. Additionally, the system also allows payment to be made, thereby facilitating the bill payment process and increasing the chance of bills being paid on time.
A number of further features will now be described.
The bill indication can be displayed to the user in any suitable manner. In one example, the bill indication is displayed on the transaction device by having the processing device generate a bill message which is indicative of bill details, including one or more of a bill identity, a biller identity, a bill amount, a bill reference or a bill due date. The bill message can be provided to the transaction device, with the transaction device being responsive to the bill message to display the bill indication, which is in turn indicative of at least some of the bill details, and at least a biller or bill identity.
Following display of the bill indication, the user can then optionally select a bill payment option allowing the bill to be paid using a selected payment mechanism, such as the account being used for the current transaction. In one example, this is performed by having the transaction device detect selection of a payment option based on user input commands, enabling a bill payment request to be generated and provided to the one or more payment processing devices. The payment processing devices then receive the bill payment request and initiate the bill payment process based on the bill payment request.
Accordingly, it will be appreciated that this provides a mechanism for bill details to be displayed to the user on the transaction device allowing the user to selectively initiate the bill payment process. Whilst all bill details could be initially displayed, in an alternative example the method includes displaying an indication of either a biller identity or bill identity, allowing the user to choose whether to view further information. For example, in the event that the user is interested in proceeding with the bill payment, the user can select a bill payment option causing further information such as an indication of the bill amount to be displayed on the transaction device. This allows the user to rapidly assess whether they are interested in paying the bill and if so allows further information to be displayed only as required.
Once additional information has been displayed and the user confirms they wish to proceed with the bill payment, the user can select a bill payment option, with this being detected by the transaction device in accordance with user input commands, allowing the bill payment request to be generated.
In the above process, all of the bill details can be transferred to the transaction device as part of the bill message, with only the biller or bill identity initially being displayed. Alternatively, initially only the bill or biller identity could be provided to the transaction device with the remaining details being requested if required by the user. In this example, the transaction device generates a bill details request, providing this to the one or more payment processing devices, which in turn determine bill details, generate a bill details message indicative of the bill details and provide the bill details message to the transaction device. The transaction device is then responsive to the bill details message to display remaining bill details to the user allowing the user to choose whether or not to pay the bill.
The payment processing device could be of any appropriate form and typically forms part of a back end payment system. In one example the one or more payment processing devices include an acquirer processing device that communicates with the transaction device to allow the transaction to be performed, and a payment network processing device that communicates with the acquirer processing device. In this example the acquirer processing device typically administers an account of a party to the transaction other than a user. The party could be a provider of an ATM machine, a merchant with whom the transaction is performed or the like. In such a situation, the one or more payment processing devices also typically include an issuer processing device that administers a user account of the user with the transaction and/or bill payment involving a payment from the user account to an account of the third party or biller, with this process being coordinated by the acquirer, issuer and network payment processing devices, as required.
The division of processing between the acquirer and the payment network processing device will vary depending on the preferred implementation. For example, billing data could be created, maintained and stored by the payment network processing device, or alternatively could be provided to the acquirer processing device, allowing the acquirer processing device to query the billing data.
In one example, the acquirer processing device receives the transaction message, determines the identifier from the transaction message and provides an indication of the identifier to the payment network processing device. Following this, the payment network processing device receives the indication of the identifier, determines the bill details associated with any bills to be paid and then provides an indication of the bill details to the acquirer processing device. This allows the acquirer processing device to provide the bill message to the transaction device. Accordingly, in this example the billing data is typically stored by and accessed by the payment network processing device, with the acquirer determining the identifier and passing this to the payment network processing device to allow bill details to be retrieved.
In an alternative example, the acquirer processing device can receive the transaction message and forward this to the payment network processing device which then determines the identifier, determines the bill details using the identifier and provides an indication of the bill details to the acquirer processing device. Thus, in this example, the payment network processing device performs the additional step of determining the identifier from the transaction data, but with the billing data still being stored and maintained by the payment network processing device.
In another example, the payment network processing device provides billing data to the acquirer processing device. This can performed as part of a batch transfer process, allowing the billing data to be updated periodically as required, for example on a daily basis. In this example, upon receiving the transaction message the acquirer processing device typically determines the identifier from the transaction message, determines bill details associated with any bills to be paid using the identifier and the billing data, and provides the bill message to the transaction device. Thus, in this example, billing data is created by the payment network processing device and pushed to the acquirer processing device, allowing the acquirer processing device to obtain the bill details without requiring further action from the payment network processing device.
As a further alternative, the payment network processing device can store billing data in a billing database which can also be accessed by the acquirer processing device. In this example the acquirer processing device typically receives the transaction message, determines the identifier from the transaction message, and then determines bill details associated with any bills to be paid using the identifier and the billing database. Again the acquirer processing device can then provide the bill message to the transaction device.
The transaction device can be of any appropriate form and in one example includes a user operated device ensuring that details of the bill are only provided to the user, in turn ensuring user privacy requirements are met. The transaction device can include a transaction terminal, a point of sales (POS) terminal, or an ATM, or a user client device such as a mobile phone or tablet, capable of displaying a merchant website or other payment portal and accepting user input which is transmitted to the payment portal for processing. In this latter case, it will be appreciated that functionality of the transaction device can be divided between the user client device and a web server or the like which hosts the merchant website. The extent to which the merchant web server is involved will depend upon the manner in which a payment system is implemented via the website and in particular whether this is hosted locally by the web server, or involves redirecting the client device to a payment portal such as a payment gateway and/or a portal hosted by the acquirer processing device, as will be appreciated by persons skilled in art.
The nature of the transaction will vary depending upon the preferred implementation but could include any one or more of a payment to a third party other than the biller (such as another merchant), an online payment, a funds transfer, a cash deposit, a cash withdrawal or a balance enquiry. It will be appreciated from this that the techniques can be performed with a wide range of different transactions and that the specified examples are not intended to be limiting.
In one example, in order to participate in the scheme a user must undergo a registration process in which they nominate billers for whom alerts are to be provided. As part of this, the payment processing devices receive a biller selection message indicative of one or more of billers from a user client device, and then use the indication of the billers to generate the billing data.
In one particular example, this process involves having a user client device provide biller registration requests to the one or more payment processing devices which then respond by determining a list of available billers registered with the system, generating a biller message indicative of the available billers, and providing the biller message to the client device. The client device receives the biller message, displays a list of available billers, determines user selection of one of more of the billers in accordance with user input commands, generates a biller selection message in accordance with the user selection and then provides the biller selection message to the one or more payment processing devices. The payment processing devices then typically update the billing data stored in the billing database. In this example, when a biller issues a bill, this information is obtained by the payment processing device and added to the billing data. In this way, once a transaction is performed the payment processing device, and in particular either the acquirer processing device or the payment network processing device can access the billing data and retrieve details of any outstanding bills.
In one example, the process is performed by one or more processing systems operating as part of a distributed architecture, an example of which will now be described with reference to Figure 2.
In this example, a number of processing systems 210 are provided coupled to one or more transaction terminals 220, and one or more client devices 230, via one or more communications networks 240, such as the Internet, and/or a number of local area networks (LANs).
The processing systems 210 are typically operated by parties, such as acquirers, service providers and issuers, and in one example, three types of processing devices, corresponding to acquirer processing systems 210.1, payment network processing systems 210.2 and issuer processing systems 210.3 are shown. However, it will be appreciated that any number of processing systems and similarly any number of transaction terminals 220 could be provided, and the current representation is for the purpose of illustration only. The configuration of the networks 240 is also for the purpose of example only, and in practice the processing systems 210, transaction terminals 220 and client device 230 can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as 802.11 networks, the Internet, LANs, WANs, or the like, as well as via direct or point-to-point connections, such as Bluetooth, or the like.
In use, the processing systems 210, are adapted to be perform various data processing tasks forming part of a transaction process, and the particular functionality will vary depending on the particular requirements. For example, the processing systems can be adapted to determine transaction details, perform transactions, identify bills, provide details of bills and perform bill payments, or cause further payment systems (not shown), such as servers of financial institutions, payment gateways or the like, to perform payments, as will be appreciated by persons skilled in the art.
Whilst the processing systems 210 are shown as single entities, it will be appreciated they could include a number of processing systems distributed over a number of geographically separate locations, for example as part of a cloud based environment. Thus, the above described arrangements are not essential and other suitable configurations could be used.
An example of a suitable processing system 210 is shown in Figure 3. In this example, the processing system 210 includes at least one microprocessor 300, a memory 301, an optional input/output device 302, such as a keyboard and/or display, and an external interface 303, interconnected via a bus 304 as shown. In this example, the external interface 303 can be utilised for connecting the processing system 210 to peripheral devices, such as the communications networks 240, databases 211, other storage devices, or the like. Although a single external interface 303 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (eg. Ethernet, serial, USB, wireless or the like) may be provided.
In use, the microprocessor 300 executes instructions in the form of applications software stored in the memory 301 to allow the required processes to be performed. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.
Accordingly, it will be appreciated that the processing system 210 may be formed from any suitable processing system, such as a suitably programmed transaction terminal, PC, web server, network server, or the like. In one particular example, the processing system 210 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. However, it will also be understood that the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
As shown in Figure 4, in one example, the transaction terminal 220 includes at least one microprocessor 400, a memory 401, an input/output device 402, such as a keyboard and/or display, an external interface 403, and typically a card reader 404, interconnected via a bus 405 as shown. In this example the external interface 403 can be utilised for connecting the transaction terminal 220 to peripheral devices, such as the communications networks 240 databases, other storage devices, or the like. Although a single external interface 403 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (eg. Ethernet, serial, USB, wireless or the like) may be provided. The card reader 404 can be of any suitable form and could include a magnetic card reader, or contactless reader for reading smartcards, or the like.
In use, the microprocessor 400 executes instructions in the form of applications software stored in the memory 401, and to allow communication with one of the processing systems 210.
Accordingly, it will be appreciated that the transaction terminals 220 may be formed from any suitable transaction terminal, and could include suitably programmed PCs, Internet terminal, lap-top, or hand-held PC, POS terminals, ATMs or the like, as well as a tablet, or smart phone, with integrated or connected card reading capabilities. However, it will also be understood that the transaction terminals 220 can be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
In one example, the client device 230 is a handheld computer device such as a smart phones or a PDA such as one manufactured by AppleTM, LGTM, HTCTM, Research In MotionTM, or MotorolaTM. In one particular example, the client device 230 includes a mobile phone or a computer such as a tablet computer. An exemplary embodiment of the client device 230 is shown in Figure 5. As shown, the client device 230 includes the following components in electronic communication via a bus 506:
1. a display 502;
2. non-volatile memory 504;
3. random access memory ("RAM") 508;
4. N processing components 510;
5. a transceiver component 512 that includes N transceivers;
6. user controls 514;
7. microphone/speaker 507.
Although the components depicted in Figure 5 represent physical components, Figure 5 is not intended to be a hardware diagram; thus many of the components depicted in Figure 5 may be realized by common constructs or distributed among additional physical components. Moreover, it is certainly contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to Figure 5.
The display 502 generally operates to provide a presentation of content to a user, and may be realized by any of a variety of displays (e.g., CRT, LCD, HDMI, micro-projector and OLED displays). And in general, the non-volatile memory 504 functions to store (e.g., persistently store) data and executable code including code that is associated with the functional components of a browser component and a transaction App 508. In some embodiments, for example, the non-volatile memory 504 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation of one or more portions of the transaction App 518 as well as other components well known to those of ordinary skill in the art that are not depicted for simplicity.
In many implementations, the non-volatile memory 504 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from the non-volatile memory 504, the executable code in the non-volatile memory 504 is typically loaded into RAM 508 and executed by one or more of the N processing components 510.
The N processing components 510 in connection with RAM 508 generally operate to execute the instructions stored in non-volatile memory 504 to effectuate the functional components. As one of ordinarily skill in the art will appreciate, the N processing components 510 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components.
The transceiver component 512 includes N transceiver chains, which may be used for communicating with external devices via wireless networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme. For example, each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS networks), and other types of communication networks.
Accordingly, it will be appreciated that the client device 230 be formed from any suitably programmed processing system and could include suitably programmed PCs, Internet terminal, lap-top, or hand-held PC, a tablet, a smart phone, or the like. However, it will also be understood that the client device 230 can be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
Examples of the processes for initiating bill payments will now be described in further detail. For the purpose of these examples it is assumed that one or more respective processing systems 210 are servers that provide functionality required of the acquirer, the issuer and the card services provider, and will be referred to respectively as acquirer, issuer and provider servers. The servers 210 typically execute processing device software, allowing relevant actions to be performed, with actions performed by the server 210 being performed by the processor 300 in accordance with instructions stored as applications software in the memory 301 and/or input commands received from a user via the I/O device 302. It will also be assumed that actions performed by the transaction terminal 220, are performed by the processor 400 in accordance with instructions stored as applications software in the memory 401 and/or input commands received from a user via the I/O device 402, whilst actions performed by the client device 230 are performed by the processor 510 in accordance with instructions stored as applications software in the memory 504 and/or input commands received from a user via the user controls 514.
However, it will be appreciated that the above described configuration assumed for the purpose of the following examples is not essential, and numerous other configurations may be used. It will also be appreciated that the partitioning of functionality between the different processing systems may vary, depending on the particular implementation.
An example of the interaction of the various entities involved will now be described with reference to Figure 6.
In this example, as shown in Figure 6, a customer 600 utilises a client device 630 to interact directly with the payment network server 610.2. The customer can also interact directly with the transaction terminal 620 which in turn interacts with the acquirer server 810.1. The issuer server 810.3 is also in communication with the payment network server 810.2, whilst either or both of the payment network server 810.2 and acquirer server 810.1 can have access to a database 811, which stores billing data associated with user that have registered for bill updates.
An example of a process of registering for bill updates will now be described in more detail with reference to Figure 7.
In this example at step 700 the user selects to register a biller. This is typically performed by utilising a payment application executed by the client device 230 and selecting an appropriate menu option from within the payment application.
At step 710 the payment application generates and provides a biller registration request to the payment network server 610.2. The payment network server 610.2 retrieves a list of available billers from a suitable billing database or the like at step 720. The available billers are typically billers that have previously registered with the system to allow bills and/or reminders to be delivered utilising the process described herein.
At step 730, the payment network server 610.2 generates a biller message including a list of available billers, providing this to the user client device 230. The user client device then displays a list of available billers at step 740, allowing a user to select one of the billers at step 750 through suitable interaction with the payment application. The payment application then provides a biller selection message to the payment network server 610.2 at step 760, which operates to update billing data stored in the database 611, and associated with the respective user, at step 770.
It will be appreciated that when a biller has been added to the database for the respective user, the payment network server 610.2 typically generates a biller notification, which is transferred to the respective biller, informing the biller that when bills are issued for the respective user in future, details of the bills should be provided to the payment network server 610.2, allowing these to be added to the billing data stored in the database 611 for the respective user.
As previously discussed, in one example the billing data could then be accessed directly by the acquirer server or alternatively could be uploaded to the acquirer server as part of a batch update process. However, for the purpose of the following example, it will be assumed that querying of the billing data is performed by the payment network server 610.2.
In this example, a user operates to commence a transaction at step 800. The transaction can be performed in any one of a number of ways depending on the preferred implementation. For example, the transaction could be performed by having the user interact with an ATM or other transaction device, providing payment information, such as payment card to the transaction device, allowing the transaction device to retrieve relevant payment data, such as a PAN, account number or the like. Alternatively, the transaction can be commenced in an online environment, for example by having a user perform an online purchase with a merchant, with part of this process involving having the user enter payment details into a website. The website could be hosted by the merchant themselves, or alternatively could be hosted as part of a payment gateway.
In either case, at step 805 a transaction message is provided to an acquirer server 610.1 with the acquirer server being operated by an acquirer associated with the transaction device 220 and/or administering an account of the merchant. The transaction message is typically utilised in order to perform a transaction, in particular allowing the transaction to be processed at step 810. Processing of the transaction will involve a number of steps, such as seeking authorisation from an issuer associated with an account of the user and subsequently transferring batch data to the issuer in order to cause the payment to be performed. It will be appreciated that such transaction processes are well known in the art and these will not therefore be described in any further detail.
In parallel with this traditional transaction process, at step 815 the payment network server 610.2 determines an identifier, either by receiving this from the acquirer server 610.1, or extracting this from a transaction message received from the acquirer server 610.1, for example as part of the transaction process. The identifier could correspond to an account number of the user or could correspond to other information identifying user, such as a user name or the like.
Irrespective of the form of the identifier, at step 820, the payment network server 610.2 operates to determine details of bills payable from the billing data, using the identifier. Thus the payment network server 610.2 operates to retrieve billing data for the respective user, based on the identifier, and then from this determines if there are any bills outstanding or due.
At step 825, the payment network server 610.2 provides bill details to the acquirer server 610.1 which in turns transfers a bill message to the transaction device at step 830. Thus, this will involve transferring a bill message to either the client device 230, for example via a merchant website, or to the transaction terminal 220, depending on the manner in which the transaction is being performed.
At step 835 the transaction device, and in particular the transaction terminal 220 or the client device 230, displays an indication of any bills to be paid. The indication can simply be an indication of a bill name or an identity of a biller, such as "phone bill" or could include additional information, such as a biller amount, payment reference numbers or the like.
In this example, at step 840, the user selects one or more bills of interest, allowing additional information relating to the bill to be retrieved. To do this, at step 845 the transaction device generates a bill details request, which is provided to the payment network server 610.2. The payment network server 610.2 determines additional bill details at step 850, with these being provided to the transaction device as part of a bill details message at step 855. At step 860 the transaction device displays bill details to the user allowing the user to optionally select whether or not a bill payment is to be made at step 865. It will be appreciated that if bill details are initially displayed, steps 840 to 860 may not be required.
Assuming a bill payment is selected, at step 870, the transaction device provides a bill payment request to the payment network server 610.2, which is indicative of the selected bill. As part of this process, the user may also be required to nominate a user account from which payment is to be made, although more typically this is performed using the account associated with the transaction described above.
In any event, the payment network server 610.2 can then process the bill payment request at step 875 causing a bill payment to be performed at step 880. In particular, this typically involves transferring details of the bill payment to the issuer server 610.3, which hosts an account of the user, allowing the issuer server to debit the account, with the money being transferred to an account of the biller in accordance with normal payment processes. It will be appreciated as part of this confirmation of the bill payment could be provided to the user either via the transaction device 220 and/or via the client device 230.
Accordingly, the above described process enables a bill payment to be made when performing another transaction which is not directly related to the bill. In particular, by storing billing data centrally, either at the payment network server (or a server in communication with the payment network server), or at the acquirer server, this enables the bill to be identified when the user is performing a general transaction, such as an ATM transaction, online purchase or the like. Details of the bill can then be provided to the user, via the transaction device which is used to perform the transaction, ensuring notification of the bill is received by the user as part of the ongoing transaction process and allowing the user to simply select to perform the bill payment. This simplifies the bill payment process, and ensures users are automatically reminded regarding outstanding bills, thereby reducing the likelihood of bills being overlooked or being unpaid.
By way of a specific example, a user may proceed with performing a transaction via an ATM. In this example, the user inserts their card into the ATM and selects a transaction, such as to withdraw cash, transfer funds, deposit funds, view an account balance, or the like. As system messages are passed from the ATM to the ATM acquirer switch, the acquirer switch operates to determine details of any bills to be paid, either from locally stored billing data supplied via the payment network server, or by receiving details of bills from a payment network server. The acquirer switch can then provide a system message to the ATM, causing the ATM to display a screen including details of the bill, such as a bill name, to the user. The user can then select response options, such as to view further details, proceed with bill payment, select a payment option, or the like. Appropriate system messages are provided to the acquirer switch, allowing action to be taken, such as paying the bill by causing an account of the user to be debited.
It will also be appreciated that a similar process could be used in respect of online purchases. In this example, the user can visit a merchant website and select one or more goods or services to be acquired. Upon completion of the selection process the user will typically be required to undergo a checkout procedure during which payment details are entered or a pre-existing payment option selected. Once the payment details have been entered, these are provided to an acquirer of the merchant, either directly, or via an intermediate merchant web server. Once received, the acquirer switch can perform a similar process to that outlined above in order to determine details of outstanding bills. An indication of the bills can then be presented to the user via the merchant website, allowing the user to select whether or not the bills are to be paid.
Throughout this specification and claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.
Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

Claims:We Claim:
1)A method of initiating a bill payment in a transaction system including a transaction device in communication with one or more payment processing devices, via a communications network, the method including, in the one or more payment processing devices:
a)receiving a transaction message indicative of a transaction;
b)determining an identifier from the transaction message, the identifier being at least partially indicative of at least one of:
i) an identity of the user; and,
ii) an identity of an account of the user;
c) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of users, the at least one bill being determined at least partially in accordance with the identifier; and,
d)causing a bill indication indicative of the bill to be displayed using the transaction device to thereby allow a user to selectively initiate a bill payment process.
2) A method according to claim 1, wherein the method includes, in the one or more payment processing devices:
a) generating a bill message, the bill message being indicative of bill details including at least one of:
i) a bill identity;
ii) a biller identity;
iii) a bill amount; and
iv) a bill due date;
b) providing the bill message to the transaction device, the transaction device being responsive to the bill message to:
i) display the bill indication indicative of at least some of the bill details;
ii) determine user selection of a bill payment option in accordance with user input commands;
iii) generate a bill payment request; and,
iv) provide the bill payment request to the one or more payment processing devices;
c) receiving the bill payment request; and,
d) initiating the bill payment process at least partially in accordance with the bill payment request.
3) A method according to claim 1 or claim 2, wherein the method includes, in the transaction device:
a) displaying an indication of at least one of the biller identity and the bill identity;
b) determining user selection of a bill payment option in accordance with user input commands;
c) displaying an indication of at least the bill amount;
d) determining user selection of a bill payment confirmation in accordance with user input commands; and,
e) generating the bill payment request in response to selection of the bill payment confirmation.
4) A method according to any one of the claims 1 to 3, wherein the method includes, in the transaction device:
a) generating a bill details request;
b) providing the bill details request to the one or more payment processing devices, the one or more payment processing devices being responsive to the bill details request to:
i) determine bill details; and,
ii) generate a bill details message indicative of the bill details; and,
iii) provide the bill details message to the transaction device;
c) receiving the bill details message; and,
d) displaying a bill indication indicative of the bill details.
5) A method according to any one of the claims 1 to 4, wherein the one or more payment processing devices include:
a) an acquirer processing device that communicates with the transaction device to allow the transaction to be performed; and,
b) a payment network processing device that communicates with the acquirer processing device.
6) A method according to claim 5, wherein the acquirer processing device administers an account of a party to the transaction other than the user.
7) A method according to claim 5 or claim 6, wherein the one or more payment processing devices include an issuer processing device that administers a user account of the user and wherein at least one of the transaction and bill involvement a payment from the user account.
8) A method according to any one of the claims 5 to 7, wherein the method includes:
a) in the acquirer processing device:
i) receiving the transaction message;
ii) determining the identifier from the transaction message;
iii) providing an indication of the identifier to the payment network processing device; and,
b) in the payment network processing device:
i) receiving the indication of the identifier;
ii) determining bill details associated with any bills to be paid from the billing data using the identifier; and,
iii) providing an indication of the bill details to the acquirer processing device, the acquirer processing device being responsive to the bill details to provide the bill message to the transaction device.
9) A method according to any one of the claims 5 to 7, wherein the method includes:
a) in the payment network processing device, providing billing data to the acquirer processing device;
b) in the acquirer processing device:
i) receiving the transaction message;
ii) determining the identifier from the transaction message;
iii) determining bill details associated with any bills to be paid from the billing data using the identifier; and,
iv) providing the bill message to the transaction device.
10) A method according to claim 9, wherein the payment network processing device provide billing data to the acquirer processing device as part of a batch data transfer.
11) A method according to any one of the claims 5 to 7, wherein the method includes:
a) in the payment network processing device, storing billing data in a billing database;
b) in the acquirer processing device:
i) receiving the transaction message;
ii) determining the identifier from the transaction message;
iii) determining bill details associated with any bills to be paid using the identifier and the billing database; and,
iv) providing the bill message to the transaction device.
12) A method according to any one of the claims 5 to 7, wherein the method includes:
a) in the acquirer processing device:
i) receiving the transaction message; and,
ii) forwarding the transaction message to the payment network processing device; and,
b) in the payment network processing device:
i) receiving the transaction message;
ii) determining the identifier from the transaction message;
iii) determining bill details associated with any bills to be paid from the billing data using the identifier; and,
iv) providing an indication of the bill details to the acquirer processing device, the acquirer processing device being responsive to the bill details to provide the bill message to the transaction device.
13) A method according to any one of the claims 1 to 12, wherein the transaction device is at least one of:
a) a user operated device;
b) a transaction terminal;
c) a POS terminal;
d) an ATM; and,
e) a user client device displaying a merchant website.
14) A method according to any one of the claims 1 to 13, wherein the transaction is at least one of:
a) a payment to a third party other than the biller;
b) an online payment;
c) a payment to a merchant;
d) a cash deposit;
e) a cash withdrawal; and,
f) a balance enquiry.
15) A method according to any one of the claims 1 to 14, wherein the method includes, in the one or more payment processing devices:
a) receiving a biller selection message indicative of one or more billers from a user client device; and,
b) using the an indication of one or more billers to generate the billing data.
16) A method according to any one of the claims 1 to 15, wherein the method includes, in a user client device:
a) providing a biller registration request to the one or more payment processing devices, the one or more payment processing devices being response to the bill registration request to:
i) determine a list of available billers;
ii) generate a biller message indicative of the available billers;
iii) provide the biller message to the client device;
b) receiving the biller message;
c) display a list of available billers;
d) determine user selection of one or more of the billers in accordance with user input commands;
e) generate the biller selection message in accordance with the user selection; and,
f) provide the biller selection message to the one or more payment processing devices.
17) A method of initiating a bill payment, the method including, in one or more payment processing devices:
a) receiving a transaction message indicative of a transaction, the transaction being performed at least in part using a transaction device;
b) determining an identifier from the first transaction message, the identifier being at least partially indicative of at least one of:
i) an identity of the user; and,
ii) an identity of an account of the user;
c) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of user, the at least one bill being determined at least partially in accordance with the identifier; and,
d) causing a bill indication to be displayed using the transaction device to thereby selectively initiate a bill payment process.
18) A transaction system for initiating a bill payment, the transaction system including:
a) a transaction device;
b) one or more payment processing devices in communication with the transaction device via a communications network, wherein the one or more payment processing devices initiate a bill payment by:
i) receiving a transaction message indicative of a transaction;
ii) determining an identifier from the transaction message, the identifier being at least partially indicative of at least one of:
(1) an identity of the user; and,
(2) an identity of an account of the user;
iii) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of users, the at least one bill being determined at least partially in accordance with the identifier; and,
iv) causing a bill indication indicative of the bill to be displayed using the transaction device to thereby allow a user to selectively initiate a bill payment process.
19) A transaction system according to claim 18, wherein the one or more payment processing devices initiate a bill payment by further including:
a) generating a bill message, the bill message being indicative of bill details including at least one of:
i) a bill identity;
ii) a biller identity;
iii) a bill amount; and
iv) a bill due date;
b) providing the bill message to the transaction device, the transaction device being responsive to the bill message to:
i) display the bill indication indicative of at least some of the bill details;
ii) determine user selection of a bill payment option in accordance with user input commands;
iii) generate a bill payment request; and,
iv) provide the bill payment request to the one or more payment processing devices;
c) receiving the bill payment request; and,
d) initiating the bill payment process at least partially in accordance with the bill payment request.
20) A transaction system according to claim 18 or claim 19, wherein the transaction device is configured to:
a) display an indication of at least one of the biller identity and the bill identity;
b) determine user selection of a bill payment option in accordance with user input commands;
c) display an indication of at least the bill amount;
d) determine user selection of a bill payment confirmation in accordance with user input commands; and,
e) generate the bill payment request in response to selection of the bill payment confirmation.
21) A transaction system according to any of the claims 18 to 20, wherein the transaction device is further configured to:
a) generating a bill details request;
b) providing the bill details request to the one or more payment processing devices, the one or more payment processing devices being responsive to the bill details request to:
i) determine bill details; and,
ii) generate a bill details message indicative of the bill details; and,
iii) provide the bill details message to the transaction device;
c) receiving the bill details message; and,
d) displaying a bill indication indicative of the bill details.
22) A transaction system according to any one of the claims 18 to 21, wherein the one or more payment processing devices include:
a) an acquirer processing device that communicates with the transaction device to allow the transaction to be performed; and,
b) a payment network processing device that communicates with the acquirer processing device.
23) A transaction system according to claim 22, wherein the acquirer processing device administers an account of a party to the transaction other than the user.
24) A transaction system according to any one of the claims 22 to 23, wherein the one or more payment processing devices include an issuer processing device that administers a user account of the user and wherein at least one of the transaction and bill involvement a payment from the user account.
25) A transaction system according to any one of claims 22 to 24, wherein
a) the acquirer processing device is configured to:
i) receive the transaction message;
ii) determine the identifier from the transaction message;
iii) provide an indication of the identifier to the payment network processing device; and,
b) the payment network processing device is configured to:
i) receive the indication of the identifier;
ii) determine bill details associated with any bills to be paid from the billing data using the identifier; and,
iii) provide an indication of the bill details to the acquirer processing device, the acquirer processing device being responsive to the bill details to provide the bill message to the transaction device.
26) A transaction system according to any one of the claims 22 to 24, wherein
a) the payment network processing device is configured to provide billing data to the acquirer processing device; and
b) the acquirer processing device is configured to
i) receive the transaction message;
ii) determine the identifier from the transaction message;
iii) determine bill details associated with any bills to be paid from the billing data using the identifier; and,
iv) provide the bill message to the transaction device.
27) A transaction system according to claim 26, wherein the payment network processing device is configured to provide billing data to the acquirer processing device as part of a batch data transfer.
28) A transaction system according to any one of the claims 22 to 24, wherein
a) the payment network processing device is configured to store billing data in a billing database; and
b) the acquirer processing device is configured to:
i) receive the transaction message;
ii) determine the identifier from the transaction message;
iii) determine bill details associated with any bills to be paid using the identifier and the billing database; and,
iv) provide the bill message to the transaction device.
29) A transaction system according to any one of the claims 22 to 24, wherein
a) the acquirer processing device is configured to:
i) receive the transaction message; and,
ii) forward the transaction message to the payment network processing device; and,
b) the payment network processing device is configured to:
i) receive the transaction message;
ii) determine the identifier from the transaction message;
iii) determine bill details associated with any bills to be paid from the billing data using the identifier; and,
iv) provide an indication of the bill details to the acquirer processing device, the acquirer processing device being responsive to the bill details to provide the bill message to the transaction device.
30) A transaction system according to any one of the claims 18 to 29, wherein the transaction device is at least one of:
a) a user operated device;
b) a transaction terminal;
c) a POS terminal;
d) an ATM; and,
e) a user client device displaying a merchant website.
31) A transaction system according to any one of the claims 18 to 30, wherein the transaction is at least one of:
a) a payment to a third party other than the biller;
b) an online payment;
c) a payment to a merchant;
d) a cash deposit;
e) a cash withdrawal; and,
f) a balance enquiry.
32) A transaction system according to any one of the claims 18 to 31, wherein the one or more payment processing devices are also configured to:
a) receive a biller selection message indicative of one or more billers from a user client device; and,
b) use the an indication of one or more billers to generate the billing data.
33) A transaction system according to any one of the claims 18 to 32, wherein a user client device is configured to:
a) provide a biller registration request to the one or more payment processing devices, the one or more payment processing devices being response to the bill registration request to:
i) determine a list of available billers;
ii) generate a biller message indicative of the available billers;
iii) provide the biller message to the client device;
b) receive the biller message;
c) display a list of available billers;
d) determine user selection of one or more of the billers in accordance with user input commands;
e) generate the biller selection message in accordance with the user selection; and,
f) provide the biller selection message to the one or more payment processing devices.
34) A transaction system for initiating a bill payment, the transaction system including one or more payment processing devices in communication with a transaction device via a communications network that initiate a bill payment by:
a) receiving a transaction message indicative of a transaction;
b) determining an identifier from the transaction message, the identifier being at least partially indicative of at least one of:
i) an identity of the user; and,
ii) an identity of an account of the user;
c) determining at least one bill to be paid from billing data indicative of nominated bills for each of a number of users, the at least one bill being determined at least partially in accordance with the identifier; and,
d) causing a bill indication indicative of the bill to be displayed using the transaction device to thereby allow a user to selectively initiate a bill payment process.