Post-transaction tipping using modified transaction message fields

By adding tip or remuneration data structures to the transaction packet and automatically correcting the total transaction amount with the server, the problem of tip or remuneration cannot be processed after the transaction is solved, and automated tip or remuneration processing is realized, avoiding fraud marking.

CN113168626BActive Publication Date: 2025-08-19VISA INTERNATIONAL SERVICE ASSOCIATION
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN201880099667.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2018-11-27
Publication Date
2025-08-19
Estimated Expiration
2038-11-27

AI Technical Summary

Technical Problem

In the prior art, tips or remuneration after transactions cannot be effectively processed in a non-cash payment system, resulting in the possibility of being marked as fraudulent transactions and being cancelled, and the purpose of paying tips cannot be achieved.

Method used

Add data structures to the header field of the transaction message to store tip or remuneration information, and automatically correct the transaction amount through the server to keep the transaction in the "Open" or "Pending" state to facilitate subsequent tip or remuneration addition.

Benefits of technology

The ability to automatically add tips or remuneration after the transaction is completed is realized, avoiding the individual transactions being marked as fraud and ensuring that the tips or remuneration can be processed successfully.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113168626B_ABST
    Figure CN113168626B_ABST
Patent Text Reader

Abstract

A transaction server receives a request from a merchant's POS device. The server determines whether the merchant ID in the request matches a merchant ID stored in a database. If so, the server automatically modifies the first field with a predetermined secondary value associated with the merchant ID and updates the total amount in the second field to the sum of the transaction value and the predetermined secondary value. The server processes the request as a single request with the total amount in the second field. In one embodiment, if there is no match, the server monitors a subsequent request stream with an encrypted account and the merchant ID. Once identified, the server modifies the first field with the subsequent value and updates the total amount in the message field to the sum of the transaction value and the subsequent value, and processes the electronic transaction request as the single request.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present invention generally relate to post-transaction modifications of electronic transactions. Background Art

[0002] Cashless payment methods, such as credit and debit cards, mobile payments, and contactless payments, have significantly changed consumer spending habits. These payment methods have evolved over time, from plastic cards with magnetic stripes to cards with advanced security technologies, such as EMV (Electronic Media Module) cards. Additional features have also been added, such as contactless devices or transponders embedded in the cards themselves.

[0003] Furthermore, with the increasing versatility of mobile devices and the software (e.g., apps) installed thereon, payment convenience has further increased when payment mechanisms have shifted to software installed on mobile devices. Contactless hardware chips are now common in mobile devices (e.g., mobile phones and smartwatches), enabling consumers to link their mobile devices to their card-related accounts for payment. Due to the more robust security mechanisms on mobile devices, they are even more reliable than physical cards themselves.

[0004] However, as consumers conduct more transactions via these cashless payment mechanisms, they are missing the opportunity to contribute to the traditional "tip jar" at quick-service restaurants or establishments. This contribution occurs after the transaction is complete and is significantly different from existing exemplary practices, which typically include the following steps when a consumer dines in a restaurant and presents a cashless payment mechanism for payment:

[0005] -The waiter brings the bill

[0006] -Customer puts credit card into folder

[0007] - The waiter takes the card back to the waiting counter and processes it at the Point of Sale (POS) station

[0008] -POS station sends pending transaction authorization

[0009] - At the POS station, the attendant does not "close the check" after processing the card (instead, the process is "open" or "pending")

[0010] - For customer tip and signature, the waiter returns with the receipt

[0011] -Customer adds tip and signs receipt

[0012] - The waiter takes the receipt and enters the new total with the tip into the "open" or "pending" check at the POS station, and

[0013] -Finally, the waiter closes the check and the POS station sends a transaction adjustment with the tip in place of the transaction authorization.

