JP6731080B2 - Immediate processing of electronic payment transactions - Google Patents

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application benefits from the priority of US Patent Application No. 15/197,708, filed June 29, 2016, entitled "Expedited Processing of Electronic Payment Transactions." That application is incorporated herein by reference. This application benefits from the priority of US Application No. 15/197,711, entitled "Multi-Interface Processing of Electronic Payment Transactions," filed June 29, 2016. That application is incorporated herein by reference.

Electronic payments can be made in various ways. The payment terminal may process the payment transaction and may interact with the payment device. Such a device may be, for example, a payment card with a magnetic stripe swiped with a magnetic reader of a payment terminal, a payment device with a Europay/Mastercard/Visa (EMV) chip plugged into a corresponding EMV slot of the payment terminal, or , Near field communication (NFC) enabled devices such as smartphones and EMV cards that tap payment terminals to send payment information via a secure wireless connection. The payment terminal may receive payment information from the payment device along with information about the transaction and may communicate this information to the payment system for processing the transaction.

At times, conditions may arise that prevent the payment terminal from communicating with the payment server to complete the payment transaction. Such conditions may be caused by a lack of a communication link between the payment terminal and the payment server, such as a network connection failure. Even otherwise, the payment terminal may not be able to send information for approval by the payment server, for example when the connection between the payment terminal and the server is experiencing high latency. In some cases, these conditions can cause a long delay in the payment process if the payment terminal cannot complete the payment process until it can send the payment information to the server. If the delay is long enough, both the user of the payment terminal and the consumer trying to complete the payment transaction may be unbearable. Delays during payment transactions can irritate consumers trying to complete the transaction and can reduce the transaction volume of the merchant.

In addition, payment terminals experiencing large payment transaction volumes may experience significant delays even when communication between the payment device and the payment server, eg, a server located at a financial institution, occurs at high speed. .. The duration of a transaction can be affected by the time required by the payment terminal to retrieve electronic payment information from the payment device. Delays may occur based on the type of payment device used to complete the payment transaction. For example, the chip card must be physically inserted in the payment terminal during the process. In particular, delays in processing chip card transactions can cause discomfort or friction during payment transactions.

The above as well as other aspects, features, and various advantages of the present disclosure will become apparent in view of the following detailed description in conjunction with the accompanying drawings.

FIG. 6 shows an illustrative block diagram of a payment system according to an embodiment of the disclosure.

FIG. 6 shows an illustrative block diagram of a payment device and payment terminal according to an embodiment of the disclosure.

FIG. 6 shows an illustrative block diagram of a payment reader according to an embodiment of the disclosure.

FIG. 6 shows an illustrative block diagram of a merchant device according to an embodiment of the disclosure.

FIG. 3 shows an illustrative block diagram of a payment service system according to an embodiment of the disclosure.

FIG. 6 shows a non-limiting flow diagram illustrating an exemplary method for processing electronic payment information received from a chip card in an expedited processing mode, according to an embodiment of the disclosure.

FIG. 7 shows a non-limiting ladder diagram illustrating an exemplary method for processing electronic payment information received from a chip card in an expedited processing mode, according to an embodiment of the disclosure.

FIG. 6 illustrates a non-limiting flow diagram illustrating an exemplary method for selectively processing electronic payment information through multiple interfaces, according to an embodiment of the disclosure.

The payment system may include a payment terminal and a payment server. The payment terminal may have a payment reader and a merchant device. The payment reader receives payment information from a payment device such as an EMV chip card, magnetic stripe card or NFC payment device. The merchant device has a point of sale application that provides a user interface for the merchant and that communicates with the payment reader and the payment server. The payment server processes the transaction based on other information received from the merchant device (eg, payment amount, merchant, location, etc.) and the payment information and communicates the payment result (eg, approval or disapproval) to the merchant device.

The merchant device may accept a request at the user interface of the merchant device to process the electronic payment information from the chip card in the expedited processing mode. In the urgent processing mode, the merchant device may process electronic payment transactions faster than with normal processing steps. Before entering the emergency processing mode, the merchant device may provide an opt-in request to the user interface. In certain embodiments, the opt-in request may include information for the user, such as a notification or disclosure regarding the consequences of accepting the opt-in request.

If the user accepts the opt-in request, the merchant device may accept the payment request and request an electronic payment response from the chip card inserted at the payment reader's interface (eg, contact interface). The electronic payment response from the chip card may include information from the chip card, such as encrypted payment information. In some embodiments, the chip card may provide an electronic payment response that includes an authentication request cipher (“ARQC”). The merchant device may receive the electronic payment response from the chip card and store it in the memory of the merchant device.

The merchant device may approve the payment transaction associated with the electronic payment response from the chip card. In certain embodiments, the approval may be provided as an "offline approval". In certain embodiments, authorization of the payment transaction from the merchant device may allow the chip card to be removed from the payment reader. The merchant device may process additional payment requests, receive additional electronic payment responses from each corresponding chip card, and store them in the memory of the merchant device. In one embodiment, for each corresponding chip card providing an electronic payment response indicating authorization (eg, including ARQC), the merchant device provides the chip card with authorization of the transaction. You may. After the merchant device provides authorization for the payment transaction, the merchant device may associate a payment type indicator and a time-of-day indicator with each electronic payment response. The merchant device may send the authorization request to one or more payment servers if the merchant device determines that the authorization request can be sent. The payment type indicator may inform the payment server that the authorization request is subject to processing according to the urgent payment protocol. Therefore, the chip card need not remain in the chip card slot for additional communication with the payment server, but rather at an early stage of the transaction (eg, after the first electronic payment response is received). Can be removed.

FIG. 1 shows an illustrative block diagram of a payment system 1 according to an embodiment of the present disclosure. In one embodiment, the payment system 1 includes a payment device 10, a payment terminal 20, a network 30, and a payment server 40. In the exemplary embodiment, payment server 40 may include multiple servers operated by different entities, such as payment service system 50 and bank server 60. These components of payment system 1 facilitate electronic payment transactions between merchants and customers.

Electronic interaction between the merchant and the customer occurs between the customer's payment device 10 and the merchant's payment terminal 20. The customer has a payment device 10 such as a credit card with a magnetic stripe, a credit card with an EMV chip, an NFC-enabled electronic device such as a smartphone running a payment application. The merchant has a payment terminal 20, such as a payment terminal or other electronic device. Such other electronic devices may process payment information (eg encrypted payment card data and user authentication data) and transaction information (eg purchase volume and point of purchase information), eg payment applications. Is a smartphone or tablet that runs.

In some embodiments (eg, for cheap transactions or payment transactions less than the payment cap indicated by NFC or EMV payment device 10), initial processing and authorization of payment transactions may be processed at payment terminal 20. In other embodiments, payment terminal 20 may communicate with payment server 40 via network 30. Although payment server 40 may be operated by a single entity, in some embodiments payment server 40 may include any suitable number of servers operated by any suitable entity, eg, payment. It should be appreciated that the service system 50 may include one or more banks of merchants and customers (eg, bank server 60). The payment terminal 20 and the payment server 40 exchange payment information and transaction information and decide whether to approve the transaction. For example, the payment terminal 20 may provide the payment server 40 with the encrypted payment data, the user authentication data, the purchase amount information, and the point of purchase information via the network 30. The payment server 40 determines whether to approve the transaction based on this received information and the information about the customer or merchant account, and via the network 30 to indicate whether the payment transaction has been approved. You may respond to the payment terminal 20. Payment server 40 may also send additional information to payment terminal 20, such as a transaction identifier.

Based on the information received at the payment terminal 20 from the payment server 40, the merchant may indicate to the customer whether the transaction has been approved. In some embodiments, such as a chip card payment device, the authorization may be shown at the payment terminal, for example on the screen of the payment terminal. In other embodiments, such as smartphones and watches operating as NFC payment devices, the NFC payment device is provided with information about approved transactions and additional information (eg, receipts, special offers, coupons, loyalty program information, etc.). And may be displayed on the screen of a smartphone or watch or stored in memory.

In some embodiments, payment server 40 may receive multiple payment authorization requests from payment terminal 20. As detailed below, each payment authorization request may include an electronic payment response and an associated payment type indicator, which payment type indicator should be processed using the expedited processing mode. Is shown. The payment server 40 also includes an indicator from the payment terminal 20 for checking the communication interface of the payment terminal 20, the ability to communicate with the payment server 40, or the connection speed between the payment terminal 20 and the payment server 40. A payment authorization request may be received. In some embodiments, payment server 40 may receive the payment approval request and an associated time indicator and process the payment approval request according to the time indicated by the time indicator. Further, in certain embodiments, payment server 40 may receive electronic payment information and a swipe mode processing indicator and provide a payment authorization response for the electronic payment information.

FIG. 2 shows an illustrative block diagram of payment device 10 and payment terminal 20 according to an embodiment of the disclosure. It is understood that the payment terminal 20 and the payment device 10 of the payment system 1 can be implemented in any suitable manner, but in one embodiment the payment terminal 20 includes the payment reader 22 and the merchant device 29. You may prepare. However, it is understood that the term payment terminal, as used herein, may refer to the entire payment terminal 20 or any suitable component of the payment terminal 20, such as the payment reader 22 or the merchant device 29. Will be done. In some embodiments, the payment reader 22 of the payment terminal 20 may be a wireless communication device that facilitates transactions between the payment device 10 and a merchant device 29 that executes a point-of-sale application.

In one embodiment, payment device 10 may be a device capable of communicating with payment terminal 20 (eg, via payment reader 22), an NFC device 12, an EMV chip card 14, or the like. Chip card 14 may include a secure integrated circuit. This integrated circuit can communicate with payment terminals, such as payment terminal 20, can generate encrypted payment information, and is subject to one or more electronic payment standards, such as those published by EMVCo. , The encrypted payment information and other payment or transaction information (eg, transaction caps for locally processed payments) can be provided. The chip card 14 may include contact pins (eg, according to ISO 7816) for communicating with the payment reader 22, and in some embodiments is inductively coupled with the payment reader 22 via the near field 15. Good. The chip card 14 inductively coupled with the payment reader 22 may communicate with the payment reader 22 using load modulation of the wireless carrier signal provided by the payment reader 22 according to a wireless communication standard such as ISO14443.

The NFC device 12 may be an electronic device, such as a smartphone, tablet or smartwatch, capable of conducting a secure transaction with the payment terminal 20 (eg, via communication with the payment reader 22). The NFC device 12 executes on hardware (eg, a secure element containing hardware and executable code) and/or software (eg, a processor according to a host card emulation routine) for performing secure transaction functions. Executable code). During a payment transaction, the NFC device 12 may be inductively coupled with the payment reader 22 via the near field 15 and a wireless carrier provided by the payment reader 22 in accordance with one or more wireless communication standards such as ISO14443 and ISO18092. The payment terminal 20 may be communicated by active or passive load modulation of the signal.

Payment terminal 20 may be implemented in any suitable manner, but in some embodiments payment terminal 20 may include a payment reader 22 and a merchant device 29. The merchant device 29 runs a point of sale application that provides a user interface for the merchant and facilitates communication with the payment reader 22 and the payment server 40. Payment reader 22 may facilitate communication between payment device 10 and merchant device 29. As described herein, payment device 10, such as NFC device 12 or chip card 14, may communicate with payment reader 22 via inductive coupling. This is depicted as the near field 15 in FIG. This near field 15 comprises a wireless carrier signal having a suitable frequency (eg 13.56 MHz) emanating from the payment reader 22.

In one embodiment, payment device 10 may be a contactless payment device such as NFC device 12 or chip card 14, and payment reader 22 and contactless payment device 10 modulate a wireless carrier signal in near field 15. You may communicate by doing. To convey information to the payment device 10, the payment reader 22 changes the amplitude and/or the phase of the wireless carrier signal based on the data to be transmitted from the payment reader 22, so that the radio transmitted to the payment device. A data signal is generated. This signal is transmitted by the antenna of the payment reader 22 which is tuned to transmit at 13.56 MHz, and the payment device 10 also has the antenna tuned appropriately within the near field 15 (eg 0 cm to 10 cm). If so, the payment device receives the wireless carrier signal or wireless data signal transmitted by the payment reader 22. In the case of a wireless data signal, the processing circuitry of payment device 10 can demodulate the received signal and process the data received from payment reader 22.

If a contactless payment device, such as payment device 10, is within range of near field 15, it is inductively coupled with payment reader 22. Therefore, the payment device 10 may also modulate the wireless carrier signal via active or passive load modulation. By changing the tuning characteristics of the antenna of the payment device 10 (eg, by selectively selecting a parallel load based on the modulated data to be transmitted in the antenna circuit), both the payment device 10 and the payment reader 22 are wireless. The carrier signal is modulated, which produces a modulated wireless carrier signal. In this way, the payment device can send the modulated data to the payment reader 22.

In one embodiment, payment reader 22 also includes an EMV slot 21 that can receive chip card 14. The chip card 14 may have contacts that engage corresponding contacts of the payment reader 22 when the chip card 14 is inserted into the EMV slot 21. The payment reader 22 supplies power to the EMV chip of the chip card 14 through these contacts, and the payment reader 22 and the chip card 14 communicate through the communication path established by those contacts.

Payment reader 22 may also include hardware that interfaces with a magnetic stripe card (not shown in FIG. 2). In certain embodiments, the hardware may include a slot that guides the customer to swipe or sink the magnetic stripe of the magnetic stripe card, in which case the magnetic stripe reader may receive payment information from the magnetic stripe card. .. The payment information received is then processed by payment reader 22.

Merchant device 29 may be any suitable device such as tablet payment device 24, mobile payment device 26, or payment terminal 28. For computing devices such as tablet payment device 24 and mobile payment device 26, the point-of-sale application may be responsible for entering purchase and payment information, interacting with customers, and communicating with payment server 40. For example, the payment application may provide a service menu from which the merchant may choose and a set of menus or screens to automate the transaction. The payment application may also facilitate entering customer credentials such as a signature, PIN number, biometric information. Similar features may be provided to the dedicated payment terminal 28.

The merchant device 29 may communicate with the payment reader 22 via communication path 23/25/27. The communication path 23/25/27 may be implemented via a wired connection (eg Ethernet, USB, Firewire, Lightning) or a wireless connection (eg Wi-Fi, Bluetooth, NFC, ZigBee), but in some implementations. In the form of, the payment reader 22 may communicate with the merchant device 29 via the Bluetooth throw energy interface, in which case the payment reader 22 and the merchant device 29 are connected devices. In some embodiments, processing of payment transactions may occur locally at payment reader 22 and merchant device 29, for example, if the transaction volume is low or there is no connection to payment server 40. In other embodiments, the merchant device 29 or payment reader 22 may communicate with the payment server 40 via a public or private communication network 30. The communication network 30 may be any suitable communication network, but in one embodiment the communication network 30 may be the Internet and payment and transaction information is between the payment terminal 20 and the payment server 40. Communication may be in encrypted form, for example by Transport Layer Security (TLS) or Secure Socket Layer (SSL) protocols.

