AUTHORIZING PAYMENTS USING PRE-REGISTERED CUSTOMER TOKENS

A method, computer program product, and system are described. The method comprises receiving payment information, receiving a communication from an electronic device of a user, wherein the communication comprises a token that corresponds to the combination of the user and the electronic device. The method further comprises transmitting, to a payment processor of a payment network, the token and an identifier of the electronic device that is derived from the communication. The method further comprises receiving, from the payment network, a payment authorization that indicates that the token and the identifier of the electronic device were previously registered with an issuer corresponding to the payment information.

BACKGROUND

Within the service industry, merchants routinely use point of sale (POS) systems to provide a platform for customers to pay for goods or services. Modern POS systems may include personal identification number (PIN) pads to support a high volume of small-ticket customer transactions. Customers interact with a PIN pad by swiping, dipping, or a tapping a debit card, credit card, or smart card on electronic components of the PIN pad. The PIN pad reads the customer's PIN during the interaction, and encrypts the PIN for transmission as part of a payment authorization process.

DETAILED DESCRIPTION

Though the use of PIN pads has become widespread, operating and maintaining PIN pads can be expensive for a merchant. In some cases, PIN pads may also be inconvenient or even an impediment to accept certain types of transactions.

Further, in some types of transactions, an initial authorization is performed for the customer's payment method, and the customer is then prompted to add an amount to the total of the transaction (e.g., writing a gratuity on a receipt). Some PIN pads may not be able to accommodate such transactions. Additionally, customer-added amounts can be entered inaccurately into the POS system, whether intentional (e.g., another party fraudulently enters a larger gratuity) or unintentional (e.g., the amount is keyed in incorrectly).

Personal electronic devices of users, such as smartphones or wearables, may be used to provide multi-factor and multi-step authentication for transactions, removing any requirement for merchants to operate and maintain separate PIN pads. In this disclosure, an electronic device pre-registers with an issuer of a payment method (e.g., a credit card issuer), and the issuer provides a token corresponding to the combination of the user and the electronic device. The token may be based on a unique hardware identifier of the electronic device, such as a MAC address.

During a transaction, the electronic device transmits a communication (including the token) to a point of sale (POS) system, which then transmits the token and the identifier of the electronic device to a payment network. In some cases, the POS system may derive the identifier of the electronic device from the communication, e.g., by inspecting header information. When the POS system receives a payment authorization for the transaction, this indicates that the token and the identifier of the electronic device have been pre-registered with the issuer of the payment method. Using this token-based validation, the transaction can be authorized without using the PAN (primary account number) of the customer. In this way, the transaction authorization process can be completed without requiring the entire POS system to comply with security standards having stricter requirements.

Further, the personal electronic device can be used in a closed-loop authentication process that authenticates customer-added amounts. For example, a customer receives a receipt from a merchant that includes a field for a gratuity. After writing in the amount of the gratuity, the customer captures an image of the receipt using the electronic device. The customer uses an app or a website to transmit the image (or text derived from the image) to the issuer of the payment method. The issuer of the payment method determines whether the amount of the receipt corresponds to the amount entered at the POS system when determining whether to authorize the payment. In this way, the responsibility for authorizing gratuity amounts (and any associated risk) may be transferred away from the merchant to the issuer of the payment method.

Turn now toFIG.1, which illustrates an exemplary system100for authorizing payments using an electronic device135of a customer130and a POS system150of a merchant. The system100includes a public network115and a private network120of the merchant, each encompassing a respective one or more electronic devices that operate to provide control and/or data to one or more client electronic devices when the one or more client electronic devices are connected to the respective one of the public network115and the private network120. As used herein, “electronic device” generally refers to any device having electronic circuitry that provides a processing or computing capability, which implements logic and/or executes program code to perform various operations that collectively define the functionality of the electronic device. The functionality of the electronic device includes a communicative capability with one or more other electronic devices, e.g., when connected to a same network. An electronic device may be implemented with any suitable form factor, whether relatively static in nature (e.g., mainframe, computer terminal, server, kiosk, workstation) or mobile (e.g., laptop computer, tablet, handheld, smart phone, wearable device). The communicative capability between electronic devices may be achieved using any suitable techniques, such as conductive cabling, wireless transmission, optical transmission, and so forth.