[0014] In other words, the technical problem with the “tip jar” scenario is that, unlike the restaurant tipping example above, the transaction is completed before the tip is paid. It is not an authorization, and there is no “open” or “waiting” state at the POS station to “close” after the new amount is entered. The POS station has already transmitted the completed transaction data packet to the payment processor for the issuer to verify and ultimately pay the merchant. Second, paying the tip after the transaction can be considered a second transaction, and because it is a tip, the amount is usually smaller and can sometimes be flagged as a potentially fraudulent transaction by the issuing bank. If the consumer fails to follow up with the issuer to confirm that the amount is not fraudulent, the issuing bank will cancel the transaction - thereby defeating the purpose of paying the tip - which may be intended to help supplement the waiter or waitress earning minimum wage.

[0015] Embodiments of the present invention seek to solve or address one or more of the identified technical problems. Summary of the Invention

[0016] Embodiments of the present invention may provide a novel technical solution by creating a header or similar data field in a transaction header, thereby enabling a transaction processor to modify or amend the header field to reflect a post-transaction tip, such that the post-transaction tip is not processed as a separate and discrete transaction. Aspects of the present invention further provide a user interface that enables a user to set a predetermined amount for a tip at a quick service establishment. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Those skilled in the art will appreciate that the elements in the figures are shown for simplicity and clarity, and therefore not all connections and options are shown to avoid obscuring various aspects of the present invention. For example, common but well-understood elements that are useful or necessary in commercially viable embodiments may generally not be depicted to facilitate unimpeded viewing of the various embodiments of the present disclosure. It will be further understood that certain actions and / or steps may be described or depicted in a particular order of occurrence, but those skilled in the art will understand that such specificity regarding order is not actually required. It will also be understood that the terms and expressions used herein may be defined relative to their corresponding queries and research areas, unless a specific meaning is otherwise set forth herein.

[0018] Figure 1 is a diagram illustrating a data packet structure according to an embodiment of the present invention.

[0019] Figure 2 is a system diagram according to another embodiment of the present invention.

[0020] Figure 3is a flow chart illustrating a computerized method according to one embodiment of the present invention.

[0021] Figures 4A to 4B is a diagram illustrating a graphical user interface (GUI) on a configuration portal according to one embodiment of the present invention.

[0022] Figure 5 is a diagram illustrating a graphical user interface (GUI) on a mobile device according to one embodiment of the present invention.

[0023] Figure 6 is a diagram illustrating a portable computing device according to one embodiment of the present invention.

[0024] Figure 7 is a diagram illustrating a remote computing device according to one embodiment of the present invention. DETAILED DESCRIPTION

[0025] The present invention will now be more fully described with reference to the accompanying drawings, which form a part hereof and illustrate in diagrammatic form specific exemplary embodiments by which the invention may be practiced. These diagrams and exemplary embodiments may be presented, and it will be understood that the present disclosure is an example of the principles of one or more inventions and may not be intended to limit any one invention to the embodiments shown. The present invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that the present disclosure will be thorough and complete and will fully convey the scope of the invention to those skilled in the art. Furthermore, the present invention may be embodied as a method, system, computer-readable medium, apparatus or device. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Accordingly, the following detailed description may be regarded as non-limiting.

[0026] Reference Figure 1 , a diagram illustrates a data structure 102 for a data packet of an electronic transaction request. In one example, data structure 102 defines an exemplary data packet format with a value definition or schema for a given electronic transaction request to be processed by a transaction processing server. Data structure 102 may include a first or header field 104. In one example, first field 104 may include a declaration of the format or schema, a version of the format or schema, or other information. In one embodiment, first field 104 may include information or data related to a post-transaction tip or gratuity value or amount that a user may wish to add after the electronic transaction is completed.

[0027] In one embodiment, a user may visit a quick-service merchant (hereinafter referred to as a "merchant"), which may be a small business establishment, such as a local coffee shop. After placing an order at the merchant, the user has completed their transaction. However, before leaving the merchant, the user may wish to add a tip to help the waiter or staff member, who may be earning minimum wage. Instead of using a traditional "tip jar" with cash, the user may not have cash on hand, and asking for the waiter or staff member's phone number to make a quick "cash" transfer via the user's mobile device may be unwise. Therefore, the user may want to provide a tip or gratuity to the aforementioned individual.