FIG. 3 illustrates a block diagram of an exemplary payment reader 22 according to certain embodiments of the present disclosure. In some embodiments, payment reader 22 may be a wireless communication device that wirelessly communicates with an interactive electronic device, such as merchant device 29, using Bluetooth Classic or Bluetooth throw energy, for example. Although particular components are depicted in particular configurations in FIG. 3, payment reader 22 may include additional components, such that one or more of the components shown in FIG. It will be appreciated that the components of payment reader 22 may be reconfigured in any suitable manner. In one embodiment, the payment reader 22 includes a reader chip 100, a plurality of payment interfaces (eg, contactless interface 102, contact interface 104, and swipe interface 105), a power supply 106, a wireless communication interface 108, and a wired interface. It includes an interface 110 and a transaction chip 114. The payment reader 22 also includes a processing unit 120 and a memory 122 in the reader chip 100 and a general purpose processing unit 124, a cryptographic processing unit 125, a general purpose memory 126 and a cryptographic memory 128 in the transaction chip 114. In one embodiment, the processing unit 120 and the memory 122 are described as packaged in the reader chip 100 and the transaction chip 114, respectively, and configured in a particular manner. Unit 124, cryptographic processing unit 125, memory 122, general purpose memory 126 and cryptographic memory 128 may be configured in any suitable manner to perform the functions of payment reader 22 as described herein. You will understand. The functionality of the reader chip 100 and the transaction chip 114 may be implemented in a single chip or multiple chips, each of which may include any suitable combination of processing units and memories, thereby collectively. It will be appreciated that it performs the functions of reader chip 100 and transaction chip 114 described in.

In certain embodiments, payment reader 22 may include various interface elements (not shown) for providing output to a user. In one embodiment, the interface element may provide an indicator of the progress of a transaction or transaction at payment reader 22. The interface element may be any suitable device for providing output to the user of payment reader 22, such as a touch screen, light, text display, speaker, or other interface. In certain embodiments, the interface element may be configured to accept input from a user and provide the input to various resources of payment reader 22, such as reader chip 100 or transaction chip 114.

In one embodiment, reader chip 100 may be any suitable chip, such as the K21 chip supplied by Freescale Semiconductor, Inc. The processing unit 120 of the reader chip 100 of the payment reader 22 may be any suitable processor, and may include hardware, software, memory, and circuitry as long as it is necessary to carry out and control the functions of the payment reader 22. May be included. The processing unit 120 may include one or more processors and may operate the reader chip 100 based on instructions in any suitable number of memories or memory types. In some embodiments, processing unit 120 may include multiple independent processing units, such as multi-core processors or other similar components. The processing unit 120 may control the operation and processing of the payment reader 22 by executing instructions retained in the memory 122 of the reader chip 100. As used herein, a processor or processing unit may include one or more processors with the processing power necessary to perform the processing functions described herein, such as hardware logic (eg, The hardware readable language (HDL) and other computer-readable instructions executed by a processor and hardware designed by software that describes the configuration of hardware, and any appropriate combination thereof are included, but are not limited thereto. The processor may execute software to perform the operations described herein, such software being software accessed in a machine-readable form on a substantive non-transitory computer-readable storage medium. including.

In the exemplary embodiment, processing unit 120 of reader chip 100 is configured to act as a hub for controlling the operation of various components of payment reader 22 based on instructions held in memory 122. It may also include two RISC processors. Memory, as used herein, may refer to any suitable physical or non-transitory storage medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, and memory, but not transmission signals. Substantial computer readable storage media includes volatile and nonvolatile, removable and non-removable media such as computer readable instructions, data structures, program modules and other data. Examples of such media are RAM, ROM, EPROM, EEPROM, SRAM, flash memory, disk or optical storage, magnetic storage, or any other non-transitory medium holding information accessed by a processor or computing device. including.

Reader chip 100 may also include additional circuitry such as interface circuitry, analog front end circuitry, security circuitry, and component monitoring circuitry. In one embodiment, the interface circuit is a circuit that interfaces with a wireless communication interface 108 (eg, Wi-Fi, Bluetooth Classic, Bluetooth Throw Energy) and a wired interface 110 (eg, USB, Ethernet, FireWire, and Lightning), a circuit that interfaces with another communication interface or a bus (for example, I2C, SPI, UART, and GPIO), and a circuit that interfaces with the power supply 106 (for example, a power management circuit, Power conversion circuit, rectifier, and battery charging circuit).

The transaction chip 114 may include one or more processors having the processing power necessary to perform the processing functions described herein, such as hardware logic, computer readable instructions executed by the processor, or any of these. And the like, but is not limited thereto. In the exemplary embodiment, transaction chip 114 may perform functions related to processing payment transactions, interfacing with payment devices, encryption, and other payment specific functions. In some embodiments, transaction chip 114 may include a general purpose processing unit 124 for performing instructions associated with a general purpose payment function and a cryptographic processing unit 125 for handling cryptographic processing operations. Each of general purpose processing unit 124 and encryption processing unit 125 may have a dedicated memory associated with it (ie, general purpose memory 126 and encryption memory 128). In this manner, certain cryptographic operations and important security information (eg, encryption keys, passwords, user information, etc.) may be securely held and processed by the encryption memory 128 and the encryption processing unit 125.

One or both of the general purpose processing unit 124 and the cryptographic processing unit 125 of the transaction chip 114 may communicate with the reader chip 100 (eg, processing unit 120) using, for example, any suitable internal bus and communication technology. In this aspect, the reader chip 100 and the transaction chip 114 may together process a transaction and convey information regarding the processed transaction (eg, to the merchant device 29).

The transaction chip 114 may also include circuitry for interfacing with the contact interface 104 (eg, power and communication circuitry for directly interfacing with the EMV chip of the chip card 14 inserted in the slot 21). In some embodiments, the transaction chip 114 also includes analog front end circuitry (eg, electromagnetic matching (EMC) circuitry, matching circuitry, modulator circuitry, and measurement circuitry) that interfaces with the analog components of the contactless interface 102. But it's okay.

The contactless interface 102 may provide NFC communication with contactless devices such as the chip card 14 and the NFC device 12. Based on the signal provided by the reader chip 100, the antenna of the contactless interface 102 may output either a carrier signal or a modulated signal. The carrier signal may be a signal having a fixed frequency such as 13.56 MHz. The modulated signal may be a version of a carrier signal that is modulated according to a modulation procedure such as ISO 14443 or ISO 18092. When the payment reader 22 inductively couples with a contactless device, the contactless device also modulates a carrier signal, the modulated signal being detected by contactless interface 102 and provided to reader chip 100 for processing. Good. Based on this modulation of the carrier signal, payment reader 22 and contactless device can convey information such as payment information.

Contact interface 104 may be a suitable interface for powering and communicating with a payment chip, such as the EMV chip of chip card 14. The contact interface 104 may include a plurality of contact pins (not shown in FIG. 3) that are physical interfaces with the chip card 14 according to the EMV standard. In one embodiment, the contact interface 104 includes a power supply (VCC) pin, a ground (GND) pin, a reset (RST) pin for resetting an EMV card, a clock (CLK) pin for providing a clock signal, and an EMV. It may include a programming voltage (VPP) pin for providing a programming voltage to the card, an input/output (I/O) pin for providing EMV communication, and two auxiliary pins. In this aspect, the payment reader and chip card can exchange information such as payment information.

In some embodiments, the contact interface 104 may be provided with a chip card detection circuit 112 that detects when a chip card is inserted into the chip card interface (eg, card slot) of the contact interface 104. May be. In the exemplary embodiment, the chip card detection circuit includes suitable hardware (eg, switches, optical detection circuits, proximity sensors, etc.) for detecting the presence of a chip card in the card slot of contact interface 104. ) May be included. This signal may then be provided for processing by one or more other components of payment reader 22 (eg, reader chip 100 of payment reader 22).

The swipe interface 105 may provide an interface for reading information from a magnetic strip (“magnetic strip”) of a payment device, such as a credit card or debit card, swiped through the swipe interface 105. In one embodiment, swipe interface 105 may communicate with transaction chip 114, and electronic payment information received when a user swipes a magnetic strip through swipe interface 105 is provided to transaction chip 114 for processing. May be provided. In one embodiment, swipe interface 105 may include any suitable hardware for reading information from the magnetic strip of a payment card and providing that information to transaction chip 114.

In one embodiment, general purpose processing unit 124 may include any suitable processor for performing the payment processing functions of payment reader 22 described herein. In one embodiment, general purpose memory 126 may be any suitable memory as described herein, and may include multiple sets of instructions for performing general purpose transaction processing operations of payment reader 22. Often, such a set of instructions is, for example, a transaction processing instruction 166, a data authentication instruction 168, a signal conditioning instruction 170, or the like.

Transaction processing instructions 166 control the interaction between payment reader 22 and payment device 10 (eg, to interface with the payment device via contactless interface 102 and contact interface 104), Selecting a payment processing procedure (eg, based on the payment processing entity associated with the payment method), interfacing with the cryptographic processor 125, any other suitable aspect of transaction processing, etc. Instructions may be included to control the general transaction processing operations of payment reader 22.

The data authentication instruction 168 may include an instruction for providing the setting information of the payment terminal 20. The configuration information may include any suitable information such as payment caps, transaction types for local transactions (ie, transactions that occur without connecting to payment server 40) and supported applications. In one embodiment, by way of example, data authentication instructions 168 may include configuration instructions such as TMS-CAPK instructions. In some embodiments, the TMS-CAPK instructions may be tailored for a particular jurisdiction (eg, country specific).

Signal conditioning instructions 170 may include instructions to condition signals received from payment device 10 (eg, from NFC payment device 10) via contactless interface 102. In some embodiments, the signal conditioning instructions 170 may include instructions for manipulating the signals received via the contactless interface 102, the signal conditioning instructions 170 being the NFC received via the contactless interface 102. Instructions may be included to condition the signal using any suitable hardware, logic, or algorithms required to process the signal.

Cryptographic processing unit 125 may be any suitable processor described herein, and in one embodiment may perform cryptographic functions for processing payment transactions. For example, in one embodiment, cryptographic processing unit 125 may encrypt and decrypt data based on one or more cryptographic keys, which isolates cryptographic functionality from other components of payment reader 22. Doing so protects the encryption key from exposure to other components of payment reader 22.

In certain embodiments, encryption memory 128 may be any suitable memory described herein or combinations thereof, for performing encryption operations such as payment processing instructions 176 and encryption instructions 178. It may include multiple sets of instructions. Payment processing instructions 176 provide cryptographic techniques to be used in connection with a particular payment procedure, access an account to process information, and/or any other suitable payment processing function, or the like. May include instructions for performing aspects of payment processing, such as any suitable combination of. Cryptographic instructions 178 may include instructions for performing cryptographic operations. The encryption processing unit 125 is an encryption function for performing various encryption functions such as an encryption function, a decryption function, a signature function, a function of verifying a signature at the time of payment and a function of verifying transaction information as a part of a payment transaction. The conversion instruction 178 may be executed.

The wireless communication interface 108 participates in wireless communication with appropriate wireless communication hardware (eg, antenna, etc.) and with the merchant device 29 (eg, via a protocol such as Bluetooth throw energy) and controls associated circuitry. And/or one or more processors having the necessary processing power for the relevant circuitry, including but not limited to hardware logic, computer readable instructions to be executed by the processor, or any suitable combination thereof. The wireless communication interface 108 may be implemented in any suitable manner, but in the exemplary embodiment, the wireless communication interface 108 may include a processing unit (not shown) and a memory (not shown), Texas Instruments CC2640. It may be implemented as a device.

Power source 106 may include one or more power sources, such as an AC power source or a physical connection to a battery. The power supply 106 may include power conversion circuitry for converting an AC or DC power supply into a plurality of DC voltages for use by the components of the payment reader 22. If the power source 106 includes a battery, the battery can be charged via a physical power connection, or via inductive charging, or via any other suitable method. Although not shown in FIG. 3 as being physically connected to other components of payment reader 22, power supply 106 may supply various voltages to the components of payment reader 22 according to the requirements of the component. ..

Wired interface 110 is any suitable interface for wired communication with other devices or communication networks, such as USB, Lightning, Firewire, Ethernet, or any other suitable wired communication interface or any combination thereof. May be included. In some embodiments, the wired interface 110 may allow the payment reader to communicate with one or both of the merchant device 29 and the payment server 40.

The memory 122 of the reader chip 100 may include multiple sets of instructions for controlling the operation of the payment reader 22, such as operating instructions 130 and transaction processing instructions 132.

The operating instructions 130 are payment readers such as internal communication, power management, message processing, system monitoring, sleep mode, user interface response and control, operation of the wireless interface 108, operation of the transaction chip 114, management of other sets of instructions. Instructions for controlling 22 general purpose operations may be included. In certain embodiments, operating instructions 130 may provide the operating system and applications necessary to perform most of the processing operations performed by processing unit 120 of reader chip 100 of payment reader 22.

Operating instructions 130 may also include instructions for interfacing with merchant device 29. In one embodiment, the merchant device 29 may be running a point of sale application. The operating instructions 130 may include instructions for complementary applications executed in the processing unit 120 of the reader chip 100 for exchanging information with the point of sale application. For example, a point-of-sale application may provide a user interface that facilitates a user, such as a merchant, to make a purchase transaction with a customer. The menu may provide item selection, tax calculation, tip addition, and other related functions. When it is time to receive payment, the point-of-sale application may send a message (eg, via the wireless interface 108) to the payment reader 22. The operating instruction 130 obtains payment information, for example, via the contactless interface 102 or the contact interface 104, calls the transaction chip 114 to process the payment information, and, via the wireless interface 108, a point-of-sale of the merchant device. Facilitates payment processing by generating a response message that is transmitted to the application.

Operating instructions 130 may also include instructions for interfacing payment server 40 with payment service system 50. In some embodiments, payment service system 50 may be associated with the point of sale application of payment reader 22 and merchant device 29. For example, payment service system 50 may have information about payment reader 22 and merchant device 29 registered with payment service system 50 (eg, based on a unique identifier). This information can be used to process transactions with merchants and customer financial institution servers, provide analytics and reporting to merchants, and collect transaction data. Payment reader 22 may process payment information (eg, based on the operation of reader chip 100 and transaction chip 114) and communicate the so processed payment information to a point-of-sale application. It then communicates with the payment service system 50. In this aspect, messages from payment reader 22 are forwarded to payment service system 50 of payment server 40, where payment reader 22 and payment service system 50 may cooperatively process payment transactions.

Transaction processing instructions 132 may include instructions for processing payment transactions at payment reader 22. In some embodiments, transaction processing instructions may comply with payment standards such as those published by EMV. Depending on the payment method in use (eg Europay, Mastercard, Visa, American Express, etc.), a particular procedure associated with that payment method may be selected and the transaction processed according to that procedure. .. When executed by processing unit 120, these instructions determine whether to process the transaction locally, determine how to access the payment information from the payment device, and then process the payment information. Whether you decide how to handle it, decide which cryptographic functions to perform, the type of communication you want to exchange with the payment server, and any other appropriate information about the handling of payment transactions. Good. In certain embodiments, transaction processing instructions 132 may perform high level processing and provide instructions for processing unit 120 to communicate with transaction chip 114 to perform most transaction processing operations.

Transaction processing instructions 132 may include precharge instructions for communicating payment information to a payment device when performing a precharge operation during a payment transaction. In one embodiment, transaction processing instructions 132 are preliminary to processing by payment reader 22 until the payment transaction is complete (eg, in a point-of-sale application executing on merchant device 29 in communication with the payment reader). It may include instructions for handling transactions intended to provide a charge to the chip card. In some embodiments, the pre-charge or pre-charges may provide a dummy charge amount for the chip card to generate an authentication response (eg, authentication response cipher). Depending on when the precharge request is received from the merchant device, this authentication response may be returned to the merchant device (eg, via wireless interface 108 or wired interface 110) before the merchant completes the payment transaction. May be

