JP2019527873A - Urgent processing of electronic payment transactions - Google Patents

Abstract

The payment terminal may accept a request to process the electronic payment information from the chip card in an urgent processing mode. The payment terminal may provide an opt-in request. If accepted by the user, the payment terminal may accept the payment request and request an electronic payment response from the chip card. The payment terminal may receive an electronic payment response from the chip card and store it in the payment terminal's memory. The payment terminal may allow the chip card to be removed from the payment terminal by approving the payment transaction associated with the electronic payment response. The payment terminal may process additional payment requests and associate a payment type indicator and a time indicator with each electronic payment response. When the terminal determines that the approval request can be transmitted, the payment terminal may transmit an approval request to one or more payment servers and receive a payment approval response for each request. [Selection] Figure 1

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application benefits from the priority of US patent application Ser. No. 15 / 197,708, filed Jun. 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, filed June 29, 2016, entitled “Multi-Interface Processing of Electronic Payment Transactions”. That application is incorporated herein by reference.

  Electronic payments can be made in various ways. The payment terminal may process payment transactions and may interact with the payment device. Such devices include, for example, a payment card having a magnetic stripe swipe with a magnetic reader of the payment terminal, a payment device having a Europay / MasterCard / Visa (EMV) chip plugged into the corresponding EMV slot of the payment terminal, A device capable of near field communication (NFC), such as a smartphone or an EMV card, which taps on a payment terminal to transmit payment information via a secure wireless connection. The payment terminal may receive payment information along with information about the transaction from the payment device and may communicate this information to the payment system for processing the transaction.

  Sometimes, conditions can arise that prevent the payment terminal from communicating with the payment server to complete the payment transaction. Such a condition may be caused by a lack of communication link between the payment terminal and the payment server, such as a network connection failure. If not, the payment terminal will 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 long delays in the payment process if the payment terminal cannot complete the payment process until it can send payment information to the server. If the delay is long enough, the user at the payment terminal and the consumer trying to complete the payment transaction may not be able to tolerate. Delays during payment transactions can frustrate consumers trying to complete the transaction and reduce the merchant's transaction volume.

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

  The above and other aspects, properties and various advantages of the present disclosure will become apparent upon consideration of the following detailed description taken in conjunction with the accompanying drawings.

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

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

FIG. 4 shows an illustrative block diagram of a payment reader, in accordance with certain embodiments of the present disclosure.

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

1 illustrates an illustrative block diagram of a payment service system, in accordance with certain embodiments of the present disclosure. FIG.

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

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