[0028] Embodiments of the present invention achieve such capabilities by providing a technical solution starting with a data structure 102 having a first field 104. While the amount of a tip or gratuity can be revised or inserted after the user has completed a transaction at a merchant, the first field 104 can reserve data storage space for storing such information.

[0029] Still refer to Figure 1 , the data structure 102 may also include a second or message field 106 for storing information or data, such as the amount of the transaction. In one example, the second field 106 may include the currency name of the transaction (e.g., USD, EU, etc.) and a value. In another embodiment, the second field 106 may also include the total amount of the transaction. The data structure 102 also includes a third field 108, which may store information or data, such as the name of the merchant, the address of the merchant, and a merchant identifier (ID). The data structure 102 may include a fourth field 110, which may store information or data, such as an encrypted account number of a payment device used by the user to pay for the transaction, an account identifier (ID) associated with the user, or other information.

[0030] In one embodiment, the data structure 102 may include other data fields required by the transaction processing server to process the transaction. In another embodiment, the data structure 102 may be tokenized or encrypted to protect the sensitivity of the data.

[0031] Unlike the aforementioned methods for providing a tip or gratuity at a restaurant after the customer has finished their meal, the practice in this method does not allow the transaction to be closed or "completed." Instead, it remains in an open or pending state so that restaurant staff can return to the transaction to close it with the tip or gratuity amount.

[0032] Figure 22 is a system diagram illustrating one embodiment of the present invention. For example, system 200 may include a server 210 that may exchange and process data packets between a front-end server (not shown), a database server / database 212, and / or a server of an issuer 216. In one embodiment, server 210 may further exchange and process data packets from an application (hereinafter referred to as an "App") 204 installed on a mobile device 202-2.

[0033] In one embodiment, server 210 may process electronic transaction requests received at a merchant 206, which has a merchant ID associated with it. For example, a user may present a cashless payment mechanism 202-1 or a mobile device 202-2 at a point-of-sale (POS) device connected to merchant 206 (wherein the cashless payment mechanism 202-1 may already be linked or aligned with the mobile device 202-2, so that the user may not need to provide a physical mechanism). The merchant 206's POST device receives information from the mechanism 202-1 or mobile device 202-2 and combines the information with the transaction in question before sending it to server 210 in a format or schema defined by server 210, such as data structure 102. Server 210 may inspect the data content of data structure 102 to ensure that the data content is authenticated before forwarding it to issuer 216, which may perform further verification or authentication with its server 214. Once authenticated, merchant 206 may be paid, and the account associated with the cashless payment mechanism 202-1 or mobile device 202-2 may be debited for the amount of the transaction.

[0034] Aspects of the present invention provide a database server or database 212 that is accessible by server 210 to provide the automatic tip or gratuity added to the transaction request in the above example. In other words, server 210 intelligently identifies the subsequent transaction as a tip or gratuity transaction, rather than creating a second and separate transaction to be processed.

[0035] To further illustrate these embodiments, Figure 3302 is a flow chart describing an exemplary operation of one embodiment of the present invention. In one example, server 210 may receive an electronic transaction request from a POS at merchant 206 for processing at 302. Upon receiving this request, server 210 may determine at 304 whether the merchant ID of merchant 206 may already be in database 212. In one embodiment, database 212 may store a collection of merchant IDs that can be identified by a user as merchants to whom the user wishes to provide tips or gratuities. In one embodiment, system 200 may also include a configuration portal 208 that enables a user to configure preferences for tips or gratuities regarding merchants under their account IDs. In another embodiment, system 200 may provide configuration portal 208 to an administrator of server 210 to provide additional management tasks or controls.

[0036] If the determination is positive, the server 210 may automatically amend the first field (e.g., first field 104) with a predetermined secondary value (e.g., a tip or gratuity) associated with the merchant ID at 306, and may update the total amount in the second field (e.g., second field 106) to the sum of the transaction value and the predetermined secondary value. In this example, once the server 210 recognizes that the user has predetermined a tip or gratuity amount for the merchant 206 through the configuration portal 208, the server 210 may retrieve this tip / gratuity amount and apply it to the total amount of the transaction. In this case, the user may not need to perform an explicit action to provide a tip at the merchant 206. In another embodiment, the server 210 may also waive any merchant transaction fees for the tip / gratuity.

[0037] At 308 , the server 210 processes the request as a single request with the total amount in the second field.

[0038] If the determination is negative, server 210 may monitor a subsequent request stream for requests with the account ID and merchant ID in the request at 310. In response to identifying a match in the subsequent request stream, server 210 may identify a subsequent value from the matching subsequent transaction at 312. In one example, the subsequent value may be a tip / gratuity that the user may wish to provide after the transaction at merchant 206 is completed.

[0039] At 314, the server 210 may amend the first field of the original transaction with the subsequent value (eg, tip / gratuity) and may update the total to the sum of the transaction's value and the subsequent value. At 316, the server 210 may process the request as a single request.

[0040] Reference Figure 4A, a graphical user interface (GUI) 400 on a configuration portal (e.g., configuration portal 208) is shown according to one embodiment of the present invention. In one embodiment, GUI 400 provides a view 402 showing a header 404 to inform the user that this is the portal where the user sets their preferences. In one example, view 402 can be presented via a website so that the user can view the view on various devices. In another example, view 402 can be presented via App 204 on mobile device 202-2.

[0041] In one embodiment, the view 402 may include a first preference setting 406 for configuring the amount of the tip / gratuity. For example, the first preference setting 406 may provide an additional selection of a fixed amount or as a percentage of an earlier completed bill or transaction.

[0042] View 402 may also include a tip / gratuity method in second preference 408. For example, second preference 408 may include a selection of a debit card, a credit card, or other funding source. In another example, view 402 may also include a third preference 410 that enables the user to filter merchants. In one example, the user may filter merchants by merchant ID. In another example, the user may filter merchants by region or geographic location. In yet another example, the user may filter merchants based on establishment type, whether the merchant is a small business, or the like.

[0043] It is understood that other preference settings may be added without departing from the scope or spirit of embodiments of the invention.

[0044] Reference Figure 4BGUI 420 may be presented to an administrator of server 210 or an administrator of issuer 216. In one example, GUI 420 may be incorporated into an existing configuration portal of an administrator of server 210 or issuer 216. In another example, GUI 420 may include a header 424 indicating this to an administrative user or a user with administrative rights. GUI 420 may also include a first setting 426 indicating the status of the merchant's registration with the tip / gratuity processing scheme. In another embodiment, GUI 420 may include a second setting 428 indicating whether the transaction tax calculation setting is pre-tax or post-tax. GUI 420 may also include a third setting 430 indicating whether server 210 may waive merchant transaction fees for tips / gratuities that may be added to the transaction. In another embodiment, GUI 420 may also include a fourth setting 432 for crediting the merchant with the amount from the tip / gratuity, making the amount available for future charges. In another embodiment, if the merchant can request that the waived fee be donated to a charity of the merchant's choice, the GUI 420 may include a fifth setting 434. Thus, the configuration portal's GUI 420 may provide various settings for an administrator of the server 210 or issuer 216 to use in managing merchants who may wish to be part of this post-transaction adjustment scheme as described.

[0045] In another embodiment, Figure 5 Another GUI 500 may be presented on app 204, allowing a user to quickly tip / gratuity to merchant 206 or the merchant identified in field 514. In one embodiment, GUI 500 may provide a header 504 for view 502 to identify the view. View 502 may further identify user 506 by displaying the user's account ID. View 502 may also include a pane 508 displaying one or more associated accounts. In one example, a user may select Credit Card 1, Credit Card 2, and Debit Card 1 as associated accounts. In one example, pane 508 displays a selection 510 indicating that the user has selected "Credit Card 2" as the card to use for the tip / gratuity or that "Credit Card 2" has been pre-selected. The user may modify the selection by selecting (e.g., double-clicking, pressing for several seconds, single-tapping, or other gestures) menu 512. In another embodiment, view 502 may further identify, in field 514, the merchant ID of the merchant to which the tip / gratuity will be sent. View 502 may also include a pane 516 displaying the amount of the tip / gratuity. For example, pane 516 may include options such as a predetermined amount, a percentage of the bill, or a new amount to be entered by the user. In this example, selection 520 may indicate that the user may have preselected the option or has now selected the option. View 502 may provide an indicator 522 in the form of a check mark to confirm payment of the tip / gratuity.

[0046] It should be understood that other options may be presented consistent with the options shown in view 502 without departing from the scope or spirit of embodiments of the present invention.

[0047] Figure 6 This is a high-level diagram of a portable computing device 801 communicating with a remote computing device 841, but the application can be stored and accessed in a variety of ways. Additionally, the application can be obtained in a variety of ways, such as from an app store, from a website, from a store Wi-Fi system, etc. Various versions of the application can exist to take advantage of different computing devices, different languages, and different API platforms.

[0048] In one embodiment, the portable computing device 801 may be a mobile device 112 that operates using a portable power source 855, such as a battery. The portable computing device 801 may also have a display 802, which may or may not be a touch-sensitive display. More specifically, the display 802 may have a capacitive sensor, such as a capacitive sensor that can be used to provide input data to the portable computing device 801. In other embodiments, an input pad 804, such as an arrow, a scroll wheel, or a keyboard, may be used to provide input to the portable computing device 801. In addition, the portable computing device 801 may have a microphone 806 that can receive and store spoken data, a camera 808 for receiving images, and a speaker 810 for transmitting sound.

[0049] The portable computing device 801 can communicate with a computing device 841 or multiple computing devices 841 that constitute a cloud of computing devices 811. The portable computing device 801 can communicate in a variety of ways. In some embodiments, communication can be wired, such as through an Ethernet cable, a USB cable, or an RJ6 cable. In other embodiments, communication can be wireless, such as through Wi-Fi (802.11 standard), Bluetooth, cellular communication, or near-field communication devices. Communication can be directed to the computing device 841, or can be carried out through the communication network 102, such as a cellular service, through the Internet, through a private network, through Bluetooth, etc. Figure 6 may be a simplified illustration of the physical elements that make up the portable computing device 801, and Figure 7 This may be a simplified illustration of the physical elements that make up the server-type computing device 841.

[0050] Figure 6A sample portable computing device 801 may be physically configured as part of a system. The portable computing device 801 may include a processor 850 physically configured according to computer-executable instructions. The portable computing device may include a portable power source 855, such as a rechargeable battery. The portable computing device may also include a sound and video module 860 to assist in displaying video and sound, and may be turned off when not in use to conserve power and battery life. The portable computing device 801 may also include volatile memory 865 and non-volatile memory 870. The portable computing device may include GPS capability 880, which may be a separate circuit or may be part of the processor 850. An input / output bus 875 may also be present to transmit data to and from various user input devices, such as a microphone 806, a camera 808, and other inputs such as an input pad 804, a display 802, and a speaker 810. Communication with a network may also be controlled via wireless or wired means. Of course, this is just one embodiment of a portable computing device 801, and the number and type of portable computing devices 801 are limited only by imagination.

[0051] As a result of the system, better information can be provided to users at the point of sale. Information can be user-specific and can be required to exceed a relevance threshold. Consequently, users can make better-informed decisions. The system not only speeds up the process but also uses computing systems to achieve better results.

[0052] The physical components that make up the remote computing device 841 may further be Figure 7 . At a high level, computing device 841 may include digital storage, such as magnetic disks, optical disks, flash memory, non-volatile memory, and the like. Structured data may be stored in the digital storage, such as in a database. Server 841 may include a processor 1000 physically configured according to computer-executable instructions. The server may also include a sound and video module 1005 that assists in displaying video and sound, and may be shut down when not in use to conserve power and battery life. Server 841 may also include volatile memory 1010 and non-volatile memory 1015.

[0053] Database 1025 may be stored in memory 1010 or 1015, or may be separate. Database 1025 may also be part of a cloud of computing devices 841 and may be stored in a distributed manner across multiple computing devices 841. An input / output bus 1020 may also be present, which transmits data to and from various user input devices, such as microphone 806, camera 808, inputs such as input pad 804, display 802, and speaker 810. I / O bus 1020 may also control communication with the network via wireless or wired means. In some embodiments, the application may be located on the local computing device 801, and in other embodiments, the application may be remote 841. Of course, this is just one embodiment of a server 841, and the number and type of portable computing devices 841 are limited only by imagination.

[0054] The user devices, computers, and servers described herein may be general-purpose computers that may have, among other components, a microprocessor (e.g., from Intel Corporation, AMD, ARM, Qualcomm, or MediaTek); volatile and non-volatile memory; one or more mass storage devices (i.e., hard drives); various user input devices, such as a mouse, keyboard, or microphone; and a video display system. The user devices, computers, and servers described herein may run on any of a number of operating systems, including but not limited to WINDOWS, UNIX, LINUX, MACOS, iOS, Android, or Windows (XP, VISTA, etc.). However, it is contemplated that any suitable operating system may be used with the present invention. The server may be a cluster of network servers, each of which may be based on LINUX and supported by a load balancer that decides which of the network server clusters should handle the request based on the current request load of the available servers.

[0055] The user devices, computers, and servers described herein can communicate via a network, including the Internet, a WAN, a LAN, Wi-Fi, other computer networks (now known or invented in the future), and / or any combination of the foregoing. It will be understood by those of ordinary skill in the art, after becoming familiar with this specification, the drawings, and the claims, that a network can connect various components through any combination of wired and wireless channels, including copper wire, optical fiber, microwave, and other forms of radio frequency, electrical, and / or optical communication technologies. It will also be understood that any network can be connected to any other network in different ways. The interconnection between the computer and the server in the system is an example. Any device described herein can communicate with any other device through one or more networks.

[0056] Example embodiments may include additional devices and networks beyond those shown. Furthermore, functions described as being performed by one device may be distributed and performed by two or more devices. Multiple devices may also be combined into a single device that can perform the functions of the combined devices.

[0057] The various participants and elements described herein may operate one or more computer devices to facilitate the functions described herein.Any element in the above figures, including any server, user device or database, may use any suitable number of subsystems to facilitate the functions described herein.

[0058] Any of the software components or functions described in this application may be implemented as software code or computer-readable instructions that may be executed by at least one processor using any suitable computer language, such as Java, C++, or Perl, using, for example, conventional or object-oriented techniques.

[0059] The software code may be stored as a series of instructions or commands on a non-transitory computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device and may be present on or within different computing devices within a system or network.

[0060] It will be appreciated that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on this disclosure and the teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing the present invention using hardware, software, or a combination of hardware and software.

[0061] The above description is illustrative and not restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalents.

[0062] Without departing from the scope of the present invention, one or more features of any embodiment may be combined with one or more features of any other embodiment. Unless expressly indicated to the contrary, the phrase "a," "an," or "the" is intended to mean "one or more." Unless expressly indicated to the contrary, the phrase "and / or" is intended to indicate the most inclusive meaning of the term.

[0063] One or more elements of the system of the present invention may be claimed as components that realize specific functions. In the case of using such means plus functional elements to describe certain elements of the system for protection, it will be understood by those skilled in the art who can consult this specification, the accompanying drawings and the claims that the corresponding structure is a general-purpose computer, a processor or a microprocessor, and the microprocessor (depending on the specific circumstances) is programmed to use the functions present in any general-purpose computer without special programming to perform the functions of special narration and / or to realize the functions by realizing one or more algorithms. As will be understood by those skilled in the art, the algorithm can be expressed in the present disclosure as a mathematical formula, a flow chart, a narrative formula and / or provide enough structures to implement any other way of the process and its equivalent to those skilled in the art.