One or more electronic devices of the merchant that are included in the public network115and the private network120are “on-site”, that is, disposed on the physical premises of the merchant (e.g., within the store, restaurant, building). In some embodiments, one or more other electronic devices of the merchant are “off-site”, that is, disposed apart from the physical premises of the merchant and communicatively coupled with the on-site electronic device(s). In some embodiments, the off-site electronic device(s) are not owned by the merchant but are allocated, assigned, leased, etc. in whole or in part to the merchant.

As shown, the POS system150comprises one or more servers155that are communicatively coupled with a POS terminal160through the private network120. The POS system150comprises one or more processors165, a memory170, and a number of input/output devices that are communicatively coupled with the one or more processors165.

The one or more processors165are any electronic circuitry, including, but not limited to one or a combination of microprocessors, microcontrollers, application-specific integrated circuits (ASIC), application-specific instruction set processors (ASIP), and/or state machines, that is communicatively couples to the memory170and controls the operation of the POS system150. The one or more processors165is not limited to a single processing device and may encompass multiple processing devices.

The one or more processors165may include other hardware that operates software to control and process information. The one or more processors165executes software stored in the memory170to perform any of the functions described herein. The one or more processors165control the operation and administration of the POS system150by processing information (e.g., information received from input devices and/or communicatively coupled electronic devices).

The memory170may store, either permanently or temporarily, data, operational software, or other information for the one or more processors165. The memory170may include any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, the memory170may 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. The software represents any suitable set of instructions, logic, or code embodied in a computer-readable storage medium. For example, the software may be embodied in the memory170, a disk, a CD, or a flash drive. In particular embodiments, the software may include an application executable by the one or more processors165to perform one or more of the functions described herein.

In this example, the memory170stores a payment authorization service172that communicates with one or more electronic devices of an external payment network and/or the electronic device135for transactions performed using the POS system150. The payment network is discussed in greater detail with respect toFIG.2. The payment authorization service172may be implemented as a software application that is executed by the one or more processors165.

The input/output devices of the POS system150comprise a card reader175, a printer, and an input device185. The card reader175reads an account number (or card number) and/or other information from a debit card, credit card, or smart card using any suitable technologies. For example, the card reader175may include a magnetic stripe reader, an EMV chip reader, and/or a NFC chip.

The printer180outputs a receipt or invoice for the transaction using any suitable printing technologies on paper or other suitable materials. The receipt is presented to the customer. In some cases, the printer180generates a first receipt with transaction information, prompting the customer to present a payment method for an initial authorization. Responsive to the initial authorization, the printer180generates a second receipt that includes a field for a customer-added amount, such as a gratuity. The customer-updated transaction information is entered into the POS system150for a subsequent authorization.

The input device185has any suitable implementation for receiving user inputs (e.g., an employee or other representative of the merchant). Some non-limiting examples of the input device185include a keyboard, a touchscreen, and a fingerprint sensor. In some embodiments, the input device185is used by an employee of the merchant to manually enter customer-added amounts to transactions.

The public network115of the merchant comprises one or more access points125providing wireless connections for customers, guests, employees, etc. on the physical premises of the merchant. In another example, the access points125provide connections to the external network105, e.g., a public network such as the internet. The public network115is typically distinct from the private network120to accommodate customers or other guests, while avoiding unnecessarily exposing the various components of the POS system150. However, alternate implementations may combine the functionality of the public network115and the private network120into a single network of the merchant.

A customer130operates an electronic device135to connect to the public network115through the access point125. The electronic device135may have any suitable implementation, and in many cases is implemented as a mobile electronic device such as a laptop, smart phone, or wearable device. The electronic device135comprises one or more processors136and a memory140. The description of the one or more processors136is similar to that of the one or more processors165, and the description of the memory140is similar to that of the memory170. In this example, the memory140stores a merchant app142and an imaging/OCR service144. The merchant app142comprises program code executed by the one or more processors136to perform one or more of the following functions: to pre-register the electronic device135with the issuer of the payment method (e.g., via communication with the payment network), to receive token(s) (which in some cases includes single-use token(s)), and transmit image-based updated transaction information to the payment network. Some or all of the functionality of the merchant app142may be implemented separately. Further, the merchant app142may have alternate functionality that is not discussed here.