In certain embodiments, it is desirable to process the authorization response returned during precharge with a payment amount that matches the actual payment amount of the transaction to be completed by the merchant. Such precharging may include obtaining a plurality of preliminary payment amounts for approval by the chip card based on transaction processing instructions 132. The reader chip 100 may receive, in a message, each of the plurality of preliminary payment amounts, for example, from a point-of-sale application at the merchant device 29 or payment server 40. As will be discussed in more detail below, in some embodiments, the plurality of preliminary payment amounts may be arbitrarily determined and provided to the payment reader 22 for use by the reader chip 100. As will be described in more detail below, in other embodiments, multiple preliminary payment amounts may be derived based on a forecasting technique using historical data of the merchant device 29, and in some embodiments the forecasting amount may be derived. Alternatively, data from another payment terminal 20 may be used. Transaction processing instructions 132 may include instructions for continuing to provide the preliminary charge until the actual payment amount is received (eg, processing of payment information from the payment transaction is complete).

In another embodiment, transaction processing instruction 132 receives an indicator that the charge request is a precharge request, assigns a priority to the indicator associated with the precharge request, and assigns the indicator and the priority assigned to it. Instructions may be included for storing the degrees in a memory, such as memory 122. At this point, the reader chip 100 may raise or lower the priority of the precharge request based on the indicator. In some embodiments, the reader chip 100 may obtain approval for each precharge request in a priority order (eg, highest to lowest priority). In one embodiment, the transaction processing instruction 132 assigns a priority assigned to the preliminary payment amount that is proportional to the score that indicates the probability that the preliminary payment amount matches the actual payment amount of the transaction. It may include instructions for assigning. In yet another embodiment, the reader chip 100 uses the instructions held in the transaction processing instruction 132 to store a request for payment information, regardless of whether the request is a precharge request and its priority. You can raise or lower it.

Transaction processing instructions 132 may include instructions for collecting information other than payment information before a charge is initiated during a payment transaction. For example, if a chip card is inserted in the contact interface 104, but before the transaction chip 114 requests electronic payment information (i.e., charge) from the card, the reader chip 100 may check the details and consumption of the chip card. Other information needed to process payment transactions from the chip card, such as information identifying the financial institution, information identifying the issuer that issued the chip card, account number, expiration date of the chip card, and other information. May be collected. In addition, transaction processing instructions 132 may include instructions for determining information about a customer using a payment device, including customer identifying information, transaction history and other information. In some embodiments, transaction processing instructions 132 may include instructions for collecting any suitable information from payment device 10 prior to requesting electronic payment information or otherwise initiating a charge at payment device 10. May be included.

FIG. 4 illustrates an exemplary merchant device 29 according to certain embodiments of the present disclosure. Although the merchant device 29 may be implemented in any suitable manner, in one embodiment, the merchant device 29 is a two-way electronic device that provides a user interface and communicates with one or more other devices. Good. Examples of interactive electronic devices are tablets, smartphones, smart watches, desktop computers, laptop computers, custom electronic devices, or any that have the necessary user interfaces and communication capabilities to perform the functions described herein. Including other suitable electronic devices.

Although particular components are depicted in particular configurations in FIG. 4, merchant device 29 may include additional components, and one or more of the components shown in FIG. 4 may not be included in merchant device 29. It will be appreciated that the components of the merchant device 29 may be reconfigured in any suitable manner. In one embodiment, the merchant device 29 includes a processing unit 202, a memory 204, an interface bus 206, a power supply 208, a user interface 210, a first wireless interface 212, a second wireless interface 214, and a wired interface. 216, and.

In one embodiment, the merchant device 29 includes a processing unit 202 and a memory 204 configured to control and perform the required operations of the merchant device 29. In some embodiments, processing unit 202 may be a general purpose processor that executes instructions for mobile operating systems, programs and applications based on instructions that may be retained in memory 204. Memory 204 may include any suitable memory type or combination thereof as described herein, which retains instructions and other data to execute the operating system, programs and applications of merchant device 29. And a flash memory or a RAM memory, for example. In some embodiments, memory 204 may include multiple sets of instructions such as operating instructions 220, point-of-sale application instructions 222, EMV offline instructions 224, and EMV/swipe mode instructions 226.

The processing unit 202 may interact with and control one or more other components of the merchant device 29 by executing instructions in the memory 204. Although the processing unit 202 may communicate with other components of the merchant device 29 in any suitable manner, in one embodiment the processing unit may use the interface bus 206. Interface bus 206 may include one or more communication buses such as I2C, SPI, USB, UART, and GPIO. In certain embodiments, the processing unit 202 may execute memory instructions and communicate with other components of the merchant device 29 via the communication bus of the interface bus 206 based on those instructions.

Merchant device 29 may also include a power supply 208. The power supply 208 may include power conversion circuitry for converting AC power and/or generating multiple DC voltages for use by components of the merchant device 29. If the power source 208 comprises a battery, the battery can be charged via a physical power connection, or via inductive charging, or via any other suitable method. Although not depicted in FIG. 4 as being physically connected to the other components of merchant device 29, power supply 208 may provide various voltages to the components of merchant device 29 according to the requirements of the component. ..

The merchant device 29 may also include a user interface 210. The user interface 210 may provide the user of the merchant device 29 with various options for interacting with applications and programs running on the merchant device 29. Exemplary user interface 210 may be any suitable user interface hardware and software, such as a touch screen interface, voice command interface, keyboard or mouse gesture recognition, any other suitable user interface, or any combination thereof. Wear may be included. In one embodiment, user interface 210 may be a touch screen interface that displays an interactive user interface for an application or program, such as a point-of-sale application running on merchant device 29.

The merchant device 29 may also include multiple wireless communication interfaces. The wireless communication interface is for providing a wireless communication interface such as Bluetooth Classic, Bluetooth Throw Energy, WiFi, Cellular, Short Message Service (SMS), NFC, or any other suitable wireless communication interface or any combination thereof. It may include any suitable hardware and software. In one embodiment, the first wireless communication interface 212 may be a wireless communication interface that primarily communicates with the payment reader 22 (eg, a Bluetooth throw energy interface), while the second wireless communication interface 214 is primarily the payment server 40. Wireless communication interface (for example, WiFi) that communicates with the payment service system 50 (for example, via the Internet).

The merchant device may also include a wired interface 216, which may be any other device or communication network such as USB, Lightning, Firewire, Ethernet, or any other suitable wired communication interface or any combination thereof. May include any suitable interface for wired communication with.

The operating instructions 220 may include internal communication, power management, I/O device control, communication device control, other hardware control of the merchant device 29, any other suitable instruction, or any combination thereof. Instructions may be included to control any suitable general purpose operation of the merchant device 29. In one embodiment, the operating instructions may provide instructions to the operating system of merchant device 29 along with most drivers, programs and applications running on merchant device 29.

Operating instructions 220 may include instructions for controlling the operation of user interface 210. The user interface 210 may be controlled according to the program and application instructions of operating instructions 220, point of sale application instructions 222, EMV offline instructions 224, and EMV/swipe mode instructions 226. In some embodiments, operating instructions 220 may include instructions that display information about EMV offline mode or EMV/swipe mode. The operating instructions 220 may also include instructions for interfacing the payment server 40 with the payment service system 50 and with the payment reader 22. The application running on payment reader 22 and/or merchant device 29 may be known to payment service system 50 (eg, via a registration process), in which case merchant device 29 may point to sale application instruction 222. Payments may be processed in accordance with payment service system 50 in accordance with.

Point-of-sale application instructions 222 include instructions for executing a point-of-sale application on merchant device 29. When executed by processing unit 202, point-of-sale application instructions 222 may provide a rich display of an interactive interface that enables merchants to process payment transactions with customers. These instructions allow merchants or customers to select products to purchase, calculate sales taxes, process chips, provide receipts, generate discounts and special offers, It may include a customized interface that allows it to process a customer loyalty program, perform inventory and delivery searches for items, and perform any other suitable retail operation. In some embodiments, the point-of-sale application instructions 222 may include instructions to provide a rich display of information regarding emergency processing modes such as EMV offline mode or EMV/swipe mode.

In some embodiments, point of sale application instructions 222 may include instructions for processing a request to enter an expedited processing mode. In one embodiment, the point-of-sale application instruction 222 may receive a request from a user, such as via the user interface 210, to enter an expedited processing mode. In the exemplary embodiment, various conditions may arise that make the processing of payment transactions using normal procedures impractical. For example, when the connection between the payment terminal 20 and the payment server 40 is lost and the payment terminal 20 cannot communicate with the payment server 40. By entering the expedited processing mode, as described below, the merchant device 29 can continue to process payment transactions until the connection between the payment terminal 20 and the payment server 40 is restored. In addition, such as during peak transaction hours or when large groups visit merchant locations and wait a long time for customers making purchases to experience long queues or to provide payment and leave the merchant's store. During this time period, normal processing operations may be impractical. By entering a swipe mode at the merchant device 29, the customer can enjoy the benefits of fast processing of payment information available through processing transactions by swiping a payment device with a magnetic strip.

In some embodiments, the point-of-sale application instructions 222 may include instructions for accepting an input from a user at the user interface 210 requesting entry into an urgent processing mode. For example, in one embodiment, the point-of-sale application instruction 222 may display an opt-in request in response to a request to enter an expedited processing mode. In some embodiments, the point-of-sale application instruction 222 may require the user to accept an opt-in request before the user can execute the expedited processing mode. In this regard, the user may accept or decline the opt-in request from the point of sale application instruction 222. If the user rejects the request, the point-of-sale application instruction 222 may process the transaction normally without entering the expedited processing mode. If the user accepts, the point-of-sale application instruction 222 allows the user to proceed in that mode (eg, EMV offline mode or swipe mode) if the user accepts an opt-in request for a mode. Good.

In some embodiments, the point-of-sale application instructions 222 may include instructions for providing and displaying a user interface framework and notifications or disclosures regarding urgent processing modes. For example, the user may receive a notification that the payment transaction will be made according to the expedited processing mode, after accepting the opt-in request. In one embodiment, the point-of-sale application instruction 222 may transfer responsibility from an issuer of the payment device 10 (eg, chip card or swipe card) to a merchant using the payment terminal 20 to process a payment transaction, etc. The user may be provided with a notification of a change of liability that may occur as part of the emergency processing mode. Other notifications and disclosures may be provided in other embodiments. In some embodiments, the point-of-sale application instructions 222 may provide the user with any information regarding the expedited processing mode for which disclosure is required or appropriate.

In some embodiments, point of sale application instructions 222 may include instructions for providing various notifications to processing element 202 of merchant device 29 in response to acceptance of an opt-in request by a user. In some embodiments, the notification may include an indication that the transaction is in the process of being processed in the urgent processing mode according to the urgent payment protocol. In some embodiments, the processing unit 202 may perform the urgent processing mode steps in response to the notification. In some embodiments, the notification may include an indication of why the transaction was treated as a swipe mode transaction. For example, when a request to enter a swipe mode is received and the user accepts the opt-in request, the payment information is received by reading the magnetic strip at the swipe interface 105, and the transaction is due to a failure to read the chip card at the payment terminal 20. Notification as not to be processed (eg, if payment reader 22 is unable to read the EMV chip, allowing the user to swipe the chip card). May be. In other embodiments, the notification may provide other information in response to acceptance of the opt-in request by the user.

EMV offline instructions 224 may include instructions for entering EMV offline mode at merchant device 29 and processing payment information from payment device 10 (eg, a chip card) in EMV offline mode. In certain embodiments, EMV offline instructions 224 may cause merchant device 29 to enter EMV offline mode in response to various events. Based on the EMV offline instruction 224, the merchant device 29 may not be able to communicate with the one or more payment servers of the merchant device 29's communication interface (eg, wireless interface 214) if the user accepts the opt-in request at the user interface 210. The processing unit 202 determines, the latency of the communication between the merchant device 29 and the payment server 40 exceeds a threshold, or in response to other events or other criteria, the EVM offline mode is entered. Good.

In some embodiments, EVM offline instructions 224 may include instructions for processing electronic payment information from a chip card as part of EMV offline mode. The EVM offline mode step provides payment authorization in response to an electronic payment response from the chip card, such as a transaction processing operation using Visa(R) QuickChip for EMV(R) or other similar processing operation. Aspects of existing EMV processing tasks for For example, in one embodiment, the EVM offline instruction may request and receive electronic payment information from a chip card as part of an urgent processing mode. The EMV offline instruction 224 may cause the processing unit 202 to provide the payment reader 22 with a request for an electronic payment response from a chip card at the chip card interface 104 of the payment reader 22. In certain embodiments, the request for electronic payment response may be provided in response to a first payment request received at the point of sale application 222 or otherwise.

In some embodiments, EMV offline instructions 224 may include instructions for receiving an electronic payment response. In one embodiment, the electronic payment response may be provided by a chip card inserted at the contact interface 104 of the payment reader 22. The chip card may perform risk management in response to a request for an electronic payment response, refuse to approve the transaction offline, or provide the information required for an online authorization request. In some embodiments, the information provided by the chip card may include an authentication request cryptography (“ARQC”) or other similar information needed to perform online authentication of electronic payment requests. In some embodiments, other steps for receiving an electronic payment response from payment reader 22 may be performed.

In one embodiment, EMV offline instructions 224 may include instructions for assigning a time-of-day indicator or timestamp to the electronic payment response received from payment reader 22. EMV offline instructions 224 may include instructions for associating electronic payment responses with one or more time-of-day indicators depending on various factors and requirements applicable to the transaction. For example, as described below, processing an electronic payment response at one or more payment servers may require a time-of-day indicator associated with the electronic payment response to enter within a particular transaction window. In some embodiments, the time-of-day indicator may correspond to the time the chip card provided the electronic payment response when requested for processing of the electronic payment response (eg, the time-of-day indicator is required for response authentication). Hash or part of ARQC). In this regard, in some embodiments, the electronic payment response may have more than one time indicator associated with it, eg, the time at which the chip card provided the electronic payment response and one or more payment servers received the electronic payment response. This is the case when the time between the time and the specified time exceeds a threshold value (for example, a latency threshold value). In certain embodiments, the associated time-of-day indicator may identify transmissions to the payment server at the earliest possible time in the future, or at a pre-scheduled time. In one embodiment, EMV offline instructions 224 may include instructions for assigning multiple time-of-day indicators to electronic payment responses from a chip card. In this regard, one of the plurality of time indicators may match a time within the time zone of the transaction requested by the one or more payment servers. In an embodiment, the time indicator associated with the electronic payment response allows the merchant device 29 to schedule a time for sending the electronic payment response to one or more payment servers based on the EMV offline instruction 224. May be

In some embodiments, EMV offline instructions 224 may include instructions for storing payment transaction information in memory 204 of merchant device 29 as an offline transaction. Payment transaction information may include an electronic payment response and one or more associated time of day indicators or payment type indicators. In one embodiment, the payment type indicator may include information about the payment device 10 that provided the electronic payment response, such as a chip card. In some embodiments, the indicator may include an indicator of whether or not a transfer of responsibility has occurred, such as a transfer of responsibility from a chip card issuer to a merchant.

In some embodiments, EMV offline instructions 224 may include instructions for authorizing a transaction associated with an electronic payment response. This approval may be based on standard EMV processing steps at merchant device 29, such as EMV processing performed during normal operation at merchant device 29. In certain embodiments, EMV offline instructions 224 may include instructions for providing authorization as an offline authorization, such as notification that an initial electronic payment response is received at merchant device 29. In certain embodiments, the EMV offline instruction 224 may provide a notification (eg, at the user interface) for the user prompting removal of the chip card from the chip card interface 104 following authorization. The user may remove the chip card before the transmission of information associated with the transaction, such as electronic payment response or other information. In this regard, the payment transaction time perceived by the user can be reduced.

EMV offline instructions 224 may include instructions for performing the above steps if an additional payment request is received at merchant device 29. In one embodiment, the EMV offline instruction 224 requests an additional electronic payment response in response to the additional payment request at the user interface and stores the additional electronic payment response in the memory 204 to provide the additional electronic payment response. Instructions may be included to approve additional transactions associated with the electronic payment response. These steps may be repeated as needed for payment requests received at the user interface 210 of the merchant device 29.

In some embodiments, EMV offline instructions 224 may include instructions for sending a payment authorization request to one or more payment servers. In some embodiments, the payment authorization request may include one or more electronic payment responses and a payment type indicator associated with each electronic payment response. In some embodiments, the payment type indicator may indicate to one or more payment servers that one or more electronic payment responses are subject to processing according to an expedited payment protocol. Under an urgent payment protocol (eg, Visa quick chip), transactions can be approved without further communication between the payment server and the chip card. This allows the chip card to be removed early in the payment process (eg, after an electronic payment response has been sent, at a particular stage in the transaction, or during preliminary approval by the merchant device). In addition, the payment authorization request may include an indicator that includes information about the transfer of responsibility, such as an indicator that a transfer of responsibility to the merchant has occurred.

In certain embodiments, EMV offline instructions 224 may include instructions for sending payment authorization requests at various times or in response to various events. For example, in one embodiment, after storing one or more electronic payment responses in memory, the EMV offline instruction 224 sends the one or more payment servers to one or more payment servers based on the determination that one or more payment authorization requests can be sent. It may include the option to submit one or more payment authorization requests. The EMV offline instruction may determine that one or more payment authorization requests may be sent based on determining that the communication interface of payment terminal 20 (eg, wireless interface 214 of merchant device 29) is available. Good. In this regard, processing unit 202 (based on EMV offline instructions 224) checks, in any suitable manner, whether the communication interface is capable of communicating with one or more payment servers (eg, payment server 40). You may. This is done, for example, by monitoring the transmissions received at the communication interface or by receiving responses to messages sent from the communication interface from one or more payment servers. In one embodiment, EMV offline instructions 224 may include instructions for performing the check after the first electronic payment response is received at merchant device 29. In some embodiments, the EMV offline instruction 224 may include instructions for determining that the frequency of payment requests is less than a threshold as part of determining that the payment authorization request can be submitted. In this regard, EMV offline instructions 224 may include instructions for recording the time at which each payment request was accepted at user interface 210 and comparing the frequency of the request with a predetermined threshold. The threshold may be updated from time to time based on various factors such as the latency of communication between the payment terminal 20 and the payment server 40 and other similar information.

In one embodiment, EMV offline instructions 224 may include instructions for forwarding one or more payment authorization requests to one or more payment servers if the communication interface is capable of communicating with one or more payment servers. In some embodiments, the EMV offline instruction 224 may assign a time-of-day indicator to the payment authorization request, eg, if the time-of-day indicator is not part of the ARQC associated with the electronic payment response. In certain embodiments, EMV offline instructions 224 may include instructions for waiting until the time indicated by the time-of-day indicator associated with the payment authorization request before sending the payment authorization request to one or more payment servers. The time indicated by the time-of-day indicator may be a specific or explicit time, an elapsed time, or an interim time. For example, the time indicated by the time-of-day indicator is based on a determination that the latency of communication between the payment terminal 20 and the payment server 40 is below a threshold value, or that the frequency of payment requests is below a threshold value. May be. In other embodiments, the time of day indicator may include other information.

The EMV offline instruction 224 may include instructions for forwarding the payment approval request at a time corresponding to the time of the associated time indicator. The time corresponding to the time-of-day indicator may be a future time when the payment authorization request is scheduled to be sent. In certain embodiments, each of the multiple payment approval requests may be associated with an associated time indicator corresponding to a similar time. In this regard, the EMV offline instruction may process multiple payment approval requests at a time corresponding to the time associated with the time of day indicator. In one embodiment, the EMV offline instruction 224 provides instructions to forward the payment authorization request and its associated time indicator to one or more payment servers at a time prior to the time corresponding to the time of day of the time indicator. May be included. In this regard, one or more payment servers may wait until the time corresponding to the time of day of the time indicator before processing the payment authorization request. In certain embodiments, the EMV offline instruction 224 may include instructions for forwarding the payment authorization request to an intermediate server, which at a later time forwards the payment authorization request to one or more payment servers. You may. In one embodiment, EMV offline instructions 224 may include instructions for forwarding all payment authorization requests that can be sent at a given time to one or more payment servers. In other embodiments, EMV offline instructions 224 may include instructions for processing payment authorization requests using other techniques.

EMV offline instructions 224 may include instructions for receiving a payment approval response in response to a payment approval request sent to one or more payment servers. In certain embodiments, the payment authorization response may be associated with one or more payment authorization requests, and may indicate that a particular payment transaction has been approved or rejected, for example, by a chip card issuer. In one embodiment, EMV offline instructions 224 may include instructions for providing user interface 210 with notification of final approval or rejection of a payment approval request indicated by a payment approval response. A payment authorization response may be received for each payment authorization request sent to one or more payment servers.

Described below are embodiments in which the merchant device 29 may include a swipe interface 105 and may be configured to process payment transactions with a chip card in a swipe mode. Under certain conditions, payment terminal 20 may not be able to process payment transactions in which a customer attempts to provide electronic payment information using a chip card. For example, damage to the EMV chip of a chip card, improper use, various hardware and software problems at payment terminal 20, or other problems may prevent processing of payment information using normal EMV procedures. is there. If the payment reader 22 cannot read the payment information using normal EMV processing, processing of the EMV chip card may be done using magnetic strips. In general, a "falling back" process that allows processing of payment information from a chip card using a magnetic strip of the chip card may be referred to as a "fallback transaction". During a swipe transaction involving a card with a magnetic strip but no EMV chip, the responsibility for non-payment risk if the transaction is rejected is transferred from the issuer of the card to the merchant who accepted the swipe transaction. However, there is no transfer of liability as part of the technical retreat transaction (eg, when the retreat transaction occurs as a result of a technical issue in the payment procedure) and liability remains with the card issuer. In order to allow merchants to opt-in to allow payment transactions involving chip cards to be processed as swipe transactions, card issuers and various regulatory agencies may ensure that non-payment liability is converted to merchants. You may request. By accepting the card issuer's request to transfer responsibility to the merchant, the merchant is allowed to operate the payment terminal 20 in swipe mode, thereby achieving faster payment transaction processing and reduced checkout time. can do.

EMV/swipe mode instructions 226 may include instructions for causing payment terminal 20 to enter a swipe mode. In one embodiment, EMV/swipe mode instructions 226 may include instructions for determining when to enter swipe mode at merchant device 29. For example, merchant device 29 may respond to a request to enter swipe mode received at user interface 210 (eg, by user input at point-of-sale application 222) or to predetermined criteria (eg, queue size, transaction). The swipe mode may be entered in response to the determination that the frequency of () and the like) satisfy a threshold value. In one embodiment, the request to enter the swipe mode may be provided in response to a request for payment information at the user interface 210, or when a chip card is detected at the payment terminal 20, for example at the contact interface 104. May be.

In one embodiment, the EMV/swipe mode instruction 226 accepts an opt-in request or diversion of card issuer-to-merchant liability before allowing the payment transaction to proceed by performing a swipe mode step. The user may be requested to accept. If the user refuses to accept the opt-in request, processing of the payment transaction for which the request was provided follows normal processing behavior (eg, the chip card is processed through the chip card interface rather than the magnetic strip interface). May be continued). Upon acceptance of the opt-in request, merchant device 29 may be allowed to perform steps for processing payment transactions in swipe mode. The opt-in request may include any suitable information to display to the user in conjunction with the opt-in request, such as notice or disclosure of transfer of responsibility to the merchant, or other information. In one embodiment, the EMV/swipe mode instruction 226 determines when the user has provided a request via the user interface 210 or that the merchant is experiencing a large number of customers (eg, from sensors or cameras). (Based on information), when the time between payment transactions at the payment terminal falls below a threshold time, and the customer may experience a delay in completing the payment transaction at the payment terminal 20. Instructions may be included to provide an opt-in request in response to various events, such as other events shown.

In some embodiments, EMV/swipe mode instructions 226 may include instructions for processing swipe payment type electronic payment information as part of swipe mode operation. The user may provide a payment transaction request at user interface 210. In one embodiment, EMV/swipe mode instructions 226 may include instructions for receiving electronic payment information from a swipe payment card magnetic strip through swipe interface 105 in response to a payment transaction request at user interface 210. .. Electronic payment information may include information provided as part of a conventional swipe payment transaction, such as card issuer information and card and cardholder specific information.

EMV/swipe mode instructions 226 may include instructions for generating an indicator and associating with electronic payment information received during swipe mode. In some embodiments, EMV/swipe mode instruction 226 may generate a swipe mode indicator based on the payment terminal entering swipe mode. The swipe mode indicator may allow electronic payment information to be processed according to procedures for processing swipe payment types. Additionally, the swipe mode indicator may indicate that the transaction is not a technical backtrack transaction. Since the chip card is operating in swipe mode in the absence of technology recession, the indicator may also inform the payment server that the transaction should be processed as a swipe transaction requiring a transfer of responsibility to the merchant. Good. In one embodiment, EMV/swipe mode instruction 226 may generate an indicator that the payment card that provided the electronic payment information is a chip card. The payment card is a chip card indicator may be based on any suitable information received at the merchant device 29, including notification that the payment card is a chip card. In other embodiments, the indicator that the payment card is a chip card may be based on other information. In one embodiment, EMV/swipe mode instructions 226 provide instructions for associating electronic payment information received at the payment terminal during swipe mode with a swipe mode indicator and an indicator that the payment card is a chip card. May be included. In other embodiments, EMV/swipe mode instruction 226 may generate and associate other indicators.

In one embodiment, EMV/swipe mode instructions 226 may include instructions for processing payment transactions, along with swipe payment type electronic payment information provided by a payment card that is not a chip card. In this regard, the EMV/swipe mode instruction 226 may cause the merchant device 29 to receive a payment transaction request and swipe payment type electronic payment information from the swipe interface 105 of the payment reader 22. The EMV/swipe mode instruction 226 may cause the merchant device 29 to determine that the card that provided the electronic payment information is not a chip card and process the electronic payment information provided by the card according to a swipe protocol. In one embodiment, the swipe protocol may include steps for processing electronic swipe payment information using conventional methods (eg, responsibility to the merchant if the payment reader 105 is provided with a swipe-only card). Will not occur).

In one embodiment, the EMV/swipe mode instruction 226 is an instruction to allow normal processing of a payment transaction after a request to enter a swipe mode is accepted (eg, from one payment transaction to another payment transaction). May be included. For example, the merchant device 29 may determine that the condition that prompted the request to enter swipe mode has been removed or is no longer present. In one embodiment, such a determination is that the number of customers on the merchant's premises has fallen below a threshold, or that the time between payment transactions has exceeded a threshold time that was previously below. May be based on. At this point, the merchant device 29 may exit the swipe mode and return to normal processing of payment transactions. In one embodiment, EMV/swipe mode instructions 226 may include instructions for processing payment information from a chip card at contact interface 104 after entering swipe mode using normal payment processing. Requests for normal chip card processing may be provided from the user interface 210, and EMV/swipe mode instructions 226 provide electronic payment information from the chip card in the normal manner (eg, through communication with the chip card at the contact interface 104). May include instructions for processing. For example, the EMV/swipe mode instruction 226 may cause the merchant device 29 to receive payment information and send the electronic payment information to one or more payment servers. The EMV/swipe mode instruction 226 may accordingly receive the payment approval response at the communication interface (eg, wireless interface 214) of the payment terminal 20. In this regard, no transfer of liability occurs as part of the processing of electronic payment information from the chip card (eg, responsibility for payment transaction requests is not placed on the merchant).

EMV/swipe mode instructions 226 may include instructions for sending electronic payment information associated with a payment transaction request to one or more payment servers, eg, via wireless interface 214. The electronic payment information may be received at the merchant device 29 via normal processing or performing a swipe mode, one of a swipe mode indicator and an indicator that the card providing the electronic payment information is a chip card. The above may be included. EMV/swipe mode instructions 226 may include instructions for receiving a payment authorization response associated with electronic payment information sent to one or more payment servers. Thus, in an exemplary embodiment, for transmission of multiple electronic payment information, a payment authorization response associated with the electronic payment information may be received at a communication interface of payment terminal 20 (eg, at wireless interface 214). .. In some embodiments, the payment authorization response may be based on one or more of a swipe mode indicator and an indicator that the card that provided the electronic payment information is a chip card. In other embodiments, the payment authorization response may be based on other information.

In one embodiment, EMV/swipe mode instructions 226 include instructions for identifying a delay condition when transmission of electronic payment information to one or more payment servers should be delayed for a delay condition. But it's okay. The condition may be an event such as a loss of connection with one or more payment servers, a high volume of transactions, a slow connection, or any combination thereof. In some embodiments, EMV/swipe mode instructions 226 may include instructions for storing electronic payment information (eg, in memory 204) in response to identifying delay conditions. In one embodiment, the EMV/swipe mode instruction 226 causes the merchant device 29 to monitor the delay condition, and when the delay condition is resolved, the electronic payment information stored according to the delay condition is transferred to one or more payment servers. You may send it. In some embodiments, the delay condition may be a determination that the frequency of payment transactions (eg, at payment terminal 20) exceeds a threshold frequency. In some embodiments, the delay condition may include a connection speed between the payment terminal 20 (eg, merchant device 29) and one or more payment servers. In one embodiment, the threshold is any suitable value including merchant specific information, merchant type, merchant location, employee specific information, customer specific information, product type, time of day, or other information. It may be based on various information. In some embodiments, resolving the delay condition may include the frequency of payment transactions falling below a threshold. In some embodiments, resolving the delay condition may include the connection speed exceeding a threshold connection speed. In other embodiments, resolution of delay conditions may be based on any suitable information.

In certain embodiments, the capabilities assigned to merchant device 29 based on EMV offline instructions 224 and EMV/swipe mode instructions 226 may be combined. For example, if it is determined that the processing period of the payment transaction using the expedited processing mode based on the EMV offline instruction 224 exceeds a threshold, the merchant device 29 executes the EMV/swipe mode instruction 226 to pay the payment. You may try to reduce the transaction time. The determination is made using any suitable information about the transaction and the average duration of payment transactions performed using one or more of the expedited processing mode according to EMV offline instructions 224 and the swipe mode according to EMV/swipe instructions 226. May be based on. It will be appreciated that such capabilities may be combined in any suitable configuration to achieve the objectives described herein.

FIG. 5 illustrates an exemplary payment service system 50 of payment server 40 according to an embodiment of the disclosure. Although payment service system 50 is depicted as a single server, it will be appreciated that the operation and memory of payment service system 50 may be distributed over any suitable number of servers. Although particular components are depicted in particular configurations in FIG. 5, payment service system 50 may include additional components, and one or more of the components shown in FIG. 5 may be included in payment service system 50. It will be appreciated that it may not be necessary and that the components of payment service system 50 may be reconfigured in any suitable manner. It should be appreciated that in some embodiments, the payment service system 50 may include and have the necessary components to perform any of the functions herein that belong to the payment server 40. Let's do it. In one embodiment, payment service system 50 includes at least one processing unit 302, memory 304, interface bus 306, power supply 308, and communication interface 310.

In one embodiment, payment service system 50 includes a processing unit 302 and a memory 304 configured to control and perform required operations of payment service system 50. In some embodiments, processing unit 302 may be a high speed processor that executes operating system, program and application instructions for a server based on instructions that may be retained in memory 304. Memory 304 may include any suitable memory type or combination thereof as described herein, which retains instructions and other data and which may be used by operating system, programs and applications of payment service system 50. It is intended to provide working memory for execution. In some embodiments, the memory may include multiple sets of instructions including but not limited to operating instructions 320, payment processing instructions 322, EMV offline instructions 324, and EMV/swipe mode instructions 326.

The processing unit 302 may interact with and control one or more other components of the payment service system 50 by executing instructions in the memory 304. In some embodiments, processing unit 302 may use interface bus 306, although processing unit 302 may communicate with other components of payment service system 50 in any suitable manner. The interface bus 306 may include one or more communication buses such as I2C, SPI, USB, UART, and GPIO. In some embodiments, the processing unit 302 may execute instructions in the memory 304 and communicate with other components of the payment service system 50 via the communication bus of the interface bus 306 based on those instructions.

Payment service system 50 may also include a power supply 308. The power supply 308 may include power conversion circuitry to convert AC power and/or generate multiple DC voltages for use by components of the payment services system 50. In some embodiments, the power supply 308 may include a backup system, such as a battery backup, to avoid service interruption in the event of a power failure. Although not shown in FIG. 5 as being physically connected to other components of payment service system 50, power supply 308 provides various voltages to the components of payment service system 50 according to the requirements of the component. Good.

Payment service system 50 may also include communication interface 310. Communication interface 310 may include any suitable communication interface or combination thereof, but in some embodiments communication interface 310 may use a high speed communication interface such as WiFi, cellular, Ethernet, or optical fiber. The communication interface 310 secures a connection (for example, TLS) with the payment terminal 20 (for example, the payment reader 22 via the merchant device 29) for exchanging messages regarding transactions to be processed, firmware updates, application updates, and the like. Or via SSL). The communication interface 310 may also be in communication with other servers of the payment server 40, such as a payment server, which, in some embodiments, may be located remotely from the payment service system 50. It may be operated by an entity different from the entity that controls the system 50. For example, in some embodiments, payment service system 50 may be operated by an entity that provides one or more of payment reader 22, merchant device 29, or point of sale application 222. The payment server may be associated with and operated by one or more of the merchant, issuer, or customer bank.

The memory 304 may include operating instructions 320, payment instructions 322, EMV offline instructions 324, EMV/swipe mode instructions 326, and any other suitable instructions for operating the payment service system 50 (eg, one or more of the payment service systems 50). May include multiple sets of instructions for performing processing operations of payment service system 50, such as instructions regarding the operation of other applications or components of

Operating instructions 320 are any of payment service system 50, such as internal communication, power management, control of communication devices, control of other hardware of payment service system 50, any other suitable instruction, or any combination thereof. May include instructions for controlling the appropriate general-purpose behavior of the. In some embodiments, the operating instructions may provide instructions to the operating system of payment service system 50 along with most drivers, programs and applications running on payment service system 50.

Operating instructions 320 may also include instructions for interfacing with merchant device 29. In some embodiments, payment service system 50 may communicate with merchant device 29 via communication interface 310. The operating instructions 320, when executed by the processing unit 302, control these communications and provide instructions to provide secure communications by implementing procedures such as TLS, SSL or data encrypted based on keys. May be included.

Payment processing instructions 322 include instructions for processing payments and may also control the content of messages communicated to merchant device 29, payment reader 22 (eg, via merchant device 29), and/or payment server. Good. In certain embodiments, the payment processing instructions may include information about each of the payment reader 22 and the merchant device 29 having the point of sale application 222 installed. In addition to providing payment information, such as amount and credit card number, to the transaction processing system and performing payment processing functions such as returning a response to the merchant, the payment service system 50 also performs complex parsing of the merchant data. It may be implemented and used to provide reports, metrics, and other data to merchants (eg, merchants operating multiple merchant devices 29 at multiple locations). Payment processing instructions 322 may also include a shared secret key or a key of a public/private key pair for encrypting and decrypting data provided by one or more of payment device 10, payment reader 22, or merchant device 29. It may also include instructions for accessing the encryption key.

EMV offline instructions 324 may include instructions for processing an EMV offline payment authorization request received from payment terminal 20. EMV offline instructions 324 may include instructions for determining when to perform the steps for processing a payment authorization request. In one embodiment, the EMV offline instruction 324 causes the payment service system 50 to determine a time corresponding to the time indicated by the time indicator associated with the payment approval request and wait until that time before processing the payment approval request. May be started. In one embodiment, the EMV offline instruction 324 may include instructions for matching the time-of-day indicator of the payment authorization request with the time indicated by the electronic payment response, such as ARQC or cryptographic hash. In one embodiment, EMV offline instructions 324 may also include instructions for processing a payment authorization request at an arbitrarily assigned time if the time indicator is not specified by the ARQC or cryptographic hash of the electronic payment response. Good. In one embodiment, EMV offline instruction 324 causes payment service system 50 to provide the payment information included in the electronic payment response to the bank server for approval as soon as payment service system 50 receives the payment approval request. Or may wait until the time corresponding to the time indicator associated with the payment authorization request or its associated electronic payment response. In addition, EMV offline instructions 324 may include instructions for assigning an indicator to the payment authorization request indicating an occurrence of a transfer of liability as part of the payment transaction. In other embodiments, EMV offline instruction 324 may assign other information to the payment authorization request.

In one embodiment, EMV offline instructions 324 may include instructions for holding one or more payment authorization requests in memory 304 of payment service system 50 until transmission for processing at a bank server. .. The payment approval request is received at the communication interface 310 of the payment service system 50, at a time corresponding to a time associated with a time indicator of the payment approval request, and the number of payment approval requests received at the payment service system 50. May be sent to one or more bank servers at various times, such as when a threshold exceeds a threshold, at other times, and so on. In some embodiments, the time of transmission of the payment authorization request may be determined according to user input or any other suitable information.

In one embodiment, EMV offline instruction 324 may cause payment service system 50 to receive a payment authorization response (eg, from a bank server) and provide the response to payment terminal 20. The payment approval response may indicate whether the issuer approved or rejected the payment transaction based on the corresponding payment approval request. In certain embodiments, the payment authorization response may be based on a payment type indicator associated with the payment authorization request (eg, the payment authorization response is provided without the need for additional round trip communication with the chip card. Good). In this regard, the payment authorization response may indicate the rationale for the outcome of the payment authorization response (eg, why the bank server approved or rejected the associated payment authorization request).

EMV/swipe mode instructions 326 may include instructions for processing electronic payment information received from payment terminal 20. In one embodiment, the EMV/swipe mode instruction 326 is for determining that the electronic payment information was provided with an accompanying swipe mode indicator and an indicator that the card that provided the electronic payment information is a chip card. Instructions may be included. The EMV/swipe mode instruction 326 may cause the payment service system 50 to determine that the payment transaction has completed as a swipe mode transaction based on the payment information and the indicator. In one embodiment, the EMV/swipe mode instruction 326 causes the payment service system 50 to modify the indicator or assign the indicator to electronic payment information, the electronic payment information being one or more servers (eg, bank servers). May be sent for approval. In one embodiment, EMV/swipe mode instructions 326 include instructions for receiving a plurality of electronic payment information from payment terminal 20 and storing the plurality of electronic payment information for transmission to one or more servers. But it's okay. The EMV/swipe mode instructions 326 may further include instructions for sending a plurality of electronic payment information to one or more servers for approval.

In one embodiment, EMV/swipe mode instructions 326 may include instructions for receiving a payment authorization response to electronic payment information and sending the payment authorization response to payment terminal 20. In some embodiments, the payment authorization response may indicate whether the payment transaction was accepted or rejected by the card issuer. In some embodiments, the payment authorization response may be based on one or more of a swipe mode indicator and an indicator that the card that provided the electronic payment information is a chip card. In one embodiment, the indicator may include information indicating to one or more payment servers that the chip card provided swipe payment type electronic payment information. In this regard, the indicator may allow one or more servers to determine that a technological recession has not occurred and that the merchant has accepted the opt-in request and thus the responsibility for the payment request has been transferred to the merchant. In some embodiments, the indicator may indicate that the payment card that provided the electronic swipe payment information was not from a chip card, and the responsibility for the payment request remains with the bank or issuer. .. EMV/swipe mode instructions 326 may include instructions for receiving a payment authorization response and sending it to payment terminal 20. In some embodiments, the payment service system may repeat the process for each of the plurality of electronic payment information received at the payment service system 50 based on the EMV/swipe mode instruction 326.

Methods that may be implemented in accordance with the disclosed subject matter in light of the above configurations and devices will be better understood with reference to the flowcharts of FIGS. 6-8. Although the method is shown and described as a series of steps for the purpose of simplifying the description, such illustration or corresponding description is not limited to the order of the steps, and some steps may be performed herein. It should be understood and appreciated that they may occur out of the order shown and described and/or concurrently with other steps. Any non-sequential or branched flows illustrated via the flowcharts should be understood as an indication that various other branched or flow paths or order of steps that achieve the same or similar results can be implemented. Is. Moreover, not all illustrated steps may be required to implement the methodologies described below.

FIG. 6 illustrates an exemplary method for expedited processing of electronic payment transactions, according to an embodiment of the disclosure. In one embodiment, as shown in FIG. 6, a method of expedited processing of electronic payment transactions may be performed by a payment terminal 20 device (eg, described in the exemplary embodiment of FIG. 6). , Payment reader 22 and merchant device 29). Although in one embodiment these steps are depicted as being performed by a particular device, the assignment of steps between devices may be modified in any suitable manner, or the device performing the step. It will be appreciated that the number of may be changed in any suitable manner.

At step 602, a request to enter the expedited processing mode may be accepted at the user interface 210 of the merchant device 29 to process the payment transaction at the merchant device 29 and the payment reader 22 according to the expedited processing mode steps. In some embodiments, the request may be received as input from the user via the point-of-sale application instructions 222 displayed on the user interface 210. In some embodiments, when a payment transaction begins (eg, when a user opens point of sale application instruction 222, when payment device 10 is detected, when a customer provides input at payment reader 22, or Any combination of), the request may be generated in response to a message displayed to the user via the user interface 210. In one embodiment, the request is automatically generated in response to determining that the merchant device 29 is incommunicable with one or more payment servers, or based on other criteria such as transaction frequency or queue size. May be. After the request to enter the urgent processing mode is accepted, processing may continue to step 604.

At step 604, an opt-in request may be provided to the user interface 210 of the merchant device 29 in response to the request to enter the expedited processing mode being received at step 602. In one embodiment, the opt-in request may be displayed as a graphical message to the user at the user interface 210, selectable by the user to provide an input indicating whether the user accepts the opt-in request. It may include GUI elements. In one embodiment, the opt-in request is an opt-in request, such as information indicating that a transfer of responsibility to a merchant is required for a given transaction (eg, a chip card transaction) if the merchant enters an expedited processing mode. It may include disclosure or notification of the consequences of accepting or rejecting the request. After the opt-in request has been provided to the user interface 210, processing may continue to step 606.

At step 606, the merchant device 29 may determine whether the opt-in request was accepted. The determination may be made based on the input from step 604. In certain embodiments, the user may be allowed to perform steps in the expedited processing mode only if the user accepts the opt-in request. In one embodiment, if the user rejects the opt-in request, processing may continue to step 607, where processing of the payment transaction at merchant device 29 and payment reader 22 follows the steps of the normal transaction processing mode. (E.g., usually according to a chip card processing procedure). If the user accepts the opt-in request, processing may proceed to step 608.

At step 608, the merchant device 29 may enter an emergency processing mode and perform the remaining steps shown in FIG. At step 610, the first payment request information may be received at the user interface 210 of the merchant device 29. Payment requests may be provided as input from the merchant via the point of sale application 222 based on the merchant's and customer's progress in completing the transaction. The customer may then be prompted to insert the chip card into the payment reader 22, for example by means of a user interface or instructions provided by the merchant. After the payment request information is received, processing may continue to step 611.

In step 611, the merchant device 29 may provide the payment reader 22 with an electronic request for an electronic payment response from the inserted chip card. Chip cards perform risk management in response to requests for electronic payment responses and authorize transactions offline (eg, based on offline payment limits held on chip cards, in which case a transfer of liability is required). It is not necessary to process the transaction accordingly) or, if offline authorization is not available, an electronic payment response may be provided that includes the information required for an online authorization request according to the urgent payment protocol. In some embodiments, the payment response may include a certificate request cryptography or other similar information needed to perform online verification of the electronic payment request. After the request for electronic payment response is provided to the chip card and the chip card provides the associated electronic payment response, processing may continue to step 612.

At step 612, the merchant device 29 may store the electronic payment response received from the chip card in the memory of the merchant device 29 (eg, the memory 204 of the merchant device 29). In some embodiments, multiple electronic payment responses associated with multiple requests for electronic payment responses may be stored at any given time. For example, following receipt of the first electronic payment response associated with the first request at the merchant device 29, the merchant device 29 may request an additional electronic payment response and the additional electronic payment response associated with the additional request. Different responses may be received and stored on the merchant device 29. At this point, multiple electronic payment responses may be received and stored as a batch, one at a time, or any combination thereof. After the electronic payment response is stored in the memory of merchant device 29, processing may continue to step 614.

At step 614, the merchant device 29 may provide approval of the payment transaction if an electronic payment response for the payment transaction was provided. This approval may be based on standard EMV processing steps at merchant device 29, such as EMV processing performed during normal operation at merchant device 29. In the embodiment shown in FIG. 6, merchant device 29 may provide the authorization as an offline authorization without communicating the electronic payment response to the payment server. In certain embodiments, the merchant device 29 may provide notification (eg, at the user interface) for the user to prompt removal of the chip card from the chip card interface 104 following authorization. The user may remove the chip card before the transmission of information associated with the transaction, such as electronic payment response or other information. After the transaction approval is provided, processing may continue to step 616.