[0064] While the disclosure may be embodied in many different forms, the drawings and discussion are presented with the understanding that the disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one invention to the embodiments shown.

[0065] The present disclosure provides a solution to the long-standing need described above. Specifically, the systems and methods described herein can be configured to improve transaction data message processing by enabling modifications to data message fields after a transaction is completed. Other advantages and modifications of the above-described systems and methods will readily occur to those skilled in the art. Therefore, the present disclosure, in its broader aspects, is not limited to the specific details, representative systems and methods, and illustrative examples shown and described above. Various modifications and variations may be made to the foregoing description without departing from the scope or spirit of the present disclosure, and it is intended that the present disclosure cover all such modifications and variations, provided that all such modifications and variations come within the scope of the appended claims and their equivalents.

Claims

1. A computerized method executable on a transaction server, comprising: receiving an electronic transaction request from a point-of-sale (POS) device of a merchant, the electronic transaction request comprising a request data packet having at least a header field and a message field, the message field comprising a value of the transaction and an encrypted account of a user, the merchant having a merchant identifier (ID) associated therewith, wherein the header field is created to enable the transaction server to amend the header field to reflect a post-transaction secondary value such that the post-transaction secondary value is not processed as a separate and discrete transaction; determining whether the merchant ID in the electronic transaction request matches one of merchant identifiers stored in a database, the database connected to the transaction server; modifying, by the transaction server, the electronic transaction request based on whether the determination is affirmative or negative, wherein: modifying the electronic transaction request based on the determination being positive includes automatically amending the header field with a predetermined secondary value associated with the merchant ID retrieved from the database and updating the total amount in the message field to the sum of the value of the transaction and the predetermined secondary value; and Modifying the electronic transaction request based on the determination being negative includes: monitoring a subsequent flow of transaction requests having the encrypted account and the merchant ID; In response to identifying a subsequent transaction in the monitored subsequent transaction request stream that matches the encrypted account and the merchant ID, identifying a subsequent value from the subsequent transaction; and amending the header field with the subsequent value and updating the total amount in the message field to the sum of the value of the transaction and the subsequent value; and The electronic transaction request is processed into a single request based on the modification of the electronic transaction request.

2. The computerized method of claim 1, further comprising providing a graphical user interface (GUI) to the user to configure the condition of the predetermined secondary value.

3. The computerized method of claim 2, wherein the condition comprises at least one of: a fixed value of the predetermined secondary value; a region where a merchant is located, a type of the merchant, and whether an audit for the merchant has been received.

4. The computerized method of claim 1, wherein the encrypted account of the user includes a user identifier.

5. The computerized method of claim 1 further comprising determining a pre-tax amount before said predetermined secondary value or said subsequent value is added to said total amount.

6. The computerized method of claim 1 further comprising determining an after-tax amount of the total amount.

7. A computerized method executable on a transaction server, comprising: receiving an electronic transaction request from a point of sale (POS) device of a merchant, the electronic transaction request comprising a request data packet having at least a first field and a second field, the second field comprising a value of the transaction and an account identifier (ID) of a user, the merchant having a merchant identifier (ID) associated therewith, wherein the first field is created to enable the transaction server to amend the first field to reflect a post-transaction secondary value such that the post-transaction secondary value is not processed as a separate and discrete transaction; determining whether the merchant ID in the electronic transaction request matches one of merchant identifiers stored in a database, the database connected to the transaction server; modifying, by the transaction server, the electronic transaction request based on whether the determination is affirmative or negative, wherein: modifying the electronic transaction request based on the determination being affirmative includes automatically amending the first field with a predetermined secondary value associated with the merchant ID retrieved from the database and updating the total amount in the second field to be the sum of the value of the transaction and the predetermined secondary value; and Modifying the electronic transaction request based on the determination being negative includes: monitoring a subsequent flow of transaction requests having the account ID and the merchant ID; In response to identifying a subsequent transaction in the monitored subsequent transaction request stream that matches the account ID and the merchant ID, identifying a subsequent value from the subsequent transaction; and amending the first field with the subsequent value and updating the total in the second field to the sum of the value of the transaction and the subsequent value; and The electronic transaction request is processed into a single request based on the modification of the electronic transaction request.