The imaging/OCR service144comprises program code executed by the one or more processors136to capture, using a camera145of the electronic device, an image of a physical receipt that includes customer-provided updated transaction information. In some embodiments, OCR processing is performed on the image and the customer-provided updated transaction information is transmitted to the payment network. In other embodiments, the image is transmitted to the payment network, and OCR processing occurs within the payment network. The imaging/OCR service144may be included in the merchant app142or separately therefrom (e.g., included in separate app(s) or within the operating system of the electronic device135).

In some embodiments, the electronic device135operates the camera145or one or more other input devices (not shown) to authenticate the customer. The electronic device135may prompt the customer to authenticate responsive to one or more conditions: periodically (e.g., elapse of a period of time), on transitions out of sleep or low-power states, on loading the merchant app142, and so forth. In one example, the camera145may capture an image of the customer, and facial recognition processing is performed on the image to authenticate the customer. In another example, a touchscreen of the electronic device135receives a password or passcode from the customer. In another example, a fingerprint sensor of the electronic device135receives a fingerprint from the customer. In some embodiments, the electronic device135transferring a token to the payment network indicates to the payment network that the customer has been authenticated, e.g., within a recent window of time. Stated another way, the electronic device135may decline to transmit the token when the customer has not (recently) been authenticated.

The public network115and the private network120of the merchant are communicatively coupled to one or more external networks105. In some embodiments, the external network105is a public network, e.g., the internet. The external network105encompasses a large number of electronic devices, and may provide network connections over a large area, when compared with the relatively limited public network115and private network120of the merchant.

The payment network is implemented using a plurality of electronic devices communicatively coupled through the external network105, such as the server computers110-1,110-2, . . . ,110-N. The various electronic devices of the payment network may be owned or operated by different entities, which in turn are distinct from the merchant.

Turn now toFIG.2, which is a diagram200illustrating an exemplary payment network210. Diagram200illustrates an exemplary sequence of a payment authentication process for a transaction from the POS system150. The features illustrated in the diagram200may be used in conjunction with other embodiments.

In some embodiments, the POS system150receives a payment method from a customer130(e.g., card account information) and performs a first (initial) authorization for the transaction. In some embodiments, the POS system150transmits transaction information (e.g., the card account information, the amount of the transaction) to a payment gateway215of the payment network210. The payment gateway215facilitates the information transfer between a payment portal and the payment processor220. The payment portal may be a “card-present” payment environment such as the POS system150, or a “card-not-present” payment environment such as the e-commerce store205. The payment gateway215encrypts the card information and other sensitive information to ensure security of the transaction.

In some embodiments, the customer130pre-registers the electronic device135with the card issuer230, and receives a token240which corresponds to the combination of the customer130and the electronic device135. The token240may have any suitable length and form. In some embodiments, a hash function may be applied to a unique (hardware) identifier245of the electronic device135(such as a MAC address) and an identifier of the customer130to generate a unique hash value for the combination. In other embodiments, the unique identifier245of the electronic device135and the identifier of the customer130may be combined using one or more arithmetic or logical functions. In one simplified example, the unique identifier245of the electronic device135and the identifier of the customer130may be concatenated within the token240. In another simplified example, the identifier of the customer130and the unique identifier245of the electronic device135are multiplied and the result included in the token240. The identifier of the customer130may be retrieved downstream by dividing the result within the token240by the unique identifier245of the electronic device135. Other techniques of generating the token240are also contemplated.

During the payment authentication process, the electronic device135transmits a communication to the POS system150that includes the token240. The POS system150transmits the token240, as well as the identifier245of the electronic device135, to the payment network210. The identifier245of the electronic device135is derived from the communication. In some embodiments, the POS system150extracts the identifier245from header information of the communication (e.g., a MAC address of the electronic device135). In other embodiments, the identifier245may be included in payload information of the communication.

In some embodiments, the POS system150transmits the token240and the identifier245of the electronic device135with the transaction information to the payment gateway215. The transaction information (with the token240and the identifier245) is sent from the payment gateway215to a payment processor220, which transmits an authorization request (with the token240and the identifier245) to the card network225. In alternate embodiments, the payment gateway215may be omitted, such that the POS system150communicates directly with the payment processor220.

The payment processor220maintains compliance with the Payment Card Industry Data Security Standards (PCI DSS). In some cases, the payment processor220provides its own payment gateway215. In other cases, the payment processor220has a reseller agreement to provide the payment gateway215.

The card network225sends an authorization request to the card issuer230(also referred to as the “cardholder's bank” or “consumer bank”, which represents the issuer of the payment method presented by the customer for the transaction). In some embodiments, the authorization request to the card issuer230includes the token240and the identifier245. The card network225is operated by the “brand” of the customer's card, such as American Express, Visa, MasterCard, or Discover. The card network225is typically responsible for setting interchange and assessment fees, as well as setting the standards for PCI DSS compliance.

The card issuer230makes the determination whether to authorize the payment. In some embodiments, the card issuer230determines whether the payment method (e.g., cardholder's account) has sufficient funds or credit for the amount of the transaction. In some embodiments, the card issuer230also determines whether the token240and the identifier245, received with the authorization request, match the token and the identifier that were issued by the card issuer230during the registration of the electronic device135. In some embodiments, the card issuer230also performs fraud analysis on the transaction. The card issuer230transmits a verification back through the payment network210to the POS system150(or to the e-commerce store206).

In some embodiments, after the verification for the first (initial) authorization, the POS system150receives customer-updated transaction information and performs a second authorization therewith using the payment network210. Assuming the second authorization is verified, the card issuer230also communicates with a merchant bank235(also referred to as an “acquiring bank”) to release funds for settlement of the transaction.

Although the payment network210has been depicted as including the payment gateway215, the payment processor220, the card network225, the card issuer230, and the merchant bank235, alternate implementations of the payment network210may have different numbers and/or configurations of elements. For example, an alternate implementation may have fewer intermediary elements before the authorization request reaches the issuer of the payment method (e.g., the card issuer230) and the merchant bank235.

FIG.3is a method300using a point of sale (POS) system to authorize payment for a transaction illustrating an exemplary payment network, according to one or more embodiments. The method300may be used in conjunction with other embodiments, for example, using the POS system150and various elements of the payment network210.

The method300begins at block305, where the POS system150receives payment information, which in some cases indicates a payment method presented by a user (e.g., the customer130) for the transaction. In some embodiments, the payment method comprises a credit card, debit card, or smart card of the user.

At block310, the POS system150requests, to the payment network210, an initial authorization, which in some cases is for the payment method for the transaction. In some embodiments, the initial authorization corresponds to an amount of the transaction not including a customer-added amount, such as a gratuity.

At block315, the POS system150receives the initial authorization from the payment network210. At block320, the POS system150presents the transaction information to the user. In some embodiments, presenting the transaction information comprises printing a receipt that includes a field for a customer-added amount, such as a gratuity.

At block325, the POS system150receives, from the electronic device135of the user, a communication comprising the token240which corresponds to the combination of the user and the electronic device135. In some embodiments, at block330, the POS system150extracts the identifier245of the electronic device135from header information of the communication. Stated another way, the electronic device135does not include the identifier245in payload information of the communication, allowing for a more secure authorization as well as a smaller and relatively faster communication. In other embodiments, the POS system150extracts the identifier245from the payload information of the communication.

At block335, the POS system150receives, by user input at an input device185of the POS system150, updated transaction information including a gratuity.

At block340, the POS system150transmits, to a payment processor220of the payment network210, the token240and the identifier245of the electronic device135that is derived from the communication. In some embodiments, the token240is a single-use token that is linked to the amount of the transaction, or alternately, to a maximum authorized amount for the transaction. In some embodiments, the token240and the identifier245are transmitted through one or more intermediate elements of the payment network210(e.g., the payment gateway215) before reaching the payment processor220. In some embodiments, the token240and the identifier245are further transmitted along one or more other elements of the payment network210.

At block350, the POS system150receives, from the payment network210, a payment authorization, in some cases for the transaction, that indicates that the token240and the identifier245were previously registered with an issuer corresponding to the payment information (e.g., an issuer of the payment method). In some embodiments, receiving the payment authorization further indicates that the amount of the updated transaction information is less than or equal to an authorized amount for the transaction that is included in the single-use token. The method300ends following completion of block350.

FIG.4is an exemplary communication diagram400illustrating payment authorization using a pre-registered token, according to one or more embodiments. The features in the communication diagram400may be used in conjunction with other embodiments, for example, as part of performing the method300ofFIG.3.

During a registration phase the electronic device135transmits, in a first communication405, account information of the customer130and an identifier245of the electronic device135to the payment network210. In some embodiments, the identifier245comprises a MAC address of the Wi-Fi network interface card or of a NFC chip of the electronic device135. In some embodiments, the first communication405is transmitted directly between the electronic device135and an issuer of the payment method (e.g., the card issuer230of the payment network210). The payment network210returns to the electronic device135, in a second communication410, a token which corresponds to the combination of the customer and the electronic device135. In some embodiments, the issuer of the payment method transmits the token to the electronic device135with a time-to-live (TTL) value, such that the token expires after a predetermined amount of time. The TTL value limits the possibility of fraudulent use by another who improperly obtains the token. In some embodiments, the information of the first communication405is transmitted between the card issuer230and one or more other elements of the payment network210, such as the payment processor220.

During a payment authorization phase, the POS system150provides transaction information to the customer in a third communication415. In some embodiments, providing the transaction information comprises printing a first receipt with the transaction information, prompting the customer to present payment information to the POS system150in a fourth communication420(e.g., a payment method for an initial authorization).

The POS system150transmits, in a fifth communication425, a request for an initial authorization to the payment network210. The POS system150receives, in a sixth communication430, the initial authorization from the payment network210.

Responsive to the initial authorization, the POS system150provides the transaction information to the customer in a seventh communication435. In some embodiments, providing the transaction information comprises printing a second receipt that includes a field for a customer-added amount, such as a gratuity.

The POS system150receives, in an eighth communication440, updated transaction information, which in some cases includes a gratuity. The POS system150receives, in a ninth communication445, the token and the identifier of the electronic device135from the electronic device135. In some embodiments, receiving the ninth communication445indicates that the customer has been locally authenticated by the electronic device, using a password or biometrics. In some embodiments, the POS system150extracts the identifier of the electronic device135from the protocol used for the communication.

The POS system150transmits, in a tenth communication450, the updated transaction information, token, and identifier of the electronic device to the payment network210for a subsequent authorization. The POS system150receives, in an eleventh communication455, the payment authorization for the transaction from the payment network210. In some embodiments, receiving the eleventh communication455indicates that the token and identifier of the electronic device were previously registered with the issuer of the payment method.

In some embodiments, the payment processor220of the payment network210validates the updated transaction information, token, and identifier using information included in the first communication405in the registration phase. Using the token-based validation, the transaction can be authorized without using the PAN (primary account number) of the customer. In this way, the transaction authorization can be completed without requiring the POS system150to be maintained within the scope of PCI DSS.

FIG.5is an exemplary communication diagram500illustrating payment authorization using a single-use token, according to one or more embodiments. The features in the communication diagram500may be used in conjunction with other embodiments, for example, as part of performing the method300ofFIG.3.

During a registration phase the electronic device135transmits, in a first communication505, account information of the customer130and an identifier245of the electronic device135to the payment network210. In some embodiments, the identifier245comprises a MAC address of the Wi-Fi network interface card or of a NFC chip of the electronic device135. In some embodiments, the first communication505is transmitted directly between the electronic device135and an issuer of the payment method (e.g., the card issuer230of the payment network210). The payment network210returns to the electronic device135, in a second communication510, a token which corresponds to the combination of the customer and the electronic device135. In some embodiments, the issuer of the payment method transmits the token to the electronic device135with a time-to-live (TTL) value, such that the token expires after a predetermined amount of time. The TTL value limits the possibility of fraudulent use by another who improperly obtains the token. In some embodiments, the information of the first communication405is transmitted between the card issuer230and one or more other elements of the payment network210, such as the payment processor220.

During a payment authorization phase, the POS system150provides transaction information to the customer in a third communication515. In some embodiments, providing the transaction information comprises printing a first receipt with the transaction information, prompting the customer to present payment information to the POS system150in a fourth communication520(e.g., a payment method for an initial authorization).

The POS system150transmits, in a fifth communication525, a request for an initial authorization to the payment network210. The POS system150receives, in a sixth communication530, the initial authorization from the payment network210.

The electronic device135transmits, in a seventh communication535, the account information, the identifier of the electronic device, and an amount of the transaction to the payment network210. In some embodiments, the electronic device135communicates with an element of the payment network210(e.g., the card issuer230) using a communication path that is distinct from the communication path used by the electronic device135for payment authorization (e.g., the electronic device135communicatively coupled with the payment gateway215).

In some embodiments, the amount of the transaction is provided via user input to an input device of the electronic device (e.g., a virtual numeric pad displayed on a touchscreen). In other embodiments, the amount of the transaction is acquired from an image captured by a camera of the electronic device, and the electronic device performs OCR on the image to determine the amount of the transaction. The payment network210returns, in an eighth communication540, a single-use token to the electronic device135for the transaction. In some embodiments, the single-use token is linked to the amount of the transaction, or alternately, to a maximum authorized amount for the transaction.

Responsive to the initial authorization, the POS system150provides the transaction information to the customer in a ninth communication545. In some embodiments, providing the transaction information comprises printing a second receipt that includes a field for a customer-added amount, such as a gratuity.

The POS system150receives, in a tenth communication550, updated transaction information, which in some cases includes a gratuity. The POS system150receives, in an eleventh communication555, the single-use token and the identifier of the electronic device from the electronic device135. In some embodiments, receiving the eleventh communication555indicates that the customer has been locally authenticated by the electronic device, using a password or biometrics.

The POS system150transmits, in a twelfth communication560, the updated transaction information, the single-use token, and the identifier of the electronic device to the payment network210for a subsequent authorization. The POS system150receives, in a thirteenth communication565, the payment authorization for the transaction from the payment network210. In some embodiments, receiving the thirteenth communication565indicates that the single-use token and identifier of the electronic device were previously registered. In some embodiments, receiving the thirteenth communication565indicates that the amount of the updated transaction information is less than or equal to an authorized amount for the transaction.

In some embodiments, the payment processor220of the payment network210validates the updated transaction information, single-use token, and identifier using information included in the first communication405in the registration phase. Using the token-based validation, the transaction can be authorized without using the PAN (primary account number) of the customer. In this way, the transaction authorization can be completed without requiring the POS system150to be maintained within the scope of PCI DSS.

FIG.6is an exemplary communication diagram600illustrating payment authorization using a captured image, according to one or more embodiments. The features in the communication diagram600may be used in conjunction with other embodiments, for example, as part of performing the method300ofFIG.3.

During a registration phase the electronic device135transmits, in a first communication605, account information of the customer130and an identifier245of the electronic device135to the payment network210. In some embodiments, the identifier245comprises a MAC address of the Wi-Fi network interface card or of a NFC chip of the electronic device135. In some embodiments, the first communication605is transmitted directly between the electronic device135and an issuer of the payment method (e.g., the card issuer230of the payment network210). The payment network210returns to the electronic device135, in a second communication610, a token corresponds to the combination of the customer and the electronic device135. In some embodiments, the issuer of the payment method transmits the token to the electronic device135with a time-to-live (TTL) value, such that the token expires after a predetermined amount of time. The TTL value limits the possibility of fraudulent use by another who improperly obtains the token. In some embodiments, the information of the first communication605is transmitted between the card issuer230and one or more other elements of the payment network210, such as the payment processor220.

During a payment authorization phase, the POS system150provides transaction information to the customer in a third communication615. In some embodiments, providing the transaction information comprises printing a first receipt with the transaction information, prompting the customer to present payment information to the POS system150in a fourth communication620(e.g., a payment method for an initial authorization).

The POS system150transmits, in a fifth communication625, a request for an initial authorization to the payment network210. The POS system150receives, in a sixth communication630, the initial authorization from the payment network210.

Responsive to the initial authorization, the POS system150provides the transaction information to the customer in a seventh communication635. In some embodiments, providing the transaction information comprises printing a second receipt that includes a field for a customer-added amount, such as a gratuity.

The POS system150receives, in an eighth communication640, updated transaction information, which in some cases includes a gratuity.

In some embodiments, the electronic device135transmits, in a ninth communication645, image-based updated transaction information (and optionally location information) to the payment network210. In some embodiments, the electronic device135captures an image of a physical receipt that includes the customer-provided updated transaction information. In some embodiments, OCR processing is performed on the image and the customer-provided updated transaction information is transmitted to the payment network210. In other embodiments, the image is transmitted by the electronic device135to the payment network210, and OCR processing occurs within the payment network210.

The POS system150receives, in a tenth communication650, the token and the identifier of the electronic device135from the electronic device135. In some embodiments, receiving the ninth communication645indicates that the customer has been locally authenticated by the electronic device135, using a password or biometrics. In some embodiments, the POS system150extracts the identifier of the electronic device135from the protocol used for the communication.

The POS system150transmits, in an eleventh communication655, the updated transaction information, token, and identifier of the electronic device to the payment network210for a subsequent authorization. The POS system150receives, in a twelfth communication660, the payment authorization for the transaction from the payment network210. In some embodiments, receiving the twelfth communication660indicates that the amount of the customer-provided updated transaction information in the ninth communication645matches the amount of the updated transaction information received in the eleventh communication655. In some embodiments, receiving the twelfth communication660further indicates that the token and identifier of the electronic device were previously registered with the issuer of the payment method.

In alternate embodiments, the payment authorization sequence shown the in the communication diagram600may be performed without the electronic device135obtaining and/or transmitting the token. In one non-limiting example, the customer receives a first receipt from the merchant with an initial amount of the transaction. The customer presents a payment method (e.g., a credit card) to the merchant, and the payment information is provided to the POS system. Upon receiving an initial authorization for the initial amount using the payment method, the customer receives a second receipt from the merchant that includes a field for a customer-added amount (e.g., a gratuity).

The customer captures an image of the second receipt using a camera of the electronic device. In some embodiments, the second receipt includes the customer-added amount (e.g., written in by the customer) in the field. In other embodiments, the second receipt does not include the customer-added amount. The image-based updated transaction information (whether as an image or as OCR-provided text) is transmitted to the issuer of the payment method (e.g., the card issuer230). In some cases, the image-based updated transaction information is transmitted through an app provided by, or a website of, the issuer of the payment method.

Where the image-based updated transaction information does not include the customer-added amount, the app or website of the issuer prompts the customer whether to add a gratuity. The customer may add the gratuity using an input device of the electronic device, and approves payment of the transaction using the payment method.

The issuer of the payment method compares the amount(s) of the image-based updated transaction information with the initial amount of the transaction (e.g., used for the initial authorization). If the different amounts match (or the difference does not indicate an excessive gratuity), the issuer of the payment method authorizes the payment and transmits the verification via the payment network210to the POS system150. In some embodiments, the issuer of the payment method may further compare location information of the customer (e.g., included in metadata of the captured image, or the network connection information of the electronic device) with the location of the merchant when determining whether to authorize the payment. In this way, the responsibility for authorizing gratuity amounts (and associated risk) may be transferred from the merchant to the issuer of the payment method.

In some embodiments, the payment processor220of the payment network210validates the updated transaction information, token, and identifier using information included in the first communication605in the registration phase. Using the token-based validation, the transaction can be authorized without using the PAN (primary account number) of the customer. In this way, the transaction authorization can be completed without requiring the POS system150to be maintained within the scope of PCI DSS.