US20150220889A1 - Systems and methods of direct account transfer - Google Patents
Systems and methods of direct account transfer Download PDFInfo
- Publication number
- US20150220889A1 US20150220889A1 US14/689,894 US201514689894A US2015220889A1 US 20150220889 A1 US20150220889 A1 US 20150220889A1 US 201514689894 A US201514689894 A US 201514689894A US 2015220889 A1 US2015220889 A1 US 2015220889A1
- Authority
- US
- United States
- Prior art keywords
- user
- payment
- account
- bank
- amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
Definitions
- the present disclosure generally relates to monetary transfers and, more specifically, to systems and methods for facilitating direct account transfers.
- ACH Automated Clearing House
- a customer connects to a server associated with his or her bank, enters the transaction details, and submits the transfer request.
- the money is transferred directly to the merchant account from the customer account via ACH.
- the customer To transfer money via a third party, the customer connects to a server associated with the third party, enters the transaction details, and submits the transfer request.
- the money is transferred from the customer account to an account of the third party and then from the third-party account to the merchant account.
- FIG. 1 is a block diagram depicting an example single ledger accounting platform, according to some embodiments.
- FIG. 2 is a block diagram depicting an example accounting application framework for the accounting platform, according to some embodiments.
- FIG. 3 is a block diagram depicting an example hosting infrastructure for the accounting platform, according to some embodiments.
- FIG. 4 is a block diagram depicting an example data center system of the accounting platform, according to some embodiments.
- FIG. 5 is a block diagram depicting an example client device for accessing the accounting platform, according to some embodiments.
- FIG. 6 is an interface diagram depicting an example user interface (UI) displaying accounts accessible by a user of the accounting platform, according to some embodiments.
- UI user interface
- FIG. 7 is an interface diagram depicting an example user interface for creating an invoice from a business, according to some embodiments.
- FIG. 8 is an interface diagram depicting an example user interface displaying an invoice from a business, according to some embodiments.
- FIG. 9 is an interface diagram depicting an example user interface for configuring bank options, according to some embodiments.
- FIG. 10 is an interface diagram depicting an example user interface for paying an invoice from a business, according to some embodiments.
- FIG. 11 is a block diagram depicting the flow of data between entities facilitating a transfer of funds, according to some embodiments.
- FIG. 12 is a flowchart of an example method for facilitating direct bank transfers, according to some embodiments.
- FIG. 13 is a flowchart of an example method for facilitating direct bank transfers, according to some embodiments.
- FIG. 14 is a block diagram of a machine in the example form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed, according to some embodiments.
- Example systems and methods to facilitate direct bank transfers are described.
- numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the present technology may be practiced without these specific details.
- the technology described herein provides online accounting software to businesses with features such as a payment mechanism available to a business's customers, where the payment mechanism may drive payments through a bank rather than third-party payment services (e.g., credit card transaction processors, PayPal, and so on).
- financial institutions may also use such payment features to let trusted partners submit payments to them for confirmation and processing.
- the financial institution and the payment initiator may exchange public keys, to enable the secure exchange of data.
- the business provides its account information to the payment initiator.
- the payment initiator can encrypt the account information along with details for a particular invoice (such as payment amount and payment date) and transmit the information to the financial institution.
- the financial institution can decrypt the information and initiate a transfer of money from one of the customer's bank accounts to the business on the payment date.
- the financial institution presents the information about the transaction to the customer for modification or confirmation before initiating the transfer.
- the financial institution allows the customer to confirm or cancel the transaction, but not to modify it.
- the payment initiator may include one or more flags in the data to indicate whether the various prepopulated fields for the transaction (e.g., payment amount, payment date, and so on) can be modified by the customer. Based on the flags, the financial institution can modify the options presented to the customer.
- the various prepopulated fields for the transaction e.g., payment amount, payment date, and so on
- the information may be sent from the payment initiator to the financial institution via the customer.
- the encrypted data may be sent from a web site of the payment initiator to a web browser of the customer running on a customer device.
- a confirmation may be sent to the customer, the payment initiator, the business, or any suitable combination thereof.
- FIG. 1 is a block diagram depicting an example single ledger accounting system 100 .
- a single ledger accounting system 100 may provide accounting tools to a particular entity managing accounting for one or more businesses.
- the example single ledger accounting system 100 may include a practice studio 110 that allows an entity to manage one or more businesses and an organization access module 150 that provides a business with tools for managing accounting data for that particular business.
- the practice studio 110 may include a practice staff management module 114 , an online training module 116 , a partner resources module 120 , a report packs setup module 122 , and a work papers module 124 .
- the practice studio 110 may be in communication with core features 130 .
- the core features 130 may include an accounting and payroll module 132 , a community module 134 , a billing/subscription management module 136 , a notifications center module 138 , a user profile management module 140 , and a login module 142 .
- the organization access module 150 may be in communication with the core features 130 .
- the practice studio 110 and core features may be accessed by an entity using a login module 142 .
- features of the system 100 are divided into three areas based on the target user.
- the features of the practice studio 110 provide a suite of tools for accountants to interact with their clients and manage their practices.
- the core features 130 provide the core functionality and user tools common to both accountants and businesses.
- the organization access 150 provides a user interface for individual businesses to access their data.
- Practice studio 110 is the central login for accountants. For example, an accountant with multiple clients, each of which is a small business, can login using practice studio 110 and gain access to the accounting data for the clients, messages from the clients, and so on.
- the practice staff management module 114 provides the ability for the manager of an accounting practice to control settings for the staff of the practice. For example, some staff members may have read-only access to data for certain clients, some staff members may have read-write access for certain clients, some staff members may be able to modify the access permissions for other staff members, and so on.
- the online training module 116 provides training for accountants and their staff.
- the provided training includes one or more video presentations and one or more online tests. Notification of passing a test at completion of a training may be provided.
- a staff member may take a training course and, upon successful completion, the accountant supervising the staff member may receive a notification of the successful completion.
- the partner resources module 120 provides information regarding third-party partners.
- a third party may provide tools that interact with the system to provide useful functionality beyond that of the system alone.
- the user can access the partner resources module 120 to learn about available third-party tools. For example, links to third-party websites, documentation, videos, and search tools may all be provided.
- the report packs setup module 122 provides tools to allow accountants to create and generate standardized sets of reports. For example, a profit and loss statement and quarterly report could both be added to a pack. The accountant would then be able to easily generate both reports for any selected client, or generate the reports for every client.
- the work papers module 124 provides tools for accountants to interactively create financial reports. For example, an accountant can enter known data for a client into the work paper, and then send the work paper to the client with an indication of data needed from the client. After the client enters the missing data into the work paper, the accountant can complete the report.
- the core features 130 includes modules that are used both by accountants and organizations.
- the accounting and payroll module 132 provides the general ledger for organizations.
- the general ledger may be integrated with the organization's payroll, bypassing the separate step of entering payroll data into the general ledger each pay period.
- the accounting and payroll module 132 accesses banking data for each client business.
- the banking data may be imported into either through a bank feed or a user- or accountant-created document.
- the accounting and payroll module 132 may also communicate with third-party tools via an application protocol interface (API).
- API application protocol interface
- the community module 134 provides a forum through which users can communicate. For example, a user with a question may post a topic in the forum and later receive a helpful response from another user. Information taken from the user profile (e.g., the user profile managed via the user profile management module 140 ) may appear along with forum posts by the user. For example, a user name, an image of the user, and the user's status as an accountant or member of an organization may each be shown.
- the billing/subscription management module 136 allows a user to configure one or more billing accounts for each organization using the system.
- the system may periodically charge a subscription fee for access (e.g., a monthly or annual subscription fee).
- the subscription fee may be automatically deducted from the one or more billing accounts.
- the notifications center module 138 provides notifications to users. For example, users may send messages to each other, which appear as notifications. Notifications may also be created by the system (e.g., by accounting and payroll module 132 ) based on events. For example, a minimum account balance for a particular bank account may be set by a user via the accounting & payroll module 132 . When the balance for that bank account drops below the minimum account balance, a notification can be generated by the system informing the user.
- the user profile management module 140 allows a user to manage the profile of the user's organization and the profiles of others based on permission settings. For example, an accountant may have permission to manage the profiles of the accountant's clients.
- the profile may include public-facing information such as a business name and address.
- the login module 142 verifies the identify of a user logging into the system (e.g., via user name and password). Based on the user's identity, a user interface is presented that includes a list of organizations that a user has access to. For most small business clients, the list will consist of a single organization.
- the organization access module 150 accesses the core features 130 for a single organization.
- the organization access module 150 presents, after user verification by the login module 142 , a user interface with options for a single organization without the additional features used only by the practice studio 110 .
- FIG. 2 is a block diagram depicting an example accounting application framework 200 for the accounting platform.
- the accounting application framework 200 may be an end-to-end web development framework enabling a “software as a service” (SaaS) product.
- the accounting application framework 200 may include a hypertext markup language (HTML) and/or JavaScript layer 210 , ASP.Net Model-View-Controller (MVC) 220 , extensible stylesheet language transformations (XSLT) 230 , construct 240 , services 250 , object relational module 260 , and database 270 .
- HTTP hypertext markup language
- MVC ASP.Net Model-View-Controller
- XSLT extensible stylesheet language transformations
- the HTML and/or JavaScript layer 210 provides client-side functionality, such as UI generation, receipt of user input, and communication with a server.
- the client-side code may be created dynamically by the ASP.NET MVC 220 or the XSLT 230 .
- the client-side code may be statically created or dynamically created using another server-side tool.
- the ASP.Net MVC 220 and XSLT 230 provide server-side functionality, such as data processing, web page generation, and communication with a client. Other server-side technologies may also be used to interact with the database 270 and create an experience for the user.
- the construct 240 provides a conduit through which data is processed and presented to a user.
- the ASP.Net MVC 220 and XSLT 230 can access the construct 240 to determine the desired format of the data.
- client-side code for presentation of the data is generated.
- the generated client-side code and data for presentation is sent to the client, which then presents the data.
- the services 250 provide reusable tools that can be used by the ASP.Net 220 , the XSLT 230 , and the construct 240 to access data stored in the database 270 .
- aggregate data generated by calculations operating on raw data stored in the database 270 may be made accessible by the services 250 .
- the object relational model 260 provides data structures usable by software to manipulate data stored in the database 270 .
- the database 270 may represent a many-to-one relationship by storing multiple rows in a table, with each row having a value in common.
- the software may prefer to access that data as an array, where the array is a member of an object corresponding to the common value.
- the object relational model 260 may convert the multiple rows to an array when the software accesses them and perform the reverse conversion when the data is stored.
- FIG. 3 is a block diagram depicting an example hosting infrastructure 300 for the accounting platform.
- the platform may be implemented using one or more pods 310 .
- Each pod 310 includes application server virtual machines 320 (shown as application server virtual machines 320 a - 320 c in FIG. 3 ) that are specific to the pod 310 as well as application server virtual machines (VMs) that are shared between pods 310 (e.g., the internal services VM 330 and the application protocol interface VM 340 ).
- the application server virtual machines 320 - 340 communicate with clients and third-party applications via a web interface or an API.
- the application server virtual machines 320 - 340 are monitored by application hypervisors 350 .
- An internal firewall 360 ensures that only approved communications are allowed between a database hypervisor 370 and the publically-accessible virtual machines 320 - 340 .
- the database hypervisor 370 monitors the primary SQL servers 380 a and 380 b.
- the primary SQL servers 380 a and 380 b access the shared storage layer 450 a or 450 b (shown in FIG. 4 ) to read and write data generated by or used by the application server virtual machines 320 - 340 .
- the redundant SQL servers 390 a and 390 b provide backup functionality for the primary SQL servers 380 a and 380 b , respectively.
- the virtual machines 320 - 340 can be implemented using Windows 2008 R2, Windows 2012, or another operating system.
- the application and support servers supporting the virtual machines 320 - 340 can be built using spares for redundancy.
- the support servers can be shared across multiple pods 310 .
- the application hypervisors 350 , internal firewall 360 , and database hypervisor 370 may span multiple pods 310 within a data center.
- each primary SQL server 380 and redundant SQL server 390 is configured to support 30,000-45,000 organizations. Accordingly, in embodiments using two such server pairs per pod 310 , the pod capacity is 60,000-90,000 organizations.
- the redundant SQL servers 390 may take advantage of the “always on” resilience feature of SQL 2012.
- FIG. 4 is a block diagram depicting an example data center system 400 of the accounting platform interacting with other systems over a network.
- the primary data center 410 services customer requests and is replicated to the secondary data center 420 .
- the secondary data center 420 may be brought online to serve customer requests in case of a fault in the primary data center 410 .
- the primary data center 410 communicates over a network 455 with bank server 460 , third party server 470 , client device 480 , and client device 490 .
- the bank server 460 provides banking data (e.g., via the banking application 465 ).
- the third party server 470 is running third party application 475 .
- Client devices 480 and 490 interact with the primary data center 410 using web client 485 and programmatic client 495 , respectively.
- each data center 410 and 420 a plurality of pods, such as the pod 310 of FIG. 3 , are shown.
- the primary data center 410 is shown containing pods 440 a - 440 d .
- the secondary data center 420 is shown containing pods 440 e - 440 h.
- the applications running on the pods of the primary data center are replicated to the pods of the secondary data center.
- EMC replication (provided by EMC Corporation) in combination with VMWare site recovery manager (SRM) may be used for the application layer replication.
- the database layer handles replication between the storage layer 450 a of the primary data center and the storage 450 b of the secondary data center.
- Database replication provides database consistency and the ability to ensure that all databases are at the same point in time.
- the data centers 410 and 420 use load balancers 430 a and 430 b , respectively, to balance the load on the pods within each data center.
- the data centers 410 and 420 can be created using identical hardware to ensure that the performance of the secondary data center 420 is the same as the performance of the primary data center 410 .
- the storage 450 a and 450 b may be implemented using one or more storage area networks such as the VNX storage area networks from EMC.
- the bank server 460 interacts with the primary data center 410 to provide bank records for bank accounts of the client.
- the client may provide account credentials to the primary data center 410 , which the primary data center 410 uses to gain access to the account information of the client.
- the bank server 460 can provide the banking records to the primary data center 410 for later reconciliation by the client using the client device 480 or 490 .
- the third party server 470 may interact with the primary data center 410 and the client device 480 or 490 to provide additional features to a user of the client device 480 or 490 .
- a user may authorize the third party server 470 to access the user's data stored in the primary data center 410 .
- the third party application 475 of the third party server 470 may use the user's data to generate reports, provide macros, or otherwise improve the user's ability to access or manipulate the user's data.
- the third party application 475 may communicate with the primary data center 410 via the network 455 using an API.
- the third party application 475 may communicate with the client device 480 or 490 using a web or programmatic interface.
- FIG. 5 is a block diagram 500 illustrating components of a client device suitable for mobile banking reconciliation, according to some example embodiments.
- the client device 480 or 490 is shown as including a communication module 510 , a display module 520 , an input module 530 , and a reconciliation module 540 , configured to communicate with each other (e.g., via a bus, shared memory, or a switch).
- the communication module 510 may communicate with the primary data center 410 , the third party server 470 , the network 455 , or any suitable combination thereof. Information received via the communication module 510 may be presented (e.g., displayed on a display device) via the display module 520 . Information may be selected or search queries may be entered by a user of the client device 480 or 490 .
- a user interface is presented by the display module 520 .
- the input from the user is detected by the input module 530 .
- Commands received from the user by the input module 530 may be communicated to the primary data center 410 by the communication module 510 .
- the communication module 510 may receive a response from the primary data center 410 that includes a set of banking records, a set of business records, associations between individual banking records and individual business records that indicate reconciliation between those records, and other data, in any combination.
- the reconciliation module 540 can generate requests to the primary data center 410 to indicate that a banking record is reconciled by one or more business records.
- the request can be communicated to the primary data center 410 via the communication module 510 , over the network 455 .
- FIG. 6 is an interface diagram depicting an example user interface 600 displaying accounts accessible by a user of the accounting platform.
- the elements 660 a - 660 e are individual rows of data with information about different businesses and may be referred to collectively as elements 660 .
- an individual one of the elements 660 may be referred to as an element 660 .
- An element 605 shows the name of a logged-in user along with a downward-pointing arrow.
- the name or arrow may be operable to cause the display of a user profile menu.
- the user may be able to change a contact email address, a password, and other individual information about the user.
- An element 610 shows the name of the current application interface.
- the name is “My Xero.”
- the element 610 may be used to distinguish between access by an organization (e.g., access via the organization access module 150 ) and access by an accounting practice (e.g., access via the practice studio 110 ).
- Elements 615 - 630 may be operable to cause the display of additional user interface options.
- element 615 labeled “Billing”
- the element 620 labeled “Staff,” may be operable to bring up a staff interface that allows the user to control permissions for staff members.
- the functions of the staff interface may be implemented by the practice staff management module 114 .
- the element 625 labeled “Training,” may be operable to bring up a training interface that allows the user to schedule training sessions or review the results of training sessions.
- the user may be enabled to set up a particular training session for a particular staff member.
- the element 630 labeled “Settings,” may be operable to bring up a settings interface that allows the user to modify settings for the organization.
- the organization may have a billing account on file that is used to pay for subscription access to the application.
- the settings interface can be used to add or change the billing account (e.g., using the billing/subscription management module 136 ).
- Element 635 displays the name of the accountant for the organization. In some example embodiments, a logo for the accounting firm is also displayed.
- Element 640 displays the currently selected organization and the last time data for the organization was updated.
- Element 645 is a search box.
- the user may enter one or more search terms into the search box to cause the system to search for organizations matching the search terms.
- Element 650 labeled “Group,” allows the user to select multiple organizations and put them into a custom group. Operations may then be performed on the group. For example, a report pack may be run on every organization in a selected group.
- Element 655 is a header for the elements 660 with information regarding organizations to which the user has access.
- the element 655 shows that each element 660 has a name, a date on which it was last viewed, an access permission, and subscription data.
- the name of the organization for element 660 a is Aaron Construction.
- Element 660 a further shows that Aaron Construction was last viewed today at 9:22 AM.
- the current user is a financial advisor for Aaron Construction, and has the appropriate access privileges to manage users.
- element 660 a shows that Aaron Construction has a “Large” subscription.
- the word “View” in the element 660 a may be operable to view subscription information for Aaron Construction.
- the elements 660 may be shown in the elements 660 .
- the elements 660 b, 660 d, and 660 e each show a number of unreconciled lines. This may suggest to the user that further reconciliation of banking and business records is needed for the corresponding organizations: Cafe 88 East, Artisan Kitchens, and Hawker Foods.
- the elements 660 show at least a subset of the accounts to which the user has access.
- the accounts may be associated with one or more organizations for which the user manages a business. The user may click on a link associated with one of the businesses to access and manage accounting information associated with that business.
- FIG. 7 is an interface diagram depicting an example user interface 700 creating an invoice from a business.
- the user interface 700 includes elements 710 - 790 , discussed in more detail below, and may be presented to a business user for creating an invoice for a customer.
- Element 710 is a button operable to create the invoice according to the options selected and information entered by the business user in the other elements of the UI 700 .
- operation of element 710 may cause the payment initiator to contact the customer (e.g., by email, text message, over a social network, and so on) with information regarding the invoice.
- an HTML web link may be provided to the customer, operable to cause the display of UI 800 , shown in FIG. 8 .
- element 710 is also operable to save the work in progress on an invoice without actually sending the invoice to the customer. Alternatively or additionally, another element is used to save the work in progress.
- Element 720 displays the total amount of the invoice.
- the currency in which the total is denominated may be determined by a setting of the business user (e.g., to denominate all invoices in dollars), determined automatically based on the address of the business user (e.g., to denominate invoices in New Zealand dollars based on the business user's address being in New Zealand), determined by a setting of the customer (e.g., to denominate all invoices for the customer in Euros), determined automatically based on an address of the customer (e.g., to denominate invoices to the customer in Rubles based on the customer's address being in Russia), determined by a per-customer setting of the business user (e.g., to denominate all invoices for the customer from this business in Pesos), or any suitable combination thereof (e.g., to denominate invoices in an automatically-determined currency unless overridden by an explicit setting).
- a setting of the business user e.g., to denominate all invoices in
- Element 730 displays the name of the customer.
- Element 730 may be implemented as a drop-down list or other selector, enabling the business user to select the customer.
- Element 740 displays the type of invoice.
- Element 740 may be implemented as a drop-down list or other selector, enabling the business user to select the type of invoice.
- Element 750 displays a logo for the business.
- the element 750 shows an oversized and italicized version of an example company name, “Demo Co.”
- Element 750 may be operable to cause the upload of an image file to use for the logo. For example, clicking on element 750 may cause the presentation of a file selector interface. The business user can then select an image file to use for the logo. After selecting the file, the file is transferred to the server and the image or text shown in element 750 is replaced by the uploaded image. Other ways of selecting or uploading images may also be used. In some example embodiments, text, either formatted or plain, is used in addition to or in place of an image.
- Element 760 shows the mailing address of the customer.
- the information in element 760 may be automatically generated based on the selection of the customer using element 730 .
- the business user may be enabled to edit or populate the information in element 760 .
- element 760 may be a text field, directly editable by the business user.
- a selection of element 760 can be detected. Responsive to the selection, an editing interface may be presented to the business user. After editing the address information for the customer, the customer's address may be updated for the business user. When editing a later invoice for the same customer, the updated address may be retrieved.
- Element 770 shows metadata regarding the invoice.
- element 770 includes an invoice number, a reference name, a goods and services tax (GST) number, an issued date, and a due date.
- the metadata may be automatically generated.
- the invoice number may be generated by automatically incrementing the most recently used invoice number.
- the GST number of a business may be the same for all customers, and populated from information about the business in a database.
- the issued date may be pre-populated with the current date, and the due date may be calculated based on a pre-determined grace period (e.g., 30, 60, or 90 days).
- some or all of the metadata may be created or edited by the business user.
- Element 780 shows item detail data for the invoice. For each item, a description, a quantity, a unit price, and an amount is shown. Selecting an item description may cause a drop-down menu or other selector to appear. Using the selector, a different item may be chosen. When a different item is chosen, the description, unit price, and amount may be automatically updated. For example, if the “Golf balls—white single” with a unit price of 4.87 is replaced by “Golf balls—black triple” with a unit price of 15.00, the amount can be automatically calculated as 600.00, based on the unchanged quantity and updated unit price.
- the description, quantity, and unit price fields allow for direct entry of data, instead of or in addition to selection of items from an item database.
- the unit price for each item may be converted automatically from a currency in which the price is stored to the currency being used for the invoice. For example, if the unit prices are stored in a database denominated in NZD, but the invoice is being generated in US dollars, a current exchange rate between the two currencies can be accessed and used to convert the price.
- element 780 Also shown in element 780 is an icon in the lower right-hand corner.
- the icon may be operable to cause the addition of an additional row of item data to the invoice.
- a blank row is added to the invoice each time the last row is used, allowing the business user to add items as needed.
- Element 790 shows total detail data for the invoice. As shown in element 790 , the subtotal, GST, and amount due are shown.
- the specific line items shown in element 790 may vary based on the location of the business user, the location of the customer, and business user options. For example, one business may choose to include a shipping cost as an item included in the subtotal while another business may choose to include the shipping cost as an additional charge included in the total but excluded from the subtotal.
- the subtotal may be determined by summing the amounts shown in element 780 . Accordingly, subtotal may be automatically updated whenever an item is added or changed in the element 780 . Alternatively or additionally, a UI element operable to cause the updating may be presented.
- the GST may be calculated based on tax rules for the location of the business.
- the amount due may be determined by summing the line items in element 790 .
- a business using the online accounting software may have the ability to present online invoices to their customers, making the invoicing process more efficient.
- the business may send out an invoice and know when it has been seen by the customer. If a business has set up a payment service, their debtor may make payment through the invoice.
- FIG. 8 is an interface diagram depicting an example user interface 800 displaying an invoice from a business.
- the user interface 800 includes elements 805 - 870 , described in more detail below.
- the UI 800 may be presented in response to an activation of a link sent to the user on request of the business expecting payment on the invoice.
- the UI 800 may be presented in response to a login by the user to the accounting system, based on a determination that the user has outstanding invoices to respond to. Multiple instances of the UI 800 may be presented in sequence when multiple invoices are pending. Alternatively, an additional UI (not shown) may be presented, allowing the user to select between the pending invoices.
- Element 805 is a button, which a user (e.g., a business's customer) may select to be redirected to a bank site in order to pay the invoice.
- a user e.g., a business's customer
- the business Demo Co. (as shown by element 835 ) may be owed a particular amount for a good or service the business Demo Co. provided to their customer Bayside Club (as shown by element 845 ).
- the user interface 800 may present the invoice associated with this outstanding amount owed, and the customer may use the button 805 to initiate payment directly through the customer's bank account.
- Element 810 displays the total amount of the invoice.
- Elements 815 and 820 are operable to cause the downloading or saving of the invoice in one of a variety of formats.
- element 815 may be operable to select the format of the download (e.g., as portable document format (PDF), comma-separated value (CSV), text, Word, etc.), while element 820 may be operable to save the invoice in the selected format or a default format.
- PDF portable document format
- CSV comma-separated value
- Word etc.
- Element 830 may be operable to open a help or messaging interface that allows the user to gather information about bill payment in general, about invoices from the merchant specifically, or to send a message to the merchant.
- Element 840 indicates the type of invoice (for example, a taxable transaction, a tax-exempt transaction, a charitable contribution, and so on).
- Element 845 shows information regarding the customer such as name and mailing address.
- element 850 shows information regarding the invoicing business, including the name and mailing address.
- Element 855 shows the metadata of the invoice, including invoice number, reference, GST number of the invoicing business, date on which the invoice was issued, and date on which the invoice is due. Element 855 also shows the amount of time remaining before the invoice is due.
- Element 860 shows the line items of the invoice, including, for each item, a description, a quantity, a unit price, and an amount. In embodiments, more or fewer information for each line item is shown.
- Element 870 shows total detail data for the invoice. As shown in element 870 , the subtotal, GST, and amount due are shown. The specific line items shown in element 870 may vary based on the location of the business user, the location of the customer, and business user options. The subtotal may be determined by summing the amounts shown in element 860 . The GST may be calculated based on tax rules for the location of the business. The amount due may be determined by summing the line items in element 870 .
- a user e.g., debtor
- the user may be presented with the UI 800 including element 805 , which may include a link to a dialog listing participating banks
- element 805 may include a link to a dialog listing participating banks
- the UI 900 shown in FIG. 9
- the user may be presented in response to a selection of the “Pay Now” button (element 805 ) by the user.
- the user may be immediately redirected to the bank for payment of the invoice (e.g., as shown in the UI 1000 of FIG. 10 ), or returned to the UI 800 .
- operation of the element 805 may redirect the user's device to that bank for payment.
- FIG. 9 is an interface diagram depicting an example user interface 900 for configuring bank options for a customer.
- the UI 900 includes elements 910 - 940 , as discussed in more detail below, and may be presented to a user during initial configuration, in response to receiving an invoice, or in response to a request from the user.
- Element 910 is a title, showing that the user is currently on a “Bank Configuration” screen.
- element 920 is an informational message, requesting that the user select a default bank for invoice payments.
- Element 930 includes radio buttons to allow the user to select a bank from a list of banks for the user.
- a drop-down list or other selector is used.
- the set of banks available for selection may be the set of banks with which the payment initiator has exchanged encryption keys, a set of banks identified based on information about the user (e.g., the location of the user), a set of banks identified based on information about the transaction (e.g., the currency of the transaction), a set of banks identified based on information about the payee (e.g., the location of the payee or banks associated with the payee), or any suitable combination thereof.
- the set of banks may be accessed from a database, such as the database 380 A or storage 450 A.
- Element 940 is a button operable to confirm the selected bank. For example, the user may select the radio button corresponding to “ABC Bank” shown in the element 930 , then press the “Done” button of element 940 to save the selection. In other example embodiments, the choice of bank is made without a second confirmation action.
- a cookie may be stored on the debtor's machine so that any subsequent invoices the debtor receives from the payment initiator will automatically invoke the preference to use their chosen bank to pay the invoice. This may be changed by the user selecting another bank and replacing the information stored in the cookie.
- the payment mechanism through the direct bank transfer may be an endpoint exposed by a financial institution (and shared with a particular payment initiation partner) to which a debtor receiving a payment request is redirected, should they choose to pay using their bank.
- the direct bank transfer may avoid using a third-party intermediary, such as a credit card transaction service.
- the payment mechanism may accept the payment details, authenticate the online banking user into Internet banking, and may present the payment information for confirmation by the debtor. Benefits of this service may include:
- HTTPS secure hypertext transfer protocol
- the user may authenticate with the bank using a valid Internet banking user account.
- Data may be transferred from the payment initiator to the financial institution via the user's browser when the user chooses to make a payment.
- the data transferred may be sent in one direction, from the payment initiator to the financial institution.
- the communication protocol may be designed to avoid any server-to-server communication between the financial institution and payment initiators, meaning that virtual private networks (VPNs) or other secure infrastructure do not need to be implemented.
- the data is transferred via the user's web browser client, as an encrypted, signed blob contained within a JavaScript object notation (JSON) data structure.
- JSON JavaScript object notation
- the payment initiator assembles a blob of data containing information about the payment that the user wishes to make.
- This blob may contain payment details and other sensitive information, and hence is encrypted so the data within is opaque to the client browser transferring the data.
- the payment data may be transferred using the “Encrypt then MAC” pattern.
- a symmetric key may be randomly generated and used to encrypt the payment data.
- the payment initiator has the financial institution's public RSA key that may be used to encrypt the symmetric key.
- the financial institution may use its private RSA key to decrypt the symmetric key and in turn use it to decrypt the message.
- the payment initiator may have a private RSA key that is used to sign messages sent to the financial institution.
- the financial institution may use the payment initiator's public RSA key to verify that the signature is valid.
- Any suitable cryptographic algorithm may be used, such as AES for symmetric encryption, RSA for asymmetric encryption, RSA-SHA2 for signing, and the like. Additionally, for cryptographic keys generated and used in the system, any key sizes may be used (e.g., AES 256 bits, RSA 2048 bits, SHA 256 bits, etc.).
- Any nonce and initialization vectors may be generated from a cryptographically secure random number generator. This ensures that the symmetric encryption will be strong and prevent brute force attacks against the encrypted data bytes in the message. In some embodiments, certain default random number generators may not be cryptographically secure. Thus, a cryptographically secure algorithm should be chosen (e.g. in C#, the System.Security.Cryptography. RandomNumberGenerator class should be used instead of the System.Random class).
- the financial institution may store a private RSA key issued and held only by the financial institution (e.g., the financial institution's private key) and a public RSA key issued by the payment initiator (e.g., the payment initiator's public key).
- the payment initiator may store a public RSA key issued by the financial institution (e.g., the financial institution's public key) and a private RSA key issued and held only by payment initiator (e.g., the payment initiator's private key).
- Packaging a message to send to the financial institution may occur in a variety of manners.
- the payment initiator may use the following algorithm and/or pseudo-code to package a message for receipt by the financial institution.
- the JSON Payment containing the sensitive data may be encrypted and signed, and the resulting MessageContainer may be sent to the financial institution as a JSON data structure via the user's browser.
- Verifying and unpackaging a message upon receipt by the financial institution may occur in a variety of manners. For example, upon the receipt of a message from a payment initiator, the financial institution may decrypt and unpack the message to ensure it has come from an approved payment initiator and has not been tampered with. The following algorithm and/or pseudo-code may be used to unpack the MessageContainer and receive the Payment.
- the financial institution may then validate the internals of the payment to check that it has integrity. For example, this may include:
- the user may be shown displays allowing the user to continue to proceed with an Internet payment via internet banking
- the example message encryption and packaging described above may allow messages to pass from the payment initiator to the financial institution over an untrusted communication mechanism (the user's browser).
- the encryption and signing provide guarantees that the payment initiator legitimately generated the message, the message was not tampered with or viewed in transit, and the message cannot be replayed.
- the payment initiator can also be assured that only the financial institution will be able to decrypt the data.
- the payment initiator may sign the data using their private key, which is kept secret and held only by them.
- the FI receives the message and checks the signature using the PI's public key, they can be assured the PI originally generated the message.
- the signature check may also prevent tampering in transit. If the initialization vector (IV), key or data is altered, then the signature check will fail.
- the payment may contain some sensitive information, such as amounts and account numbers. This may be encrypted using a one-time-use encryption key.
- the encryption key may be transmitted in the message, but may be encrypted asymmetrically using the FI's public key, which only the FI can decrypt.
- Replay attacks may be prevented by a timestamp and nonce value that allows the FI to guarantee it will receive and process a given message only once. If a message arrives with the same timestamp and nonce, the FI may reject the message.
- MiTM Man-in-the-middle
- Denial of Service This protocol may not provide protection against denial of service; an attacker could send large, malformed, or numerous messages to the FI endpoint and cause a costly signature check or decryption process to occur. This should be mitigated by using the FI's standard brute force detection mechanisms.
- Elevation of Privilege The message transferred from the payment initiator to the FI may not convey privileges from one environment to the other. The user may still have to authenticate independently with the FI institution site in order to have the option to complete a payment.
- An example message sent from the initiator to the financial institution may include the following payment information:
- the nonce allows the server to verify that a request has never been made before and helps prevent replay attacks.
- the server will cache all (ProviderID, TimestampUTC, Nonce) tuples until after the expiration of the messages, and reject any un-expired messages that have already been received.
- ReturnURL String(255) A URL to redirect the (Well-formed absolute user to, upon completion uniform resource locator of the payment process. (URL))
- An example JSON value for the payment message may be as follows:
- An example message (e.g., MessageContainer) that may be sent from the payment initiator to the financial institution via the user browser may include the following:
- Each Byte[ ] array may be transmitted as a Base 64 encoded string when rendered as JSON.
- An example JSON value for the MessageContainer may be as follows:
- the payment mechanism provided by the online accounting software server may facilitate sending payment from the payment initiator to the financial institution for the authenticated internet banking user to pay. Once the user has been redirected from the payment initiator to the financial institution, and the appropriate information has been passed, this action may be completed within the financial institution. The user may be presented with the payment details, and the user may elect to pay. Implementation of this functionality may be left up to the financial institution.
- certain preconditions may be required before the financial institution will present the proposed transaction to the customer, such as:
- certain post-conditions may be required. For example, approval of the payment by the customer may be required before processing the payment continues.
- FIG. 10 is an interface diagram depicting an example user interface 1000 for paying an invoice from a business, according to some embodiments.
- the user interface 1000 includes elements 1010 - 1070 , as discussed below.
- Element 1010 is a title, showing that the user is currently viewing information provided by “ABC BANK.”
- element 1020 is a description, showing that the user is viewing a page for “INTER-BANK TRANSFER.”
- Elements 1030 - 1050 show the payee (e.g., the business that sent the invoice using the UI 700 ), the amount (e.g., the amount of the invoice), and the payment date (e.g., the current date or the due date of the invoice).
- the payee e.g., the business that sent the invoice using the UI 700
- the amount e.g., the amount of the invoice
- the payment date e.g., the current date or the due date of the invoice.
- one or more of the payee, the amount, and the payment date are modifiable by the user.
- the user is not allowed to modify the fields.
- Element 1060 is a button operable to confirm the details shown in elements 1030 - 1050 , and operable to cause the financial institution to transfer the amount shown in element 1040 from the customer's account to the business's account shown in element 1030 on the transaction date shown in element 1050 .
- the financial institution may communicate with the payment initiator to inform the payment initiator that the payment was made or is scheduled to be made on the payment date. Alternatively or additionally, the financial institution may inform the payment initiator that the payment was successfully completed after the transfer of funds is complete.
- Element 1070 is a button operable to cancel the transfer of funds.
- the payment initiator is informed that payment was not completed.
- the payment initiator may send one or more additional messages to the user to remind the user of the outstanding invoice.
- FIG. 11 is a block diagram depicting the flow of data between entities facilitating a transfer of funds, in an example embodiment.
- the user may interact with the accounting software platform to choose the bank to make payment with.
- the UI 900 of FIG. 9 may be used to make the bank selection, and the selected bank sent to the accounting software platform via a ChooseBank function 1105 .
- the accounting software platform provides a response 1110 to the user.
- the response may be in the form of a web page informing the user that the bank selection was successfully made.
- the user then chooses to pay the invoices via a PayNow function 1115 (e.g., by activating element 805 of FIG. 8 ).
- a PayNow function 1115 e.g., by activating element 805 of FIG. 8 .
- the accounting software platform After receiving the payment command from the user, the accounting software platform generates request 1120 to the accounting software server.
- the accounting software server responds by creating an encrypted block of data that includes the information for the user's bank and an invoice to be paid and sending the encrypted block of data in the response 1125 .
- the response 1130 from the accounting software platform to the user also includes this data, along with an address for redirection.
- the received web page may include an HTML meta tag that causes the page to refresh from a different URL.
- the user is redirected 1135 to the internet banking site.
- the internet banking site sends a response 1140 , such as a welcome or login web page.
- the user sends authentication data to the internet banking site, such as a user name and password.
- the internet banking site sends a response 1150 , such as an acknowledgement that the user authentication was successful, along with a redirection address to another page within the internet banking site at which the invoice can be paid.
- the user is redirected 1155 to the new page, and receives the page in response 1160 from the internet banking server.
- the response page may include information about the transaction and request for confirmation from the user to pay the invoice.
- the user submits the confirmation 1165 to the internet banking server, which generates a request to process 1170 the payment to the banking services server.
- the banking services server initiates the processing of the payment and sends an appropriate response 1175 to the internet banking server.
- the internet banking server sends a response 1180 to the user. For example, the user may be presented with
- the banking services server or internet banking server sends a confirmation 1185 to the accounting software platform or accounting software server to inform the accounting software that the invoice has been paid. Accordingly, when the entity that generated the invoice next accesses the accounting software, the entity can be informed that payment was received.
- FIG. 12 is a flowchart of an example method 1200 for facilitating direct bank transfers.
- the online accounting software server may present an invoice and a payment button (such as those shown in FIG. 8 ) to a client device of a user (e.g., a customer of a business).
- the invoice may identify an amount owed by the user to the business.
- the payment button may be associated with an option to pay the amount to the business through a particular bank of the user. The particular bank to be used may be selected by the user.
- the online accounting software server may receive, from the client device, a request to pay the amount through the user's account with the particular bank selected.
- the request may be made using the payment button.
- the request may be used by the online account software server to redirect the client device to a website of the particular bank selected, such that the particular bank may determine the validity of the request to pay the amount through the user's account and may transfer the amount from the user account to the business's bank account.
- the online accounting software server may receive an indication indicating the amount was transferred from the user account to the business's bank account.
- the indication may have been sent from the bank selected by the user, from which funds were transferred. Alternatively or additionally, the indication may have been sent from the bank of the business, to which funds were transferred.
- FIG. 13 is a flowchart of an example method 1300 for facilitating direct bank transfers.
- the payment initiator and a bank exchange public keys.
- the payment initiator and the bank may exchange public keys via email.
- the payment initiator presents an invoice with a payment button at a client device of a user.
- the payment initiator may send a web page to a web browser on a client device.
- the payment initiator and the client device may interact through a programmatic interface, such as an API, to cause the presentation of the invoice and payment button to the user.
- the payment initiator receives a request to pay the invoice.
- the user may press the payment button, causing an HTTP or API message to be sent to the payment initiator.
- the request may include information about a user's bank account at the bank, or an indication usable by the payment initiator to access the user's bank account information in a database of the payment initiator.
- the payment initiator encrypts a data packet using the bank's public key and signs the data packet with the payment initiator's private key.
- the data packet includes information usable by the bank to process the payment of the invoice.
- the data packet may include an account number of the user, account information of the entity presenting the invoice, a timestamp for when the data packet was created, a valid duration for the request or timestamp for when the data packet expires, an amount of the invoice, and so on.
- the payment initiator redirects the client device to the bank. For example, if the client is connected to the payment initiator via a web connection, the client's web browser can be directed to load a web page from a website of the bank. As another example, if the client is connected to the payment initiator via an application interface, an application of the bank on the client device may be started for the user.
- the encrypted data is sent from the payment initiator to the bank via the client device.
- the encrypted data can be sent to the client device from the payment initiator.
- the bank receives the encrypted data from the client device.
- the bank After receiving the encrypted data, the bank decrypts the data using the payment initiator's public key and the bank's private key. Based on the information in the data, the bank presents a user interface to the user, allowing the user to confirm payment.
- the UI presented to the user may be prepopulated with information from the invoice, such as the amount and the payee, based on the information extracted from the encrypted data.
- Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules.
- a hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner.
- one or more computer systems e.g., a standalone, client, or server computer system
- one or more hardware modules of a computer system e.g., a processor or a group of processors
- software e.g., an application or application portion
- a hardware module may be implemented mechanically or electronically.
- a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations.
- a hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
- the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein.
- hardware modules are temporarily configured (e.g., programmed)
- each of the hardware modules need not be configured or instantiated at any one instance in time.
- the hardware modules comprise a general-purpose processor configured using software
- the general-purpose processor may be configured as respective different hardware modules at different times.
- Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
- Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
- a resource e.g., a collection of information
- processors may be temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions.
- the modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
- the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
- the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a SaaS. For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).
- a network e.g., the Internet
- APIs appropriate interfaces
- Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
- Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
- a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment.
- a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
- operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output.
- Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry (e.g., a FPGA or an ASIC).
- the computing system can include clients and servers.
- a client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
- both hardware and software architectures require consideration.
- the choice of whether to implement certain functionality in permanently configured hardware e.g., an ASIC
- temporarily configured hardware e.g., a combination of software and a programmable processor
- a combination of permanently and temporarily configured hardware may be a design choice.
- hardware e.g., machine
- software architectures that may be deployed, in various example embodiments.
- FIG. 14 is a block diagram of a machine in the example form of a computer system 1400 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
- the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
- the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
- PC personal computer
- PDA Personal Digital Assistant
- STB set-top box
- WPA Personal Digital Assistant
- a cellular telephone a web appliance
- network router switch or bridge
- machine any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
- machine shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
- Example computer system 1400 includes a processor 1402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 1404 , and a static memory 1406 , which communicate with each other via a bus 1408 .
- Computer system 1400 may further include a video display device 1410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
- Computer system 1400 also includes an alphanumeric input device 1412 (e.g., a keyboard), a user interface navigation device 1414 (e.g., a mouse or touch sensitive display), a disk drive unit 1416 , a signal generation device 1418 (e.g., a speaker), and a network interface device 1420 .
- an alphanumeric input device 1412 e.g., a keyboard
- a user interface navigation device 1414 e.g., a mouse or touch sensitive display
- a disk drive unit 1416 e.g., a disk drive unit 1416
- signal generation device 1418 e.g., a speaker
- network interface device 1420 e.g., a network interface device
- Disk drive unit 1416 includes a machine-readable medium 1422 on which is stored one or more sets of instructions and data structures (e.g., software) 1424 embodying or utilized by any one or more of the methodologies or functions described herein. Instructions 1424 may also reside, completely or at least partially, within main memory 1404 , within static memory 1406 , and/or within processor 1402 during execution thereof by computer system 1400 , with main memory 1404 and processor 1402 also constituting machine-readable media.
- instructions 1424 may also reside, completely or at least partially, within main memory 1404 , within static memory 1406 , and/or within processor 1402 during execution thereof by computer system 1400 , with main memory 1404 and processor 1402 also constituting machine-readable media.
- machine-readable medium 1422 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures.
- the term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present technology, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions.
- the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.
- machine-readable media include non-volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
- semiconductor memory devices e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices
- EPROM Erasable Programmable Read-Only Memory
- EEPROM Electrically Erasable Programmable Read-Only Memory
- flash memory devices e.g., electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices
- magnetic disks such as internal hard disks and removable disks
- magneto-optical disks e.g., magneto-optical disks
- Instructions 1424 may further be transmitted or received over a communications network 1426 using a transmission medium. Instructions 1424 may be transmitted using network interface device 1420 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMAX networks).
- POTS Plain Old Telephone
- the term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
- inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed.
- inventive concept merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
- Detergent Compositions (AREA)
Abstract
Description
- The application claims priority to and incorporates by reference U.S. application Ser. No. 14/446,782, filed Jul. 30, 2014, entitled “Systems and Methods of Direct Bank Transfer,” which claimed priority from U.S. Provisional Application No. 61/860,771, filed Jul. 31, 2013, entitled “Systems and Methods of Direct Bank Transfer.”
- The present disclosure generally relates to monetary transfers and, more specifically, to systems and methods for facilitating direct account transfers.
- Merchants send invoices to customers with information regarding money owed by a customer to a merchant. A customer pays an invoice by writing a check, using a credit card, transferring money via a third party, or transferring money from a customer bank account to a merchant bank account. Money transfers between banks may be performed using the Automated Clearing House (ACH).
- To make an ACH transfer, a customer connects to a server associated with his or her bank, enters the transaction details, and submits the transfer request. The money is transferred directly to the merchant account from the customer account via ACH.
- To transfer money via a third party, the customer connects to a server associated with the third party, enters the transaction details, and submits the transfer request. The money is transferred from the customer account to an account of the third party and then from the third-party account to the merchant account.
- Some embodiments are illustrated by way of example and not of limitation in the figures of the accompanying drawings.
-
FIG. 1 is a block diagram depicting an example single ledger accounting platform, according to some embodiments. -
FIG. 2 is a block diagram depicting an example accounting application framework for the accounting platform, according to some embodiments. -
FIG. 3 is a block diagram depicting an example hosting infrastructure for the accounting platform, according to some embodiments. -
FIG. 4 is a block diagram depicting an example data center system of the accounting platform, according to some embodiments. -
FIG. 5 is a block diagram depicting an example client device for accessing the accounting platform, according to some embodiments. -
FIG. 6 is an interface diagram depicting an example user interface (UI) displaying accounts accessible by a user of the accounting platform, according to some embodiments. -
FIG. 7 is an interface diagram depicting an example user interface for creating an invoice from a business, according to some embodiments. -
FIG. 8 is an interface diagram depicting an example user interface displaying an invoice from a business, according to some embodiments. -
FIG. 9 is an interface diagram depicting an example user interface for configuring bank options, according to some embodiments. -
FIG. 10 is an interface diagram depicting an example user interface for paying an invoice from a business, according to some embodiments. -
FIG. 11 is a block diagram depicting the flow of data between entities facilitating a transfer of funds, according to some embodiments. -
FIG. 12 is a flowchart of an example method for facilitating direct bank transfers, according to some embodiments. -
FIG. 13 is a flowchart of an example method for facilitating direct bank transfers, according to some embodiments. -
FIG. 14 is a block diagram of a machine in the example form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed, according to some embodiments. - Example systems and methods to facilitate direct bank transfers are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the present technology may be practiced without these specific details.
- The technology described herein provides online accounting software to businesses with features such as a payment mechanism available to a business's customers, where the payment mechanism may drive payments through a bank rather than third-party payment services (e.g., credit card transaction processors, PayPal, and so on). In some embodiments, financial institutions may also use such payment features to let trusted partners submit payments to them for confirmation and processing.
- The financial institution and the payment initiator may exchange public keys, to enable the secure exchange of data. The business provides its account information to the payment initiator. The payment initiator can encrypt the account information along with details for a particular invoice (such as payment amount and payment date) and transmit the information to the financial institution. The financial institution can decrypt the information and initiate a transfer of money from one of the customer's bank accounts to the business on the payment date. In some example embodiments, the financial institution presents the information about the transaction to the customer for modification or confirmation before initiating the transfer. In some example embodiments, the financial institution allows the customer to confirm or cancel the transaction, but not to modify it. For example, the payment initiator may include one or more flags in the data to indicate whether the various prepopulated fields for the transaction (e.g., payment amount, payment date, and so on) can be modified by the customer. Based on the flags, the financial institution can modify the options presented to the customer.
- The information may be sent from the payment initiator to the financial institution via the customer. For example, the encrypted data may be sent from a web site of the payment initiator to a web browser of the customer running on a customer device. After the payment has been initiated by the financial institution, a confirmation may be sent to the customer, the payment initiator, the business, or any suitable combination thereof.
-
FIG. 1 is a block diagram depicting an example singleledger accounting system 100. A singleledger accounting system 100 may provide accounting tools to a particular entity managing accounting for one or more businesses. The example singleledger accounting system 100 may include apractice studio 110 that allows an entity to manage one or more businesses and anorganization access module 150 that provides a business with tools for managing accounting data for that particular business. Thepractice studio 110 may include a practicestaff management module 114, anonline training module 116, apartner resources module 120, a reportpacks setup module 122, and awork papers module 124. Thepractice studio 110 may be in communication withcore features 130. Thecore features 130 may include an accounting andpayroll module 132, acommunity module 134, a billing/subscription management module 136, anotifications center module 138, a userprofile management module 140, and alogin module 142. Theorganization access module 150 may be in communication with thecore features 130. Thepractice studio 110 and core features may be accessed by an entity using alogin module 142. - As shown in
FIG. 1 , features of thesystem 100 are divided into three areas based on the target user. The features of thepractice studio 110 provide a suite of tools for accountants to interact with their clients and manage their practices. Thecore features 130 provide the core functionality and user tools common to both accountants and businesses. Theorganization access 150 provides a user interface for individual businesses to access their data. -
Practice studio 110 is the central login for accountants. For example, an accountant with multiple clients, each of which is a small business, can login usingpractice studio 110 and gain access to the accounting data for the clients, messages from the clients, and so on. - The practice
staff management module 114 provides the ability for the manager of an accounting practice to control settings for the staff of the practice. For example, some staff members may have read-only access to data for certain clients, some staff members may have read-write access for certain clients, some staff members may be able to modify the access permissions for other staff members, and so on. - The
online training module 116 provides training for accountants and their staff. In some cases, the provided training includes one or more video presentations and one or more online tests. Notification of passing a test at completion of a training may be provided. For example, a staff member may take a training course and, upon successful completion, the accountant supervising the staff member may receive a notification of the successful completion. - The
partner resources module 120 provides information regarding third-party partners. For example, a third party may provide tools that interact with the system to provide useful functionality beyond that of the system alone. The user can access thepartner resources module 120 to learn about available third-party tools. For example, links to third-party websites, documentation, videos, and search tools may all be provided. - The report packs
setup module 122 provides tools to allow accountants to create and generate standardized sets of reports. For example, a profit and loss statement and quarterly report could both be added to a pack. The accountant would then be able to easily generate both reports for any selected client, or generate the reports for every client. - The
work papers module 124 provides tools for accountants to interactively create financial reports. For example, an accountant can enter known data for a client into the work paper, and then send the work paper to the client with an indication of data needed from the client. After the client enters the missing data into the work paper, the accountant can complete the report. - The core features 130 includes modules that are used both by accountants and organizations. The accounting and
payroll module 132 provides the general ledger for organizations. The general ledger may be integrated with the organization's payroll, bypassing the separate step of entering payroll data into the general ledger each pay period. The accounting andpayroll module 132 accesses banking data for each client business. The banking data may be imported into either through a bank feed or a user- or accountant-created document. The accounting andpayroll module 132 may also communicate with third-party tools via an application protocol interface (API). - The
community module 134 provides a forum through which users can communicate. For example, a user with a question may post a topic in the forum and later receive a helpful response from another user. Information taken from the user profile (e.g., the user profile managed via the user profile management module 140) may appear along with forum posts by the user. For example, a user name, an image of the user, and the user's status as an accountant or member of an organization may each be shown. - The billing/
subscription management module 136 allows a user to configure one or more billing accounts for each organization using the system. The system may periodically charge a subscription fee for access (e.g., a monthly or annual subscription fee). The subscription fee may be automatically deducted from the one or more billing accounts. - The
notifications center module 138 provides notifications to users. For example, users may send messages to each other, which appear as notifications. Notifications may also be created by the system (e.g., by accounting and payroll module 132) based on events. For example, a minimum account balance for a particular bank account may be set by a user via the accounting &payroll module 132. When the balance for that bank account drops below the minimum account balance, a notification can be generated by the system informing the user. - The user
profile management module 140 allows a user to manage the profile of the user's organization and the profiles of others based on permission settings. For example, an accountant may have permission to manage the profiles of the accountant's clients. The profile may include public-facing information such as a business name and address. - The
login module 142 verifies the identify of a user logging into the system (e.g., via user name and password). Based on the user's identity, a user interface is presented that includes a list of organizations that a user has access to. For most small business clients, the list will consist of a single organization. - The
organization access module 150 accesses the core features 130 for a single organization. Theorganization access module 150 presents, after user verification by thelogin module 142, a user interface with options for a single organization without the additional features used only by thepractice studio 110. -
FIG. 2 is a block diagram depicting an exampleaccounting application framework 200 for the accounting platform. Theaccounting application framework 200 may be an end-to-end web development framework enabling a “software as a service” (SaaS) product. Theaccounting application framework 200 may include a hypertext markup language (HTML) and/orJavaScript layer 210, ASP.Net Model-View-Controller (MVC) 220, extensible stylesheet language transformations (XSLT) 230, construct 240,services 250, objectrelational module 260, anddatabase 270. - The HTML and/or
JavaScript layer 210 provides client-side functionality, such as UI generation, receipt of user input, and communication with a server. The client-side code may be created dynamically by theASP.NET MVC 220 or theXSLT 230. Alternatively, the client-side code may be statically created or dynamically created using another server-side tool. - The
ASP.Net MVC 220 andXSLT 230 provide server-side functionality, such as data processing, web page generation, and communication with a client. Other server-side technologies may also be used to interact with thedatabase 270 and create an experience for the user. - The
construct 240 provides a conduit through which data is processed and presented to a user. For example, theASP.Net MVC 220 andXSLT 230 can access theconstruct 240 to determine the desired format of the data. Based on theconstruct 240, client-side code for presentation of the data is generated. The generated client-side code and data for presentation is sent to the client, which then presents the data. - The
services 250 provide reusable tools that can be used by the ASP.Net 220, theXSLT 230, and theconstruct 240 to access data stored in thedatabase 270. For example, aggregate data generated by calculations operating on raw data stored in thedatabase 270 may be made accessible by theservices 250. - The object
relational model 260 provides data structures usable by software to manipulate data stored in thedatabase 270. For example, thedatabase 270 may represent a many-to-one relationship by storing multiple rows in a table, with each row having a value in common. By contrast, the software may prefer to access that data as an array, where the array is a member of an object corresponding to the common value. Accordingly, the objectrelational model 260 may convert the multiple rows to an array when the software accesses them and perform the reverse conversion when the data is stored. -
FIG. 3 is a block diagram depicting anexample hosting infrastructure 300 for the accounting platform. The platform may be implemented using one ormore pods 310. Eachpod 310 includes application server virtual machines 320 (shown as application server virtual machines 320 a-320 c inFIG. 3 ) that are specific to thepod 310 as well as application server virtual machines (VMs) that are shared between pods 310 (e.g., theinternal services VM 330 and the application protocol interface VM 340). The application server virtual machines 320-340 communicate with clients and third-party applications via a web interface or an API. The application server virtual machines 320-340 are monitored byapplication hypervisors 350. Aninternal firewall 360 ensures that only approved communications are allowed between adatabase hypervisor 370 and the publically-accessible virtual machines 320-340. Thedatabase hypervisor 370 monitors the primary SQL servers 380 a and 380 b. The primary SQL servers 380 a and 380 b access the shared storage layer 450 a or 450 b (shown inFIG. 4 ) to read and write data generated by or used by the application server virtual machines 320-340. The redundant SQL servers 390 a and 390 b provide backup functionality for the primary SQL servers 380 a and 380 b, respectively. - The virtual machines 320-340 can be implemented using Windows 2008 R2, Windows 2012, or another operating system. The application and support servers supporting the virtual machines 320-340 can be built using spares for redundancy. The support servers can be shared across
multiple pods 310. The application hypervisors 350,internal firewall 360, anddatabase hypervisor 370 may spanmultiple pods 310 within a data center. In some example embodiments, each primary SQL server 380 and redundant SQL server 390 is configured to support 30,000-45,000 organizations. Accordingly, in embodiments using two such server pairs perpod 310, the pod capacity is 60,000-90,000 organizations. The redundant SQL servers 390 may take advantage of the “always on” resilience feature of SQL 2012. -
FIG. 4 is a block diagram depicting an exampledata center system 400 of the accounting platform interacting with other systems over a network. Theprimary data center 410 services customer requests and is replicated to thesecondary data center 420. Thesecondary data center 420 may be brought online to serve customer requests in case of a fault in theprimary data center 410. Theprimary data center 410 communicates over anetwork 455 withbank server 460,third party server 470,client device 480, andclient device 490. Thebank server 460 provides banking data (e.g., via the banking application 465). Thethird party server 470 is runningthird party application 475.Client devices primary data center 410 usingweb client 485 andprogrammatic client 495, respectively. - Within each
data center pod 310 ofFIG. 3 , are shown. Theprimary data center 410 is shown containing pods 440 a-440 d. Thesecondary data center 420 is shown containing pods 440 e-440 h. The applications running on the pods of the primary data center are replicated to the pods of the secondary data center. For example, EMC replication (provided by EMC Corporation) in combination with VMWare site recovery manager (SRM) may be used for the application layer replication. The database layer handles replication between the storage layer 450 a of the primary data center and the storage 450 b of the secondary data center. Database replication provides database consistency and the ability to ensure that all databases are at the same point in time. - The
data centers data centers secondary data center 420 is the same as the performance of theprimary data center 410. The storage 450 a and 450 b may be implemented using one or more storage area networks such as the VNX storage area networks from EMC. - The
bank server 460 interacts with theprimary data center 410 to provide bank records for bank accounts of the client. For example, the client may provide account credentials to theprimary data center 410, which theprimary data center 410 uses to gain access to the account information of the client. Thebank server 460 can provide the banking records to theprimary data center 410 for later reconciliation by the client using theclient device - The
third party server 470 may interact with theprimary data center 410 and theclient device client device third party server 470 to access the user's data stored in theprimary data center 410. Thethird party application 475 of thethird party server 470 may use the user's data to generate reports, provide macros, or otherwise improve the user's ability to access or manipulate the user's data. Thethird party application 475 may communicate with theprimary data center 410 via thenetwork 455 using an API. Thethird party application 475 may communicate with theclient device -
FIG. 5 is a block diagram 500 illustrating components of a client device suitable for mobile banking reconciliation, according to some example embodiments. Theclient device communication module 510, adisplay module 520, aninput module 530, and areconciliation module 540, configured to communicate with each other (e.g., via a bus, shared memory, or a switch). - The
communication module 510 may communicate with theprimary data center 410, thethird party server 470, thenetwork 455, or any suitable combination thereof. Information received via thecommunication module 510 may be presented (e.g., displayed on a display device) via thedisplay module 520. Information may be selected or search queries may be entered by a user of theclient device - A user interface is presented by the
display module 520. The input from the user is detected by theinput module 530. Commands received from the user by theinput module 530 may be communicated to theprimary data center 410 by thecommunication module 510. Thecommunication module 510 may receive a response from theprimary data center 410 that includes a set of banking records, a set of business records, associations between individual banking records and individual business records that indicate reconciliation between those records, and other data, in any combination. - The
reconciliation module 540 can generate requests to theprimary data center 410 to indicate that a banking record is reconciled by one or more business records. The request can be communicated to theprimary data center 410 via thecommunication module 510, over thenetwork 455. -
FIG. 6 is an interface diagram depicting anexample user interface 600 displaying accounts accessible by a user of the accounting platform. The elements 660 a-660 e are individual rows of data with information about different businesses and may be referred to collectively as elements 660. Similarly, an individual one of the elements 660 may be referred to as an element 660. - An
element 605 shows the name of a logged-in user along with a downward-pointing arrow. The name or arrow may be operable to cause the display of a user profile menu. For example, the user may be able to change a contact email address, a password, and other individual information about the user. - An
element 610 shows the name of the current application interface. In the example shown, the name is “My Xero.” Theelement 610 may be used to distinguish between access by an organization (e.g., access via the organization access module 150) and access by an accounting practice (e.g., access via the practice studio 110). - Elements 615-630 may be operable to cause the display of additional user interface options. For example,
element 615, labeled “Billing,” may be operable to cause the display of a billing interface that allows the user to enter time-tracking information for use by the accounting andpayroll module 132. Theelement 620, labeled “Staff,” may be operable to bring up a staff interface that allows the user to control permissions for staff members. The functions of the staff interface may be implemented by the practicestaff management module 114. Theelement 625, labeled “Training,” may be operable to bring up a training interface that allows the user to schedule training sessions or review the results of training sessions. For example, the user may be enabled to set up a particular training session for a particular staff member. Theelement 630, labeled “Settings,” may be operable to bring up a settings interface that allows the user to modify settings for the organization. For example, the organization may have a billing account on file that is used to pay for subscription access to the application. The settings interface can be used to add or change the billing account (e.g., using the billing/subscription management module 136). -
Element 635 displays the name of the accountant for the organization. In some example embodiments, a logo for the accounting firm is also displayed. -
Element 640 displays the currently selected organization and the last time data for the organization was updated. -
Element 645 is a search box. The user may enter one or more search terms into the search box to cause the system to search for organizations matching the search terms. -
Element 650, labeled “Group,” allows the user to select multiple organizations and put them into a custom group. Operations may then be performed on the group. For example, a report pack may be run on every organization in a selected group. -
Element 655 is a header for the elements 660 with information regarding organizations to which the user has access. Theelement 655 shows that each element 660 has a name, a date on which it was last viewed, an access permission, and subscription data. For example, the name of the organization for element 660 a is Aaron Construction. Element 660 a further shows that Aaron Construction was last viewed today at 9:22 AM. As also shown in element 660 a, the current user is a financial advisor for Aaron Construction, and has the appropriate access privileges to manage users. Similarly, element 660 a shows that Aaron Construction has a “Large” subscription. The word “View” in the element 660 a may be operable to view subscription information for Aaron Construction. - Additional information about the available organizations may be shown in the elements 660. For example, the elements 660 b, 660 d, and 660 e each show a number of unreconciled lines. This may suggest to the user that further reconciliation of banking and business records is needed for the corresponding organizations: Cafe 88 East, Artisan Kitchens, and Hawker Foods.
- The elements 660 show at least a subset of the accounts to which the user has access. For example, the accounts may be associated with one or more organizations for which the user manages a business. The user may click on a link associated with one of the businesses to access and manage accounting information associated with that business.
-
FIG. 7 is an interface diagram depicting anexample user interface 700 creating an invoice from a business. Theuser interface 700 includes elements 710-790, discussed in more detail below, and may be presented to a business user for creating an invoice for a customer. -
Element 710 is a button operable to create the invoice according to the options selected and information entered by the business user in the other elements of theUI 700. For example, operation ofelement 710 may cause the payment initiator to contact the customer (e.g., by email, text message, over a social network, and so on) with information regarding the invoice. For example, an HTML web link may be provided to the customer, operable to cause the display ofUI 800, shown inFIG. 8 . In some example embodiments,element 710 is also operable to save the work in progress on an invoice without actually sending the invoice to the customer. Alternatively or additionally, another element is used to save the work in progress. -
Element 720 displays the total amount of the invoice. The currency in which the total is denominated may be determined by a setting of the business user (e.g., to denominate all invoices in dollars), determined automatically based on the address of the business user (e.g., to denominate invoices in New Zealand dollars based on the business user's address being in New Zealand), determined by a setting of the customer (e.g., to denominate all invoices for the customer in Euros), determined automatically based on an address of the customer (e.g., to denominate invoices to the customer in Rubles based on the customer's address being in Russia), determined by a per-customer setting of the business user (e.g., to denominate all invoices for the customer from this business in Pesos), or any suitable combination thereof (e.g., to denominate invoices in an automatically-determined currency unless overridden by an explicit setting). -
Element 730 displays the name of the customer.Element 730 may be implemented as a drop-down list or other selector, enabling the business user to select the customer. -
Element 740 displays the type of invoice.Element 740 may be implemented as a drop-down list or other selector, enabling the business user to select the type of invoice. -
Element 750 displays a logo for the business. For example, theelement 750 shows an oversized and italicized version of an example company name, “Demo Co.”Element 750 may be operable to cause the upload of an image file to use for the logo. For example, clicking onelement 750 may cause the presentation of a file selector interface. The business user can then select an image file to use for the logo. After selecting the file, the file is transferred to the server and the image or text shown inelement 750 is replaced by the uploaded image. Other ways of selecting or uploading images may also be used. In some example embodiments, text, either formatted or plain, is used in addition to or in place of an image. -
Element 760 shows the mailing address of the customer. The information inelement 760 may be automatically generated based on the selection of thecustomer using element 730. Alternatively or additionally, the business user may be enabled to edit or populate the information inelement 760. For example,element 760 may be a text field, directly editable by the business user. As another example, a selection ofelement 760 can be detected. Responsive to the selection, an editing interface may be presented to the business user. After editing the address information for the customer, the customer's address may be updated for the business user. When editing a later invoice for the same customer, the updated address may be retrieved. -
Element 770 shows metadata regarding the invoice. As shown,element 770 includes an invoice number, a reference name, a goods and services tax (GST) number, an issued date, and a due date. Some or all of the metadata may be automatically generated. For example, the invoice number may be generated by automatically incrementing the most recently used invoice number. As another example, the GST number of a business may be the same for all customers, and populated from information about the business in a database. Similarly, the issued date may be pre-populated with the current date, and the due date may be calculated based on a pre-determined grace period (e.g., 30, 60, or 90 days). Optionally, some or all of the metadata may be created or edited by the business user. -
Element 780 shows item detail data for the invoice. For each item, a description, a quantity, a unit price, and an amount is shown. Selecting an item description may cause a drop-down menu or other selector to appear. Using the selector, a different item may be chosen. When a different item is chosen, the description, unit price, and amount may be automatically updated. For example, if the “Golf balls—white single” with a unit price of 4.87 is replaced by “Golf balls—black triple” with a unit price of 15.00, the amount can be automatically calculated as 600.00, based on the unchanged quantity and updated unit price. In some example embodiments, the description, quantity, and unit price fields allow for direct entry of data, instead of or in addition to selection of items from an item database. The unit price for each item may be converted automatically from a currency in which the price is stored to the currency being used for the invoice. For example, if the unit prices are stored in a database denominated in NZD, but the invoice is being generated in US dollars, a current exchange rate between the two currencies can be accessed and used to convert the price. - Also shown in
element 780 is an icon in the lower right-hand corner. The icon may be operable to cause the addition of an additional row of item data to the invoice. In some example embodiments, a blank row is added to the invoice each time the last row is used, allowing the business user to add items as needed. -
Element 790 shows total detail data for the invoice. As shown inelement 790, the subtotal, GST, and amount due are shown. The specific line items shown inelement 790 may vary based on the location of the business user, the location of the customer, and business user options. For example, one business may choose to include a shipping cost as an item included in the subtotal while another business may choose to include the shipping cost as an additional charge included in the total but excluded from the subtotal. The subtotal may be determined by summing the amounts shown inelement 780. Accordingly, subtotal may be automatically updated whenever an item is added or changed in theelement 780. Alternatively or additionally, a UI element operable to cause the updating may be presented. The GST may be calculated based on tax rules for the location of the business. The amount due may be determined by summing the line items inelement 790. - A business using the online accounting software may have the ability to present online invoices to their customers, making the invoicing process more efficient. The business may send out an invoice and know when it has been seen by the customer. If a business has set up a payment service, their debtor may make payment through the invoice.
-
FIG. 8 is an interface diagram depicting anexample user interface 800 displaying an invoice from a business. Theuser interface 800 includes elements 805-870, described in more detail below. TheUI 800 may be presented in response to an activation of a link sent to the user on request of the business expecting payment on the invoice. Alternatively, theUI 800 may be presented in response to a login by the user to the accounting system, based on a determination that the user has outstanding invoices to respond to. Multiple instances of theUI 800 may be presented in sequence when multiple invoices are pending. Alternatively, an additional UI (not shown) may be presented, allowing the user to select between the pending invoices. -
Element 805 is a button, which a user (e.g., a business's customer) may select to be redirected to a bank site in order to pay the invoice. In the example shown inFIG. 8 , the business Demo Co. (as shown by element 835) may be owed a particular amount for a good or service the business Demo Co. provided to their customer Bayside Club (as shown by element 845). Theuser interface 800 may present the invoice associated with this outstanding amount owed, and the customer may use thebutton 805 to initiate payment directly through the customer's bank account. -
Element 810 displays the total amount of the invoice.Elements element 815 may be operable to select the format of the download (e.g., as portable document format (PDF), comma-separated value (CSV), text, Word, etc.), whileelement 820 may be operable to save the invoice in the selected format or a default format. -
Element 830 may be operable to open a help or messaging interface that allows the user to gather information about bill payment in general, about invoices from the merchant specifically, or to send a message to the merchant. -
Element 840 indicates the type of invoice (for example, a taxable transaction, a tax-exempt transaction, a charitable contribution, and so on). -
Element 845 shows information regarding the customer such as name and mailing address. Similarly,element 850 shows information regarding the invoicing business, including the name and mailing address. -
Element 855 shows the metadata of the invoice, including invoice number, reference, GST number of the invoicing business, date on which the invoice was issued, and date on which the invoice is due.Element 855 also shows the amount of time remaining before the invoice is due. -
Element 860 shows the line items of the invoice, including, for each item, a description, a quantity, a unit price, and an amount. In embodiments, more or fewer information for each line item is shown. -
Element 870 shows total detail data for the invoice. As shown inelement 870, the subtotal, GST, and amount due are shown. The specific line items shown inelement 870 may vary based on the location of the business user, the location of the customer, and business user options. The subtotal may be determined by summing the amounts shown inelement 860. The GST may be calculated based on tax rules for the location of the business. The amount due may be determined by summing the line items inelement 870. - When a user (e.g., debtor) receives an online invoice or payment request, the user may be presented with the
UI 800 includingelement 805, which may include a link to a dialog listing participating banks For example, if the user has not yet selected a default bank, theUI 900, shown inFIG. 9 , may be presented in response to a selection of the “Pay Now” button (element 805) by the user. After setting a default bank, the user may be immediately redirected to the bank for payment of the invoice (e.g., as shown in theUI 1000 ofFIG. 10 ), or returned to theUI 800. After a default bank has been set, operation of theelement 805 may redirect the user's device to that bank for payment. -
FIG. 9 is an interface diagram depicting anexample user interface 900 for configuring bank options for a customer. TheUI 900 includes elements 910-940, as discussed in more detail below, and may be presented to a user during initial configuration, in response to receiving an invoice, or in response to a request from the user. -
Element 910 is a title, showing that the user is currently on a “Bank Configuration” screen. Similarly,element 920 is an informational message, requesting that the user select a default bank for invoice payments. -
Element 930 includes radio buttons to allow the user to select a bank from a list of banks for the user. In other example embodiments, a drop-down list or other selector is used. The set of banks available for selection may be the set of banks with which the payment initiator has exchanged encryption keys, a set of banks identified based on information about the user (e.g., the location of the user), a set of banks identified based on information about the transaction (e.g., the currency of the transaction), a set of banks identified based on information about the payee (e.g., the location of the payee or banks associated with the payee), or any suitable combination thereof. The set of banks may be accessed from a database, such as thedatabase 380A orstorage 450A. -
Element 940 is a button operable to confirm the selected bank. For example, the user may select the radio button corresponding to “ABC Bank” shown in theelement 930, then press the “Done” button ofelement 940 to save the selection. In other example embodiments, the choice of bank is made without a second confirmation action. - A cookie may be stored on the debtor's machine so that any subsequent invoices the debtor receives from the payment initiator will automatically invoke the preference to use their chosen bank to pay the invoice. This may be changed by the user selecting another bank and replacing the information stored in the cookie.
- The payment mechanism through the direct bank transfer may be an endpoint exposed by a financial institution (and shared with a particular payment initiation partner) to which a debtor receiving a payment request is redirected, should they choose to pay using their bank. The direct bank transfer may avoid using a third-party intermediary, such as a credit card transaction service. The payment mechanism may accept the payment details, authenticate the online banking user into Internet banking, and may present the payment information for confirmation by the debtor. Benefits of this service may include:
-
- Participating financial institutions have presence and utility in front of not only businesses, but a business's customers.
- The financial institution processes the payment via Internet bill payment functions, rather than the payment being processed via scheme (e.g., credit card payment processing).
- The financial institution controls who can present the payment functionality by requiring a signed and encrypted payment message that uses a key exchange.
- Reduced merchant fees for the biller, and no merchant account requirement. For example, the merchant does not pay credit card fees on an ACH transaction.
- Greater business satisfaction—merchant gets paid without charge-back concerns, customer can pay larger sums via Internet banking
- Drives debtor back into Internet banking rather than payment gateway.
- Debtor is not forced to pay surcharge (becoming more common with payment gateways that collect payment via credit card)
- Below is a table of entities that may be common to both the financial institution (FI) and the payment initiator (PI):
-
Name Source Type Description Global FI Public Key FI Byte[ ] Public Key for Financial Institution PI Public Key PI Byte[ ] Public Key for Payment Initiator Provider ProviderCode PI String(50) Used so that FI can recognize partner before decryption. ProviderID PI String(50) Used so that FI can confirm recognition of payment initiator after decryption. - Below is a table of FI entities:
-
Name Source Type Description Global FI Private Key FI Byte[ ] Private Key for Financial Institution - Below is a table of PI entities:
-
Name Source Type Description Global PI Private Key PI Byte[ ] Private Key for Payment Initiator Payment AccountNumber PI String(50) Payee's account number DueDate PI Date Date the payment is due. (ISO 8601) Payee PI String(50) Payee's name Reference PI String(50) Invoice reference Amount PI Decimal Amount to pay Currency PI Char(3) Currency (ISO 4217) - Once a debtor has chosen their bank, the payment mechanism is handed over to the financial institution to complete. Transfer to the financial institution may be done via a secure hypertext transfer protocol (HTTPS) POST, triggered by the user clicking element 905 once a bank has been selected. In order to complete the payment, the user may authenticate with the bank using a valid Internet banking user account.
- Data may be transferred from the payment initiator to the financial institution via the user's browser when the user chooses to make a payment. The data transferred may be sent in one direction, from the payment initiator to the financial institution. The communication protocol may be designed to avoid any server-to-server communication between the financial institution and payment initiators, meaning that virtual private networks (VPNs) or other secure infrastructure do not need to be implemented. The data is transferred via the user's web browser client, as an encrypted, signed blob contained within a JavaScript object notation (JSON) data structure.
- The payment initiator assembles a blob of data containing information about the payment that the user wishes to make. This blob may contain payment details and other sensitive information, and hence is encrypted so the data within is opaque to the client browser transferring the data.
- In some embodiments, the payment data may be transferred using the “Encrypt then MAC” pattern. A symmetric key may be randomly generated and used to encrypt the payment data. The payment initiator has the financial institution's public RSA key that may be used to encrypt the symmetric key. The financial institution may use its private RSA key to decrypt the symmetric key and in turn use it to decrypt the message.
- The payment initiator may have a private RSA key that is used to sign messages sent to the financial institution. The financial institution may use the payment initiator's public RSA key to verify that the signature is valid.
- Any suitable cryptographic algorithm may be used, such as AES for symmetric encryption, RSA for asymmetric encryption, RSA-SHA2 for signing, and the like. Additionally, for cryptographic keys generated and used in the system, any key sizes may be used (e.g., AES 256 bits, RSA 2048 bits, SHA 256 bits, etc.).
- Any nonce and initialization vectors may be generated from a cryptographically secure random number generator. This ensures that the symmetric encryption will be strong and prevent brute force attacks against the encrypted data bytes in the message. In some embodiments, certain default random number generators may not be cryptographically secure. Thus, a cryptographically secure algorithm should be chosen (e.g. in C#, the System.Security.Cryptography. RandomNumberGenerator class should be used instead of the System.Random class).
- The financial institution may store a private RSA key issued and held only by the financial institution (e.g., the financial institution's private key) and a public RSA key issued by the payment initiator (e.g., the payment initiator's public key). Similarly, the payment initiator may store a public RSA key issued by the financial institution (e.g., the financial institution's public key) and a private RSA key issued and held only by payment initiator (e.g., the payment initiator's private key).
- Packaging a message to send to the financial institution may occur in a variety of manners. For example, the payment initiator may use the following algorithm and/or pseudo-code to package a message for receipt by the financial institution. The JSON Payment containing the sensitive data may be encrypted and signed, and the resulting MessageContainer may be sent to the financial institution as a JSON data structure via the user's browser.
-
PlainTextDataString = Base64Encode(Payment) IVBytes = GenerateRandomlV( ) EncryptedIV = RSAEncrypt(IVBytes, FI_PubKey) RandomKeyBytes = GenerateRandomKey( ) EncryptedRandomKey = RSAEncrypt(RandomKeyBytes, FI_PubKey) EncryptedDataBytes = AESEncrypt(PlainTextDataString, RandomKeyBytes, IVBytes) SignatureBytes = Calculate SHA2Signature( EncryptedIV + EncryptedRandomKey + EncryptedDataBytes, PI_PrivKey) MessageContainer.PC = “PROVIDER/XERO” MessageContainer.EIV = Base64Encode(EncryptedIV) MessageContainer.ERK = Base64Encode(EncryptedRandomKey) MessageContainer.Data = Base64Encode(EncryptedDataBytes) MessageContainer.S = Base64Encode(SignatureBytes) MessageContainer.SM = “RSA-SHA2” - Verifying and unpackaging a message upon receipt by the financial institution may occur in a variety of manners. For example, upon the receipt of a message from a payment initiator, the financial institution may decrypt and unpack the message to ensure it has come from an approved payment initiator and has not been tampered with. The following algorithm and/or pseudo-code may be used to unpack the MessageContainer and receive the Payment.
-
EncryptedIV = Base64Decode(MessageContainer.EIV) EncryptedRandomKey = Base64Decode(MessageContainer.ERK) EncryptedDataBytes = Base64Decode(MessageContainer.Data) SignatureBytes = Base64Decode(MessageContainer.S) (Check MessageContainer.SM == “RSA-SHA2”) VerifySignatureBytes = CalculateSHA2Signature( EncryptedIV + EncryptedRandomKey + EncryptedDataBytes, PI_PubKey) (Check VerifySignatureBytes == SignatureBytes) IVBytes = RSADecrypt(EncryptedIV, FI_PrivKey) RandomKeyBytes = RSADecrypt(EncryptedRandomKey, FI_PrivKey) PlainTextDataString = AESDecrypt(EncryptedDataBytes, RandomKeyBytes, IVBytes) AccountMapMessage = Base64Decode(PlainTextDataString) - The financial institution may then validate the internals of the payment to check that it has integrity. For example, this may include:
-
- Check Payment.ProviderID matches MessageContainer.PC
- TimeStampUTC is within the tolerance for valid messages, and the message has not expired
- The (TimeStampUTC, Nonce) have not been used by the Payment Initiator, to check the message is not a replay attempt
- Other validation of message contents
- Once the verification and unpackaging operations are successfully completed, the user may be shown displays allowing the user to continue to proceed with an Internet payment via internet banking
- The example message encryption and packaging described above may allow messages to pass from the payment initiator to the financial institution over an untrusted communication mechanism (the user's browser).
- The encryption and signing provide guarantees that the payment initiator legitimately generated the message, the message was not tampered with or viewed in transit, and the message cannot be replayed. The payment initiator can also be assured that only the financial institution will be able to decrypt the data.
- Other security issues include:
- Spoofing: It may not be possible for anyone other than the online accounting software server to generate a valid message due to the use of the public/private key pair shared between the online accounting software server and the Financial Institution. Any other keys used for encryption may fail the signature verification step.
- Repudiation: The payment initiator may sign the data using their private key, which is kept secret and held only by them. When the FI receives the message and checks the signature using the PI's public key, they can be assured the PI originally generated the message.
- Tampering: The signature check may also prevent tampering in transit. If the initialization vector (IV), key or data is altered, then the signature check will fail.
- Information Disclosure: The payment may contain some sensitive information, such as amounts and account numbers. This may be encrypted using a one-time-use encryption key. The encryption key may be transmitted in the message, but may be encrypted asymmetrically using the FI's public key, which only the FI can decrypt.
- Replay: Replay attacks may be prevented by a timestamp and nonce value that allows the FI to guarantee it will receive and process a given message only once. If a message arrives with the same timestamp and nonce, the FI may reject the message.
- Man-in-the-middle (MiTM): It may be possible for an attacker to intercept the generated JSON from the payment initiator and forward it to the FI before the legitimate user is able to. This may be mitigated by secure socket layer/transport layer security (SSL/TLS) connections being used in the user's browser, preventing MiTM on the client side, and the use of a short expiration against the message timestamp. As the user will not need to perform any action between the message generation and the immediate POST to the FI, the expiration can be kept short.
- Denial of Service: This protocol may not provide protection against denial of service; an attacker could send large, malformed, or numerous messages to the FI endpoint and cause a costly signature check or decryption process to occur. This should be mitigated by using the FI's standard brute force detection mechanisms.
- Elevation of Privilege: The message transferred from the payment initiator to the FI may not convey privileges from one environment to the other. The user may still have to authenticate independently with the FI institution site in order to have the option to complete a payment.
- An example message sent from the initiator to the financial institution may include the following payment information:
-
Name Type Description ProviderID String(50) FI's identifier for the payment initiator Currency Char(3) ISO4217 currency code for the payment AccountNum- String(50) Payee's supplied account ber number. (Numerals only) DueDate Date Date payment is due (ISO 8601) Payee String(50) Payee name Reference String(50) Payees's invoice reference Amount Decimal Amount to pay Time- DateTime The time that the stampUTC (e.g. message was constructed “2000-12-29T00:00:00Z”) by the caller. Used to expire messages that have passed a timeout threshold. ISO 8601 Nonce String(255) The Nonce value should be unique for all requests with that TimestampUTC. The nonce allows the server to verify that a request has never been made before and helps prevent replay attacks. The server will cache all (ProviderID, TimestampUTC, Nonce) tuples until after the expiration of the messages, and reject any un-expired messages that have already been received. ReturnURL String(255) A URL to redirect the (Well-formed absolute user to, upon completion uniform resource locator of the payment process. (URL)) - An example JSON value for the payment message may be as follows:
-
{ “ProviderID”: “PROVIDER/XERO”, “Currency”: “NZD”, “AccountNumber”: “01013703294839400”, “DueDate”: “2013-07-23”, “Payee”: “Demo Company” “Reference”: “INV-01234”, “Amount”: 124.32, “TimestampUTC”: “2012-12-10700:00:00”, “Nonce”: “A7813747-C47A-496E-8DE6-682D16A457D2”, “ReturnURL”: “https://www.xyz.com/” } - An example message (e.g., MessageContainer) that may be sent from the payment initiator to the financial institution via the user browser may include the following:
-
Name Type Description PC String(50) FI's identifier for the payment initiator Data Byte[ ] An encrypted blob of data ERK Byte[ ] Encrypted Random Key The key used to encrypt/decrypt the data blob. Should be encrypted with FI's public key. EIV Byte[ ] Initialization Vector used when encrypting data. Should be encrypted with FI's public key. S Byte[ ] The signature calculated when running the request signing method over the Encrypted IV, Encrypted Random Key and Data fields. SM String(50) The method used to calculate the message signature. If not specified, the default of “RSA-SHA2” is assumed. - Each Byte[ ] array may be transmitted as a Base 64 encoded string when rendered as JSON. An example JSON value for the MessageContainer may be as follows:
-
{ “PC”: “PROVIDER/XERO”, “Data”: “qas43...==”, “ERK”: “Rxut...==”, “EIV”: “QEDF...==”, “S”: “zyw...==”, “SM”: “RSA-SHA2” } - The payment mechanism provided by the online accounting software server may facilitate sending payment from the payment initiator to the financial institution for the authenticated internet banking user to pay. Once the user has been redirected from the payment initiator to the financial institution, and the appropriate information has been passed, this action may be completed within the financial institution. The user may be presented with the payment details, and the user may elect to pay. Implementation of this functionality may be left up to the financial institution.
- In some embodiments, certain preconditions may be required before the financial institution will present the proposed transaction to the customer, such as:
-
- The user is authenticated with the FI.
- The ProviderCode is recognized.
- The random key can be decrypted with the FI's private key.
- The request data can be decrypted with the random key.
- The signature is verified with the financial institution's public key.
- The ProviderID is a valid provider.
- The nonce has not been used before.
- The data is able to be parsed and all required elements included.
- Full payment information is provided.
- The timestamp is within a valid timeout period.
- In some embodiments, certain post-conditions may be required. For example, approval of the payment by the customer may be required before processing the payment continues.
-
FIG. 10 is an interface diagram depicting anexample user interface 1000 for paying an invoice from a business, according to some embodiments. Theuser interface 1000 includes elements 1010-1070, as discussed below. -
Element 1010 is a title, showing that the user is currently viewing information provided by “ABC BANK.” Similarly,element 1020 is a description, showing that the user is viewing a page for “INTER-BANK TRANSFER.” - Elements 1030-1050 show the payee (e.g., the business that sent the invoice using the UI 700), the amount (e.g., the amount of the invoice), and the payment date (e.g., the current date or the due date of the invoice). In some example embodiments, one or more of the payee, the amount, and the payment date are modifiable by the user. In other example embodiments, the user is not allowed to modify the fields.
-
Element 1060 is a button operable to confirm the details shown in elements 1030-1050, and operable to cause the financial institution to transfer the amount shown inelement 1040 from the customer's account to the business's account shown inelement 1030 on the transaction date shown inelement 1050. The financial institution may communicate with the payment initiator to inform the payment initiator that the payment was made or is scheduled to be made on the payment date. Alternatively or additionally, the financial institution may inform the payment initiator that the payment was successfully completed after the transfer of funds is complete. -
Element 1070 is a button operable to cancel the transfer of funds. In some example embodiments, the payment initiator is informed that payment was not completed. The payment initiator may send one or more additional messages to the user to remind the user of the outstanding invoice. -
FIG. 11 is a block diagram depicting the flow of data between entities facilitating a transfer of funds, in an example embodiment. As shown inFIG. 11 , the user may interact with the accounting software platform to choose the bank to make payment with. For example, theUI 900 ofFIG. 9 may be used to make the bank selection, and the selected bank sent to the accounting software platform via aChooseBank function 1105. The accounting software platform provides aresponse 1110 to the user. The response may be in the form of a web page informing the user that the bank selection was successfully made. The user then chooses to pay the invoices via a PayNow function 1115 (e.g., by activatingelement 805 ofFIG. 8 ). After receiving the payment command from the user, the accounting software platform generatesrequest 1120 to the accounting software server. The accounting software server responds by creating an encrypted block of data that includes the information for the user's bank and an invoice to be paid and sending the encrypted block of data in theresponse 1125. Theresponse 1130 from the accounting software platform to the user also includes this data, along with an address for redirection. For example, the received web page may include an HTML meta tag that causes the page to refresh from a different URL. - Accordingly, the user is redirected 1135 to the internet banking site. The internet banking site sends a
response 1140, such as a welcome or login web page. The user sends authentication data to the internet banking site, such as a user name and password. The internet banking site sends aresponse 1150, such as an acknowledgement that the user authentication was successful, along with a redirection address to another page within the internet banking site at which the invoice can be paid. The user is redirected 1155 to the new page, and receives the page inresponse 1160 from the internet banking server. The response page may include information about the transaction and request for confirmation from the user to pay the invoice. The user submits theconfirmation 1165 to the internet banking server, which generates a request to process 1170 the payment to the banking services server. The banking services server initiates the processing of the payment and sends anappropriate response 1175 to the internet banking server. The internet banking server sends aresponse 1180 to the user. For example, the user may be presented with a web page indicating that the invoice payment was successful. - The banking services server or internet banking server sends a
confirmation 1185 to the accounting software platform or accounting software server to inform the accounting software that the invoice has been paid. Accordingly, when the entity that generated the invoice next accesses the accounting software, the entity can be informed that payment was received. -
FIG. 12 is a flowchart of anexample method 1200 for facilitating direct bank transfers. - In
operation 1210, the online accounting software server may present an invoice and a payment button (such as those shown inFIG. 8 ) to a client device of a user (e.g., a customer of a business). The invoice may identify an amount owed by the user to the business. The payment button may be associated with an option to pay the amount to the business through a particular bank of the user. The particular bank to be used may be selected by the user. - In
operation 1220, the online accounting software server may receive, from the client device, a request to pay the amount through the user's account with the particular bank selected. The request may be made using the payment button. - In
operation 1230, the request may be used by the online account software server to redirect the client device to a website of the particular bank selected, such that the particular bank may determine the validity of the request to pay the amount through the user's account and may transfer the amount from the user account to the business's bank account. - In
operation 1240, the online accounting software server may receive an indication indicating the amount was transferred from the user account to the business's bank account. The indication may have been sent from the bank selected by the user, from which funds were transferred. Alternatively or additionally, the indication may have been sent from the bank of the business, to which funds were transferred. -
FIG. 13 is a flowchart of anexample method 1300 for facilitating direct bank transfers. - In
operations - In
operation 1330, the payment initiator presents an invoice with a payment button at a client device of a user. For example, the payment initiator may send a web page to a web browser on a client device. As another example, the payment initiator and the client device may interact through a programmatic interface, such as an API, to cause the presentation of the invoice and payment button to the user. - In
operation 1340, the payment initiator receives a request to pay the invoice. For example, the user may press the payment button, causing an HTTP or API message to be sent to the payment initiator. The request may include information about a user's bank account at the bank, or an indication usable by the payment initiator to access the user's bank account information in a database of the payment initiator. - In
operations 1350 and 1360, the payment initiator encrypts a data packet using the bank's public key and signs the data packet with the payment initiator's private key. The data packet includes information usable by the bank to process the payment of the invoice. For example, the data packet may include an account number of the user, account information of the entity presenting the invoice, a timestamp for when the data packet was created, a valid duration for the request or timestamp for when the data packet expires, an amount of the invoice, and so on. - In
operation 1370, the payment initiator redirects the client device to the bank. For example, if the client is connected to the payment initiator via a web connection, the client's web browser can be directed to load a web page from a website of the bank. As another example, if the client is connected to the payment initiator via an application interface, an application of the bank on the client device may be started for the user. - In
operation 1380, the encrypted data is sent from the payment initiator to the bank via the client device. For example, the encrypted data can be sent to the client device from the payment initiator. After the client has been redirected to the bank, or as part of the redirection process, the bank receives the encrypted data from the client device. - After receiving the encrypted data, the bank decrypts the data using the payment initiator's public key and the bank's private key. Based on the information in the data, the bank presents a user interface to the user, allowing the user to confirm payment. The UI presented to the user may be prepopulated with information from the invoice, such as the amount and the payee, based on the information extracted from the encrypted data.
- Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
- In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
- Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
- Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
- The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
- Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
- The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a SaaS. For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).
- Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
- A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
- In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry (e.g., a FPGA or an ASIC).
- The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.
-
FIG. 14 is a block diagram of a machine in the example form of acomputer system 1400 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. -
Example computer system 1400 includes a processor 1402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), amain memory 1404, and astatic memory 1406, which communicate with each other via abus 1408.Computer system 1400 may further include a video display device 1410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).Computer system 1400 also includes an alphanumeric input device 1412 (e.g., a keyboard), a user interface navigation device 1414 (e.g., a mouse or touch sensitive display), adisk drive unit 1416, a signal generation device 1418 (e.g., a speaker), and anetwork interface device 1420. -
Disk drive unit 1416 includes a machine-readable medium 1422 on which is stored one or more sets of instructions and data structures (e.g., software) 1424 embodying or utilized by any one or more of the methodologies or functions described herein.Instructions 1424 may also reside, completely or at least partially, withinmain memory 1404, withinstatic memory 1406, and/or withinprocessor 1402 during execution thereof bycomputer system 1400, withmain memory 1404 andprocessor 1402 also constituting machine-readable media. - While machine-
readable medium 1422 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present technology, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. -
Instructions 1424 may further be transmitted or received over acommunications network 1426 using a transmission medium.Instructions 1424 may be transmitted usingnetwork interface device 1420 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMAX networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software. - Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the technology. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
- Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
Claims (20)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/689,894 US20150220889A1 (en) | 2013-07-31 | 2015-04-17 | Systems and methods of direct account transfer |
US17/664,761 US11803826B2 (en) | 2013-07-31 | 2022-05-24 | Systems and methods of direct account transfer |
US18/468,431 US20240070635A1 (en) | 2013-07-31 | 2023-09-15 | Systems and methods of direct account transfer |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361860771P | 2013-07-31 | 2013-07-31 | |
US14/446,782 US9741024B2 (en) | 2013-07-31 | 2014-07-30 | Systems and methods of bank transfer |
US14/689,894 US20150220889A1 (en) | 2013-07-31 | 2015-04-17 | Systems and methods of direct account transfer |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/446,782 Continuation US9741024B2 (en) | 2013-07-31 | 2014-07-30 | Systems and methods of bank transfer |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/664,761 Continuation US11803826B2 (en) | 2013-07-31 | 2022-05-24 | Systems and methods of direct account transfer |
Publications (1)
Publication Number | Publication Date |
---|---|
US20150220889A1 true US20150220889A1 (en) | 2015-08-06 |
Family
ID=52428578
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/446,782 Active 2035-11-18 US9741024B2 (en) | 2013-07-31 | 2014-07-30 | Systems and methods of bank transfer |
US14/689,894 Abandoned US20150220889A1 (en) | 2013-07-31 | 2015-04-17 | Systems and methods of direct account transfer |
US17/664,761 Active US11803826B2 (en) | 2013-07-31 | 2022-05-24 | Systems and methods of direct account transfer |
US18/468,431 Pending US20240070635A1 (en) | 2013-07-31 | 2023-09-15 | Systems and methods of direct account transfer |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/446,782 Active 2035-11-18 US9741024B2 (en) | 2013-07-31 | 2014-07-30 | Systems and methods of bank transfer |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/664,761 Active US11803826B2 (en) | 2013-07-31 | 2022-05-24 | Systems and methods of direct account transfer |
US18/468,431 Pending US20240070635A1 (en) | 2013-07-31 | 2023-09-15 | Systems and methods of direct account transfer |
Country Status (9)
Country | Link |
---|---|
US (4) | US9741024B2 (en) |
EP (1) | EP3028226A4 (en) |
CN (1) | CN105593882B (en) |
AU (4) | AU2014296104A1 (en) |
CA (1) | CA2919380C (en) |
MY (1) | MY180889A (en) |
SG (1) | SG11201600569WA (en) |
WO (1) | WO2015017707A2 (en) |
ZA (1) | ZA201600817B (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105787714A (en) * | 2016-03-18 | 2016-07-20 | 联想(北京)有限公司 | A method and system for transferring accounts between payment applications |
US9741024B2 (en) | 2013-07-31 | 2017-08-22 | Xero Limited | Systems and methods of bank transfer |
US20220230237A1 (en) * | 2021-01-15 | 2022-07-21 | Eric Solis | Credential push to credit push network |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160043909A1 (en) * | 2014-08-08 | 2016-02-11 | Microsoft Corporation | Hierarchical Subscription Management |
US11037142B2 (en) * | 2016-10-28 | 2021-06-15 | Jpmorgan Chase Bank, N.A. | Systems and methods for the application of distributed ledgers for network payments as financial exchange settlement and reconciliation |
US20180240083A1 (en) * | 2017-02-21 | 2018-08-23 | Capital One Services, Llc | Systems and methods for providing an orchestration layer for service offered by early warning services |
CN107992992B (en) * | 2017-11-07 | 2021-12-21 | 中国银行股份有限公司 | Unionpay IC card transaction data analysis system and method |
CN110659891A (en) * | 2019-09-29 | 2020-01-07 | 浪潮软件集团有限公司 | Method for multi-order concurrent large-data-volume online payment |
CN113988847A (en) | 2019-12-31 | 2022-01-28 | 网联清算有限公司 | Payment processing method, device and system |
Citations (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010047332A1 (en) * | 2000-02-18 | 2001-11-29 | Editt Gonen-Friedman | Methods and systems for online self-service receivables management and automated online receivables dispute resolution |
US20020082987A1 (en) * | 2000-12-27 | 2002-06-27 | Wilson Linda S. | Systems and methods for making installment loan payments using payroll debits |
US20020120566A1 (en) * | 2001-02-28 | 2002-08-29 | E-Business Exchange Pte. Ltd | Payment enabling exchange client system |
US20020194123A1 (en) * | 2001-06-07 | 2002-12-19 | Richard Agee | Rapid tax collection system and method |
US20030009427A1 (en) * | 2001-07-03 | 2003-01-09 | Wistron Corporation | Phone-mediating trading system and method |
US20040044603A1 (en) * | 2002-08-30 | 2004-03-04 | Gordon-Ervin Brenda L. | Electronic invoice processing system with boolean feature |
US20040049439A1 (en) * | 2002-09-06 | 2004-03-11 | David Johnston | Interactive electronic bill payment system |
US20040059924A1 (en) * | 2002-07-03 | 2004-03-25 | Aurora Wireless Technologies, Ltd. | Biometric private key infrastructure |
US20050154664A1 (en) * | 2000-08-22 | 2005-07-14 | Guy Keith A. | Credit and financial information and management system |
US20050177518A1 (en) * | 2004-02-10 | 2005-08-11 | Brown Collie D. | Electronic funds transfer and electronic bill receipt and payment system |
US20050283259A1 (en) * | 2004-06-22 | 2005-12-22 | Wolpow Richard A | Dispensing system with real time inventory management |
US20060282680A1 (en) * | 2005-06-14 | 2006-12-14 | Kuhlman Douglas A | Method and apparatus for accessing digital data using biometric information |
US20080320576A1 (en) * | 2007-06-22 | 2008-12-25 | Microsoft Corporation | Unified online verification service |
US20090043687A1 (en) * | 2000-11-01 | 2009-02-12 | Van Soestbergen Mark | Method and System for Banking and Exchanging Emission Reduction Credits |
US20090068982A1 (en) * | 2007-09-10 | 2009-03-12 | Microsoft Corporation | Mobile wallet and digital payment |
US20090265775A1 (en) * | 2005-03-31 | 2009-10-22 | British Telecommunications Public Limited Company | Proximity Based Authentication Using Tokens |
US20110288881A1 (en) * | 2010-05-21 | 2011-11-24 | Diversinet Corp. | Method and System for Processing Healthcare Payments |
US20120072296A1 (en) * | 2010-09-22 | 2012-03-22 | James Sinton | Methods and systems for initiating a financial transaction by a cardholder device |
US20120089521A1 (en) * | 2010-01-11 | 2012-04-12 | Abrevaya Adam | Method and apparatus for billing purchases from a mobile phone application |
US20120089943A1 (en) * | 2010-10-06 | 2012-04-12 | Microsoft Corporation | Initiating and completing transactions via notification elements |
US20120116967A1 (en) * | 2010-11-04 | 2012-05-10 | Bank Of America Corporation | Mobile payment system and method |
US20120221466A1 (en) * | 2011-02-28 | 2012-08-30 | Thomas Finley Look | Method for improved financial transactions |
US20120259717A1 (en) * | 2011-04-08 | 2012-10-11 | Research In Motion Limited | Payment processing system including mobile wireless communications device to send a payment confirmation to a transaction terminal and associated methods |
US20130080298A1 (en) * | 2011-09-23 | 2013-03-28 | Deborah A. Latulipe | System and method for processing a financial account |
US20130137405A1 (en) * | 2011-11-27 | 2013-05-30 | Fortumo OU | System and method to facilitate in-application purchases on mobile devices |
US20130273882A1 (en) * | 2012-04-17 | 2013-10-17 | Bango.Net Limited | Payment authentication systems |
US8850567B1 (en) * | 2008-02-04 | 2014-09-30 | Trend Micro, Inc. | Unauthorized URL requests detection |
US9197696B1 (en) * | 2015-01-19 | 2015-11-24 | Vuclip | Offline content distribution networks |
Family Cites Families (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5790677A (en) * | 1995-06-29 | 1998-08-04 | Microsoft Corporation | System and method for secure electronic commerce transactions |
US6324525B1 (en) | 1996-06-17 | 2001-11-27 | Hewlett-Packard Company | Settlement of aggregated electronic transactions over a network |
DE69739173D1 (en) | 1996-10-09 | 2009-01-29 | Visa Int Service Ass | ELECTRONIC SYSTEM FOR PRESENTING EXPLANATIONS |
US6044362A (en) | 1997-09-08 | 2000-03-28 | Neely; R. Alan | Electronic invoicing and payment system |
US6314517B1 (en) | 1998-04-02 | 2001-11-06 | Entrust Technologies Limited | Method and system for notarizing digital signature data in a system employing cryptography based security |
US8165958B1 (en) * | 1999-03-26 | 2012-04-24 | Metavante Corporation | Electronic bill presentation and payment method and system |
AUPQ696500A0 (en) | 2000-04-17 | 2000-05-11 | Qsi Payment Technologies Pty Ltd | Electronic commerce payment system |
US8417628B2 (en) | 2000-06-29 | 2013-04-09 | Jpmorgan Chase Bank, N.A. | Electronic bill presentment and payment system and method |
US20020082990A1 (en) | 2000-12-22 | 2002-06-27 | J.J. & Associates Inc. | Method of invoice presentation and payment |
WO2002086829A1 (en) | 2001-04-16 | 2002-10-31 | Mobile Solutions And Payment Services Pte Ltd | Method and system for performing a transaction utilising a thin payment network (mvent) |
US7110986B1 (en) | 2001-04-23 | 2006-09-19 | Diebold, Incorporated | Automated banking machine system and method |
WO2004025392A2 (en) | 2002-09-11 | 2004-03-25 | Purchase, Graham, Erlank | Electronic commerce transactions |
US7404204B2 (en) * | 2004-02-06 | 2008-07-22 | Hewlett-Packard Development Company, L.P. | System and method for authentication via a single sign-on server |
GB0410724D0 (en) | 2004-05-13 | 2004-06-16 | Watkins Daniel R | Authorisation system |
US7591424B2 (en) | 2006-03-30 | 2009-09-22 | Microsoft Corporation | Framework for adding billing payment types |
US9069745B2 (en) | 2007-01-16 | 2015-06-30 | Ebay, Inc. | Electronic form automation |
US8145189B2 (en) | 2007-06-27 | 2012-03-27 | Intuit Inc. | Technique for securely communicating information |
CN101354765A (en) * | 2008-09-24 | 2009-01-28 | 中国工商银行股份有限公司 | System and method for implementing internet trade guarantee payment and financing |
US10380573B2 (en) | 2008-09-30 | 2019-08-13 | Apple Inc. | Peer-to-peer financial transaction devices and methods |
US9928490B1 (en) * | 2009-01-16 | 2018-03-27 | Wells Fargo Bank, N.A. | System and method for transferring funds |
US20110270749A1 (en) | 2010-04-30 | 2011-11-03 | Robert Bennett | Electronic invoice presentation and payment system |
US20120116963A1 (en) | 2010-11-04 | 2012-05-10 | Bank Of America Corporation | Invoicing and electronic billing system and method |
CA2828448A1 (en) | 2011-02-27 | 2012-08-30 | Gui Sug Park | Secure payment system using a mobile phone, and payment method using same |
US11100431B2 (en) * | 2011-05-10 | 2021-08-24 | Dynamics Inc. | Systems and methods for mobile authorizations |
US8751317B2 (en) | 2011-05-12 | 2014-06-10 | Koin, Inc. | Enabling a merchant's storefront POS (point of sale) system to accept a payment transaction verified by SMS messaging with buyer's mobile phone |
US20140344127A1 (en) | 2011-10-21 | 2014-11-20 | Daniel B. Thomas | Network-based electronic invoicing system with reverse invoicing |
GB2509895A (en) | 2012-11-22 | 2014-07-23 | Visa Europe Ltd | Activation and Use of a Digital Wallet via Online Banking |
US20150003951A1 (en) | 2013-06-28 | 2015-01-01 | International Business Machines Corporation | High performance tape system |
US9741024B2 (en) | 2013-07-31 | 2017-08-22 | Xero Limited | Systems and methods of bank transfer |
-
2014
- 2014-07-30 US US14/446,782 patent/US9741024B2/en active Active
- 2014-07-31 MY MYPI2016000185A patent/MY180889A/en unknown
- 2014-07-31 CA CA2919380A patent/CA2919380C/en active Active
- 2014-07-31 AU AU2014296104A patent/AU2014296104A1/en not_active Abandoned
- 2014-07-31 EP EP14832987.3A patent/EP3028226A4/en not_active Withdrawn
- 2014-07-31 CN CN201480048034.6A patent/CN105593882B/en active Active
- 2014-07-31 SG SG11201600569WA patent/SG11201600569WA/en unknown
- 2014-07-31 WO PCT/US2014/049247 patent/WO2015017707A2/en active Application Filing
-
2015
- 2015-04-17 US US14/689,894 patent/US20150220889A1/en not_active Abandoned
-
2016
- 2016-02-05 ZA ZA2016/00817A patent/ZA201600817B/en unknown
-
2020
- 2020-03-20 AU AU2020202025A patent/AU2020202025B2/en active Active
-
2022
- 2022-02-04 AU AU2022200775A patent/AU2022200775B2/en active Active
- 2022-05-24 US US17/664,761 patent/US11803826B2/en active Active
-
2023
- 2023-03-27 AU AU2023201869A patent/AU2023201869A1/en active Pending
- 2023-09-15 US US18/468,431 patent/US20240070635A1/en active Pending
Patent Citations (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010047332A1 (en) * | 2000-02-18 | 2001-11-29 | Editt Gonen-Friedman | Methods and systems for online self-service receivables management and automated online receivables dispute resolution |
US20050154664A1 (en) * | 2000-08-22 | 2005-07-14 | Guy Keith A. | Credit and financial information and management system |
US20090043687A1 (en) * | 2000-11-01 | 2009-02-12 | Van Soestbergen Mark | Method and System for Banking and Exchanging Emission Reduction Credits |
US20020082987A1 (en) * | 2000-12-27 | 2002-06-27 | Wilson Linda S. | Systems and methods for making installment loan payments using payroll debits |
US20020120566A1 (en) * | 2001-02-28 | 2002-08-29 | E-Business Exchange Pte. Ltd | Payment enabling exchange client system |
US20020194123A1 (en) * | 2001-06-07 | 2002-12-19 | Richard Agee | Rapid tax collection system and method |
US20030009427A1 (en) * | 2001-07-03 | 2003-01-09 | Wistron Corporation | Phone-mediating trading system and method |
US20040059924A1 (en) * | 2002-07-03 | 2004-03-25 | Aurora Wireless Technologies, Ltd. | Biometric private key infrastructure |
US20040044603A1 (en) * | 2002-08-30 | 2004-03-04 | Gordon-Ervin Brenda L. | Electronic invoice processing system with boolean feature |
US20040049439A1 (en) * | 2002-09-06 | 2004-03-11 | David Johnston | Interactive electronic bill payment system |
US20050177518A1 (en) * | 2004-02-10 | 2005-08-11 | Brown Collie D. | Electronic funds transfer and electronic bill receipt and payment system |
US20050283259A1 (en) * | 2004-06-22 | 2005-12-22 | Wolpow Richard A | Dispensing system with real time inventory management |
US20090265775A1 (en) * | 2005-03-31 | 2009-10-22 | British Telecommunications Public Limited Company | Proximity Based Authentication Using Tokens |
US20060282680A1 (en) * | 2005-06-14 | 2006-12-14 | Kuhlman Douglas A | Method and apparatus for accessing digital data using biometric information |
US20080320576A1 (en) * | 2007-06-22 | 2008-12-25 | Microsoft Corporation | Unified online verification service |
US20090068982A1 (en) * | 2007-09-10 | 2009-03-12 | Microsoft Corporation | Mobile wallet and digital payment |
US8850567B1 (en) * | 2008-02-04 | 2014-09-30 | Trend Micro, Inc. | Unauthorized URL requests detection |
US20120089521A1 (en) * | 2010-01-11 | 2012-04-12 | Abrevaya Adam | Method and apparatus for billing purchases from a mobile phone application |
US20110288881A1 (en) * | 2010-05-21 | 2011-11-24 | Diversinet Corp. | Method and System for Processing Healthcare Payments |
US20120072296A1 (en) * | 2010-09-22 | 2012-03-22 | James Sinton | Methods and systems for initiating a financial transaction by a cardholder device |
US20120089943A1 (en) * | 2010-10-06 | 2012-04-12 | Microsoft Corporation | Initiating and completing transactions via notification elements |
US20120116967A1 (en) * | 2010-11-04 | 2012-05-10 | Bank Of America Corporation | Mobile payment system and method |
US20120221466A1 (en) * | 2011-02-28 | 2012-08-30 | Thomas Finley Look | Method for improved financial transactions |
US20120259717A1 (en) * | 2011-04-08 | 2012-10-11 | Research In Motion Limited | Payment processing system including mobile wireless communications device to send a payment confirmation to a transaction terminal and associated methods |
US20130080298A1 (en) * | 2011-09-23 | 2013-03-28 | Deborah A. Latulipe | System and method for processing a financial account |
US20130137405A1 (en) * | 2011-11-27 | 2013-05-30 | Fortumo OU | System and method to facilitate in-application purchases on mobile devices |
US20130273882A1 (en) * | 2012-04-17 | 2013-10-17 | Bango.Net Limited | Payment authentication systems |
US9197696B1 (en) * | 2015-01-19 | 2015-11-24 | Vuclip | Offline content distribution networks |
Non-Patent Citations (1)
Title |
---|
Soto US 2004/0049924 A1 * |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9741024B2 (en) | 2013-07-31 | 2017-08-22 | Xero Limited | Systems and methods of bank transfer |
US11803826B2 (en) | 2013-07-31 | 2023-10-31 | Xero Limited | Systems and methods of direct account transfer |
CN105787714A (en) * | 2016-03-18 | 2016-07-20 | 联想(北京)有限公司 | A method and system for transferring accounts between payment applications |
US20220230237A1 (en) * | 2021-01-15 | 2022-07-21 | Eric Solis | Credential push to credit push network |
WO2022155444A1 (en) * | 2021-01-15 | 2022-07-21 | Solis Eric | Credential push to credit push network |
Also Published As
Publication number | Publication date |
---|---|
US9741024B2 (en) | 2017-08-22 |
AU2022200775A1 (en) | 2022-02-24 |
AU2020202025A1 (en) | 2020-04-09 |
US20220292466A1 (en) | 2022-09-15 |
AU2022200775B2 (en) | 2023-03-23 |
WO2015017707A3 (en) | 2015-06-04 |
ZA201600817B (en) | 2017-11-29 |
CA2919380A1 (en) | 2015-02-05 |
AU2020202025B2 (en) | 2021-12-16 |
US20150039510A1 (en) | 2015-02-05 |
EP3028226A2 (en) | 2016-06-08 |
SG11201600569WA (en) | 2016-02-26 |
AU2023201869A1 (en) | 2023-04-27 |
US11803826B2 (en) | 2023-10-31 |
MY180889A (en) | 2020-12-11 |
CA2919380C (en) | 2023-10-10 |
CN105593882A (en) | 2016-05-18 |
AU2014296104A1 (en) | 2016-03-17 |
CN105593882B (en) | 2019-12-03 |
EP3028226A4 (en) | 2017-03-08 |
US20240070635A1 (en) | 2024-02-29 |
WO2015017707A2 (en) | 2015-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11803826B2 (en) | Systems and methods of direct account transfer | |
US11783433B2 (en) | Systems and methods of access control and system integration | |
AU2014324112A1 (en) | Systems for access control and system integration | |
AU2015100161A4 (en) | Systems and methods of direct bank transfer | |
AU2015100411A4 (en) | Systems and methods of access control and system integration | |
AU2015101667A4 (en) | Systems and methods of direct bank transfer |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: XERO LIMITED, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DRURY, RODNEY KENNETH;VICKERS, MATTHEW JOHN;SIGNING DATES FROM 20140818 TO 20141216;REEL/FRAME:040088/0603 |
|
STCV | Information on status: appeal procedure |
Free format text: EXAMINER'S ANSWER TO APPEAL BRIEF MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: ON APPEAL -- AWAITING DECISION BY THE BOARD OF APPEALS |
|
STCV | Information on status: appeal procedure |
Free format text: BOARD OF APPEALS DECISION RENDERED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |