Square, Inc.

Block, Inc.

David Terra

Michael Wells White

Koun Han

Martin Mroz

Jason Holmes

Ross Glashan

Charles Nicholson

Murat Cat

Michael Dahn

Gokhan Aydeniz

Thomas Templeton

Rodion Steshenko

Nicholas Hebner

A payment terminal includes multiple chips that perform different processing functions within the payment terminal. A terminal chip performs general functionality of the payment terminal while a transaction chip communicates with payment devices such as chip cards and NFC payment devices and processes payment information. The transaction chip may operate in a low power during which communications and processing are limited, and a transaction processing mode in which transactions may be processed. The transaction chip may transfer between these modes based on wake-up messages provided by other devices or circuitry of the payment terminal.

Preliminary enablement of transaction processing circuitry

Examples, methods and systems described herein may include determining, by a payment processing system, whether a second payment mechanism may be used to perform a payment transaction when a first payment mechanism is preferred and/or when the first payment mechanism has failed. Determining to use the second payment mechanism can be based on (i) an analysis of a communication status indicator received from a point-of-sale (POS) terminal that indicates which payment mechanisms are capable of communicating with the POS terminal, (ii) data received from the POS terminal that is associated with a read of a payment object, and/or (iii) an allowance criterion.

Technical fallback infrastructure

A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tampering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader. By these means, the processing related to a payment transaction is conducted on a hybrid system, using resources both local to and remote from the payment reader.

Point of sale (POS) systems and methods with kernel selection

A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tempering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader. By these means, the processing related to a payment transaction is conducted on a hybrid system, using resources both local to and remote from the payment reader.

Point of sale (POS) systems and methods with dynamic kernel selection

A payment terminal may run a point-of-sale application that is operated by a user such as a merchant. At a certain point in the transaction, but prior to the completion of the transaction, pre-charge requests may be sent to a chip card. The responses from the chip card may be stored such that the transaction may be completed immediately after the merchant and customer complete the transaction steps.

Preliminary acquisition of payment information

A payment terminal such as a payment reader may receive and form electrical connections with an electronic transaction card such as an EMV chip card. The payment terminal may provide power to the electronic transaction card and engage in communications with the electronic transaction card. Based on information received from the electronic transaction card, the payment terminal may predict the locations of data objects that must be accessed in order to process transactions. The data objects may be accessed based on the predictions and the transaction may be processed.

Predictive data object acquisition and processing

A payment terminal may receive a request to process electronic payment information from a payment card in a swipe mode. The payment terminal may provide an opt-in request. If a user accepts, the payment terminal may receive a payment transaction request and electronic payment information of a swipe payment type from the payment card at a swipe interface. The payment terminal may determine whether the payment card is a chip card and generate a swipe mode processing indicator. The swipe mode indicator may allow processing of electronic payment information using procedures for the swipe payment type. The payment terminal may transmit the swipe mode processing indicator and electronic payment information to a payment server from a communication interface of the payment terminal, and may receive a payment approval response based on the swipe mode processing indicator.

Multi-interface processing of electronic payment transactions

A payment terminal such as a payment reader may receive and form electrical connections with an electronic transaction card such as an EMV chip card. The payment terminal may provide power to the electronic transaction card and initiate communications with the electronic transaction card. One or more records may be acquired from the electronic transaction card. Data objects may be extracted from those records and stored in a cache. Data objects may be needed to process transactions. If the data object is available from the data cache or is otherwise received prior to all records being received, transactions may be processed prior to the acquisition of all records from the electronic transaction card.

Partial data object acquisition and processing

A payment terminal such as a payment reader may receive and form electrical connections with an electronic transaction card such as an EMV chip card. The payment terminal may provide a clock signal at a rate that exceeds a specified rate for the EMV chip card. The payment terminal may transmit messages to the EMV chip card and monitor receive messages at a data connection. The payment terminal may determine that the clock rate is excessive based on a timeout of a receive message, an error rate of a receive message, or a receive message indicating that one of the transmit messages was not received by the EMV card. The payment terminal may reduce the clock rate to a rate that is below the specified rate for the EMV chip card.

Systems and methods for determining clock rates for communicating with processing devices

In some examples, methods and systems may institute technical fallback by determining, by a payment processing system, and based on analysis of the communication status indicator and the data obtained when a magnetic stripe of the payment object is introduced in magnetic stripe object reader, whether the payment object was swiped while an EMV object reader was communicatively coupled to the POS terminal. If the magnetic stripe of the payment object was swiped while the EMV object reader was connected to the POS terminal, the payment processing system extracts a transaction count indicating a number of times the customer has attempted to insert a chip of the payment object into the EMV object reader prior to swiping magstripe. By comparing the transaction count with a threshold count, the payment processing system authorizes the payment transaction as a technical fallback transaction if the transaction count is greater than the threshold count.

A payment reader includes a power management system to control the power mode of the payment reader. The power management system can transition the payment reader between a sleep mode, a low power mode and a full power mode. The power management system can use a low power mode reference counter to determine when to transition from the full power mode to the low power mode and a sleep mode reference counter to determine when to transition from the low power mode to the sleep mode. When the low power mode reference counter reaches zero, the power management system deactivates a payment processing subsystem to transition to the low power mode. Similarly, when the sleep mode reference counter reaches zero, the power management system deactivates a payment reader system to transition to the sleep mode.

Multi-chip reference counting power management

A device such as a payment terminal may connect to an externally-driven processing device such as an EMV chip of an EMV chip card, providing signals such as a clock signal to the EMV chip. The payment terminal may obtain information about the EMV chip card or a transaction, and based on that information, modify the clock rate of the clock signal that is provided to the EMV chip. The payment terminal may monitor the operation of the EMV chip at the modified clock rate, in order to determine whether the modified clock rate causes errors in the processing of the EMV chip.

Identification of desired clock rate for an externally-driven processing device

Techniques for generating schedule(s) specific to a merchant for managing power states of component(s) of a point-of-sale (POS) system of the merchant are described. Transaction data associated with transactions involving the merchant may be received from a POS application of the POS system. Based at least partly on the transaction data, a schedule for managing the power states of a component, such as a battery-operated payment reader device, may be determined. The schedule may indicate when to change a first power state of the component to a second power state. The schedule may be sent to a POS system. The POS system may use the schedule to manage the power states of a component of the POS system, such as a battery-operated reader device. Additionally, or alternatively, the POS system may determine triggering events and may manage the power states of the component based on the triggering events.

Growing community of inventors

San Francisco, CA, United States of America

David Terra