FIG. 4 illustrates a non-limiting flow diagram illustrating an exemplary method for selectively processing electronic payment information through multiple interfaces, in accordance with certain embodiments of the present 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, a magnetic stripe card, or an NFC payment device. The merchant device provides a user interface for the merchant and has a point-of-sale application that communicates with the payment reader and 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, permission / denial) to the merchant device.

  The merchant device may accept a request for processing the electronic payment information from the chip card in the urgent processing mode in the user interface of the merchant device. In the urgent processing mode, the merchant device may process electronic payment transactions faster than with normal processing steps. Prior to entering the urgent processing mode, the merchant device may provide an opt-in request to the user interface. In some embodiments, the opt-in request may include information for the user, such as a notification or disclosure regarding the result 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 interface (eg, a 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 an electronic payment response from the chip card and store it in the merchant device's memory.

The merchant device may approve the payment transaction associated with the electronic payment response from the chip card. In some embodiments, the approval may be provided as “offline approval”. In certain embodiments, approval of a 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 and receive additional electronic payment responses from each corresponding chip card and store them in the merchant device's memory. In one embodiment, for each corresponding chip card providing an electronic payment response indicating approval (eg, including ARQC), the merchant device provides transaction approval to the chip card. May be. After the merchant device provides authorization for the payment transaction, the merchant device may associate a payment type indicator and a time indicator with each electronic payment response. The merchant device may send an approval request to one or more payment servers if the merchant device determines that the approval request can be sent. The payment type indicator may inform the payment server that the authorization request is subject to processing according to an urgent payment protocol. Thus, it is not necessary for the chip card to 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 exchange between the merchant and the customer occurs between the customer payment device 10 and the merchant payment terminal 20. A customer has a payment device 10 such as a credit card with a magnetic stripe, a credit card with an EMV chip, or an NFC enabled electronic device such as a smartphone that executes a payment application. The merchant has a payment terminal 20, such as a payment terminal or other electronic device. Such other electronic devices can 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 running.

  In some embodiments (eg, for low-priced transactions or payment transactions that are less than the payment limit indicated by the NFC or EMV payment device 10), the initial processing and approval of the payment transaction may be processed at the 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 certain embodiments, payment server 40 may include any suitable number of servers operated by any suitable entity, eg, payment It should be understood that service system 50 and one or more banks of merchants and customers (eg, bank server 60) may be included. Payment terminal 20 and payment server 40 exchange payment information and transaction information and determine whether to approve the transaction. For example, the payment terminal 20 may provide encrypted payment data, user authentication data, purchase amount information, and point of purchase information to the payment server 40 via the network 30. The payment server 40 determines whether to approve the transaction based on this received information and information about the customer account 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. The payment server 40 may also send additional information, such as a transaction identifier, to the payment terminal 20.

  Based on the information received from payment server 40 at payment terminal 20, 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, information about approved transactions and additional information (eg, receipts, special offers, coupons, loyalty program information, etc.) is provided to the NFC payment device. And may be displayed on the screen of a smartphone or watch or stored in memory.

  In some embodiments, payment server 40 may receive a plurality of payment authorization requests from payment terminal 20. As will be described in detail later, 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 urgent processing mode. Indicates that The payment server 40 also includes an indicator for checking from the payment terminal 20 the ability of the communication interface of the payment terminal 20 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 certain embodiments, payment server 40 may receive the payment authorization request and an associated time indicator and process the payment authorization 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 a payment device 10 and a payment terminal 20 according to an embodiment of the present disclosure. Although it will be appreciated that the payment terminal 20 and payment device 10 of the payment system 1 can be implemented in any suitable manner, in one embodiment, the payment terminal 20 includes a payment reader 22 and a merchant device 29. You may prepare. However, as used herein, it is understood that the term payment terminal may refer to the entire payment terminal 20 or any suitable component of the payment terminal 20 such as the payment reader 22 or merchant device 29. Will be done. In one embodiment, payment reader 22 of payment terminal 20 may be a wireless communication device that facilitates transactions between payment device 10 and merchant device 29 that executes a point-of-sale application.

  In some embodiments, payment device 10 may be a device capable of communicating with payment terminal 20 (eg, via payment reader 22), such as NFC device 12 or EMV chip card 14. The chip card 14 may include a secure integrated circuit. The integrated circuit can communicate with a payment terminal, such as payment terminal 20, can generate encrypted payment information, and comply with one or more electronic payment standards such as those published by EMVCo. The encrypted payment information and other payment or transaction information (eg, transaction limits for locally processed payments). The chip card 14 may include contact pins (eg, according to ISO 7816) for communicating with the payment reader 22, and in one embodiment, inductively coupled to the payment reader 22 via the near field 15. Also 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 in accordance with a wireless communication standard such as ISO 14443.

  The NFC device 12 may be an electronic device such as a smartphone, tablet, or smart watch that can perform a secure transaction with the payment terminal 20 (eg, via communication with the payment reader 22). The NFC device 12 is executed on a processor (e.g., a secure element including hardware and executable code) and / or software (e.g., according to a host card emulation routine) to perform a secure transaction function. 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 ISO 14443 and ISO 18092. You may communicate with the payment terminal 20 by active or passive load modulation of the signal.

  Payment terminal 20 may be implemented in any suitable manner, but in certain embodiments, payment terminal 20 may include payment reader 22 and merchant device 29. Merchant device 29 executes a point-of-sale application that provides a user interface for the merchant and facilitates communication with payment reader 22 and 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 near field 15 in FIG. This near field 15 includes a radio carrier signal having an appropriate 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 communicate information to the payment device 10, the payment reader 22 changes the amplitude and / or phase of the wireless carrier signal based on the data to be transmitted from the payment reader 22, so that the wireless transmitted to the payment device. A data signal is generated. This signal is transmitted by the antenna of the payment reader 22 tuned to transmit at 13.56 MHz, and the payment device 10 also has an 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 the wireless data signal transmitted by the payment reader 22. In the case of a wireless data signal, the processing circuit of the payment device 10 can demodulate the received signal and process the data received from the payment reader 22.

  If a contactless payment device, such as payment device 10, is within range field 15, it is inductively coupled with payment reader 22. Accordingly, the payment device 10 can also modulate the radio 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, thereby generating a modulated radio 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 with 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 a communication path established by these contacts.

  The payment reader 22 may also include hardware that interfaces with the magnetic stripe card (not shown in FIG. 2). In one embodiment, 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 can receive payment information from the magnetic stripe card. . The received payment information is then processed by the payment reader 22.

  Merchant device 29 may be any suitable device such as tablet payment device 24, mobile payment device 26, 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, a payment application may provide a service menu from which a merchant can select and a series of menus or screens for automating transactions. The payment application may also facilitate the input of customer authentication information such as a signature, PIN number, biometric information. A similar function may be provided to the dedicated payment terminal 28.

  Merchant device 29 may communicate with 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 some implementations In this form, the payment reader 22 may communicate with the merchant device 29 via a Bluetooth throw energy interface, in which case the payment reader 22 and the merchant device 29 are connected devices. In certain 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, merchant device 29 or payment reader 22 may communicate with payment server 40 via public or private communications network 30. Although communication network 30 may be any suitable communication network, in one embodiment, communication network 30 may be the Internet, and payment and transaction information may be exchanged between payment terminal 20 and payment server 40. Communication may be performed in encrypted form, for example, using Transport Layer Security (TLS) or Secure Socket Layer (SSL) protocol.

  FIG. 3 shows a block diagram of an exemplary payment reader 22 according to an embodiment of the present disclosure. In one embodiment, payment reader 22 may be a wireless communication device that wirelessly communicates with a bi-directional electronic device, such as merchant device 29, using, for example, Bluetooth Classic or Bluetooth Slow Energy. Although specific components are depicted in a specific configuration in FIG. 3, the payment reader 22 may include additional components, and one or more of the components shown in FIG. It will be appreciated that the components of the payment reader 22 may be reconfigured in any suitable manner. In one embodiment, payment reader 22 includes a reader chip 100, a plurality of payment interfaces (eg, contactless interface 102, contact interface 104, and swipe interface 105), power supply 106, wireless communication interface 108, wired Interface 110 and transaction chip 114 are included. The payment reader 22 also includes a processing unit 120 and a memory 122 within the reader chip 100, and a general purpose processing unit 124, an encryption processing unit 125, a general purpose memory 126, and an encryption memory 128 within the transaction chip 114. In one embodiment, processing unit 120 and memory 122 are described as being packaged in and configured in a specific manner with reader chip 100 and transaction chip 114, respectively. It is possible to perform the functions of the payment reader 22 as described herein by configuring the unit 124, the encryption processing unit 125, the memory 122, the general purpose memory 126, and the encryption memory 128 in any suitable manner. Will be understood. The functionality of the reader chip 100 and transaction chip 114 can be implemented on a single chip or on multiple chips, each including any suitable processing unit and memory combination, and together herewith. It will be understood that it performs the functions of the reader chip 100 and transaction chip 114 described in FIG.

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

  In certain embodiments, the reader chip 100 may be any suitable chip, such as a 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 includes hardware, software, memory, and circuitry as long as necessary to perform 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 and memory types. In some embodiments, the processing unit 120 may include multiple independent processing units such as multi-core processors and other similar components. The processing unit 120 may control the operation and processing of the payment reader 22 by executing instructions held in the memory 122 of the reader chip 100. As used herein, a processor or processing unit may include one or more processors having the processing capabilities necessary to perform the processing functions described herein, eg, hardware logic (eg, Including, but not limited to, hardware designed by hardware describing language such as hardware description language (HDL), computer readable instructions executed by the processor, and any suitable combination thereof. The processor may execute software to perform the operations described herein, such software being accessed in machine readable form on a tangible non-transitory computer readable storage medium. including.

  In the exemplary embodiment, processing unit 120 of reader chip 100 is configured to operate as a hub for controlling the operation of various components of payment reader 22 based on instructions held in memory 122. Two RISC processors may be included. As used herein, memory may refer to any suitable tangible or non-transitory holding medium. Examples of tangible (or non-transitory) holding media include a disk, a thumb drive, and a memory, but no transmission signal. Substantial computer-readable storage media include volatile and non-volatile, 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 media that holds information accessed by a processor or computing device including.

  The reader chip 100 may also include additional circuits such as an interface circuit, an analog front end circuit, a security circuit, and a component monitoring circuit. In one embodiment, the interface circuit includes a circuit that interfaces with a wireless communication interface 108 (eg, Wi-Fi, Bluetooth Classic, Bluetooth Slow Energy) and a wired interface 110 (eg, USB, Ethernet, Firewire, and A circuit that interfaces with a lightning), a circuit that interfaces with other communication interfaces or buses (for example, I2C, SPI, UART, and GPIO), and a circuit that interfaces with a power source 106 (for example, a power management circuit, Power conversion circuit, rectifier, and battery charging circuit).

  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, and any of them. Including, but not limited to, an appropriate combination. In the exemplary embodiment, transaction chip 114 may perform functions related to payment transaction processing, payment device interface, encryption, and other payment specific functions. In some embodiments, transaction chip 114 may include a general purpose processing unit 124 for executing instructions associated with the general purpose payment function and an encryption processing unit 125 for handling encryption processing operations. Each of the general purpose processing unit 124 and the encryption processing unit 125 may have dedicated memory (ie, general purpose memory 126 and encryption memory 128) associated therewith. In this aspect, certain encryption processing and critical security information (eg, encryption key, password, user information, etc.) can 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 encryption processing unit 125 of the transaction chip 114 may communicate with the reader chip 100 (eg, the processing unit 120) using, for example, any suitable internal bus and communication technology. In this aspect, reader chip 100 and transaction chip 114 may process a transaction and communicate information (eg, to merchant device 29) regarding the processed transaction.

  Transaction chip 114 may also include circuitry for interfacing with contact interface 104 (eg, a power supply and communication circuit for directly interfacing with the EMV chip of chip card 14 inserted in slot 21). In some embodiments, transaction chip 114 also includes analog front-end circuitry (eg, electromagnetic matching (EMC) circuitry, matching circuitry, modulation circuitry, and measurement circuitry) that interfaces with analog components of contactless interface 102. But you can.

  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 the carrier signal modulated according to a modulation procedure such as ISO 14443 or ISO 18092. When the payment reader 22 inductively couples with the contactless device, the contactless device also modulates the carrier signal, and the modulated signal is detected by the contactless interface 102 and provided to the reader chip 100 for processing. Also good. Based on this modulation of the carrier signal, payment reader 22 and contactless device can communicate information such as payment information.

  The contact interface 104 may be a suitable interface for powering and communicating with a payment chip, such as an EMV chip on the chip card 14. The contact interface 104 may include a plurality of contact pins (not shown in FIG. 3) that provide a physical interface with the chip card 14 in accordance with 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 the EMV card, a clock (CLK) pin for providing a clock signal, and an EMV. 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 may be included. 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 a chip card interface (eg, a card slot) of the contact interface 104. May be. In an exemplary embodiment, the chip card detection circuit is suitable hardware (eg, a switch, an optical detection circuit, a proximity sensor, etc.) for detecting the presence of a chip card in the card slot of the 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, the swipe interface 105 may communicate with the transaction chip 114 and electronic payment information received when the user swipes the magnetic strip through the swipe interface 105 is sent to the 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 the payment card and for providing that information to transaction chip 114.

  In certain embodiments, the general purpose processing unit 124 may include any suitable processor for performing the payment processing functions of the payment reader 22 described herein. In some embodiments, 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, and the like.

  The transaction processing instruction 166 controls the interaction between the payment reader 22 and the payment device 10 (eg, to interface with the payment device via the contactless interface 102 and the contact interface 104), Such as selecting a payment processing procedure (eg, based on the payment processing entity associated with the payment method), interfacing with the cryptographic processor 125, and any other suitable aspect of transaction processing, Instructions for controlling the general transaction processing operation of the payment reader 22 may be included.

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

  Signal conditioning instructions 170 may include instructions for conditioning 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 signals received via the contactless interface 102, and the signal conditioning instructions 170 may be received via the contactless interface 102. Instructions may be included to condition the signal using any suitable hardware, logic, or algorithm required to process the signal.

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

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

  The wireless communication interface 108 participates in wireless communication with appropriate wireless communication hardware (eg, antenna, etc.) and a merchant device 29 (eg, via a protocol such as Bluetooth slow energy) and controls related circuitry. One or more processors having the necessary processing power, and associated circuitry includes, but is not limited to, hardware logic, computer readable instructions executed by the processor, or any suitable combination thereof. Although the wireless communication interface 108 may be implemented in any suitable manner, 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.

  The 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 source 106 may include a power conversion circuit for converting AC or DC power into a plurality of DC voltages for use by 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 depicted in FIG. 3 as being physically connected to other components of the payment reader 22, the power supply 106 may supply various voltages to the components of the payment reader 22 according to component requirements. .

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

  The memory 122 of the leader 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 instruction 130 is a payment reader for internal communication, power management, message processing, system monitoring, sleep mode, user interface response and control, operation of the radio interface 108, operation of the transaction chip 114, and management of other sets of instructions. Instructions for controlling the 22 general-purpose operations may be included. In some embodiments, the operating instructions 130 may provide the operating system and applications necessary to perform most of the processing operations performed by the processing unit 120 of the leader chip 100 of the payment reader 22.

  Operating instructions 130 may also include instructions for interfacing with merchant device 29. In some embodiments, merchant device 29 may be running a point-of-sale application. The operating instructions 130 may include instructions for complementary applications executed by 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, adding tips, and other related functions. When it is time to receive payment, the point-of-sale application may send a message to payment reader 22 (eg, via wireless interface 108). The operating instruction 130 obtains payment information via, for example, the contactless interface 102 or the contact interface 104, invokes the transaction chip 114 to process the payment information, and points through the merchant device via the wireless interface 108. Facilitate payment processing by generating response messages that are transmitted to the application.

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

  Transaction processing instructions 132 may include instructions for processing payment transactions at payment reader 22. In certain embodiments, transaction processing instructions may conform to payment standards such as those published by EMV. Depending on the payment method in use (eg Europay, MasterCard, Visa, American Express, etc.), a specific processing 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 payment information from the payment device, Decide how to process, determine which encryption functions to perform, determine the communication type to exchange with the payment server, and determine any other suitable information regarding the processing of payment transactions Good. In some embodiments, transaction processing instructions 132 may perform higher-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, the transaction processing instruction 132 is a preliminary for processing by the payment reader 22 until the payment transaction is complete (eg, in a point-of-sale application executed on a merchant device 29 that communicates with the payment reader). Instructions may be included for handling transactions intended to provide charges to the chip card. In some embodiments, the preliminary charge or multiple preliminary charges may provide a dummy charge amount for the chip card to generate an authentication response (eg, an authentication response cipher). Depending on when the precharge request is received from the merchant device, this authentication response is returned to the merchant device (eg, via the wireless interface 108 or the wired interface 110) before the merchant completes the payment transaction. May be.

  In some embodiments, it may be 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 authorization based on transaction processing instructions 132 by a chip card. The leader chip 100 may receive each of the plurality of preliminary payment amounts in a message from, for example, the point-of-sale application in the merchant device 29 or the payment server 40. As will be described in detail below, in some embodiments, a plurality of preliminary payment amounts may be arbitrarily determined and provided to payment reader 22 for use by reader chip 100. As described in more detail below, in other embodiments, a plurality of preliminary payments may be derived based on a prediction technique using historical data of the merchant device 29, and in some embodiments, the prediction Alternatively, data from another payment terminal 20 may be used. Transaction processing instructions 132 may include instructions for continuing to provide a preliminary charge until an actual payment amount is received (eg, processing of payment information from a payment transaction is complete).

  In other embodiments, the 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 the indicator and the priority assigned thereto. Instructions for storing the degree in a memory such as memory 122 may be included. In this regard, the reader chip 100 may increase or decrease the priority of the precharge request based on the indicator. In some embodiments, the leader chip 100 may obtain approval for each precharge request in order of priority (eg, prioritization from highest to lowest). In one embodiment, the transaction processing instruction 132 assigns a priority proportional to a score assigned to the preliminary payment amount that indicates the probability that the preliminary payment amount matches the actual payment amount of the transaction. Instructions for assignment may be included. In yet another embodiment, the leader 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 to set its priority. May be raised or lowered.

  Transaction processing instructions 132 may include instructions for collecting information other than payment information before charging is initiated during the payment transaction. For example, if a chip card is inserted into the contact interface 104, but before the transaction chip 114 requests electronic payment information (i.e., charge) from the card, the reader chip 100 determines the chip card details and consumption. Other information necessary 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, chip card expiration date and other information May be collected. In addition, the transaction processing instructions 132 may include instructions for determining information about the customer using the payment device, including information identifying the customer, transaction history, and other information. In one embodiment, the transaction processing instruction 132 may request instructions for collecting any appropriate information from the payment device 10 before requesting electronic payment information or otherwise initiating charging at the payment device 10. May be included.

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

  Although specific components are depicted in a specific configuration in FIG. 4, the merchant device 29 may include additional components, and one or more of the components shown in FIG. 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.

  In one embodiment, merchant device 29 includes a processing unit 202 and memory 204 configured to control and perform the required operations of merchant device 29. In certain 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 stored in memory 204. The memory 204 may include any suitable memory type or combination thereof as described herein, which holds instructions and other data, and executes the operating system, programs and applications of the merchant device 29 For example, a flash memory or a RAM memory is provided. 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.

  Processing unit 202 may interact with and control one or more other components of merchant device 29 by executing instructions in memory 204. Although the processing unit 202 may communicate with other components of the merchant device 29 in any suitable manner, in some embodiments the processing unit may use the interface bus 206. The interface bus 206 may include one or more communication buses such as I2C, SPI, USB, UART, and GPIO. In some 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 source 208. The power source 208 may include power conversion circuitry for converting AC power and / or for generating multiple DC voltages for use by components of the merchant device 29. If the power source 208 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 depicted in FIG. 4 as being physically connected to other components of the merchant device 29, the power supply 208 may supply various voltages to the components of the merchant device 29 according to component requirements. .

  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 includes hardware and software for any suitable user interface, 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 some embodiments, user interface 210 may be a touch screen interface that displays an interactive user interface for applications and programs, such as point-of-sale applications running on merchant device 29.

  Merchant device 29 may also include multiple wireless communication interfaces. Wireless communication interface to provide wireless communication interfaces such as Bluetooth Classic, Bluetooth Slow Energy, WiFi, Cellular, Short Message Service (SMS), NFC, any other suitable wireless communication interface or any combination thereof Any suitable hardware and software may be included. In some embodiments, the first wireless communication interface 212 may be a wireless communication interface (eg, Bluetooth slow energy interface) that primarily communicates with the payment reader 22, while the second wireless communication interface 214 is primarily a payment server 40. It may be a 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 another device or communication network, such as USB, Lightning, Firewire, Ethernet, any other suitable wired communication interface, or any combination thereof. Any suitable interface for wired communication with the device may be included.

  The operating instructions 220 include internal communication, power management, I / O device control, communication device control, other hardware control of the merchant device 29, any other appropriate instructions, and any combination thereof. Instructions for controlling any suitable general purpose operation of the merchant device 29 may be included. 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 in accordance with 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 with the payment service system 50 of the payment server 40 and for interfacing with the payment reader 22. The application running on the payment reader 22 and / or the merchant device 29 may be known to the payment service system 50 (eg, via a registration process), in which case the merchant device 29 receives the point-of-sale application instructions 222. The payment service system 50 may process the payment.

  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 allows merchants to process payment transactions with customers. These instructions allow merchants or customers to select purchases, calculate sales taxes, process tips, provide receipts, generate discounts and special offers, It may include a customized interface that enables processing of customer loyalty programs, inventory and delivery searches for items, and any other suitable retail operations. In certain embodiments, point-of-sale application instructions 222 may include instructions for providing a rich display of information regarding emergency processing modes, such as EMV offline mode or EMV / swipe mode.

  In certain embodiments, the point-of-sale application instruction 222 may include instructions for processing a request to enter an urgent processing mode. In certain embodiments, the point-of-sale application instruction 222 may receive a request from the user to enter an urgent processing mode, eg, via the user interface 210. In the exemplary embodiment, various conditions may arise that make it impossible to process payment transactions using normal procedures. For example, the connection between the payment terminal 20 and the payment server 40 is lost, and the payment terminal 20 becomes unable to communicate with the payment server 40. As described below, entering the urgent processing mode allows the merchant device 29 to continue processing payment transactions until the connection between the payment terminal 20 and the payment server 40 is restored. In addition, during peak transaction hours, or when a large group visits a merchant location and waits long for a customer making a purchase to experience a long queue or provide payment to leave the merchant's store During this time period, normal processing operations will be impractical. By entering the 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 the payment device with the magnetic strip.

  In some embodiments, point-of-sale application instructions 222 may include instructions for accepting input from the user at 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 urgent 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 urgent processing mode. At this point, the user may accept or reject 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 urgent 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. Also good.

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

  In certain embodiments, the point-of-sale application instruction 222 may include instructions for providing various notifications to the processing element 202 of the 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 being processed in an urgent processing mode according to an urgent payment protocol. In some embodiments, the processing unit 202 may execute the steps in the urgent processing mode in response to the notification. In some embodiments, the notification may include an indication of why the transaction is being processed as a swipe mode transaction. For example, since a request to enter the swipe mode is received and the user has accepted the opt-in request, payment information is received by reading the magnetic strip at the swipe interface 105, and a transaction due to a chip card reading failure at the payment terminal 20 The notification indicates that this is not the case, for example, if the payment reader 22 is unable to read the EMV chip and therefore allows the user to swipe the chip card. May be. In other embodiments, the notification may provide other information in response to the user accepting the opt-in request.

  The EMV offline instructions 224 may include instructions for entering the EMV offline mode at the merchant device 29 and processing payment information from the payment device 10 (eg, a chip card) in the EMV offline mode. In certain embodiments, EMV offline instruction 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 one or more payment servers when the user accepts an opt-in request at the user interface 210. If the processing unit 202 determines that the communication latency between the merchant device 29 and the payment server 40 exceeds a threshold, or depending on other events or other criteria, the EVM offline mode is entered. Also good.

  In one embodiment, the EVM offline instruction 224 may include instructions for processing electronic payment information from the chip card as part of the 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 or other similar processing operation using Visa® QuickChip for EMV®. May include aspects of an existing EMV processing task for. For example, in one embodiment, the EVM offline instruction may request and receive electronic payment information from the 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 the chip card at the chip card interface 104 of the payment reader 22. In certain embodiments, a request for an electronic payment response may be provided in response to a first payment request received at point of sale application 222 or elsewhere.

  In certain embodiments, the EMV offline instruction 224 may include instructions for receiving an electronic payment response. In some embodiments, 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 and refuse to approve the transaction offline or provide the information necessary for an online authentication request. In some embodiments, the information provided by the chip card may include an authentication request cipher (“ARQC”) or other similar information necessary to perform online authentication of an electronic payment request. In certain embodiments, other steps for receiving an electronic payment response from payment reader 22 may be performed.

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

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

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

  The EMV offline instruction 224 may include instructions for performing the aforementioned steps when an additional payment request is received at the merchant device 29. In some embodiments, the EMV offline instruction 224 may request an additional electronic payment response in response to the additional payment request at the user interface, store the additional electronic payment response in the memory 204, and Instructions may be included to approve additional transactions associated with the electronic payment response. These steps may be repeated as necessary for payment requests accepted at the user interface 210 of the merchant device 29.

  In some embodiments, the EMV offline instruction 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 urgent payment protocol. Under an urgent payment protocol (eg Visa quick chip), the transaction 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 (e.g., after an electronic payment response has been sent, at a specific stage of the transaction or upon preliminary approval by the merchant device). In addition, the payment authorization request may include an indicator that includes information about the change of responsibility, such as an indicator that a change of responsibility to the merchant has occurred.

  In certain embodiments, EMV offline instructions 224 may include instructions for sending a payment authorization request 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 may request one or more payment servers based on determining that one or more payment authorization requests can be sent. It may include an option to send one or more payment authorization requests. Even if the EMV offline instruction determines that one or more payment approval requests can be transmitted based on the determination that the communication interface of the payment terminal 20 (for example, the wireless interface 214 of the merchant device 29) is available. Good. At this point, the processing unit 202 (based on the EMV offline instruction 224) checks whether the communication interface can communicate with one or more payment servers (eg, payment server 40) in any suitable manner. May be. This may be done, for example, by monitoring transmissions received at the communication interface or by receiving responses to messages sent from the communication interface from one or more payment servers. In some embodiments, the EMV offline instruction 224 may include instructions for performing the check after the first electronic payment response is received at the merchant device 29. In some embodiments, EMV offline instructions 224 may include instructions for determining that the frequency of payment requests is less than a threshold as part of determining that a payment authorization request can be sent. In this regard, the EMV offline instruction 224 may include instructions for recording the time at which each payment request is accepted at the 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 communication latency between the payment terminal 20 and the payment server 40 and other similar information.

  In some embodiments, the EMV offline instruction 224 may include instructions for forwarding one or more payment authorization requests to one or more payment servers when 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 indicator to the payment authorization request, for example, if the time indicator is not part of the ARQC associated with the electronic payment response. In some embodiments, the EMV offline instruction 224 may include an instruction to wait until the time indicated by the time 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 indicator may be a specific or explicit time, elapsed time, or provisional time. For example, the time indicated by the time indicator is based on a determination that the communication latency between the payment terminal 20 and the payment server 40 has fallen below a threshold value, or a determination that the frequency of payment requests has fallen below a threshold value. May be. In other embodiments, the time indicator may include other information.

  The EMV offline instruction 224 may include instructions for transferring a payment authorization request at a time corresponding to the time of the associated time indicator. The time corresponding to the time indicator may be a future time when the payment approval request is scheduled to be transmitted. In some embodiments, each of the plurality of payment authorization requests may be associated with an associated time indicator that corresponds 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 indicator. In one embodiment, the EMV offline instruction 224 provides instructions for transferring 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 the time indicator. May be included. In this regard, one or more payment servers may wait for a time corresponding to the time indicated by the time indicator before processing the payment approval request. In one embodiment, the EMV offline instruction 224 may include an instruction for forwarding a payment authorization request to an intermediate server, which forwards the payment authorization request to one or more payment servers at a later time. May be. In one embodiment, the EMV offline instruction 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.

  The EMV offline instruction 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, a payment authorization response may be associated with one or more payment authorization requests, and may indicate, for example, by a chip card issuer, that a particular payment transaction has been approved or rejected. In some embodiments, the EMV offline instruction 224 may include instructions for providing the user interface 210 with notification about the final approval or rejection of the payment approval request indicated by the payment approval response. A payment authorization response may be received for each payment authorization request sent to one or more payment servers.

  Hereinafter, an embodiment will be described in which the merchant device 29 includes the swipe interface 105 and may be configured to process a payment transaction with a chip card in a swipe mode. Under certain conditions, payment terminal 20 may not be able to process a payment transaction in which a customer attempts to provide electronic payment information using a chip card. For example, damage to the EMV chip of the chip card, improper use, various hardware and software problems at the payment terminal 20, or other problems may prevent the processing of payment information using normal EMV procedures. is there. If the payment reader 22 is unable to read payment information using normal EMV processing, processing of the EMV chip card may be done using a magnetic strip. In general, a “falling back” process that allows the payment information from the chip card to be processed using the magnetic strip of the chip card may be referred to as a “backing transaction”. During a swipe transaction involving a card with a magnetic strip but no EMV chip, the risk of non-payment if the transaction is rejected is transferred from the card issuer to the merchant who accepted the swipe transaction. However, as part of a technology reversal transaction (eg, if a reversal transaction occurs as a result of a technical problem with the payment procedure), there is no shift in responsibility and responsibility remains with the issuer of the card. In order to allow merchants to opt-in to allow payment transactions involving chip cards to be processed as swipe transactions, the card issuer and various supervisory authorities will ensure that non-payment responsibilities are transferred to the merchant. You may request. By accepting the card's issuer-to-merchant responsibility transfer request, 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.

  The EMV / swipe mode instruction 226 may include an instruction for causing the payment terminal 20 to enter the swipe mode. In certain embodiments, EMV / swipe mode instruction 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 a swipe mode received at user interface 210 (eg, by user input at point-of-sale application 222) or a predetermined criteria (eg, queue size, transaction Swipe mode may be entered in response to the determination that the frequency of In some embodiments, the request to enter the swipe mode may be provided in response to a request for payment information at the user interface 210 or provided when a chip card is detected, for example at the contact interface 104 of the payment terminal 20. May be.

  In one embodiment, the EMV / swipe mode instruction 226 accepts the opt-in request or transfers the responsibility from the card issuer to the merchant before allowing the payment transaction to proceed by executing the swipe mode step. May be required from the user. If the user refuses to accept the opt-in request, the processing of the payment transaction for which the request is 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 the payment transaction in a swipe mode. The opt-in request may include any suitable information to be displayed to the user in conjunction with the opt-in request, such as notifications or disclosure regarding the transfer of responsibility to the merchant, or other information. In some embodiments, the EMV / swipe mode instruction 226 may determine that the user has provided a request via the user interface 210 or that the merchant is experiencing a large number of customers (eg, from a sensor or camera). (Based on information), when the time between payment transactions at the payment terminal falls below a threshold time, or that the customer may be experiencing a delay in completing the payment transaction at the payment terminal 20. Instructions for providing an opt-in request may be included in response to various events, such as other events shown.

  In some embodiments, the EMV / swipe mode instruction 226 may include instructions for processing swipe payment type electronic payment information as part of the swipe mode operation. The user may provide a payment transaction request at the user interface 210. In certain embodiments, EMV / swipe mode instruction 226 may include instructions for receiving electronic payment information from a payment card magnetic strip swiped 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 traditional swipe payment transaction, such as card issuer information or card and cardholder specific information.

  The EMV / swipe mode instruction 226 may include instructions for generating an indicator and associating it with electronic payment information received during the swipe mode. In some embodiments, the EMV / swipe mode instruction 226 may generate a swipe mode indicator based on the payment terminal entering the swipe mode. The swipe mode indicator may allow electronic payment information to be processed according to a procedure for processing swipe payment types. In addition, the swipe mode indicator may indicate that the transaction is not a technology regression transaction. Since the chip card is operating in swipe mode with no technology setback, the indicator can inform the payment server that the transaction should be processed as a swipe transaction requiring a transfer of responsibility to the merchant. Good. In some embodiments, the EMV / swipe mode instruction 226 may generate an indicator that the payment card that provided the electronic payment information is a chip card. The indicator that the payment card is a chip card may be based on any suitable information received at merchant device 29, including a 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, the EMV / swipe mode instruction 226 provides instructions for associating the swipe mode indicator and an indicator that the payment card is a chip card with electronic payment information received at the payment terminal during the swipe mode. May be included. In other embodiments, the EMV / swipe mode instruction 226 may generate and associate other indicators.

  In one embodiment, the EMV / swipe mode instruction 226 may include instructions for processing payment transactions in conjunction 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 the swipe protocol. In some embodiments, the swipe protocol may include steps for processing electronic swipe payment information using conventional methods (eg, liability to merchant if payment card 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 the swipe mode is accepted (eg, from one payment transaction to another payment transaction). May be included. For example, merchant device 29 may determine that the condition that prompted the request to enter the swipe mode has been removed or no longer exists. In some embodiments, such a determination may be a determination that the number of customers on the merchant's premises has fallen below a threshold, or a determination that a time between payment transactions has exceeded a threshold time previously exceeded. May be based on At this point, the merchant device 29 may exit the swipe mode and return to normal processing operation of the payment transaction. In some embodiments, the EMV / swipe mode instruction 226 may include instructions for processing payment information from the chip card at the contact interface 104 using a normal payment process after entering the swipe mode. The request for normal chip card processing may be provided from the user interface 210, and the EMV / swipe mode instruction 226 receives the 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 receive a payment approval response at the communication interface (eg, wireless interface 214) of the payment terminal 20 accordingly. In this regard, there is no shift in responsibility as part of the processing of electronic payment information from the chip card (eg, no responsibility for payment transaction requests is imposed on the merchant).

  The EMV / swipe mode instruction 226 may include instructions for transmitting electronic payment information associated with the payment transaction request to one or more payment servers, for example via the wireless interface 214. Electronic payment information may be received at the merchant device 29 via performing normal processing or swipe mode, one of the swipe mode indicator and an indicator that the card that provided the electronic payment information is a chip card. The above may be included. The EMV / swipe mode instruction 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, a payment authorization response associated with electronic payment information may be received at a communication interface of payment terminal 20 (eg, at wireless interface 214) for transmission of multiple electronic payment information. . 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, the EMV / swipe mode instruction 226 includes instructions for identifying the delay condition when transmission of electronic payment information to one or more payment servers should be delayed for some delay condition. But you can. The condition may be an event such as a loss of connection with one or more payment servers, a high volume of transactions, a reduced connection speed, or any combination thereof. In some embodiments, the EMV / swipe mode instruction 226 may include instructions for storing electronic payment information (eg, in the memory 204) in response to specifying a delay condition. 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 in response to the delay condition is passed to one or more payment servers. It may be transmitted. In some embodiments, the delay condition may be a determination that the frequency of payment transactions (eg, at payment terminal 20) has exceeded 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 may be 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. May be based on such information. In some embodiments, the resolution of the delay condition may include the frequency of payment transactions falling below a threshold value. In some embodiments, the resolution of the delay condition may include the connection speed exceeding a threshold connection speed. In other embodiments, the resolution of the delay condition may be based on any suitable information.

  In some embodiments, the capabilities assigned to merchant device 29 based on EMV offline instruction 224 and EMV / swipe mode instruction 226 may be combined. For example, if it is determined that the processing period of the payment transaction using the urgent processing mode based on the EMV offline instruction 224 exceeds the threshold, the merchant device 29 executes the EMV / swipe mode instruction 226 to perform the payment. You may attempt to reduce transaction time. The determination is based on 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 the EMV offline instruction 224 and the swipe mode according to the EMV / swipe instruction 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 the payment server 40 according to an embodiment of the present disclosure. Although the payment service system 50 is depicted as a single server, it will be appreciated that the operation and memory of the payment service system 50 may be distributed over any suitable number of servers. Although particular components are depicted in a particular configuration in FIG. 5, the payment service system 50 may include additional components, and one or more of the components shown in FIG. It will be appreciated that this may not be necessary and that the components of payment service system 50 may be reconfigured in any suitable manner. It will be appreciated that in certain embodiments, the payment service system 50 may include the necessary components and have the necessary configuration to perform any of the functions belonging to the payment server 40 herein. Let's go. 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 the necessary operations of payment service system 50. In some embodiments, the processing unit 302 may be a high-speed processor that executes operating system, program and application instructions for the server based on instructions that may be retained in the memory 304. The memory 304 may include any suitable memory type as described herein, or a combination thereof, which holds instructions and other data and is for the operating system, program and application of the 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.

  Processing unit 302 may interact with and control one or more other components of payment service system 50 by executing instructions in memory 304. The processing unit 302 may communicate with other components of the payment service system 50 in any suitable manner, but in certain embodiments, the processing unit 302 may use the interface bus 306. 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 the instructions of 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 source 308. The power source 308 may include power conversion circuitry for converting AC power and / or for generating multiple DC voltages for use by components of the payment service system 50. In some embodiments, the power source 308 may include a backup system, such as a battery backup, to avoid service interruptions during power outages. Although not depicted in FIG. 5 as being physically connected to other components of the payment service system 50, the power supply 308 supplies various voltages to the components of the payment service system 50 according to the component requirements. Also good.

  The payment service system 50 may also include a communication interface 310. Although communication interface 310 may include any suitable communication interface or combination thereof, 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 is a secure connection (eg, TLS) with the payment terminal 20 (eg, the payment reader 22 via the merchant device 29) to exchange messages regarding transactions to be processed, firmware updates, application updates, etc. Or via SSL). The communication interface 310 may also communicate 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, and the payment service It may be operated by a subject different from the subject controlling the system 50. For example, in one embodiment, 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 be an operating instruction 320, a payment instruction 322, an EMV offline instruction 324, an EMV / swipe mode instruction 326, or any other suitable instruction for operating the payment service system 50 (eg, one or more of the payment service system 50). A plurality of instructions for performing processing operations of the payment service system 50 (such as instructions on the operation of other applications and components).

  The operating instructions 320 are optional for the payment service system 50, such as internal communication, power management, communication device control, other hardware control of the payment service system 50, any other appropriate instructions, or any combination thereof. Instructions for controlling appropriate general purpose operations may be included. In some embodiments, the operating instructions may provide instructions to the operating system of the payment service system 50 along with most drivers, programs and applications running on the payment service system 50.

  Operating instructions 320 may also include instructions for interfacing with merchant device 29. In certain embodiments, payment service system 50 may communicate with merchant device 29 via communication interface 310. The operating instruction 320, when executed by the processing unit 302, controls these communications, and implements instructions that provide secure communications by implementing procedures such as TLS, SSL, and key-encrypted data. May be included.

  Payment processing instructions 322 include instructions for processing payments and may 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 instruction may include information about each of the merchant devices 29 having a payment reader 22 and an installed point-of-sale application 222. In addition to providing payment information such as quantity 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 analysis of the merchant data. And may be used to provide reports, metrics, and other data to merchants (eg, merchants operating multiple merchant devices 29 at multiple locations). Payment processing instruction 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. Instructions for accessing the encryption key may be included.

  The EMV offline instruction 324 may include instructions for processing an EMV offline payment approval request received from the payment terminal 20. The EMV offline instruction 324 may include instructions for determining a time to execute a step 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 authorization request and waits until that time before processing the payment authorization request. May be started. In some embodiments, the EMV offline instruction 324 may include instructions for matching the time indicator of the payment authorization request with the time indicated by the electronic payment response, such as ARQC or cryptographic hash. In one embodiment, the EMV offline instruction 324 may 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, the EMV offline instruction 324 causes the payment service system 50 to provide the payment information included in the electronic payment response to the bank server for approval as soon as the payment service system 50 receives the payment approval request. Or wait until a time corresponding to the time indicator associated with the payment authorization request or the electronic payment response associated therewith. In addition, the EMV offline instructions 324 may include instructions for assigning an indicator to the payment authorization request that indicates the occurrence of a shift in responsibility as part of the payment transaction. In other embodiments, the EMV offline instruction 324 may assign other information to the payment authorization request.

  In one embodiment, the EMV offline instruction 324 may include instructions for holding one or more payment authorization requests in the memory 304 of the payment service system 50 until transmission for processing at the bank server. . The payment approval request is received at the communication interface 310 of the payment service system 50, the time corresponding to the time associated with the time indicator of the payment approval request, or 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 the threshold exceeds a threshold or at other times. In certain embodiments, the time of transmission of the payment authorization request may be determined according to user input or any other suitable information.

  In some embodiments, the EMV offline instruction 324 may cause the payment service system 50 to receive a payment authorization response (eg, from a bank server) and provide the response to the payment terminal 20. The payment authorization response may indicate whether the issuer approves or rejects the payment transaction based on the corresponding payment authorization 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). Also good). In this regard, the payment approval response may indicate the basis for the result of the payment approval response (eg, why the bank server approved or rejected the related payment approval request).

  The EMV / swipe mode instruction 326 may include instructions for processing electronic payment information received from the 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 been completed as a swipe mode transaction based on the payment information and indicators. In one embodiment, EMV / swipe mode instruction 326 causes payment service system 50 to change an indicator or assign the indicator to electronic payment information, and the electronic payment information is transmitted to one or more servers (eg, bank servers). May be sent for approval. In one embodiment, the EMV / swipe mode instruction 326 includes instructions for receiving a plurality of electronic payment information from the payment terminal 20 and storing the plurality of electronic payment information for transmission to one or more servers. But you can. The EMV / swipe mode instruction 326 may further include instructions for sending a plurality of electronic payment information to one or more servers for approval.

  In some embodiments, the EMV / swipe mode instruction 326 may include instructions for receiving a payment approval response for electronic payment information and sending the payment approval response to the payment terminal 20. In some embodiments, the payment approval 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 certain embodiments, the indicator may include information indicating to one or more payment servers that the chip card has provided swipe payment type electronic payment information. In this regard, the indicator may allow one or more servers to determine that a technical recession has not occurred and that the merchant has accepted the opt-in request, and thus 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. . The EMV / swipe mode instruction 326 may include instructions for receiving a payment approval response and sending it to the payment terminal 20. In an embodiment, the payment service system may repeat the process for each of a plurality of electronic payment information received at the payment service system 50 based on the EMV / swipe mode instruction 326.

  The methods that can be implemented in accordance with the disclosed subject matter in light of the above-described configurations and devices will be better understood with reference to the flowcharts of FIGS. 6-8. For ease of explanation, the method is shown and described as a series of steps, but such illustration or corresponding description is not limited to the order of the steps, and some steps are described herein. It should be understood and appreciated that this may occur in a different order and / or concurrently with other steps than those shown and described. Any non-sequential or branched flow illustrated through the flow chart should be understood as indicating that various other branches, flow paths, or sequence of steps that achieve the same or similar results can be implemented. It is. Moreover, not all illustrated steps may be required to implement the methods described below.

  FIG. 6 illustrates an exemplary method of urgent processing of an electronic payment transaction, according to an embodiment of the present disclosure. In some embodiments, as shown in FIG. 6, a method of expedited processing of an electronic payment transaction may be performed by the payment terminal 20 device (eg, as described in the exemplary embodiment of FIG. 6). Thus, a combination of the payment reader 22 and the merchant device 29). In some embodiments, these steps are depicted as being performed by a particular device, but the assignment of steps between devices may be altered 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 602, a request to enter the urgent 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 steps of the urgent processing mode. In some embodiments, the request may be accepted as input from the user via a point-of-sale application instruction 222 displayed on the user interface 210. In certain embodiments, when a payment transaction begins (eg, when a user opens a point-of-sale application instruction 222, when the payment device 10 is detected, when a customer provides input at the payment reader 22, or they 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 generated in response to determining that the merchant device 29 is unable to communicate 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.

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

  At step 606, merchant device 29 may determine whether the opt-in request has been accepted. The determination may be made based on the input from step 604. In some embodiments, the user may be allowed to perform the urgent processing mode steps 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. It may continue (eg, according to normal chip card processing procedures). If the user accepts the opt-in request, processing may proceed to step 608.

  At step 608, merchant device 29 may enter an urgent processing mode and perform the remaining steps shown in FIG. In step 610, the first payment request information may be received at the user interface 210 of the merchant device 29. The payment request may be provided as input from the merchant via the point-of-sale application 222 based on the merchant and customer progress in performing the transaction. The customer may then be prompted to insert a chip card into payment reader 22, for example by instructions provided by the user interface or merchant. After payment request information is received, processing may continue at 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. The chip card performs risk management in response to a request for an electronic payment response and approves the transaction offline (for example, based on the offline payment limit held on the chip card, There is no need to process the transaction with it), or if offline authorization is not available, an electronic payment response may be provided that includes the information required for an online authentication request according to an urgent payment protocol. In certain embodiments, the payment response may include an authentication request encryption or other similar information necessary to perform online authentication of an electronic payment request. After a request for an electronic payment response is provided to the chip card and the chip card provides an associated electronic payment response, processing may continue at step 612.

  In step 612, merchant device 29 may store the electronic payment response received from the chip card in memory of merchant device 29 (eg, memory 204 of merchant device 29). In certain 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 request associated with the additional request. A response may be received and stored in the merchant device 29. In this regard, 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 at step 614.

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

  In other embodiments, although not depicted in FIG. 6, the merchant device is responsible for 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, and the completion of the transaction. Monitoring parameters such as expected time to provide offline approval or communicate with a payment server to obtain approval (eg, using standard payment protocol or urgent payment protocol) ) May be determined. In one embodiment, transactions that are not approved offline may be processed in a manner that does not require a transfer of responsibility to the merchant, in which case the transaction is not approved until, for example, a response is received from a payment server. However, the conditions may be calibrated so that these online transactions are required when delays are less likely to delay transactions and are less likely to cause discomfort to merchants and customers. Thus, under appropriate conditions, only some of the transactions may be processed with a change of responsibility.

  Returning to the step of FIG. 6, at step 616, the merchant device 29 may associate one or more indicators with each of the electronic payment responses received in response to the request for the electronic payment response. In certain embodiments, the one or more indicators may include a payment type indicator. 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 an urgent payment protocol, the transaction may be approved or rejected by the payment server without requiring additional communication with the chip card. This allows the chip card to be removed early in the transaction, and the electronic payment response can be stored in a payment reader or merchant device for later transmission to the payment server.

  In some embodiments, the one or more indicators may include a time indicator associated with the payment authorization request. In certain embodiments, a time indicator may be associated with each payment authorization 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, merchant device 29 may determine whether to send a payment authorization request to one or more payment servers. In certain embodiments, this determination is performed by merchant device 29 to determine whether the communication interface (eg, wireless interface 214) of merchant device 29 is capable of communicating with one or more payment servers. May be based on other checks, or may be based on other parameters such as communication speed and average transaction processing time. If the communication interface 214 is unable to communicate with one or more payment servers, or if the predicted transaction time exceeds a threshold, the merchant device 29 may determine that a payment authorization request should not yet be sent. The process may continue to step 624. If the communication interface 214 can communicate with one or more payment servers, the merchant device 29 may determine that it can send a payment authorization request and processing may continue at 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 will be able to send a payment authorization request based on a time indicator associated with the request. In certain embodiments, a first payment authorization request may be sent before an additional electronic payment response is received at 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 therewith. In some embodiments, the merchant device 29 may send the payment authorization request and indicator prior to the time indicator time if the time indicator corresponds to a future time. In this regard, the time indicator may indicate that one or more payment servers should wait for a time corresponding to the time of the time indicator before processing a payment authorization request. In such embodiments, the payment service system may forward the request to a bank server or issuer server of payment servers at the time of the time indicator. After merchant device 29 sends one or more payment authorization requests, processing may continue at step 622.

  At step 622, merchant device 29 may receive one or more payment approval responses from one or more payment servers in response to sending one or more payment approval requests. In certain embodiments, merchant device 29 may receive each payment authorization response via a communication interface (eg, wireless interface 214). In certain embodiments, each payment authorization response may be associated with each payment authorization 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 rejections and providing a notification (eg, a rejection of the transaction following a change of responsibility).

  As described above, if the merchant device 29 cannot send an approval request, processing may continue to step 624. At step 624, merchant device 29 may determine whether an additional payment request has been accepted, for example, at user interface 210 of merchant device 29. The user may perform multiple subsequent payment transactions, each associated with a unique payment request. If an additional payment request is accepted, the process may return to step 610 and steps 610 through 618 may be repeated. If an additional payment request is not accepted, processing may return to step 618 where it is determined whether an approval request can be sent. Processing continues 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. Also good.

  FIG. 7 illustrates a non-limiting ladder diagram illustrating exemplary steps for urgent processing of an electronic payment transaction, in accordance with an embodiment of the present disclosure. In one embodiment, as shown in FIG. 7, the method of urgent processing of an electronic payment transaction includes a payment terminal 20 device (eg, a combination of payment reader 22 and merchant device 29), payment service system 50, May be executed by the bank server 60. In some embodiments, these steps are depicted as being performed by a particular device, but the assignment of steps between devices may be altered 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. As described herein, 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. The payment request may include a payment amount or other suitable information. After payment reader 22 receives the payment request, processing may continue at step 704.

  At step 704, payment reader 22 may request an electronic payment response from chip card 10, and at step 706, the chip card provides an electronic payment response. As described herein, the electronic payment response may indicate that the chip card 10 has refused to provide transaction approval. In some embodiments, chip card 10 may authorize the transaction and provide electronic payment information (eg, ARQC). At step 708, payment reader 22 may forward 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 offline authentication without communicating an electronic payment response to the payment server. . At step 710, the payment reader 22 may provide transaction approval to the chip card 10 indicating approval of the transaction to the chip card. As described above, the merchant device may provide a notification to the user that the chip card 10 may be removed.

  Exemplary steps performed by merchant device 29 and payment reader 22 as part of the urgent processing mode may be identified with reference to line 711. The steps including the urgent processing mode in the exemplary embodiment 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 can be executed. Steps that may occur later to complete the approval of the transaction urgent processing are drawn with a solid line to the right of line 711 (eg, steps 712, 714, 716 and 718). In the normal operation mode, communication with the payment card continues even after communication with the payment service system 50 and the bank server 60, but the steps performed in this normal operation mode are depicted on the right side of the line 711 and are broken lines. (Eg, steps 720, 722, 724, 726, 728, and 730). These steps are skipped in the emergency 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 hereinabove, each payment authorization request may include one or more electronic payment responses and a payment type indicator associated therewith for each. In one embodiment, multiple payment approval requests may be sent in batches, for example, when the frequency of payment processing falls below a threshold or when 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 transmission time. At step 714, payment service system 50 may forward each one or more payment authorization requests it receives to bank server 60 for authorization. As mentioned herein, each of the one or more payment approval requests may be transmitted at a time corresponding to the time of the time indicator. In an embodiment, the payment service system 50 may wait until the time indicated by the time indicator before transmitting the payment approval request.

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

  At step 718, payment service system 50 may provide merchant device 29 with one or more payment authorization responses received at step 716. As described herein, each authorization response may correspond to a specific payment authorization request obtained as part of the payment transaction. In this regard, merchant device 29 may receive confirmation that a 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 described above, steps 720, 722, 724, 726, 728 and 730 may be performed during a normal operation mode in which no urgent processing occurs. Thus, steps 720 to 730 will not occur in embodiments where the merchant device 29 and payment reader 22 perform the steps in the urgent processing mode described herein. However, if the merchant device 29 and the payment reader 22 are not operating in the urgent processing mode, the merchant device 29 provides a payment approval response to the payment reader 22 at step 720 and the payment reader 22 tips the payment approval response at step 722. It may be transferred to the card 10. If chip card 10 receives a payment authorization response, it may provide an incoming message to payment reader 22 at step 724. In some embodiments, the received message may indicate confirmation that the chip card 10 has received a payment authorization response. In step 726, the payment reader 22 sends the received message received from the chip card to the merchant device 29. If merchant device 29 receives one or more received messages from one or more chip cards 10, processing may proceed to step 728.

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

  FIG. 8 shows a non-limiting flow diagram illustrating exemplary steps for selectively processing electronic payment information through multiple interfaces, in accordance with an embodiment of the present 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 the swipe mode steps may be received at the user interface 210 of the merchant device 29. In some embodiments, the request may be accepted as input from the user via a point-of-sale application instruction 222 displayed on the user interface 210. In certain embodiments, when a payment transaction begins (eg, when a user opens a point-of-sale application instruction 222, when the payment device 10 is detected, when a customer provides input at the payment reader 22, or they The request may be generated in response to a message displayed to the user via the user interface 210. In some embodiments, upon request that a chip card has been inserted into payment terminal 20, automatically requested based on transaction frequency, based on queue size, or based on other similar factors. May be generated. After the request to enter the swipe mode is accepted, processing may continue at step 804.

  At step 804, 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 swipe mode being accepted at step 802. In some embodiments, the opt-in request may be displayed as a graphical message to the user in the user interface 210 and is selectable by the user to provide input indicating whether the user accepts the opt-in request. An indicator may be included. In some embodiments, the opt-in request may include disclosure or notification regarding the result of accepting or refusing the opt-in request (eg, a transfer of responsibility from the card issuer to the merchant), and the card issuer, merchant, or supervisor. Information from government agencies and any combination thereof may be included. After the opt-in request has been provided to the user interface 210, processing may continue at step 806.

  At step 806, merchant device 29 may determine whether the user has 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 the swipe mode step 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 807, where processing of the payment transaction at payment terminal 20 is in accordance with normal operating mode steps (eg, technical Requesting that the chip card be inserted into the chip card interface of the payment reader 22 except under special circumstances, such as a retreat situation) If the continuing user accepts the opt-in request, the process proceeds to step 808. You may go on.

  At step 808, 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 at step 810 where a first payment transaction request may be accepted at the user interface 210 of the merchant device 29. The payment request may be provided as input from the merchant via the point-of-sale application 222 and may include an electronic payment information-based purchase progress (eg, progress to a desired point in a payment transaction, finalization of the payment amount, etc.) A request may be indicated. After the payment transaction request is received, processing may continue at step 811.

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

  At step 812, merchant device 29 may determine whether the payment card that provided the swipe payment type electronic payment information is a chip card. In one embodiment, merchant device 29 may determine whether the payment card is a chip card based on electronic payment information provided at swipe interface 105 of 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, processing may continue to step 814, and the payment terminal 20 may use the normal swipe payment transaction based on the determination. A 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, merchant device 29 may generate an indicator and associate the indicator with the electronic payment information received during the swipe mode. In some embodiments, merchant device 29 may generate a swipe mode processing indicator based on a payment terminal entering swipe mode. The swipe mode processing indicator may allow the electronic payment information to be processed according to the procedure for processing the swipe payment type, and the transaction is not a technology back-end transaction (eg, the transaction is a chip card interface of the payment terminal It is also possible that the transaction is not a transaction in which chip card processing has failed. Since the chip card is operating in swipe mode without technology retreat, the swipe mode processing indicator should indicate that the transaction should be processed as a swipe transaction requiring one or more payment servers to transfer responsibility to the merchant. You may let them know. In some embodiments, merchant device 29 may generate an indicator that the payment card that provided the electronic payment information is a chip card. An indicator that the payment card is a chip card is a notification received at the merchant device 29 that the payment card is a chip card (eg, following the determination that the payment card is a chip card in step 812). May be based on any suitable information including: In one embodiment, the electronic payment information received at the payment terminal during swipe mode may be associated with a swipe mode indicator and an indicator that the payment card is a chip card. After the indicator is generated and assigned, processing may continue at step 818.

  At step 818, merchant device 29 may determine whether an additional payment transaction request has been accepted, eg, via user interface 210. If the merchant device 29 determines that an additional request has been accepted, the electronic payment and indicator may be stored for the current transaction, stored in memory, and processing may return to step 810. If an additional payment transaction request is not accepted, processing may continue at step 820, where merchant device 29 may identify a delay condition. In some embodiments, the delay condition that the merchant device 29 can identify may be an event such as a loss of connection with one or more payment servers, a large number of transactions, a slowdown in 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) has exceeded 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 merchant device 29 identifies a delay condition at step 820, processing may continue at step 822. If no delay condition is specified, processing may continue at 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 send the electronic payment information and indicators stored in memory to one or more payment servers when the delay condition is resolved. In some embodiments, the resolution of the delay condition may include the frequency of payment transactions falling below a threshold value. In some embodiments, 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, or other. May be based on any suitable information, including Processing may continue at step 824 after the merchant device 29 determines that one or more delay conditions have been resolved.

  At step 824, merchant device 29 may send the electronic payment information and associated swipe mode processing indicator to one or more payment servers, eg, via wireless interface 214. The transmitted electronic payment information may be received at the merchant device 29 via performing normal processing or swipe mode, and the swipe mode indicator and indicator card indicating that the card that provided the electronic payment information is a chip card. One or more of them may be included. After the electronic payment information and associated swipe mode process indicator are sent to one or more payment servers, processing may continue at step 826.

  At step 826, merchant device 29 may receive a payment authorization response for the electronic payment information. In some embodiments, merchant device 29 may receive a payment authorization response associated with electronic payment information sent to one or more payment servers. Thus, in an exemplary embodiment, a payment authorization response associated with electronic payment information may be received at a communication interface of payment terminal 20 (eg, at wireless interface 214) for transmission of multiple electronic payment information. . 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 rejections and providing a notification (eg, a rejection of the transaction following a change of responsibility). Thereafter, the process may end.

  In one embodiment, a method for a payment terminal that processes electronic payment information received from a chip card includes accepting a request to enter an urgent processing mode at a user interface of the payment terminal; and Providing an opt-in request in response to the request to enter the urgent processing mode at a user interface, wherein the user enters the urgent 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. Checking whether the communication interface of the payment terminal is communicable with one or more payment servers, and if the communication interface is incapable of communication with the one or more payment servers, the payment terminal Storing the first 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, requesting an additional electronic payment response from an additional chip card by the processing element of the payment terminal, and the payment terminal. In the memory, the method may further include storing the additional electronic payment response and approving an additional transaction associated with the additional electronic payment response. The method further stores 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 allows the one or more payments. Determining communication with a server, and associating a payment type indicator with each of the first electronic payment response and the additional electronic payment response, wherein the payment type indicator is the one or more payment servers. , Indicating that the first electronic payment response and the additional electronic payment response are subject to processing according to an urgent payment protocol. The method further includes transmitting the first electronic payment response, the additional electronic payment response, and the associated payment type indicator from the communication interface of the payment terminal to the one or more payment servers. And the normal payment protocol requires each of the chip cards to request additional information for processing the transaction of the chip card, and the urgent payment protocol requests the one or more payment servers without the additional information. The first transaction and the additional transaction are processed, and the first transaction and the additional transaction follow the urgent payment protocol after the first transaction and the additional transaction are approved by the payment terminal. Transmitting at the one or more servers, and receiving a payment approval response associated with each of the first electronic payment response and the additional electronic payment response at the communication interface of the payment terminal. Receiving the payment approval response based on the payment type indicator.

  In an embodiment, the method further comprises associating a time indicator with the first electronic payment response and each additional electronic payment response, wherein each time indicator corresponds to a future transaction time; Transmitting each time indicator with an electronic payment response associated therewith.

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

  In an embodiment of the method, each time indicator and its associated electronic payment response is transmitted prior to a time corresponding to the time of the time indicator, and the one or more payment servers are configured to transmit the time of the time indicator. The electronic payment response is processed.

  In one embodiment, a method for a payment terminal for processing electronic payment information received from a chip card in an urgent processing mode includes accepting a first payment request at a user interface of the payment terminal; In response to the payment request, the processing element of the payment terminal requests a first electronic payment response from the first chip card via the chip card interface of the payment terminal, and in the memory of the payment terminal, the first 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 sends 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; approving an additional transaction associated with the additional electronic payment response; , May further be included. The method further includes 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, the first electronic payment response and It may include associating the additional electronic payment response to indicate that it 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. Each payment authorization request is for one of the first electronic payment response or the additional electronic payment response and for each of the electronic payment responses, a payment type indicator associated therewith And transmitting the payment authorization request from the communication interface of the payment terminal to the one or more payment servers, wherein a normal payment protocol is provided for each of the chip cards, Additional information to process the chip card transaction And the urgent payment protocol causes the one or more payment servers to process the first transaction and the additional transaction without the additional information, wherein the first transaction and the additional transaction are the first transaction. And after the additional transaction is approved by the payment terminal, it is processed at the one or more servers according to the urgent payment protocol.

  In an embodiment, the method further includes accepting a request to enter the urgent processing mode at the user interface of the payment terminal and responding to the request to enter the urgent processing mode at the user interface of the payment terminal. Providing an opt-in request, and the user is allowed to perform the steps of the urgent processing mode only if the opt-in request is accepted by the user.

  In one embodiment, the method further comprises, after receiving the first payment response, checking whether the communication interface of the payment terminal can communicate with the one or more payment servers, and the additional Transmitting a 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 an embodiment of the method, determining that a payment authorization request can be transmitted includes determining that the communication interface of the payment terminal is capable of communicating with the one or more payment servers.

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

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

  In some embodiments, the method further includes associating a time indicator with each payment authorization request, wherein each time indicator corresponds to a future transaction time and an electronic payment response associated with each time indicator. And transmitting to the one or more payment servers.

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

  In an embodiment of the method, each time indicator and the payment approval request associated therewith is sent prior to a time corresponding to the time of the time indicator, and the one or more payment servers are said time of the time indicator. The payment approval request is processed.

  In one embodiment, a payment terminal for processing wireless electronic payment information received from a chip card in an urgent 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 accept a payment request from one or more processing elements connected to the chip card interface, the communication interface and the user interface, wherein the one or more processing elements are 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 instruction, the urgent processing instruction, and the transaction processing instruction, wherein the user interface instruction is in the one or more processing elements, Receiving a first payment request at the user interface and accepting an additional payment request at the user interface, and an urgent processing instruction causes the one or more processing elements to respond to the first payment request. Requesting a first electronic payment response from the first chip card via the chip card interface; storing the first electronic payment response in a memory of the payment terminal; Requesting an additional electronic payment response to an additional chip card via a chip card interface, storing the additional electronic payment response in the memory, the first electronic payment response and the additional Associating a payment type indicator with each of the electronic payment responses, wherein the payment type indicator causes one or more payment servers to process the first electronic payment response and the additional electronic payment response according to an urgent payment protocol. The transaction processing instruction authorizes the one or more processing elements to approve a first transaction associated with the first electronic payment response, and the addition. Associated with an electronic payment response Approving an additional transaction; storing the first electronic payment response and the additional electronic payment response; and after approving the first transaction and the additional transaction, to the one or more payment servers Determining that a payment approval request can be transmitted via the communication interface and transmitting the payment approval request to the one or more payment servers, wherein each payment approval request is sent to the first electronic device. One of a payment response or one of the additional electronic payment responses and a payment type indicator associated with each of the electronic payment responses, and a normal payment protocol for each of the chip cards Request additional information to process your transaction before The urgent payment protocol causes the one or more payment servers to process the first transaction and the additional transaction without the additional information, wherein the first transaction and the additional transaction are the first transaction and the additional transaction. After a typical transaction is approved by the payment terminal, it is processed at the one or more servers according to the urgent payment protocol.

  In one embodiment of the payment terminal, the user interface instruction further accepts a request to enter the emergency processing mode from the user interface to the one or more processing elements, and enters the emergency processing mode in the user interface. In response to the request, an opt-in request is provided, and the user is allowed to execute the step of the urgent processing mode only if the opt-in request is accepted by the user.

  In one embodiment of the payment terminal, a transaction processing instruction further allows the one or more processing elements to receive the first payment response, and then the communication interface of the payment terminal can communicate with the one or more payment servers. Prior to receiving the additional electronic payment response, and if the communication interface is communicable to the one or more payment servers via the communication interface before receiving the additional electronic payment response. Sending a payment response.

  In an embodiment of a payment terminal, determining that a payment authorization request can be sent includes determining that the communication interface of the payment terminal is capable of communicating with the one or more payment servers.

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

  In one embodiment 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 includes associating a time indicator with each payment approval request to the one or more processing elements, each time indicator corresponding to a future transaction time. Sending each time indicator with an electronic payment response associated therewith.

  In one embodiment of a payment terminal, each time indicator and its associated payment approval request is transmitted at a time corresponding to the time of the time indicator.

  In an embodiment of a payment terminal, each time indicator and its associated payment approval request is sent prior to a time corresponding to the time of the time indicator, and the one or more payment servers are The payment approval request is processed after waiting until the time.

  In one embodiment, the non-transitory computer readable storage medium may comprise instructions retained thereon, wherein when the instructions are executed by one or more processors, the one or more processors receive a payment terminal user interface. Receiving a first payment request via a chip card, requesting a first electronic payment response from the first chip card via a chip card interface in response to the first payment request, and storing the first payment request in the memory of the payment terminal. Providing an electronic payment response and approving a first transaction associated with the first electronic payment response. The operation further accepts an additional payment request via the user interface and sends an additional electronic payment response to the additional payment card in response to the additional payment request via the chip card interface. Requesting, providing the additional electronic payment response to be stored in the memory, and approving an additional transaction associated with the additional electronic payment response. But you can. The operation further relates to 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. Storing the first electronic payment response and the additional electronic payment response, indicating that the additional electronic payment response is subject to processing in accordance with an urgent payment protocol; After approving the additional transaction, determining that a 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 One of the payment responses and each of the electronic payment responses Te, comprising a payment type indicator associated with it, and a determining may include. The method may further include providing a payment authorization request for transmission to the one or more payment servers via the communication interface of the payment terminal, wherein a normal payment protocol is provided for each of the chip cards. Requesting additional information to process the transaction, the urgent payment protocol causes the one or more payment servers to process the first transaction and the additional transaction without the additional information, and 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 accepts a request to enter the emergency processing mode from the user interface to the one or more processors, and responds to the request to enter the emergency processing mode for the user interface. Providing an opt-in request, the user may be allowed to perform the steps of the urgent processing mode only if the opt-in request is accepted by the user.

  In one embodiment, the instructions further check whether the communication interface is communicable with the one or more payment servers after receiving the first payment response to the one or more processors; Prior to receiving the additional electronic payment response, providing the first electronic payment response to be transmitted to the one or more payment servers to the communication interface when the communication interface is communicable. And an operation including this.

  In one embodiment, determining that a payment authorization request can be transmitted includes determining that the communication interface of the payment terminal is capable of communicating with the one or more payment servers.

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

  In one embodiment, the instructions further associate a time indicator with each payment authorization request to the one or more processors, each time indicator corresponding to a future transaction time, and each time indicator associated with it. Providing the communication interface with an associated electronic payment response to be sent to the one or more payment servers may be performed.

  In one embodiment, each time indicator and associated payment approval request is provided to the communication interface for transmission at a time corresponding to the time of the time indicator.

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

  In one embodiment, a method for a payment terminal that selectively processes electronic payment information through a plurality of payment interfaces includes: accepting a first payment transaction request at a user interface of the payment terminal; and In the chip card interface, in response to the first payment transaction request, the first electronic payment information type of the first electronic payment information type is received from the chip card, and the communication interface of the payment terminal is connected to one or more payment servers. And transmitting the first electronic payment information and receiving a first payment approval response for the first electronic payment information at the communication interface of the payment terminal. The method further includes accepting a request to enter a swipe mode at the user interface of the payment terminal and providing an opt-in confirmation in response to the request to enter the swipe mode at the user interface of the payment terminal. The payment terminal is allowed to enter the swipe mode only if the opt-in confirmation is accepted by the user, and accepts a second payment transaction request at the user interface of the payment terminal. And 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 the 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, entering the swipe mode with the payment terminal and performing a swipe mode process based on the notification. Generating an indicator, wherein the swipe mode processing indicator allows the second electronic payment information to be processed according to a procedure of the second electronic payment information type; and generating the payment terminal Transmitting the swipe mode process indicator and the second electronic payment information from the communication interface to the one or more payment servers; and a second for the second electronic payment information at the communication interface of the payment terminal. Receiving a payment authorization response There, the payment authorization response is based on the swipe mode processing indicator, and receiving may include.

  In an embodiment of the method, the swipe mode processing indicator indicates that the transaction is not a technical back transaction, and the technical back transaction is processed by the chip card at the chip card interface of the payment terminal. Indicates 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 and transmitting the second electronic payment information based on the expiration of the delay condition.

  In an embodiment of the method, the delay condition includes a frequency of payment transactions, and the expiration of the delay condition includes the frequency of payment transactions being below a threshold.

  In one embodiment, a method for a payment terminal that selectively processes 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; and In the user interface, providing 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 the user. Providing a payment transaction request at the user interface of the payment terminal and swiping from a payment card in response to the payment transaction request at the swipe interface of the payment terminal. And to accept electronic payment information of the type payment type, it may include a. The method further comprises generating a swipe mode processing indicator at the payment terminal based on an indicator that the payment terminal has entered the swipe mode and the payment card is a chip card, the swipe mode A processing indicator enables the electronic payment information to be processed according to the swipe payment type procedure, and generates the swipe mode processing from the communication interface of the payment terminal to the one or more payment servers. Transmitting an indicator and the electronic payment information and receiving a payment approval response to the electronic payment information at the communication interface of the payment terminal, wherein the payment approval response is based on the swipe mode processing indicator. Ku, and receiving may include.

  In an embodiment of the method, the swipe mode processing indicator indicates that the transaction is not a technical back-end transaction, which indicates that the chip card failed to process at the chip card interface of the payment terminal. Indicates that

  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 memory of the payment terminal Storing the electronic payment information, and transmitting the electronic payment information based on expiration of the delay condition.

  In an embodiment of the method, the delay condition includes a frequency of payment transactions, and the expiration of the delay condition includes the frequency of payment transactions being below a threshold.

  In an embodiment of the method, 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 an embodiment, the method further comprises receiving, at the payment terminal, a notification that the payment card is a chip card, and the indicator that the payment card is a chip card. Based on receiving.

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

  In some embodiments, the method further includes accepting a second payment transaction request at the user interface of the payment terminal and a second response at the chip card interface of the payment terminal in response to the second payment transaction request. Receiving second electronic payment information of a chip card payment type from the 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 approval response to the second electronic payment information.

  In an embodiment of the method, the responsibility for the first payment transaction request is imposed on the merchant operating the payment terminal, and the responsibility for the second payment transaction request is not imposed on the merchant.

  In one embodiment, a payment terminal for selectively processing electronic payment information through a plurality of 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 the 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 And a swipe interface, a communication interface, and one or more processing elements connected to the user interface, wherein the one or more processing elements are user interfaces. Instructions configured to perform swipe mode instruction, and the transaction processing instructions. 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 in 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; receiving a payment transaction request from the user interface; And the swipe mode instruction causes the one or more processing elements to pay the payment only if the opt-in confirmation is accepted by the user. Allowing the terminal to enter the swipe mode, and generating a swipe mode processing indicator based on indicators that the payment terminal has entered the swipe mode and the payment card is a chip card. The swipe mode processing indicator allows the electronic payment information to be processed according to the swipe payment type procedure, and generates the transaction processing instruction, wherein the transaction processing instruction is the one or more processing elements. Receiving the swipe payment type electronic payment information from the payment card in response to the payment transaction request, and sending the swipe mode processing indicator and the previous to the one or more payment servers via the communication interface. And transmitting electronic payment information, comprising: receiving a payment authorization response to the electronic payment information, the payment authorization response is based on the swipe mode processing indicator, and receiving, to perform.

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

  In one embodiment of the payment terminal, the transaction processing instruction further specifies a delay condition for the one or more processing elements, and the transmission of the electronic payment information should be delayed during the delay condition. Identifying, storing the electronic payment information in a memory of the payment terminal, and permitting the transmission of the electronic payment information based on expiration of the delay condition.

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

  In one embodiment of the payment terminal, 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 indicates that the connection speed exceeds a threshold value. Including.

  In one embodiment of the payment terminal, the swipe mode instruction is further received at the payment terminal that the payment card is a chip card, wherein the payment card is a chip card. Receiving the indicator 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 is sent to the one or more processors. Further, accepting swipe payment type electronic payment information from a second payment card in response to the second payment transaction request from the swipe interface; 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 is sent to 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. Transmitting the second electronic payment information and receiving a payment approval response to the second electronic payment information via the communication interface.

  In an embodiment of a payment terminal, the responsibility for the first payment transaction request is imposed on the merchant operating the payment terminal, and the responsibility for the second payment transaction request is not imposed on the merchant.

  In some embodiments, the non-transitory computer readable storage medium may comprise instructions retained thereon, and when executed by one or more processors, the one or more processors may be instructed to a user of the payment terminal. Receiving a request to enter a swipe mode from an interface, and providing an opt-in confirmation to the user interface of the payment terminal in response to the request to enter the swipe mode, wherein the payment terminal Providing that the swipe mode is allowed to enter only if confirmation is accepted by the user, accepting a payment transaction request from the user interface of the payment terminal, and swiping the payment terminal. Via interface, in response to said payment transaction request, from the payment card, and to accept electronic payment information of the swipe payment type to perform operations including. The operation further comprises generating a swipe mode processing indicator in the processing element based on an indicator that the payment terminal has entered the swipe mode and that the payment card is a chip card, the swipe mode A processing indicator allows the electronic payment information to be processed according to the swipe payment type procedure, and generates and sends the swipe for communication from the payment terminal communication interface to one or more payment servers. Providing a mode processing indicator and the electronic payment information. The operation may further include receiving a payment approval response for the electronic payment information from the communication interface of the payment terminal, wherein the payment approval response is based on the swipe mode processing indicator.

  In one embodiment, the swipe mode processing indicator indicates that the transaction is not a technical back transaction, and the technical back transaction indicates that the chip card has failed processing at the payment card's chip card interface. Indicates.

  In one embodiment, the instruction further identifies a delay condition to the one or more processors, wherein the transmission of the electronic payment information should be delayed during the delay condition; The electronic payment information may be stored in the memory of the payment terminal, and the transmission of the electronic payment information may be permitted based on expiration of the delay condition.

  In one embodiment, the delay condition includes a frequency of payment transactions, and the expiration of the delay condition includes the frequency of payment transactions being below a threshold.

  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 further includes receiving a notification to the one or more processors that the payment card is a chip card, and the indicator that the payment card is a chip card. Based on the above, an operation including receiving may be performed.

  In one embodiment, the instructions further include accepting a second payment transaction request from the user interface of the payment terminal to the one or more processors and responding to the second payment transaction request from the swipe interface. Accepting swipe payment type electronic payment information from the second payment card; determining that the second payment card is not a chip card; and determining the second payment card as a normal swipe card based on the determination. Processing according to the protocol may be performed.

  In one embodiment, the instruction further accepts a second payment transaction request from the user interface of the payment terminal to the one or more processors and responds to the second payment transaction request via a chip card interface. Receiving the second electronic payment information of the chip card payment type from the second chip card and transmitting the second electronic payment information from the communication interface of the payment terminal to the one or more payment servers. An operation may be performed including 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 is imposed on the merchant operating the payment terminal, and the responsibility for the second payment transaction request is not imposed on the merchant.

  The foregoing is merely illustrative of the principles of the present disclosure and various modifications can be made by those skilled in the art without departing from the scope of the present disclosure. The embodiments described above are shown for purposes of illustration and not limitation. The present disclosure can also take many forms other than those explicitly described herein. Accordingly, the present disclosure is not limited to the explicitly disclosed methods, systems, and apparatus, but rather is intended to include modifications and variations thereof that are within the scope of the following claims. Emphasize.

  By way of further example, changes to apparatus 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 associated methods, have many applications. Accordingly, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in accordance with the scope of the appended claims.

Claims (15)

A method for a payment terminal that processes electronic payment information received from a chip card in an urgent processing mode,
Accepting a first payment request in a user interface of the payment terminal;
In response to the first payment request, the processing element of the payment terminal requests a first electronic payment response from the first chip card via the 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 an additional payment request in the user interface;
In response to the additional payment request, the processing element of the payment terminal requests an additional electronic payment response from an additional chip card via the chip card interface;
Storing the additional electronic payment response in the memory;
Approving an additional transaction 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 to the first electronic payment response and the additional electronic payment response. Associating, indicating that an electronic payment response is subject to processing according to an urgent payment protocol;
Stores the first electronic payment response and the additional electronic payment response, and determines that a payment approval request can be sent to the one or more payment servers after approving the first transaction and the additional transaction. Each payment authorization request includes one of the first electronic payment response or the additional electronic payment response and a payment type indicator associated therewith for 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 to request additional information for processing the transaction of the chip card, and the urgent payment protocol requests the first transaction without the additional information from the one or more payment servers. And processing said additional transaction, said first transaction and said additional transaction being said one or more according to said urgent payment protocol after said first transaction and said additional transaction are approved by said payment terminal. The method that is processed at the server.   The method of claim 1, wherein determining that a payment authorization request can be transmitted includes determining that the communication interface of the payment terminal is capable of communicating with the one or more payment servers. Further comprising accepting a payment approval response associated with each of the payment approval requests at the communication interface of the payment terminal;
The method of claim 1, wherein the payment authorization 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 a frequency of payment requests is less than a threshold. Associating a time indicator with each payment authorization request, wherein each time indicator corresponds to a future transaction time;
The method of claim 1, further comprising: transmitting each time indicator to the one or more payment servers along with an electronic payment response associated therewith.   6. The method of claim 5, wherein each time indicator and its associated payment approval request is transmitted at a time corresponding to the time of the time indicator.   Each time indicator and its associated payment approval request is transmitted prior to a time corresponding to the time of the time indicator, and the one or more payment servers wait until the time of the time indicator before the payment approval 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,
A 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, emergency 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 causing the one or more processing elements to accept a first payment request at the user interface and accept an additional payment request at the user interface;
The urgent processing instruction requests the one or more processing elements to request a first electronic payment response from 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. 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, the first electronic payment response and the additional electronic payment response. Electronic payment response follows urgent payment protocol It indicates that the sense of the object, and associating, to perform the,
The transaction processing instruction authorizes the one or more processing elements to approve a first transaction associated with the first electronic payment response and to approve an additional transaction 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 and then paying to the one or more payment servers via the communication interface. Determining that an approval request can be sent, and sending 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 therewith for each of the electronic payment responses;
The normal payment protocol requires each of the chip cards to request additional information for processing the transaction of the chip card, and the urgent payment protocol requests the first transaction without the additional information from the one or more payment servers. And processing said additional transaction, said first transaction and said additional transaction being said one or more according to said urgent payment protocol after said first transaction and said additional transaction are approved by said payment terminal. Payment terminal processed at the server. A method for a payment terminal that selectively processes electronic payment information through multiple payment interfaces, comprising:
Accepting a request to enter a swipe mode in the user interface of the payment terminal;
In the user interface of the payment terminal, providing an opt-in confirmation in response to the request to enter the swipe mode, wherein the payment terminal enters the swipe mode only if the opt-in confirmation is accepted by a user Allowed to provide, and
Accepting a payment transaction request at the user interface of the payment terminal;
Accepting swipe payment type electronic payment information from a payment card in response to the payment transaction request at a swipe interface of the payment terminal;
In the payment terminal, generating a swipe mode processing indicator based on the payment terminal entering the swipe mode and an indicator that the payment card is a chip card, wherein the swipe mode processing indicator is the swipe mode Generating the electronic payment information according to a payment type procedure;
Sending the swipe mode processing indicator and the electronic payment information from the communication interface of the payment terminal to one or more payment servers;
Receiving a payment approval response for the electronic payment information at the communication interface of the payment terminal, wherein the payment approval response is based on the swipe mode processing indicator.   10. The swipe mode processing indicator indicates that the transaction is not a technical back transaction, and the technical back transaction indicates that the chip card has failed processing at the payment card's chip card interface. The method described. Identifying a delay condition, wherein the transmission of the electronic payment information should be delayed during the delay condition;
Storing the electronic payment information in a memory of the payment terminal;
10. The method of claim 9, further comprising transmitting the electronic payment information based on expiration of the delay condition.   The method of claim 11, wherein the delay condition includes a frequency of payment transactions, and the expiration of the delay condition includes the frequency of payment transactions being below a threshold.   The method of claim 11, wherein 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. Accepting a second payment transaction request at the user interface of the payment terminal;
Accepting swipe payment type electronic payment information from a second payment card in response to the second payment transaction request at the swipe interface of the payment terminal;
Determining that the second payment card is not a chip card;
10. The method of claim 9, further comprising processing the second payment card according to a normal swipe card protocol based on the determination. Accepting a second payment transaction request at the user interface of the payment terminal;
Accepting second electronic payment information of a chip card payment type from a second chip card in response to the second payment transaction request at the chip card interface of the payment terminal;
Transmitting the second electronic payment information from the communication interface of the payment terminal to one or more payment servers;
The method according to claim 9, further comprising: receiving a payment approval response for the second electronic payment information at the communication interface of the payment terminal.

Images