8. The computerized method of claim 7, further comprising providing a graphical user interface (GUI) on a user device of the user for configuring preferences for the predetermined secondary value.

9. The computerized method of claim 8, wherein the preferences include at least one or more of: a fixed value of the predetermined secondary value; a region where a merchant is located, a type of the merchant, and whether a review has been received for the merchant.

10. The computerized method of claim 7, wherein the account ID of the user identifies a first payment account used in the electronic transaction request.

11. The computerized method of claim 7, wherein the account ID of the user identifies a second payment account used in the subsequent transaction.

12. The computerized method of claim 7, further comprising determining a pre-tax amount before said predetermined secondary value or said subsequent value is added to said total amount.

13. The computerized method of claim 7, further comprising determining an after-tax amount of the total amount.

14. A non-transitory computer-readable medium storing computer-executable instructions embodied in a software product to be installed on a mobile device, the computer-executable instructions being executable by a transaction server, the computer-executable instructions comprising: receiving an electronic transaction request from a point of sale (POS) device of a merchant, the electronic transaction request comprising a request data packet having at least a first field and a second field, the second field comprising a value of the transaction and an account identifier (ID) of a user, the merchant having a merchant identifier (ID) associated therewith, wherein the first field is created to enable the transaction server to amend the first field to reflect a post-transaction secondary value such that the post-transaction secondary value is not processed as a separate and discrete transaction; determining whether the merchant ID in the electronic transaction request matches one of merchant identifiers stored in a database, the database connected to the transaction server; modifying, by the transaction server, the electronic transaction request based on whether the determination is affirmative or negative, wherein: modifying the electronic transaction request based on the determination being affirmative includes automatically amending the first field with a predetermined secondary value associated with the merchant ID retrieved from the database and updating the total amount in the second field to be the sum of the value of the transaction and the predetermined secondary value; and Modifying the electronic transaction request based on the determination being negative includes: monitoring a subsequent flow of transaction requests having the account ID and the merchant ID; In response to identifying a subsequent transaction in the monitored subsequent transaction request stream that matches the account ID and the merchant ID, identifying a subsequent value from the subsequent transaction; and amending the first field with the subsequent value and updating the total in the second field to the sum of the value of the transaction and the subsequent value; and The electronic transaction request is processed into a single request based on the modification of the electronic transaction request.

15. The non-transitory computer-readable medium of claim 14, further comprising providing a graphical user interface (GUI) on the mobile device of the user for configuring preferences for the predetermined secondary value.

16. The non-transitory computer-readable medium of claim 15, wherein the preferences include at least one or more of: a fixed value of the predetermined secondary value; a region where a merchant is located, a type of the merchant, and whether a review of the merchant has been received.

17. The non-transitory computer-readable medium of claim 14, wherein monitoring comprises monitoring transactions via the mobile device.

18. The non-transitory computer-readable medium of claim 14, wherein the account ID of the user identifies a first payment account used in the electronic transaction request.

19. The non-transitory computer-readable medium of claim 14, wherein the account ID of the user identifies a second payment account used in the subsequent transaction.

20. The non-transitory computer-readable medium of claim 14, further comprising determining one of: a pre-tax amount before the predetermined secondary value is added to the total; a pre-tax amount before the subsequent value is added to the total; and an after-tax amount of the total.

Citation Information

Patent Citations

  • Automatically adding gratuity to amount charged in electronic transaction

    US20100217676A1