In other embodiments, although not depicted in FIG. 6, the merchant device may take the connection speed with the payment server, the average response time of the payment server, the elapsed time of the current transaction, the transaction volume, or the completion of the transaction. Provide offline authorization by monitoring parameters such as expected time or communicate with payment server to obtain authorization (eg, using standard payment protocol or urgent payment protocol) ) May be determined. In some embodiments, offline unapproved transactions may be processed in a manner that does not require transfer of responsibility to the merchant, in which case the transaction is not approved until a response is received, for example, from the payment server. However, the conditions may be calibrated so that these online transactions are required when the delay is unlikely to delay the transaction and is unlikely to be offensive to the merchant or customer. Therefore, under appropriate conditions, only some of the transactions may be processed with a transfer of liability.

Returning to the steps of FIG. 6, at step 616, the merchant device 29 may associate one or more indicators with each electronic payment response received in response to the request for electronic payment response. In some embodiments, the one or more indicators may include payment type indicators. The payment type indicator may indicate to one or more payment servers that one or more electronic payment responses are subject to processing according to an urgent payment protocol. According to the expedited payment protocol, the transaction may be approved or rejected by the payment server without the need for additional communication with the chip card. This allows the chip card to be removed early in the transaction and the electronic payment response to be stored in the payment reader or merchant device for later transmission to the payment server.

In some embodiments, the one or more indicators may include a time-of-day indicator associated with the payment authorization request. In some embodiments, a time-of-day indicator may be associated with each payment approval request and may correspond to a future transaction time. After one or more indicators are associated with each electronic payment response, processing may continue at step 618.

At step 618, the merchant device 29 may determine whether to send the payment authorization request to one or more payment servers. In one embodiment, this determination is performed by the merchant device 29 to determine whether the communication interface (eg, wireless interface 214) of the merchant device 29 can communicate with one or more payment servers. It may be based on a good check, or it may be based on other parameters such as communication speed or average transaction processing time. If the communication interface 214 is unable to communicate with one or more payment servers, or if the expected transaction time exceeds a threshold, the merchant device 29 may determine that the payment authorization request should not be sent yet. , Processing may continue to step 624. If the communication interface 214 is able to communicate with one or more payment servers, then the merchant device 29 may determine that it can send a payment authorization request and the process may continue to step 620.

At step 620, merchant device 29 may send one or more payment authorization requests and one or more indicators associated therewith to one or more payment servers. In certain embodiments, the merchant device 29 may determine when it is ready to send a payment authorization request based on a time-of-day indicator associated with the request. In some embodiments, the first payment authorization request may be sent before the additional electronic payment response is received at the merchant device 29. In certain embodiments, each payment authorization request may be sent at a time corresponding to the time of the time indicator associated with it. In certain embodiments, the merchant device 29 may send the payment authorization request and indicator before the time of the time-of-day indicator if the time-of-day indicator corresponds to a future time. In this regard, the time-of-day indicator may indicate that one or more payment servers should wait until the time corresponding to the time of the time-of-day indicator before processing the payment authorization request. In such an embodiment, the payment service system may forward the request to the bank server or issuer server of the payment servers at the time of the time-of-day indicator. Processing may continue to step 622 after the merchant device 29 sends one or more payment authorization requests.

At step 622, the merchant device 29 may receive one or more payment authorization responses from one or more payment servers in response to sending the one or more payment authorization requests. In some embodiments, the merchant device 29 may receive each payment authorization response via a communication interface (eg, wireless interface 214). In one embodiment, each payment approval response may be associated with each payment approval request sent from the merchant device 29. The merchant device may then process the received payment approval response, for example by storing a record of approvals and denials and providing a notification (eg, denial of transaction following transfer of liability).

As mentioned above, if the merchant device 29 cannot send the authorization request, processing may continue to step 624. At step 624, merchant device 29 may determine whether an additional payment request has been accepted, eg, at user interface 210 of merchant device 29. The user may make multiple subsequent payment transactions, each associated with a unique payment request. If the additional payment request is accepted, the process may return to step 610 and steps 610 to 618 may be repeated. If the additional payment request is not accepted, the process may return to step 618, where it determines if the approval request can be sent. Processing continues to traverse between these two states (eg, at regular intervals) until additional payment is required or an existing transaction is sent to the payment server for approval. Good.

FIG. 7 illustrates a non-limiting ladder diagram showing exemplary steps of an expedited processing of an electronic payment transaction, according to an embodiment of the disclosure. In one embodiment, as shown in FIG. 7, a method of expediting processing of electronic payment transactions includes a payment terminal 20 device (eg, a combination of payment reader 22 and merchant device 29), a payment service system 50, and May be performed by the bank server 60. Although in one embodiment these steps are depicted as being performed by a particular device, the assignment of steps between devices may be modified in any suitable manner, or the device performing the step. It will be appreciated that the number of may be changed in any suitable manner.

In step 702, the merchant device 29 provides a request for a first electronic payment response to the chip card 10 in response to the payment request. The payment request may be provided via the user interface 210 or the merchant device 29 and the chip card 10 may be inserted into the contact interface 104 of the payment reader 22, as described herein. The payment request may include the payment amount or other suitable information. After payment reader 22 receives the payment request, processing may continue to step 704.

At step 704, the payment reader 22 may request the electronic payment response from the chip card 10, and at step 706 the chip card provides the electronic payment response. As described herein, the electronic payment response may indicate that the chip card 10 refused to provide authorization for the transaction. In some embodiments, the chip card 10 may authorize the transaction and provide electronic payment information (eg, ARQC). At step 708, payment reader 22 may transfer the electronic payment information to merchant device 29. After the payment reader 22 transfers the electronic payment response from the chip card 10 to the merchant device 29, processing may continue to step 709.

At step 709, the merchant device 29 may provide the payment reader 22 with approval of the payment transaction if an electronic payment response for the payment transaction is provided. As described herein, authorization may be based on standard EMV processing steps at merchant device 29, or may be as an offline authorization without communicating the electronic payment response to the payment server. .. At step 710, the payment reader 22 may provide an authorization of the transaction to the chip card 10 indicating an authorization of the transaction to the chip card. As mentioned above, the merchant device may provide the user with a notification that the chip card 10 may be removed.

Exemplary steps performed by merchant device 29 and payment reader 22 as part of the expedited processing mode may be identified with reference to line 711. In the exemplary embodiment, the steps involving the expedited processing mode include the merchant device 29 and the payment reader without communicating with the payment service system 50 or the bank server 60, as depicted on the left side of line 711 in FIG. 22. The steps that may occur later to complete the approval of the expedited processing of the transaction are depicted in solid lines to the right of line 711 (eg, steps 712, 714, 716 and 718). Although communication with the payment card continues in normal operation mode after communication with payment service system 50 and bank server 60, the steps performed in this normal operation mode are depicted to the right of line 711 and are dashed. (Eg, steps 720, 722, 724, 726, 728 and 730). These steps are skipped in the urgent processing mode so that the chip card can be removed after step 710.

At step 712, merchant device 29 may provide one or more payment authorization requests to payment service system 50. As described previously herein, each payment authorization request may include one or more electronic payment responses and a payment type indicator associated with each one. In some embodiments, multiple payment approval requests may be sent in batches, for example, if the payment processing frequency falls below a threshold or if the connection speed exceeds a threshold. In one embodiment, as described above, each payment authorization request may also include a time indicator that corresponds to a transaction time (eg, a future time) and may indicate a time of transmission. At step 714, payment service system 50 may forward each of the one or more payment authorization requests it receives to bank server 60 for authorization. As mentioned herein, each of the one or more payment authorization requests may be sent at a time corresponding to the time of day of the time indicator. In some embodiments, payment service system 50 may wait until the time of day of the time indicator before sending the payment authorization request.

At step 716, payment service system 50 may receive at the communication interface of payment service system 50 one or more payment authorization responses provided by bank server 60. In some embodiments, each payment approval response may correspond to one of one or more payment approval requests provided to bank server 60 for approval in step 714. After payment service system 50 receives the payment authorization response from bank server 60, processing may continue to step 718.

At step 718, payment service system 50 may provide the one or more payment authorization responses received at step 716 to merchant device 29. As described herein, each authorization response may correspond to a particular payment authorization request obtained as part of a payment transaction. In this regard, the merchant device 29 may receive confirmation that the particular payment transaction has been approved or rejected by each corresponding bank server 60. After the payment authorization response is received at step 818, processing may continue at step 720.

As mentioned above, steps 720, 722, 724, 726, 728 and 730 may be performed during the normal operating mode where no urgent processing has occurred. As such, steps 720-730 would not occur in embodiments where merchant device 29 and payment reader 22 perform the steps of the expedited processing mode described herein. However, if the merchant device 29 and the payment reader 22 are not operating in the expedited processing mode, the merchant device 29 provides the payment authorization response to the payment reader 22 in step 720, and the payment reader 22 chips the payment authorization response in step 722. It may be transferred to the card 10. If the chip card 10 receives the payment authorization response, it may provide the receipt message to the payment reader 22 in step 724. In one embodiment, the received message may indicate confirmation that the chip card 10 has received the payment authorization response. In step 726, payment reader 22 sends the received message received from the chip card to merchant device 29. When the merchant device 29 receives the one or more received messages from the one or more chip cards 10, the process may proceed to step 728.

At step 728, the merchant device 29 may send one or more received messages from the chip card 10 to the payment service system 50. As described herein, the merchant device 29 may send the received message according to one or more relevant indicators, such as a time of day indicator. The payment service system 50 may send the received message to the corresponding bank server 60 in step 730. The process may then end.

FIG. 8 illustrates a non-limiting flow diagram illustrating exemplary steps for selectively processing electronic payment information through multiple interfaces, according to an embodiment of the disclosure. It will be appreciated that any suitable device may process electronic payment information, but in the exemplary embodiment, the transaction is completed by a payment terminal including merchant device 29 and payment reader 22. May be.

At step 802, a request to process a chip card payment transaction using according to the steps of swipe mode may be received at the user interface 210 of the merchant device 29. In some embodiments, the request may be received as input from the user via the point-of-sale application instructions 222 displayed on the user interface 210. In some embodiments, when a payment transaction begins (eg, when a user opens point of sale application instruction 222, when payment device 10 is detected, when a customer provides input at payment reader 22, or Any combination of), the request may be generated in response to a message displayed to the user via the user interface 210. In some embodiments, the request is automatically made based on the determination that the chip card has been inserted into the payment terminal 20, based on the frequency of transactions, based on the size of the queue, or other similar factors. May be generated. After the request to enter swipe mode is accepted, processing may continue to step 804.

In step 804, an opt-in request may be provided to user interface 210 of merchant device 29 in response to the request to enter swipe mode being accepted in step 802. In one embodiment, the opt-in request may be displayed as a graphical message to the user at the user interface 210, selectable by the user to provide input indicating whether the user accepts the opt-in request. It may include an indicator. In certain embodiments, the opt-in request may include disclosure or notice of the consequences of accepting or denying the opt-in request (eg, transfer of responsibility from card issuer to merchant), such as the card issuer or merchant or director. It may include information from government agencies or any combination thereof. After the opt-in request has been provided to the user interface 210, processing may continue to step 806.

At step 806, the merchant device 29 may determine whether the user accepted the opt-in request provided at step 804. The determination may be made based on the input from step 804. In some embodiments, the user may be allowed to perform steps in swipe mode only if the user accepts the opt-in request. In an embodiment, if the user rejects the opt-in request, processing may continue to step 807, where processing of the payment transaction at payment terminal 20 is in accordance with steps of a normal operating mode (eg, technical mode). Requesting that the chip card be inserted into the chip card interface of the payment reader 22 except under special circumstances, such as a retracted situation) If the user accepts the opt-in request, the process proceeds to step 808. You may move on to.

In step 808, the merchant device 29 may enter a swipe processing mode in which the chip card may be implemented as a magnetic strip card without first attempting to operate as a chip card. Processing may continue to step 810, where the first payment transaction request may be accepted at user interface 210 of merchant device 29. The payment request may be provided as input from the merchant via the point-of-sale application 222, which is an electronic payment information-based purchase progress (eg, progress of payment transaction to desired point, finalization of payment amount, etc.). It may indicate a request. After the payment transaction request is received, processing may continue to step 811.

At step 811, the merchant device 29 may receive swipe payment information from the payment reader 22. In one embodiment, payment reader 22 may read the magnetic strip of the swiped payment card through swipe interface 105. After electronic payment information of the swipe payment type in response to the payment transaction request is received at the merchant device, processing may continue to step 812.

At step 812, the merchant device 29 may determine whether the payment card that provided the electronic payment information of the swipe payment type is a chip card. In one embodiment, the merchant device 29 may determine whether the payment card is a chip card based on electronic payment information provided at the swipe interface 105 of the payment reader 22. If the merchant device 29 determines that the payment card that provided the electronic payment information of the swipe payment type is not a chip card, the process may continue at step 814, where the payment terminal 20 determines a normal swipe payment transaction. The protocol may be used to complete the payment process for the transaction. If the merchant device 29 determines that the payment card that provided the swipe payment type electronic payment information is a chip card, processing may continue to step 816.

At step 816, the merchant device 29 may generate an indicator and associate the indicator with the electronic payment information received during the swipe mode. In certain embodiments, the merchant device 29 may generate the swipe mode processing indicator based on the payment terminal entering the swipe mode. The swipe mode processing indicator may allow processing electronic payment information according to procedures for processing swipe payment types, and the transaction is not a technical recession transaction (eg, the transaction is a payment terminal chip card interface). It is not a transaction that has failed in the processing of the chip card in the above). Since the chip card is operating in swipe mode in the absence of technology recession, the swipe mode processing indicator should be processed by one or more payment servers as a swipe transaction requiring the conversion of responsibility to the merchant. You may let me know that there is. In some embodiments, the merchant device 29 may generate an indicator that the payment card that provided the electronic payment information is a chip card. The payment card is a chip card indicator is a notification received at the merchant device 29 that the payment card is a chip card (eg, following the determination in step 812 that the payment card is a chip card). May be based on any suitable information including. In an embodiment, the electronic payment information received at the payment terminal during the swipe mode may be associated with a swipe mode indicator and an indicator that the payment card is a chip card. After the indicators are generated and assigned, processing may continue at step 818.

At step 818, the merchant device 29 may determine whether an additional payment transaction request has been accepted, eg, via the user interface 210. If the merchant device 29 determines that the additional request has been accepted, the electronic payment and indicator may be stored for the current transaction and stored in memory, and the process may return to step 810. If the additional payment transaction request is not accepted, processing may continue to step 820, where merchant device 29 may identify a delay condition. In some embodiments, the delay condition identifiable by the merchant device 29 may be an event such as a loss of connection with one or more payment servers, a high volume of transactions, a slow connection, or any combination thereof. Good. In some embodiments, the delay condition may be a determination that the frequency of payment transactions (eg, at payment terminal 20) exceeds a threshold frequency. In some embodiments, the delay condition may include a connection speed between the payment terminal 20 (eg, merchant device 29) and one or more payment servers. If the merchant device 29 identified the delay condition at step 820, processing may continue at step 822. If no delay condition is specified, processing may continue to step 824.

At step 822, merchant device 29 may store electronic payment information and an indicator (eg, in memory 204) in response to identifying the delay condition. In one embodiment, the merchant device 29 may monitor the delay condition and, upon removal of the delay condition, send electronic payment information and indicators stored in memory to one or more payment servers. In some embodiments, resolving the delay condition may include the frequency of payment transactions falling below a threshold. In one embodiment, the threshold may be merchant specific information, merchant type, merchant location, employee specific information, customer specific information, connection speed, average approval time, product type, time of day, or other. Can be based on any suitable information, including Processing may continue to step 824 after the merchant device 29 determines that one or more delay conditions have been resolved.

