Patent Application
20140101045
This invention relates generally to payment processing and, more specifically, to a payment action page queue for a mobile device.
A mobile device may facilitate payment processing. For example, a user of the mobile device may perform payment initiation, payment approval, or payment rejection using a browser or dedicated application of the mobile device. The mobile device may receive payment information from an enterprise. The mobile device may communicate user input received via the browser or dedicated application to the enterprise. The enterprise may process the payments according to the user input.
In accordance with the teachings of the present disclosure, disadvantages and problems associated with processing payment transactions may be reduced or eliminated.
According to an exemplary embodiment, a method includes identifying a plurality of initiated payments awaiting approval. An initiated payment is associated with a plurality of payment details describing the initiated payment. A queue comprising a plurality of payment action pages is generated. A payment action page corresponds to an initiated payment of the plurality of initiated payments and comprises the plurality of payment details describing the corresponding initiated payment. The method further includes displaying on the mobile device a first payment action page of the plurality of payment action pages in the queue and displaying on the mobile device a second payment action page of the plurality of payment action pages in the queue in response to receiving a payment action associated with the first payment action page from the user of the mobile device.
Certain embodiments of the invention may provide one or more technical advantages. A technical advantage of one embodiment includes efficient communication between a mobile device and an enterprise by transmission of payment actions in groups. Another advantage includes queuing a plurality of payment action pages to facilitate payment review and payment actioning. Another advantage includes loading information from calls to multiple different application programming interfaces (APIs) into a single payment action page. Another advantage includes reducing network bandwidth used by extraneous submissions by immediately notifying a user that a group of payment actions has been submitted to an enterprise.
Certain embodiments of the present disclosure may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art in view of the figures, descriptions, and claims of the present disclosure.
For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
Embodiments of the present invention and its advantages are best understood by referring to
In various embodiments, a mobile device 102 receives payment information from enterprise 104. In particular embodiments, mobile device 102 receives initiated payments that are awaiting approval to be paid. The user of mobile device 102 may have the authority to apply a payment action to one or more of the initiated payments. For example, the user may approve the payment, reject the payment, delete the payment, or prompt another user to action the payment. In particular embodiments, mobile device 102 displays a summary page including a few details of each initiated payment. From this summary page, the user may apply actions to the initiated payments. However, in certain situations, additional details regarding an initiated payment may aid the user in making a quick and accurate assessment of which payment action should be applied to a payment. In particular embodiments, mobile device 102 generates a queue of payment action pages in response to user input. Each payment action page corresponds to a payment and includes detailed information regarding the payment. In some embodiments, each payment action page includes the details shown in the summary page and additional details regarding the corresponding payment. The user may iterate through the payment action pages and apply actions to each initiated payment. When the user is finished, mobile device 102 may submit the payment actions to enterprise 104 for further processing. Such embodiments may enable a user to apply actions more quickly and accurately to the initiated payments in comparison to applications in which the user must action the payments from a summary page or is not able to iterate through detailed views of the payments.
In various embodiments, mobile device 102 receives payment templates from enterprise 104. The templates may be displayed by mobile device 102 in a summary page that lists a few details about the payment template. The user may select multiple templates from the summary page. In response to the selection, mobile device 102 may generate a queue of payment template pages. Each payment template page includes information about the payment template. In various embodiments, a payment template page includes all of the information about the payment template that is shown in the summary page and additional information about the payment template. The user may iterate through the payment template pages of the queue and initiate payments by entering monetary amounts for the payments in the payment template pages. When the user is finished, mobile device 102 may submit the initiated payments to enterprise 104 for further processing. For example, the initiated payments may be sent to one or more individuals for payment actioning. Such embodiments may enable a user to initiate payments more quickly in comparison to applications that only allow a user to initiate payments one at a time.
System 100 includes mobile devices 102a-102c. In various embodiments, there may be any suitable number of mobile devices 102 that communicate with enterprise 104 through network 106. Mobile device 102 may include a wireless or cellular telephone (e.g., a smartphone); a netbook, tablet, or slate personal computer; a personal digital assistant; or any other portable device capable of receiving, processing, storing, and/or communicating information with other components of system 100. Mobile device 102 may also comprise a user interface, such as a display, touch screen, keyboard, mouse, or other appropriate terminal equipment. In particular embodiments, mobile device 102 connects to network 106 via a cellular or other wireless connection.
Mobile device 102 may be operated by a customer or a user associated with a customer of enterprise 104. A customer may maintain one or more accounts with enterprise 104. The customer may be an individual or an organization comprising multiple individuals, such as a business. An account may be a credit card account, a debit card account, a savings account, a checking account, a business account, or any other account. An account may be associated with enterprise 104. For example, enterprise 104 may maintain the account, store records of transactions involving the account, transfer money to and from the account, or perform other operations associated with the account. An account may enable a customer to purchase goods or services with funds or credit associated with the customer's account.
Network 106 represents any suitable network operable to facilitate communication between the components of system 100, such as mobile devices 102 and enterprise 104. Network 106 may include any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. Network 106 may include all or a portion of a public switched telephone network (PSTN), a cellular network, a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network, such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof, operable to facilitate communication between the components.
Enterprise 104 may represent any business or organization. One example of an enterprise may include a financial institution. A financial institution may include any business or organization that engages in financial activities, which may include, but are not limited to, banking and investment activities such as maintaining accounts (e.g., transaction accounts, savings accounts, credit accounts, investment accounts, insurance accounts, portfolios, etc.), receiving deposits, crediting accounts, debiting accounts, extending credit to account holders, purchasing securities, providing insurance, and supervising a customer's portfolio.
A financial institution may provide a variety of financial products and services. Examples of financial products and services may include, but are not limited to, account services such as maintaining accounts, receiving deposits, crediting accounts, debiting accounts, extending credit, purchasing securities, providing insurance, and portfolio management.
A financial institution may provide financial products and services to customers. For example, a financial institution may maintain an account for a customer. The customer may perform a variety of activities using the account, including contributing funds to the account, withdrawing funds from the account, managing the account, and being responsible or liable for account transactions (e.g., purchases).
In the embodiment depicted, mobile device 102a includes one or more interfaces 120, one or more processors 118, and one or more memories 114 that collectively facilitate generation of payment action page queues and payment template page queues by mobile device 102a. Mobile devices 102b and 102c may include similar components.
Network interface 120 represents any suitable device operable to receive information from network 106, transmit information through network 106, perform processing of information, communicate with other devices, or any combination of the preceding. For example, network interface 120 receives payment information such as information about initiated payments or payment template information from enterprise 104 through network 106. As another example, network interface 120 may communicate payment information such as initiated payments or actions associated with initiated payments to enterprise 104. Network interface 120 represents any port or connection, real or virtual, including any suitable hardware and/or software, including protocol conversion and data processing capabilities, to communicate through a LAN, WAN, or other communication system that allows mobile device 102a to exchange information with enterprise 104 or other components of system 100.
Processor 118 communicatively couples to network interface 120 and memory 114 and controls the operation and administration of mobile device 102a by processing information received from network interface 120 and memory 114. Processor 118 includes any hardware and/or software that operates to control and process information. For example, processor 118 executes payment application logic 116 to control the operation of mobile device 102a. Processor 118 may be a programmable logic device, a microcontroller, a microprocessor, any suitable processing device, or any suitable combination of the preceding.
Memory 114 stores, either permanently or temporarily, data, operational software, or other information for processor 118. Memory 114 includes any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, memory 114 may include Random Access Memory (RAM), Read Only Memory (ROM), magnetic storage devices, optical storage devices, or any other suitable information storage device or a combination of these devices. In the illustrated embodiment, memory 114 includes payment application logic 116. Payment application logic 116 generally refers to logic, rules, algorithms, code, tables, and/or other suitable instructions embodied in a computer-readable storage medium for performing the described functions and operations of mobile device 102a. While illustrated as including a particular module, memory 114 may include any suitable information for use in the operation of mobile device 102a.
In the embodiment depicted, enterprise 104 includes payment module 108, information reporting module 110, and administrative module 112. These modules each represent any suitable components that facilitate the operation of enterprise 104 by facilitating communication with mobile devices 102 and facilitating generation of payment action page queues and payment template page queues when appropriate. Each module may include a network server, any suitable remote server, a mainframe, a host computer, a workstation, a web server, a personal computer, a file server, or any other suitable device operable to communicate with mobile devices 102 and process data. In some embodiments, the modules may execute any suitable operating system such as IBM's zSeries/Operating System (z/OS), MS-DOS, PC-DOS, MAC-OS, WINDOWS, UNIX, OpenVMS, or any other appropriate operating system, including future operating systems. The functions of the modules 108, 110, and 112 may be performed by any suitable combination of one or more servers or other components at one or more locations. In an embodiment where a module is a server, the server may be a private server, and the server may be a virtual or physical server. The server may include one or more servers at the same or remote locations. Also, the modules may include any suitable component that functions as a server.
In particular embodiments, each module 108, 110, or 112 may provide a subset of the information used to generate payment action pages and/or payment template pages to mobile device 102. The information provided by payment module 108 may be retrieved from payment database 128, the information provided by information reporting module 110 may be retrieved from information reporting database 136, and the information provided by administrative module 112 may be retrieved from administrative database 144. In particular embodiments, payment module 108 provides information about an initiated payment or a payment template, such as a recipient of the payment, a payment amount, a value date and cut-off time, an initiator of the payment, an identifier of an account from which payment is to be made, notes associated with the payment, a transaction number associated with the payment, a transfer type, a template name, a sender reference number, or other suitable information associated with the payment. In particular embodiments, information reporting module 110 provides account balance information and any other suitable information and administrative module 112 provides contact information of individuals or entities associated with an initiated payment or a payment template and any other suitable information. In other embodiments, the information used to generate payment action pages and payment template pages may be distributed among the modules 108, 110, and 112 in any suitable manner.
In particular embodiments, each module implements its own API. When mobile device 102a requests information from a particular module, it calls the API implemented by that module. In particular embodiments, API calls to payment module 108 are sent to a first Uniform Resource Locator (URL), API calls to information reporting module 110 are sent to a second URL, and API calls to administrative module 112 are sent to a third URL. In other embodiments, API calls for the different modules may be sent to the same URL and passed to the relevant modules for processing.
Each module includes components that facilitate the operation of the module. For example, payment module 108 includes one or more interfaces 122, one or more processors 124, one or more memories 125, and payment database 128 that collectively facilitate generation of payment action page queues and payment template page queues for mobile devices 102. For purposes of explanation, only the components of payment module 108 are described in detail herein. However, the corresponding components of information reporting module 110 and administrative module 112 may perform similar functions.
Network interface 122 represents any suitable device operable to receive information from network 106, transmit information through network 106, perform processing of information, communicate with other devices, or any combination of the preceding. For example, network interface 122 may receive API calls requesting payment information from mobile devices 102 and communicate the requested information to mobile devices 102. Network interface 122 represents any port or connection, real or virtual, including any suitable hardware and/or software, including protocol conversion and data processing capabilities, to communicate through a LAN, WAN, or other communication system that allows enterprise 104 to exchange information with mobile devices 102 or other components of system 100.
Processor 124 communicatively couples to network interface 122, memory 125, and payment database 128, and controls the operation and administration of payment module 108 by processing information received from network interface 122, memory 125, and payment database 128. Processor 124 includes any hardware and/or software that operates to control and process information. For example, processor 124 executes payment API logic 126 to perform requests from API calls and otherwise control the operation of payment module 108. Processor 124 may be a programmable logic device, a microcontroller, a microprocessor, any suitable processing device, or any suitable combination of the preceding.
Memory 125 stores, either permanently or temporarily, data, operational software, or other information for processor 124. Memory 125 includes any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, memory 125 may include RAM, ROM, magnetic storage devices, optical storage devices, or any other suitable information storage device or a combination of these devices. In the illustrated embodiment, memory 125 includes payment API logic 126. Payment API logic 126 generally refers to logic, rules, algorithms, code, tables, and/or other suitable instructions embodied in a computer-readable storage medium for performing the described functions and operations of payment module 108. While illustrated as including a particular module, memory 125 may include any suitable information for use in the operation of payment module 108.
Payment database 128 stores, either permanently or temporarily, payment information used during the generation of payment action pages and payment template pages by mobile devices 102. Payment database 128 may also store payments initiated by mobile devices 102 and payment actions applied to initiated payments by mobile devices 102. Payment database 128 includes any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, payment database 128 may include RAM, ROM, magnetic storage devices, optical storage devices, or any other suitable information storage device or combination of these devices.
A component of system 100 may include an interface, logic, memory, and/or other suitable element. An interface receives input, sends output, processes the input and/or output and/or performs other suitable operations. An interface may comprise hardware and/or software. Logic performs the operation of the component, for example, logic executes instructions to generate output from input. Logic may include hardware, software, and/or other logic. Logic may be encoded in one or more tangible media, such as a computer-readable medium or any other suitable tangible medium, and may perform operations when executed by a computer. Certain logic, such as a processor, may manage the operation of a component. Examples of a processor include one or more computers, one or more microprocessors, one or more applications, and/or other logic.
Modifications, additions, or omissions may be made to system 100 without departing from the scope of the invention. For example, system 100 may include any number of mobile devices 102, networks 106, and enterprises 104. Any suitable logic may perform the functions of system 100 and the components within system 100.
In operation, mobile device 102 is operable to identify a plurality of initiated payments awaiting approval. The initiated payments may each be associated with payment details describing the particular initiated payment. Mobile device 102 is operable to generate a queue comprising a plurality of payment action pages. Each payment action page may correspond to an initiated payment and may include the payment details describing the corresponding initiated payment. Mobile device 102 is further operable to display a first payment action page of the queue and to subsequently display a second payment action page of the queue in response to receiving a payment action associated with the first payment action page from the user of mobile device 102.
In operation, mobile device 102 is further operable to display a plurality of payment template summaries simultaneously. A payment template summary corresponds to a payment template and includes a subset of a plurality of payment details associated with the payment template. The mobile device 102 is operable to receive a selection of two or more of the plurality of payment template summaries and to generate a queue of payment template pages according to the selection. A payment template page comprises the plurality of payment details associated with the payment template that corresponds to a selected payment template summary. The mobile device 102 is operable to display a first payment template page of the queue, to receive a monetary amount at the first payment template page from a user of mobile device 102, and to initiate a payment for the monetary amount. The initiated payment includes the plurality of payment details of the first payment template page.
At step 204, summaries of the identified initiated payments are displayed. For example, mobile device 102 may display the summaries in a page such as summary page 302 of
At step 206, it is determined whether a command to switch to a detailed view has been received. If a command to switch to a detailed view has not been received, the mobile device continues displaying summary page 302. If the command has been received, the method proceeds to step 208 where a queue of payment action pages is generated. Any suitable command may be used to switch to a detailed view. For example, summary page 302 may include a button that may be selected to switch to the detailed view. As another example, a user may select any of the template names 304 to switch to the detailed view.
An example queue of payment action pages 320a-320c is depicted in
In particular embodiments, the payment action pages 320 include payment details associated with the initiated payment that are not included in the corresponding summary 303. In particular embodiments, payment action pages 320 include all of the details included in summaries 303 in addition to other details associated with the corresponding payments.
As in the example summaries 303 described above, payment action pages 320 may include a name of the template used to create the payment, an amount of the payment, a value date of the payment, an icon indicating the urgency of the payment, the initiator of the payment, and an account from which the payment is to be made. A payment action page 320 may also include a separate field for a recipient of the payment, an address of the recipient, other contact information of the recipient, a balance of the account from which the payment is to be made, an enterprise (e.g., a bank) that maintains the account from which the payment is to be made, miscellaneous notes regarding the payment entered by an individual associated with the payment, a transaction number of the payment, a transfer type of the payment, (e.g., domestic high value (wire), low value wire (e.g., Automated Clearing House (ACH)), Society for Worldwide Interbank Financial Telecommunications (SWIFT) payment, foreign exchange payment, etc.), an account of the recipient to which the payment will be debited, a cut-off time of the payment (e.g., a time by which the payment must be approved in order for the payment to be processed in time for the funds to be available to the recipient on the value date), a sender reference number, the date and time that the payment was initiated, or other suitable payment details. Although payment action pages 320 depict particular details regarding the initiated payments, any available details may be depicted in the payment action pages 320. For example, payment details depicted in
In various embodiments, portions of payment action page 320 may link to additional information. For example, selection of the “View Notes” area may display notes that have been entered regarding the payment. As another example, selecting the “Debit Account” area may display information regarding the debit account, such as the account balance of the debit account.
Payment action pages 320 may also include various options that allow the user that is actioning the payment to contact the initiator of the payment. The selection of phone button 328 may initiate a phone call to a phone (e.g., an office phone) of the payment initiator, the selection of mobile phone button 330 may initiate a phone call to a mobile phone of the payment initiator, the selection of button 332 may initiate a text message to the payment initiator, and the selection of button 334 may initiate an email to the payment initiator.
In particular embodiments, the payment details displayed by or accessible via the payment action pages 320 may be obtained through API calls to enterprise 104. In various embodiments, more than one API is called to obtain the payment details accessible through payment action pages 320. For example, one API call may be sent to a first URL to obtain some of the details of payment action pages 320, while one or more other API calls may be sent to one or more other URLs to obtain the remainder of the details. As another example, separate API calls may be sent to the same URL. As an example, account balance information may be obtained through an API call sent to a URL associated with information reporting module 110, contact information of a payment initiator (made available through buttons 328, 330, 332, and 334) may be obtained through a call to a separate API that is sent to a URL associated with administrative module 112, and other payment details may be obtained through a call to another API that is sent to a URL associated with payment module 108. In particular embodiments, the results from an API call may be displayed in payment action page 320 while mobile device 102 waits to receive the results from the other API calls. Upon receipt of the remainder of the results, these results may be displayed along with the other details in payment action page 320 or may be made available via a link in payment action page 320.
In particular embodiments, the details displayed by or accessible through the payment action pages 320 are based on permissions associated with the user of mobile device 102. For example, enterprise 104 may determine which details of a payment a user may access based on an identifier of the user and transmit these details to mobile device 102 while blocking transmission of additional details that the user does not have permission to view. For example, a user may not have permission to view the balance of the account from which payment is to be made. In such a case, the balance would not be shown on payment action pages 320 generated for the user.
Upon generation of the queue of payment action pages 320, a payment action page 320 from the queue is selected and displayed by mobile device 102. The payment action page 320 that is displayed first may be determined in any suitable manner and in particular embodiments the order in which the payment action pages 320 are displayed is selectable by the user. For example, the payment action page 320a that corresponds to the same payment as the first summary 303a (or first selected summary 303) displayed by summary page 302 may be displayed first. As another example, the payment action page 320 that is the most urgent (e.g., has the least amount of time remaining before the cutoff time) may be displayed first.
In response to receiving a command from a user of mobile device 102 while the first payment action page 320a is displayed, a second payment action page 320b from the queue may be displayed. For example, selection of an approve button 322, reject button 324, or next button 336 may result in the display of the second payment action page 320b. As another example, a user may swipe a finger across a touch sensitive portion of mobile device 102 to display the second payment action page 320b. In particular embodiments, the second payment action page 320b may be displayed immediately after the user command is performed. In other embodiments, one or more intermediate pages may be displayed by mobile device 102 before the second payment action page 320b is displayed. For example, if a user selects the reject button 324, mobile device 102 may display a page that requests a reason for the rejection of the payment and after reception of this reason the second payment action page 320b may be displayed.
At step 210, payment actions for initiated payments are received. If a command to switch to the detailed view is not received at step 206, a user may action initiated payments from summary page 302 by selecting one or more payments via selection boxes 308 and then selecting an action button, such as approve button 310 or reject button 312. The selected action is then associated with the selected payments. If the command to switch to a detailed view is detected at step 206, then the queue of payment action pages 320 is generated and the user of mobile device 102 may iterate through a detailed view of each payment and apply actions to the payments. Any suitable payment action may be applied to an initiated payment. For example, in the embodiment depicted, selection of the approve button 322 results in an approval action being applied to the payment and selection of the reject button 324 results in a rejection action being applied to the payment. In other embodiments, a forward for approval action may be applied to one or more of the payments. For example, if the user decides that a different user should approve or reject the payment, the user may specify that the payment be forwarded to the other user. During review of the payment action pages 320, the user may also decide to skip the actioning of a payment and may move to the next payment action page 320 by selecting the next button 336. Any payments that are not actioned by the user may remain as pending and be included in subsequent summary pages 302 and payment action pages 320 generated by mobile device 102.
After the user is finished actioning the payments, a summary of payment actions is displayed at step 212. The user may indicate that actioning is complete in any suitable manner. For example, in the embodiment depicted in
Any suitable summary of the payment actions entered by the user may be displayed. In the embodiment depicted in
Action summary page 340 may provide various display options. For example, the view shown in action summary page 340 is an example view that may be displayed when the transactions tab 344 is selected. Action summary page 340 may also include a totals tab 346 that when selected results in display of amount totals. For example, the aggregate monetary amount of the approved transactions may be displayed, the aggregate monetary amount of the rejected transactions may be displayed, and the aggregate monetary amount of the forwarded transactions may be displayed.
At step 214, an instruction to submit the payment actions is received. For example, a user may select a submit payments button 348 of action summary page 340 or otherwise indicate that the payment actions should be submitted to enterprise 104. In particular embodiments, the user may be prompted for a passcode via passcode field 342. The passcode may ensure that only authorized users submit payment actions to enterprise 104 via mobile device 102.
At step 216, it is determined whether the payment actions have been transmitted to enterprise 104. If it is determined that they have not, the method may return to any suitable step of the method, such as the display of the action summary page 340 at step 212. If it is determined that the payment actions have been transmitted to enterprise 104, a submission confirmation page 360 is displayed by mobile device 102 at step 218. As depicted in
After display of the submission confirmation at step 218, the method ends. Modifications, additions, or omissions may be made to the method. The method may include more, fewer, or other steps. Additionally, steps may be performed in parallel or in any suitable order. Any suitable component of system 100 may perform one or more steps of the method.
Modifications, additions, or omissions may be made to the pages depicted in
At step 404, summaries of the identified payment templates are displayed. For example, mobile device 102 may display the summaries in a page such as template summary page 500 of
At step 406, a selection of payment template summaries is received. As an example, a user may select various templates via selection boxes 504 or using other suitable methods. After identifying the desired payment templates, the user may confirm his choice in any suitable manner. For example, the user may use select button 506 to confirm the choice of payment templates.
At step 408, a queue of payment template pages is generated according to the selected payment template summaries. For example, in the embodiment depicted in
Each payment template page 520 includes a detailed view of the details associated with the corresponding payment template. In particular embodiments, the payment template pages 520 include payment details associated with the payment template that are not included in the corresponding payment template summary 502. In particular embodiments, payment template pages 520 include all of the details included in payment template summaries 502 in addition to other details associated with the corresponding payment templates.
As in the example payment template summaries 502 described above, payment template page 520 may include a name of the template, a name of the recipient of the payment, and an account from which the payment is to be made. A payment template page 520 may also include a payment type that describes how the payment will be transferred to the recipient, input fields for the payment amount, the value date of the payment, and a sender reference number, or any other suitable payment information. Although payment template pages 520 depict particular details regarding the payment templates, any available details may be depicted in the payment template pages 520. For example, payment details depicted in
In various embodiments, portions of payment template page 520 may link to additional information. For example, selecting the “Debit Account” area may display information regarding the debit account, such as the account balance of the debit account. As another example, selecting the “Beneficiary” area may display information regarding the payment recipient, such as contact information associated with the recipient. As another example, payment template page 520 may allow the user to access contact information of one or more designated reviewers of payments created using a particular template.
In particular embodiments, the payment details displayed by or accessible via the payment template pages 520 may be obtained through API calls to enterprise 104. In various embodiments, more than one API is called to obtain the payment details accessible through payment template pages 520. For example, one API call may be sent to a first URL to obtain some of the details of payment template pages 520, while one or more other API calls may be sent to one or more other URLs to obtain the remainder of the details. As an example, account balance information may be obtained through an API call sent to a URL associated with information reporting module 110, contact information of a payment reviewer or a payment recipient may be obtained through a call to a separate API that is sent to a URL associated with administrative module 112, and other payment details may be obtained through a call to another API that is sent to a URL associated with payment module 108. In particular embodiments, the results from an API call may be displayed in payment template page 520 while mobile device 102 waits to receive the results from the other API calls. Upon receipt of the remainder of the results, these results may be displayed along with the other details in payment template page 520 or may be made available via a link in payment template page 520.
In particular embodiments, the details displayed by or accessible through the payment template page 520 are based on permissions associated with the user of mobile device 102. For example, enterprise 104 may determine which details of a payment template a user may access based on an identifier of the user and transmit these details to mobile device 102 while blocking transmission of additional details that the user does not have permission to view. For example, a user may not have permission to view the balance of the account from which payment is to be made. In such a case, the balance would not be shown on payment template pages 520 generated for the user.
Upon generation of the queue of payment template pages 520, a payment template page 520 from the queue is selected and displayed by mobile device 102. The payment template page 520 that is displayed first may be determined in any suitable manner. For example, the payment template page 520a that corresponds to the same payment as the first selected payment template summary 504a of payment template summary page 500 may be displayed first.
In response to receiving a command from a user of mobile device 102 while the first payment template page 520a is displayed, a second payment action page 320b from the queue may be displayed. For example, selection of a skip button 524 or a next button 526 may result in the display of the second payment template page 520b. As another example, a user may swipe a finger across a touch sensitive portion of mobile device 102 to display the second payment template page 520b. Accordingly, a user may iterate through the queue of payment template pages 520 in order to quickly create a plurality of payments.
At step 410, edits to the payment template pages 520 are received. As an example, a user may enter an amount and a currency type in the “Credit Amount” field. Particular embodiments allow payments to be specified in any suitable currency. Accordingly, particular embodiments include a single mobile banking application that may be used to initiate payments to recipients located in various different countries. As further example of edits that may be made to payment template pages 520, a user may enter a value date or a sender reference number. Upon completion of the editing of a payment template page 520, the user may move to the next payment template page 520 by selecting the next button 526, swiping the screen, or by performing any other suitable action. A user may skip a payment template page 520 by selecting the skip button 524. A user may also cancel out of the editing process by selecting the cancel button 522.
At step 412, it is determined whether the user is finished editing payment template pages 520. If it is determined that the editing is not complete, mobile device 102 may continue to receive edits to payment template pages 520 from the user. If it is determined that the user is finished editing payment template pages 520, the method moves to step 414. Any suitable method may be used to determine whether editing is complete. For example, mobile device 102 may detect that a user has selected finish button 528, thereby indicating the user is finished editing payment template pages 520. In some embodiments, mobile device 102 may detect that a user is finished editing upon an action (such as selecting the next button 526 or swiping the screen) performed while the last payment template pages 520 of the queue is displayed.
After the user is finished editing the payment template pages 520, a summary of initiated payments is displayed at step 414. An initiated payment may be generated for each payment template page 520 in which the user has entered the requisite information. In particular embodiments, the requisite information includes a monetary amount of the desired payment and a value date (which may be auto-filled by mobile device 102 or entered by the user). In other embodiments, any other suitable information may be required. An initiated payment includes the payment details associated with the payment template in addition to payment details (e.g., monetary amount, value date) entered by the user during editing of the corresponding payment template page 520.
Any suitable summary of the payment actions entered by the user may be displayed at step 414. In the embodiment depicted in
Initiated payments summary page 540 may provide various display options. For example, the view shown in
At step 416, an instruction to submit the initiated payments to enterprise 104 is received. For example, a user may select a submit button 544 of initiated payments summary page 540 or otherwise indicate that the initiated payments should be submitted to enterprise 104.
At step 418, it is determined whether the initiated payments have been transmitted to enterprise 104. If it is determined that they have not, the method may return to any suitable step of the method, such as the display of the initiated payments summary page 540 at step 414. If it is determined that the initiated payments have been transmitted to enterprise 104, a submission confirmation page 560 is displayed by mobile device 102 at step 420. As depicted in
After display of the submission confirmation at step 420, the method ends. Modifications, additions, or omissions may be made to the method. The method may include more, fewer, or other steps. Additionally, steps may be performed in parallel or in any suitable order. Any suitable component of system 100 may perform one or more steps of the method.
Modifications, additions, or omissions may be made to the pages depicted in
Certain embodiments of the invention may provide one or more technical advantages. A technical advantage of one embodiment includes efficient communication between a mobile device and an enterprise by transmission of payment actions in groups. Another advantage includes queuing a plurality of payment action pages to facilitate payment review and payment actioning. Another advantage includes loading information from calls to multiple different application programming interfaces (APIs) into a single payment action page. Another advantage includes reducing network bandwidth used by extraneous submissions by immediately notifying a user that a group of payment actions has been submitted to an enterprise.
Although the present invention has been described with several embodiments, a myriad of changes, variations, alterations, transformations, and modifications may be suggested to one skilled in the art, and it is intended that the present invention encompass such changes, variations, alterations, transformations, and modifications as fall within the scope of the appended claims.