At step 824, the merchant device 29 may send electronic payment information and associated swipe mode processing indicators to one or more payment servers, eg, via the wireless interface 214. The sent electronic payment information may be received at the merchant device 29 via performing a normal process or swipe mode, with a swipe mode indicator and an indicator that the card providing the electronic payment information is a chip card. It may include one or more of them. After electronic payment information and associated swipe mode processing indicators have been sent to one or more payment servers, processing may continue to step 826.

At step 826, the merchant device 29 may receive a payment authorization response for the electronic payment information. In certain embodiments, the merchant device 29 may receive payment authorization responses associated with electronic payment information sent to one or more payment servers. Thus, in an exemplary embodiment, for transmission of multiple electronic payment information, a payment authorization response associated with the electronic payment information may be received at a communication interface of payment terminal 20 (eg, at wireless interface 214). .. In some embodiments, the payment authorization response may be based on one or more of a swipe mode indicator and an indicator that the card that provided the electronic payment information is a chip card. The merchant device may then process the received payment approval response, for example by storing a record of approvals and denials and providing a notification (eg, denial of transaction following transfer of liability). The process may then end.

In one embodiment, a method for a payment terminal to process electronic payment information received from a chip card includes accepting a request to enter an expedited processing mode at a user interface of the payment terminal; Providing, in a user interface, an opt-in request in response to the request to enter the expedited processing mode, the user entering the expedited processing mode only if the opt-in request is accepted by the user. Is allowed. The method further includes accepting a first payment request at the user interface of the payment terminal and a processing element of the payment terminal requests a first electronic payment response from a first chip card in response to the first payment request. And checking whether the communication interface of the payment terminal can communicate with one or more payment servers, and if the communication interface cannot communicate with the one or more payment servers, the payment terminal In the memory of storing the first electronic payment response and authorizing a first transaction associated with the first electronic payment response. The method further includes accepting an additional payment request at the user interface, requesting an additional electronic payment response from an additional chip card by the processing element of the payment terminal, and the payment terminal of the payment terminal. The method may further include storing the additional electronic payment response in a memory and authorizing an additional transaction associated with the additional electronic payment response. The method further comprises storing the first electronic payment response and the additional electronic payment response, and after approving the first transaction and the additional transaction, the communication interface of the payment terminal may include the one or more payments. Determining that it is able to communicate with a server, and associating a payment type indicator with each of the first electronic payment response and the additional electronic payment response, the payment type indicator being the one or more payment servers. Associated with indicating that the first electronic payment response and the additional electronic payment response are subject to processing according to an expedited payment protocol. The method further comprises transmitting, from the communication interface of the payment terminal, the first electronic payment response, the additional electronic payment response, and the associated payment type indicator to the one or more payment servers. Then, the normal payment protocol requires each of the chip cards additional information for processing the transaction of the chip card, and the urgent payment protocol requires the one or more payment servers without the additional information. Processing a first transaction and the additional transaction, the first transaction and the additional transaction according to the urgent payment protocol after the first transaction and the additional transaction have been approved by the payment terminal. Processing, transmitting at one or more servers, and receiving, at the communication interface of the payment terminal, a payment authorization response associated with each of the first electronic payment response and the additional electronic payment response. Receiving the payment approval response based on the payment type indicator.

In an embodiment, the method further comprises associating a time-of-day indicator with the first electronic payment response and each of the additional electronic payment responses, each time-of-day indicator corresponding to a future transaction time. Sending each time-of-day indicator with an electronic payment response associated with it.

In one embodiment of the method, each time-of-day indicator and its associated electronic payment response is sent at a time corresponding to the time of day of the time-of-day indicator.

In certain embodiments of the method, each time-of-day indicator and its associated electronic payment response is sent prior to a time corresponding to the time of the time-of-day indicator, and the one or more payment servers include the time of day of the time-of-day indicator. Wait until the electronic payment response is processed.

In an embodiment, a method for a payment terminal to process electronic payment information received from a chip card in an urgent processing mode is to accept a first payment request at a user interface of the payment terminal; In response to a payment request, a processing element of the payment terminal requests a first electronic payment response to a first chip card via a chip card interface of the payment terminal; Storing an electronic payment response and approving a first transaction associated with the first electronic payment response. The method further includes accepting an additional payment request at the user interface, and in response to the additional payment request, the processing element of the payment terminal provides an additional electronic payment response to an additional chip card. Requesting via the chip card interface, storing the additional electronic payment response in the memory, and authorizing an additional transaction associated with the additional electronic payment response. May be further included. The method further comprises associating a payment type indicator with each of the first electronic payment response and the additional electronic payment response, the payment type indicator being associated with one or more payment servers. It may also include associating indicating that the additional electronic payment response is subject to processing according to an urgent payment protocol. The method can further store the first electronic payment response and the additional electronic payment response, and send a payment approval request to the one or more payment servers after approving the first transaction and the additional transaction. Determining that each payment authorization request is one of the first electronic payment response or the additional electronic payment response and a payment type indicator associated with each of the electronic payment responses. May be included, and transmitting the payment authorization request from the communication interface of the payment terminal to the one or more payment servers, the normal payment protocol is for each of the chip cards, Requesting additional information for processing the chip card transaction, the urgent payment protocol causing the one or more payment servers to process the first transaction and the additional transaction without the additional information, The first transaction and the additional transaction are processed at the one or more servers according to the urgent payment protocol after the first transaction and the additional transaction are approved by the payment terminal.

In an embodiment, the method further comprises: accepting a request to enter the expedited processing mode at the user interface of the payment terminal; and responding to the request to enter the expedited processing mode at the user interface of the payment terminal. And providing an opt-in request, the user is allowed to perform the steps of the emergency processing mode only if the opt-in request is accepted by the user.

In an embodiment, the method further comprises, after receiving the first payment response, checking whether the communication interface of the payment terminal is able to communicate with the one or more payment servers; and Sending the first electronic payment response from the communication interface to the one or more payment servers, if the communication interface is communicable, before receiving a typical electronic payment response.

In some embodiments of the method, determining that a payment authorization request is available includes determining that the communication interface of the payment terminal is able to communicate with the one or more payment servers.

In an embodiment, the method may further include, at the communication interface of the payment terminal, accepting a payment approval response associated with each of the payment approval requests, wherein the payment approval response is in the payment type indicator. Based on.

In one embodiment of the method, determining that the payment authorization request can be sent includes determining that the payment request frequency is less than a threshold.

In an embodiment, the method further comprises associating a time indicator with each payment approval request, each time indicator corresponding to a future transaction time, and associating each time indicator with its associated electronic payment response. Together with sending to the one or more payment servers.

In one embodiment of the method, each time-of-day indicator and its associated payment authorization request is sent at a time corresponding to the time of day of the time-of-day indicator.

In an embodiment of the method, each time-of-day indicator and its associated payment authorization request are sent before a time corresponding to the time of the time-of-day indicator, and the one or more payment servers include the time of day of the time-of-day indicator. Wait until the payment authorization request is processed.

In one embodiment, a payment terminal for processing wireless electronic payment information received from a chip card in an expedited processing mode includes a chip card interface, a communication interface configured to communicate with one or more payment servers, and a user. A user interface configured to receive a payment request from the chip card interface, the communication interface, and one or more processing elements connected to the user interface, the one or more processing elements being user interface instructions, urgent One or more processing elements configured to execute processing instructions and transaction processing instructions. The payment terminal may further comprise one or more memories configured to hold the user interface instructions, the expedited processing instructions and the transaction processing instructions, the user interface instructions being provided to the one or more processing elements as described above. Accepting a first payment request at the user interface and accepting an additional payment request at the user interface, wherein the urgent processing instruction directs the one or more processing elements to respond to the first payment request. Requesting a first electronic payment response from a first chip card via the chip card interface, storing the first electronic payment response in a memory of the payment terminal, and additionally via the chip card interface. An additional electronic payment response to the smart chip card, storing the additional electronic payment response in the memory, and paying each of the first electronic payment response and the additional electronic payment response Associating a type indicator, the payment type indicator indicating to one or more payment servers that the first electronic payment response and the additional electronic payment response are subject to processing according to an urgent payment protocol, Associating, wherein the transaction processing instruction authorizes the one or more processing elements to approve a first transaction associated with the first electronic payment response and is associated with the additional electronic payment response. The one or more payment servers after authorizing the additional transaction, storing the first electronic payment response and the additional electronic payment response, and authorizing the first transaction and the additional transaction. To determine that the payment approval request can be transmitted via the communication interface and to send the payment approval request to the one or more payment servers, and each payment approval request is sent to the first server. An electronic payment response or one of the additional electronic payment responses and a payment type indicator associated with each of the electronic payment responses, typically a payment protocol is provided for each of the chip cards. Request additional information to process card transactions, The expedited payment protocol allows the one or more payment servers to process the first transaction and the additional transaction without the additional information, the first transaction and the additional transaction including the first transaction and the additional transaction. Transaction is processed at the one or more servers according to the urgent payment protocol after being approved by the payment terminal.

In one embodiment of the payment terminal, the user interface instruction is further to the one or more processing elements, accepts a request from the user interface to enter the expedited processing mode, and enters the expedited processing mode at the user interface. Providing an opt-in request in response to the request, and allowing the user to perform the steps of the expedited processing mode only if the opt-in request is accepted by the user.

In an embodiment of the payment terminal, a transaction processing instruction is further provided to the one or more processing elements, the communication interface of the payment terminal being capable of communicating with the one or more payment servers after receiving the first payment response. Checking if there is, and prior to receiving the additional electronic payment response, the first electronic to the one or more payment servers via the communication interface if the communication interface is communicable. Sending a payment response and letting it take place.

In one embodiment of the payment terminal, determining that the payment authorization request can be sent includes determining that the communication interface of the payment terminal can communicate with the one or more payment servers.

In one embodiment of the payment terminal, a transaction processing instruction is further operative to the one or more processing elements to receive a payment authorization response associated with each of the payment authorization requests via the communication interface of the payment terminal. And the payment approval response is based on the payment type indicator.

In some embodiments of the payment terminal, determining that the payment authorization request can be sent includes determining that the frequency of payment requests is less than a threshold.

In one embodiment of the payment terminal, the transaction processing instruction further comprises associating with the one or more processing elements a time indicator for each payment authorization request, each time indicator corresponding to a future transaction time. , Sending each time-of-day indicator along with its associated electronic payment response.

In one embodiment of the payment terminal, each time-of-day indicator and its associated payment authorization request is sent at a time corresponding to the time of day of the time-of-day indicator.

In one embodiment of the payment terminal, each time-of-day indicator and its associated payment authorization request is sent prior to a time corresponding to the time of the time-of-day indicator, and the one or more payment servers Wait until time to process the payment approval request.

In some embodiments, the non-transitory computer readable storage medium may comprise instructions retained thereon, the instructions, when executed by one or more processors, provide the one or more processors with a payment terminal user interface. Accepting a first payment request via the card, requesting a first electronic payment response to the first chip card via a chip card interface in response to the first payment request, and storing the first electronic payment response in the memory of the payment terminal. An action is performed that includes providing an electronic payment response and approving a first transaction associated with the first electronic payment response. The operation further includes accepting an additional payment request via the user interface and providing an additional electronic payment response to the additional payment card in response to the additional payment request via the chip card interface. Further comprising: requesting, providing the additional electronic payment response to be stored in the memory, and authorizing an additional transaction associated with the additional electronic payment response. But it's okay. Acts further include associating a payment type indicator with each of the first electronic payment response and the additional electronic payment response, the payment type indicator being associated with the one or more payment servers. And indicating that said additional electronic payment response is subject to processing according to an urgent payment protocol, storing said first electronic payment response and said additional electronic payment response, said first transaction and After approving the additional transaction, determining that the payment approval request can be sent to the one or more payment servers, each payment approval request including the first electronic payment response and the additional electronic payment request. Determining one of the payment responses and a payment type indicator associated with each of the electronic payment responses. The method may further include providing a payment authorization request for transmission to the one or more payment servers via a communication interface of the payment terminal, the normal payment protocol being for each of the chip cards, the chip card. Requesting additional information for processing the first transaction, the urgent payment protocol causing the one or more payment servers to process the first transaction and the additional transaction without the additional information, the first transaction And the additional transaction is processed at the one or more servers according to the urgent payment protocol after the first transaction and the additional transaction are approved by the payment terminal.

In one embodiment, the instruction further causes the one or more processors to accept a request from the user interface to enter the urgent processing mode, and to instruct the user interface to enter the urgent processing mode. And providing an opt-in request, and the user is allowed to perform the steps of the emergency processing mode only if the opt-in request is accepted by the user.

In one embodiment, the instructions further cause the one or more processors to check, after receiving the first payment response, whether the communication interface is capable of communicating with the one or more payment servers. Prior to receiving the additional electronic payment response, providing the communication interface with the first electronic payment response to be transmitted to the one or more payment servers if the communication interface is available for communication. And an operation including

In one embodiment, determining that the payment authorization request can be sent includes determining that the communication interface of the payment terminal can communicate with the one or more payment servers.

In some embodiments, determining that the payment approval request can be sent includes determining that the frequency of payment requests is less than a threshold.

In one embodiment, the instruction is to further associate the one or more processors with a time indicator for each payment authorization request, each time indicator corresponding to a future transaction time, and each time indicator associated therewith. Providing the communication interface with the associated electronic payment response to be sent to the one or more payment servers.

In one embodiment, each time-of-day indicator and its associated payment authorization request are provided to the communication interface for transmission at a time corresponding to the time of day of the time-of-day indicator.

In one embodiment, each time-of-day indicator and its associated payment authorization request are provided to the communication interface for transmission prior to a time corresponding to the time of day of the time-of-day indicator and the payment server is configured to send the time-of-day indicator of the time-of-day indicator. The payment approval request is processed after waiting until the time.

In an embodiment, a method for a payment terminal to selectively process electronic payment information through a plurality of payment interfaces includes accepting a first payment transaction request at a user interface of the payment terminal, In the chip card interface, accepting first electronic payment information of the first electronic payment information type from the chip card in response to the first payment transaction request, and from the communication interface of the payment terminal to one or more payment servers. , Sending the first electronic payment information and receiving, at the communication interface of the payment terminal, a first payment authorization response to the first electronic payment information. The method further comprises: accepting a request to enter a swipe mode at the user interface of the payment terminal and providing an opt-in confirmation at the user interface of the payment terminal in response to the request to enter the swipe mode. And the payment terminal is allowed to enter the swipe mode only if the opt-in confirmation is accepted by the user, providing and accepting a second payment transaction request at the user interface of the payment terminal. Accepting second electronic payment information of a second electronic payment information type from a payment card in response to the second payment transaction request at a swipe interface of the payment terminal. The method further includes receiving, at the payment terminal, a notification that the payment card is a chip card, and at the payment terminal, the payment terminal has entered the swipe mode and swipe mode processing based on the notification. Generating an indicator, wherein the swipe mode processing indicator enables the second electronic payment information to be processed according to a procedure of the second electronic payment information type, generating the payment terminal. Sending the swipe mode processing indicator and the second electronic payment information from the communication interface to the one or more payment servers; and in the communication interface of the payment terminal, a second for the second electronic payment information. Receiving a payment authorization response, wherein the payment authorization response is based on the swipe mode processing indicator.

In one embodiment of the method, the swipe mode processing indicator indicates that the transaction is not a technical back-up transaction, and the technical back-up transaction is processed by the chip card at the chip card interface of the payment terminal. Indicates a failure.

In an embodiment, the method further comprises identifying a delay condition, wherein the transmission of the second electronic payment information should be delayed during the delay condition, and the payment terminal. Storing the second electronic payment information in the memory of, and transmitting the second electronic payment information based on the expiration of the delay condition.

In one embodiment of the method, the delay condition comprises a payment transaction frequency, and the expiration of the delay condition comprises the payment transaction frequency falling below a threshold value.

In one embodiment, a method for a payment terminal to selectively process electronic payment information through a plurality of payment interfaces includes accepting a request to enter a swipe mode at a user interface of the payment terminal, Providing in the user interface an opt-in confirmation in response to the request to enter the swipe mode, wherein the payment terminal is allowed to enter the swipe mode only if the opt-in confirmation is accepted by a user. And providing a payment transaction request at the user interface of the payment terminal, and a swipe payment type electronic payment from the payment card in response to the payment transaction request at the swipe interface of the payment terminal. Receiving information may be included. The method further comprises, at the payment terminal, generating a swipe mode processing indicator based on an indicator that the payment terminal has entered the swipe mode and that the payment card is a chip card. A processing indicator enables the electronic payment information to be processed according to the swipe payment type procedure, and from the communication interface of the payment terminal to the one or more payment servers, the swipe mode processing. Sending an indicator and the electronic payment information and receiving, at the communication interface of the payment terminal, a payment approval response to the electronic payment information, the payment approval response being based on the swipe mode processing indicator. Receiving may be included.

In an embodiment of the method, the swipe mode processing indicator indicates that the transaction is not a technical retreat transaction, the technical retreat transaction failing to be processed by the chip card at a chip card interface of the payment terminal. Indicates that you have done.

In an embodiment, the method further comprises identifying a delay condition, wherein the transmission of the electronic payment information should be delayed during the delay condition, and a memory of the payment terminal. Storing the electronic payment information in the. and transmitting the electronic payment information upon expiration of the delay condition.

In one embodiment of the method, the delay condition comprises a payment transaction frequency, and the expiration of the delay condition comprises the payment transaction frequency falling below a threshold value.

In an embodiment of the method, the delay condition comprises a connection speed between the payment terminal and the one or more payment servers, and the expiration of the delay condition comprises the connection speed exceeding a threshold value. ..

In an embodiment, the method further comprises receiving at the payment terminal a notification that the payment card is a chip card, wherein the indicator that the payment card is a chip card is in the notification. Based, may include receiving.

In an embodiment, the method further comprises accepting a second payment transaction request at the user interface of the payment terminal, and secondly at the swipe interface of the payment terminal in response to the second payment transaction request. Accepting electronic payment information of a swipe payment type from a payment card, determining that the second payment card is not a chip card, and converting the second payment card into a normal swipe card protocol based on the determination. Therefore, processing may be included.

In an embodiment, the method further comprises accepting a second payment transaction request at the user interface of the payment terminal, and receiving a second payment transaction request at the chip card interface of the payment terminal in response to the second payment transaction request. Accepting a second electronic payment information of a chip card payment type from a chip card, transmitting the second electronic payment information from the communication interface of the payment terminal to one or more payment servers, and the payment terminal Receiving a payment authorization response to the second electronic payment information at the communication interface of.

In an embodiment of the method, the responsibility of the first payment transaction request is left to the merchant operating the payment terminal and the responsibility of the second payment transaction request is not charged to the merchant.

In one embodiment, a payment terminal for selectively processing electronic payment information through multiple payment interfaces includes a swipe interface configured to receive swipe payment type electronic payment information from a magnetic strip payment card, and a chip. A chip card interface configured to receive electronic payment information from a card, a communication interface configured to communicate with one or more payment servers, and configured to accept requests to enter swipe mode, opt-in confirmation, and payment transaction requests User interface and one or more processing elements connected to the swipe interface, the communication interface and the user interface, the one or more processing elements comprising user interface instructions, swipe mode instructions, and transaction processing instructions. Is configured to perform. The payment terminal may further comprise one or more memories configured to hold the user interface instructions, the swipe mode instructions and the transaction processing instructions, the user interface instructions being provided to the one or more processing elements, Receiving a request to enter a swipe mode from the user interface, providing an opt-in confirmation to the user interface in response to the request to enter the swipe mode, and receiving a payment transaction request from the user interface, The swipe mode instruction allows the one or more processing elements to allow the payment terminal to enter the swipe mode only if the opt-in confirmation is accepted by the user; Generating a swipe mode processing indicator based on an indicator that the swipe mode has been entered and that the payment card is a chip card, the swipe mode processing indicator according to the swipe payment type procedure. Enabling, generating, and processing of information, the transaction processing instructions causing the one or more processing elements to perform the swipe payment type electronic from the payment card in response to the payment transaction request. Receiving payment information, sending the swipe mode processing indicator and the electronic payment information to the one or more payment servers via the communication interface, and receiving a payment authorization response to the electronic payment information. Receiving the payment approval response based on the swipe mode processing indicator.

In one embodiment of the payment terminal, the swipe mode processing indicator indicates that the transaction is not a technical retreat transaction and the technical retreat transaction is processed by the chip card at the chip card interface of the payment terminal. Indicates the failure.

In one embodiment of the payment terminal, the transaction processing instruction further comprises specifying a delay condition in the one or more processing elements, wherein the transmission of the electronic payment information should be delayed during the delay condition. One is to specify, to store the electronic payment information in the memory of the payment terminal, and to permit the transmission of the electronic payment information based on the expiration of the delay condition.

In one embodiment of the payment terminal, the delay condition comprises a frequency of payment transactions, and the expiration of the delay condition comprises the frequency of payment transactions falling below a threshold value.

In one embodiment of the payment terminal, the delay condition comprises a connection speed between the payment terminal and the one or more payment servers, and the expiration of the delay condition means that the connection speed exceeds a threshold value. Including.

In an embodiment of the payment terminal, the swipe mode instruction further comprises receiving, at the payment terminal, a notification that the payment card is a chip card, wherein the payment card is a chip card. The indicator includes receiving based on the notification.

In one embodiment of the payment terminal, the user interface instruction further causes the one or more processors to accept a second payment transaction request from the user interface, and the transaction processing instruction causes the one or more processors. Furthermore, accepting swipe payment type electronic payment information from a second payment card in response to the second payment transaction request from the swipe interface, and determining that the second payment card is not a chip card. Based on the determination, the second payment card may be processed according to a normal swipe card protocol.

In one embodiment of the payment terminal, the user interface instruction further causes the one or more processors to accept a second payment transaction request at the user interface, and the transaction processing instruction causes the one or more processors. Further, receiving second electronic payment information of a chip card payment type from the chip card in response to the second payment transaction request from the chip card interface, and one or more payment servers via the communication interface. To transmit the second electronic payment information and to receive a payment approval response to the second electronic payment information via the communication interface.

In one embodiment of the payment terminal, the responsibility of the first payment transaction request is borne by the merchant operating the payment terminal and the responsibility of the second payment transaction request is not borne by the merchant.

In some embodiments, the non-transitory computer readable storage medium may comprise instructions retained thereon, the instructions, when executed by one or more processors, cause the one or more processors to communicate with a user of the payment terminal. Accepting a request to enter a swipe mode from an interface and providing to the user interface of the payment terminal an opt-in confirmation in response to the request to enter the swipe mode, the payment terminal including the opt-in Only allowed to enter the swipe mode if confirmation is accepted by the user, providing, accepting a payment transaction request from the user interface of the payment terminal, and a swipe interface of the payment terminal. Via swiping payment type electronic payment information from the payment card in response to the payment transaction request. The operation further comprises, in the processing element, generating a swipe mode processing indicator based on an indicator that the payment terminal has entered the swipe mode and that the payment card is a chip card. A processing indicator enables the electronic payment information to be processed according to the swipe payment type procedure, the swipe for generation and transmission from the communication interface of the payment terminal to one or more payment servers. Providing a mode processing indicator and the electronic payment information. The operation may further include receiving, from the communication interface of the payment terminal, a payment authorization response to the electronic payment information, the payment authorization response being based on the swipe mode processing indicator.

In one embodiment, the swipe mode processing indicator indicates that the transaction is not a technical retreat transaction and the technical retreat transaction indicates that the chip card has failed to process at a chip card interface of the payment terminal. Indicates.

In one embodiment, the instruction further comprises specifying a delay condition to the one or more processors, wherein the transmission of the electronic payment information should be delayed during the delay condition. , Storing the electronic payment information in the memory of the payment terminal, and permitting the transmission of the electronic payment information based on the expiration of the delay condition may be performed.

In one embodiment, the delay condition comprises a payment transaction frequency, and the expiration of the delay condition comprises the payment transaction frequency falling below a threshold value.

In one embodiment, the delay condition includes a connection speed between the payment terminal and the one or more payment servers, and the expiration of the delay condition includes the connection speed exceeding a threshold value.

In one embodiment, the instruction is further to the one or more processors receiving a notification that the payment card is a chip card, the indicator indicating that the payment card is a chip card. Based on, the operation including receiving may be performed.

In one embodiment, the instruction further comprises: accepting a second payment transaction request from the user interface of the payment terminal, the swipe interface, in response to the second payment transaction request, from the one or more processors. Accepting electronic payment information of the swipe payment type from the second payment card, determining that the second payment card is not a chip card, and changing the second payment card to a normal swipe card based on the determination. Operations including processing according to the protocol may be performed.

In one embodiment, the instructions further cause the one or more processors to accept a second payment transaction request from the user interface of the payment terminal and to respond to the second payment transaction request via a chip card interface. And accepting the second electronic payment information of the chip card payment type from the second chip card, and the second electronic payment information for transmission from the communication interface of the payment terminal to the one or more payment servers. The operations may include providing and receiving a payment approval response to the second electronic payment information from the communication interface of the payment terminal.

In one embodiment, the responsibility for the first payment transaction request lies with the merchant operating the payment terminal and the responsibility for the second payment transaction request does not rest with the merchant.

The above is merely a description of the principles of the present disclosure, and those skilled in the art may make various modifications without departing from the scope of the present disclosure. The embodiments described above are presented for purposes of explanation and not limitation. The present disclosure can also take many forms other than those explicitly described herein. Therefore, this disclosure is not intended to be limited to the explicitly disclosed methods, systems and apparatus, but rather to include variations and modifications thereof within the scope of the following claims. Emphasize.

As a further example, modification of equipment or process parameters (eg, dimensions, settings, components, order of process steps, etc.) to further optimize the provided configurations, devices and methods shown and described herein. It can be performed. In any case, the configurations and devices described herein and related methods have many applications. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in scope in accordance with the appended claims.

Claims (8)

A method for a payment terminal to process electronic payment information received from a chip card in an expedited processing mode,
Accepting a first payment request at a user interface of the payment terminal;
A processing element of the payment terminal, in response to the first payment request, requests a first electronic payment response to a first chip card via a chip card interface of the payment terminal;
Storing the first electronic payment response in a memory of the payment terminal;
Approving a first transaction associated with the first electronic payment response;
Accepting additional payment requests at the user interface;
The processing element of the payment terminal in response to the additional payment request requests an additional electronic payment response to an additional chip card via the chip card interface;
Storing the additional electronic payment response in the memory;
Authorizing additional transactions associated with the additional electronic payment response;
Associating a payment type indicator with each of the first electronic payment response and the additional electronic payment response, the payment type indicator being associated with one or more payment servers. Indicating that the electronic payment response is subject to processing according to the expedited payment protocol;
After storing the first electronic payment response and the additional electronic payment response and approving the first transaction and the additional transaction, it is determined that a payment approval request can be sent to the one or more payment servers. Each payment authorization request includes one of the first electronic payment response or the additional electronic payment response and a payment type indicator associated with each of the electronic payment responses. , Judging,
Sending the payment authorization request from the communication interface of the payment terminal to the one or more payment servers,
The normal payment protocol requires each of the chip cards additional information for processing the chip card transaction, and the urgent payment protocol requires the one or more payment servers to perform the first transaction without the additional information. And processing the additional transaction, wherein the first transaction and the additional transaction are the one or more according to the urgent payment protocol after the first transaction and the additional transaction are approved by the payment terminal. How it is processed at the server. The method of claim 1, wherein determining that a payment authorization request can be sent comprises determining that the communication interface of the payment terminal can communicate with the one or more payment servers. At the communication interface of the payment terminal, further comprising receiving a payment approval response associated with each of the payment approval requests,
The method of claim 1, wherein the payment approval response is based on the payment type indicator. The method of claim 1, wherein determining that a payment authorization request can be sent includes determining that the frequency of payment requests is less than a threshold. Associating a time indicator with each payment authorization request, each time indicator corresponding to a future transaction time, and
The method of claim 1, further comprising sending each time-of-day indicator along with its associated electronic payment response to the one or more payment servers. The method of claim 5, wherein each time-of-day indicator and its associated payment authorization request are sent at a time corresponding to the time of day of the time-of-day indicator. Each time-of-day indicator and its associated payment authorization request are sent prior to a time corresponding to the time of the time-of-day indicator, and the one or more payment servers wait until the time of the time-of-day indicator before the payment authorization request. The method according to claim 5, wherein A payment terminal for processing wireless electronic payment information received from a chip card in an urgent processing mode,
Chip card interface,
A communication interface configured to communicate with one or more payment servers,
A user interface configured to accept payment requests from users,
One or more processing elements connected to the chip card interface, the communication interface, and the user interface, the one or more processing elements configured to execute user interface instructions, urgent processing instructions, and transaction processing instructions. , One or more processing elements,
One or more memories configured to hold the user interface instructions, the urgent processing instructions and the transaction processing instructions,
A user interface instruction causes the one or more processing elements to accept a first payment request at the user interface and an additional payment request at the user interface,
The urgent processing instruction requests the one or more processing elements to send a first electronic payment response to the first chip card via the chip card interface in response to the first payment request; and in the memory of the payment terminal. Storing a first electronic payment response, requesting an additional electronic payment response from an additional chip card via the chip card interface, and storing the additional electronic payment response in the memory. And associating a payment type indicator with each of the first electronic payment response and the additional electronic payment response, the payment type indicator being associated with one or more payment servers. Indicating that the electronic payment response is subject to processing according to the urgent payment protocol;
The transaction processing instructions authorize the one or more processing elements to approve a first transaction associated with the first electronic payment response and approve additional transactions associated with the additional electronic payment response. And storing the first electronic payment response and the additional electronic payment response and approving the first transaction and the additional transaction, then making a payment to the one or more payment servers via the communication interface. Determining that the approval request can be transmitted, and transmitting the payment approval request to the one or more payment servers,
Each payment authorization request includes one of the first electronic payment response or the additional electronic payment response and a payment type indicator associated with each of the electronic payment responses,
The normal payment protocol requires each of the chip cards additional information for processing the chip card transaction, and the urgent payment protocol requires the one or more payment servers to perform the first transaction without the additional information. And processing the additional transaction, the first transaction and the additional transaction according to the urgent payment protocol after the first transaction and the additional transaction are approved by the payment terminal. Payment terminal processed at the server.

Images