US20220414636A1 - Payment systems and methods for managing payment card use - Google Patents

Images

Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
  • G06Q20/3223—Realising banking transactions through M-devices
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/357—Cards having a plurality of specified features
  • G06Q20/3574—Multiple applications on card
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/20—Point-of-sale [POS] network systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/22—Payment schemes or models
  • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/326—Payment applications installed on the mobile devices
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/326—Payment applications installed on the mobile devices
  • G06Q20/3265—Payment applications installed on the mobile devices characterised by personalisation for use
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/353—Payments by cards read by M-devices
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/356—Aspects of software for card payments
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/357—Cards having a plurality of specified features
  • G06Q20/3572—Multiple accounts on card
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/405—Establishing or using transaction specific rules
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/326—Payment applications installed on the mobile devices
  • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities

Definitions

• the present invention relates generally, but not exclusively, to the use of devices capable of performing transactions with multiple payment terminals and merchants using a selection of payment applications loaded onto the devices, in particular, to the selection of the payment application in multi payment application devices during a face to face payment in the device's normal powered operation and also during the devices low power mode operation.
• Multi payment application devices such as an NFC enabled mobile phone, can store multiple payment credentials, each being a payment application on the device, typically residing in the device's secure element. As such, the same multi payment application device is capable of performing transactions using any one of the payment credentials loaded which are linked with one or more issuers and bank accounts.
• a multi payment application device When a multi payment application device is used to perform a transaction, for example, by presenting the multi payment application device at a payment terminal, a means of selecting which payment card to use in the transaction is required.
• Many multi payment application devices have user interface applications installed on them which enable a user to manually select which payment credential to use. These are commonly called wallets or wallet applications.
• PPSE Proximity Payment System Environment
• the PPSE lists the ‘default’ payment credential or credentials by including an ordered list of payment applications that a terminal will can automatically select from based on the payment application's position in the list and compatibility with the terminal.
• Chip transactions the equivalent of the PPSE is the Payment System Environment (PSE) and operates in the same manner.
• the first payment application in the ordered list is identified by a payment terminal to which the multi payment application device has been presented.
• the payment terminal attempts to perform a transaction using the first payment application. If the attempt to perform a transaction using the first payment application is not possible, for example, because the terminal does not support the payment network which the payment application uses, the payment terminal will identify the next payment application in the ordered list and check if it is compatible. The payment terminal will keep identifying the next payment application in the ordered list until a compatible payment application is found and the payment application is selected and used to perform a transaction, or until no more payment applications are found at which point the transaction will be rejected.
• a user Every time a user wants to use a payment application other than the default payment application (the first application on the ordered list), they must actively select the payment application that they do want to use, for example, by running a wallet application on the multi payment application device. This can lead to undue delay, particularly when compared with the use of conventional payment cards where the user can quickly chose which of their payment cards to use in any given transaction without the need to open an application on a multi payment application device and select which payment application to use. It can also lead to accidental use of the wrong payment application in a particular transaction where the automatically selected payment application is not the payment application which the user intended to use.
• Low power mode is defined as a state the secure element and NFC Controller enter to use minimal power. Typically this mode is used when a consumer electronics device reaches a low battery threshold and the device automatically switches off many of its functions, except the clock and a few remaining functions such as its NFC functionality. This is described in detail in the ETSI TS 102 613 and GSMA NFC Handset Requirements.
• the payment credential with which the user has chosen to tap in with is not the highest matching application in the ordered list in the PPSE of the user's multi payment application device and if the user's multi payment application device enters low on power during transit, the situation could arise where the user is unable to tap out using the same payment credential and is forced to tap with a different payment credential. In many cases, in particular where a user has already tapped in but has not yet tapped out, this can lead to the user receiving a fine in relation to either or both payment credential presentments or the maximum possible fare may be charged to each payment credential.
• the user would only be able to perform transactions using the default list of payment credentials with the payment terminal through which the transaction is to be performed.
• the user no longer has any control over which card to use, may suffer financially, and may also be unable to gain fully from any capping that might be offered by the transit authority.
• a method, at a mobile device, of assigning a preferred payment application stored on the mobile device to a merchant comprising the steps of: receiving a selection of a merchant at the mobile device; receiving a selection of a preferred payment application; and mapping the payment application to the merchant by creating a record containing an application identifier and a merchant identifier.
• the method of the first aspect of the invention enables the payment application use-preferences of a user of the mobile device to be reflected when a transaction is performed without the need to run a wallet application, and even if the mobile device were running on low power mode.
• the method of first aspect of the invention may further comprise the steps of: receiving a record request message from a terminal; and sending a record containing the application identifier and the merchant identifier(s) to a terminal.
• the method of first aspect of the invention may further comprise the steps of: receiving a record request message from a terminal; and sending a plurality of records, each record containing an application identifier, and at least one record containing a merchant identifier.
• the merchant identifier of the first aspect of the invention may identify one of a unique merchant, a unique terminal or a group of merchants.
• the merchant identifier of the first aspect of the invention may identify a group of merchants using a merchant category code.
• the step of receiving a selection of a merchant at the mobile device of the first aspect of the invention may comprise receiving an input from a user via a user interface of the mobile device.
• the step of receiving a selection of a preferred payment application at the mobile device of the first aspect of the invention may comprise receiving an input from a user via a user interface of the mobile device.
• the step of creating a record containing an application identifier and a merchant identifier of the first aspect of the invention may comprise adding a merchant identifier to a record containing the application identifier.
• a method at a terminal, of selecting a payment application stored on a mobile device, the method comprising the steps of: sending a record request message to the mobile device; receiving one or more records from the mobile device; searching the one or more records for a merchant identifier which is associated with the terminal; if an associated merchant identifier is found, searching the record which contains the associated merchant identifier for an application identifier; and processing a transaction using a payment application identified by the application identifier.
• the method of the second aspect of the invention enables the user of the mobile device to have improved control over which payment credentials are used with which merchant, as the terminal is able to identify which payment application to use by identifying the application identifier stored in the same record as the associated merchant identifier, thereby providing for an efficient user experience.
• the method of the second aspect of the invention may further comprise the step of terminating a transaction process if no associated merchant identifier is found.
• the method of the second aspect of the invention may further comprise the step of searching the one or more records for a default payment application if no associated merchant identifier is found.
• the step of searching the one or more records for a default payment application of the second aspect of the invention may comprise performing, at the terminal, a payment application selection following standard processes.
• the merchant identifier of the second aspect of the invention may identify one of a unique merchant, a unique merchant location or a group of merchants.
• the merchant identifier of the second aspect of the invention may identify a group of merchants using a merchant category code.
• the merchant identifier of the second aspect of the invention may identify a transit merchant.
• a method at a mobile device, of prioritising a preferred payment application stored on the mobile device, the method comprising the steps of: detecting a transaction of a multiple-transaction payment; detecting which payment application was used to perform the transaction; and assigning a highest priority value to a record which contains an application identifier which identifies the payment application used to perform the transaction.
• the method of the third aspect enables the user of the mobile device to perform subsequent transactions using the same payment application as was used for the prior transaction, even if the mobile device enters a low power mode.
• the method of the third aspect of the invention may further comprise the step of detecting whether the mobile device is about to enter a low power mode, wherein the step of assigning a highest priority value to a record which contains an application identifier which identifies the payment application used to perform the transaction is performed when it is detected that the device is about to enter low power mode.
• the step of assigning a highest priority value to a record which contains an application identifier which identifies the payment application used to perform the transaction of the third aspect of the invention may occur automatically once the step of detecting which payment application was used to perform the transaction has occurred.
• the transaction of the third aspect of the invention may be a tap that can be classified as a multiple-transaction payment by virtue of a zero value transaction or a Merchant Category Code.
• the highest priority value of the third aspect of the invention may only assigned for a predetermined period of time.
• the mobile device of any of the first, second and third aspects of the invention may be one of a plastic card, a mobile phone, a watch, a tablet, a laptop, or a consumer electronic device.
• the transaction of either of the second and third aspects of the invention may be a transit aggregation type transaction performed with a transit merchant.
• FIG. 1 a depicts an operating model of the parties involved when a multi payment application device is used to perform a transaction over a four-party payment system;
• FIG. 1 b depicts a flow diagram of the processes which occur in the four-party payment system of FIG. 1 a;
• FIG. 2 depicts a representation of an exemplary multi payment application device
• FIG. 3 is a message flow diagram depicting the steps involved in an exemplary known method for performing payment card selection in multi payment application devices
• FIG. 4 is a message flow diagram depicting the steps involved in a method for performing the payment application selection in multi payment application devices.
• FIG. 5 is a message flow diagram depicting the steps involved in setting the payment credential which a user has used in a first transaction as the payment application of highest priority in the PPSE of the multi payment application device.
• Multi payment application devices can take many forms.
• Multi payment application devices can be consumer devices, conventional physical payment cards, mobile phones, watches or any suitable device upon can support the credentials of multiple payment accounts and perform transactions with multiple merchants.
• the credentials of any kind of payment card may be stored on such devices including credit, debit, prepaid and charge cards.
• the credentials may each be stored in the form of a payment application.
• the terms payment credential and payment application may be used interchangeably.
• each payment application resides in a secure element comprising a part of the multi payment application device.
• some or all of the payment applications will reside in the device's operating system memory or a trusted execution environment (TEE) when host card emulation (HCE) is utilized.
• TEE trusted execution environment
• Multi payment application devices may be capable of performing conventional contact, commonly known as Chip, based transactions and/or contactless transactions.
• FIG. 1 a depicts an operating model of the parties involved when a multi payment application device is used to perform a transaction over a four-party payment system.
• FIG. 1 b depicts a flow diagram of the processes which occur in the four-party payment system of FIG. 1 a .
• FIGS. 1 a and 1 b represent a successful transaction made using a four-party payment system.
• the model includes a multi payment application device 114 and a terminal 109 (sometimes referred to as a “Point of Sale” or POS terminal).
• the terminal 109 is typically retained by a merchant 110 .
• the merchant 110 typically has a contract with a financial institution to accept payments from payment devices such as a multi payment application device 114 . That financial institution (i.e.
• the merchant's bank is the acquirer 111 .
• the issuer 113 is the financial institution that has issued the multi payment application device 114 to a particular customer (i.e. the customer's bank).
• the acquirer 111 and the issuer 113 are linked by the payment processing system 112 .
• the merchant 110 , the acquirer 111 , the payment processing system 112 , and the issuer 113 comprise a payment processing network 120 .
• a multi payment application device 114 is presented to a merchant 110 who possesses a terminal 109 .
• the multi payment application device 114 interacts with the terminal 109 and a communication is established (step 101 ). Once the connection between the terminal 109 and the multi payment application device 114 is established, a transaction is initialised at the terminal 109 .
• step 101 a For multi payment application device, payment card credentials need to be selected (step 101 a ). This step can take place either before step 101 or after step 101 and before step 102 .
• the terminal 109 then communicates an authorisation request to the acquirer 111 (step 102 ).
• the acquirer 111 forwards the request on to the payment processing system 112 (step 103 ), which determines which issuer 113 is associated with the multi payment application device 114 .
• the payment processing system 112 then forwards the authorisation request on to the issuer 113 for transaction approval (step 104 ).
• the payment processing system 112 may validate the multi payment application device's security features before forwarding the authorisation request 104 .
• the issuer 113 then checks certain criteria, such as account status, and approves the authorisation request if those checks return satisfactory results (step 105 ).
• This approval is then forwarded on to the acquirer 111 via the payment processing system 112 (steps 106 and 107 ).
• the acquirer 111 sends the approval on to the merchant 110 , which receives confirmation via the terminal 109 (step 108 ).
• EMVTM EuropayTM (which has subsequently merged with MasterCardTM), MasterCardTM and VisaTM. Other members have since joined.
• EMVTM provides open specifications for chip-based payment devices and terminals to facilitate global interoperability for transactions.
• EMVTM The key element of EMVTM involves including dynamic digital data in every transaction. Dynamic digital data makes these types of transactions extremely secure and reduces the risk of fraud.
• a consumer payment application is resident in a secure Integrated Circuit Card (ICC) or chip. This can be the contact chip in smart cards or the contactless chip in smart cards or personal devices such as smart phones.
• ICC Integrated Circuit Card
• ISO/IEC 7816 for contact cards
• ISO/IEC 14443 for contactless cards/devices.
• An EMVTM standard chip is able to perform processing and contains a secure element which stores information and performs cryptographic functions.
• each payment application resides in such a secure element.
• the payment application will reside in the multi payment application device's operating system memory or a trusted execution environment (TEE) when host card emulation (HCE) is utilized.
• TEE trusted execution environment
• EMVTM enabled device When an EMVTM enabled device is used to pay at an EMVTM enabled terminal, it can be identified as an authentic, approved payment instrument through a process called authentication (this is an almost instant process where offline data authentication is available).
• authentication this is an almost instant process where offline data authentication is available.
• PIN Personal Identification Number
• the chip or, in online verification, the issuer
• the chip verifies that the consumer is indeed in possession of his or her own device, through recognising that the correct PIN or other form of cardholder authentication has been completed.
• This implementation of EMVTM is commonly known as “Chip and PIN”.
• EMVTM transactions The transaction flow of EMVTM transactions is much the same as that of the four-party system described above, but with the addition of authentication using chip data and chip technology.
• this step can take place. For example, a user can select which payment credentials they would like to use for a particular merchant transaction. This user selection can be made via a wallet application. This step can also take place automatically with the use of a Proximity Payment System Environment (PPSE) which has been preconfigured.
• PPSE Proximity Payment System Environment
• FIG. 2 depicts a representation of an exemplary multi payment application device 114 .
• the multi payment application device 114 depicted comprises a user interface 201 , a wallet application 202 , a Near-Field Communication (NFC) module 203 which enables the multi payment application device 114 to wirelessly communicate with other NFC enabled devices, and a secure element 204 which further comprises a PPSE 205 , and payment applications 206 and 207 .
• the payment applications reside in the device's operating system memory or a trusted execution environment (TEE) when host card emulation (HCE) is utilized.
• TEE trusted execution environment
• a PPSE 205 is an applet which can be stored on the secure element 204 (or within the devices operating system if HCE technology is used) of a multi payment application device 114 . During a transaction, the PPSE 205 presents one or more available payment applications to the terminal 109 .
• the PPSE 205 presents an ordered list of available payment applications to the terminal 109 , each application being part of a set of applications being presented in the form of an Application Definition File (ADF) record.
• ADF Application Definition File
• Each ADF record contains an Application Definition File Name (ADF Name), and each ADF Name uniquely identifies a payment application and is the payment application's Application Identifier (AID).
• ADF record may also contain an Application Priority Indicator (API) which comprises a value which reflects the ADF record's position in the aforementioned ordered list.
• API Application Priority Indicator
• the wallet application 202 can communicate with an application 206 or 207 or the PPSE 205 to activate the required payment credentials and configure the PPSE ADF records.
• FIG. 3 is a message flow diagram depicting the steps involved in an exemplary known method for performing the payment card selection step 101 a of the transaction process shown in FIG. 1 b where a Proximity Payment System Environment (PPSE) is used for determining payment application selection.
• PPSE Proximity Payment System Environment
• the multi payment application device 114 is presented at terminal 109 . This may involve presenting or tapping the multi payment application device 114 at the terminal 109 , where the device includes an NFC module 203 or any other suitable wireless communication means. Alternatively, the multi payment application device 114 may be inserted into the reader and may interface with the reader via, for example, a contact point such as an exposed chip, in such as case the PPSE role is provided by a PSE. Once an interface between the multi payment application device 114 and the terminal 109 has been established, the terminal sends a SELECT (PPSE) command to the multi payment application device 114 via the interface which requests access to the PPSE 205 and the ADFs contained therein.
• PPSE SELECT
• the multi payment application device 114 responds to the select command by responding with the PPSE's File Command Information (FCI) containing the ADF record(s) stored in the PPSE including the ADF Name for each ADF record to the terminal 109 .
• FCI File Command Information
• the terminal 109 determines which of the payment applications contained in the received ADF records to use for the transaction. The terminal 109 does this by identifying the first ADF record in the ordered list which matches with the terminal's capabilities. The terminal 109 starts by looking at the first ADF record in the ordered list, which is the ADF record with the highest priority API. Once this ‘highest priority’ or ‘first’ ADF record in the list has been identified by the terminal 109 , the terminal then check whether the ADF Name contained within the first ADF record are compatible with the terminal 109 . If an ADF Name contained within the first ADF record is determined to be compatible with the terminal 109 , the terminal 109 then selects this application, using the ADF Name as the application's AID.
• the terminal 109 will then identify the ADF record of next highest priority (the ‘second’ ADF record in the list) again by identifying the ADF record with the highest priority API. If an ADF Name contained within the second ADF record is determined to be compatible with the terminal 109 , the terminal 109 then selects this ADF record.
• the payment terminal 109 will keep identifying the payment card of next highest priority until a compatible ADF Record is found and the transaction proceeds or until no more ADF Records are found at which point the transaction will be rejected
• the terminal 109 begins a payment transaction with the selected application, for example either of application 206 and application 207 .
• a payment transaction may consist of several commands and responses between the terminal 109 and the multi payment application device 114 , as well as further responses from the selected payment application 206 or 207 .
• Payment data may be sent from the payment application 206 or 207 to the terminal 109 and is built into an authorisation request 102 by the terminal 109 and sent to acquirer 111 by the terminal 109 .
• the user may change the API of each of the ADF records present on the multi payment application device 114 .
• the user is only typically able to rank one ADF record in an ordered list of ADF records at a time.
• a terminal iterates through the ordered list sequentially, as outlined above.
• the user is limited to having to set which payment credential should be used prior to each transaction or accept a default credential (i.e. the first compatible credential in the ordered list).
• a multi payment application device 114 runs low on power such that it is running in a low power mode.
• the battery on the device may not have sufficient power to run the operating system, but there may be enough power to run the secure element 204 and NFC controller 203 for period of time or operations.
• the device may not have enough power to run a display or user interface 201 , but there may be enough power to perform ten to twenty NFC taps over the course of one to two days.
• a specific payment credential be used for transport payments on a multi payment application device 114
• the user would be unable to enter the transit system using the specific payment credential unless the specific payment credential was set at the highest priority in the PPSE 205 .
• the specific payment credential may not be suitable for use in other payments, in which case it would not be desirable to set it at the highest priority in the PPSE 205 .
• the terminal at the transit entrance would attempt to select the default payment credential provided at the PPSE 205 , but as the desired specific payment credential is not set as the ‘default’ payment credential in the PPSE 205 , in low power mode, the user would be forced to use the default payment credential.
• the proposed solution to this problem is to include additional information within each ADF record which enables the user to select which ADF records should be selected by which merchants when a transaction is performed. This overrides conventional use of a priority associated with each ADF record and reduces, if not removes, the need for user interaction with a wallet application 202 prior to each transaction. A user can specify which payment cards should be used with which merchants, without needing access to the wallet prior to the transaction, even in low power mode.
• the aforementioned additional data may be in the form of a Merchant Identifier (MI) or list of Merchant Identifiers.
• MI Merchant Identifier
• An MI included in an ADF record may identify terminals 109 belonging to a single merchant or it may identify terminals 109 belonging to all merchants in a particular sector, for example, transit or fast food.
• An MI may be based on the ISO 8583:1993 defined merchant category code extended with a merchant identifier.
• An MI may include geographic zoning based on a sub set of a ZIP code.
• An MI may include day or week or time of day definitions.
• An MI may comprise one or more of a partial zip code, merchant name and location, and date/time.
• MI conditionals allow the flexibility for the user to define targeted payment credential usage without needing to make an active selection via the wallet 202 , segmenting transport, business/personal and types of purchases to credentials of their choice.
• the user is able to define and select which MI or MIs to include in each ADF record stored on the multi payment application device 114 .
• the multi payment application device 114 may, for example, be able to select a particular ADF record (which represents a particular payment credential) and select a particular merchant or group of merchants (a merchant identifier).
• the multi payment application device 114 may then map the payment credential onto the merchant by including an MI which comprises the selected merchant or group of merchants in the selected ADF record, in effect creating a new ADF record comprising an MI and means for identifying a payment application.
• the MIs of each ADF record are then passed on to a terminal 109 which can use the MIs to determine which ADF record should be used selected to perform the transaction.
• a particular payment credential may be restricted by the Issuer of said payment credential such that a user can only select certain merchants or groups of merchants as the MI for said payment credential.
• a particular payment credential may be locked by the Issuer of said payment credential such that the use of said payment credential may only be used with a specific merchant or group of merchants. This may be implemented by locking a particular MI to the particular payment credential.
• An exemplary set of ADF records stored in the PPSE may comprise a first ADF record which comprises a ADF Name and an API with the highest priority value, a second ADF record which comprises an ADF Name and an MI which identifies transit authority A, and finally a third ADF record which comprises an ADF Name and an MI which identifies a retail merchant B at a specific location to be used Monday through Friday.
• the terminal 109 to which the multi payment application device 114 is being presented belongs to transit authority A, the terminal 109 would select the second ADF record. If the terminal 109 to which the multi payment application device 114 is being presented belongs to retail merchant B, the terminal 109 would select the third ADF record if it was a weekday alternatively it would select via the API process and use the first ADF record. All terminals belonging to other merchants would select the first ADF record.
• the multi payment application device issuer or user may not wish to support payments that do not match one of the listed MIs. For example while transit is supported in low power mode retail payment should not be supported. To address this requirement the highest priority ADF record identifies a payment application that is configured to always decline transactions or always decline transactions in low power mode.
• FIG. 4 is a message flow diagram depicting the steps involved in a method for performing the payment application selection step 101 a of the transaction process shown in FIG. 1 b where a Proximity Payment System Environment (PPSE) is used for application selection and where additional MI data is used.
• PPSE Proximity Payment System Environment
• Step 401 may be the same as step 301 , although the SELECT (PPSE) command may also include an indication that the terminal 109 is capable of processing MI data.
• SELECT PPSE
• the multi payment application device 114 responds to the select request by sending File Command Information (FCI) containing the ADF records stored in the PPSE including the MIs for each ADF record to the terminal 109 .
• FCI File Command Information
• An ADF Name for each ADF record may also be included.
• the terminal 109 is configured to first check the MI of each ADF record when determining which of the payment applications contained in the received ADF records to use for the transaction.
• the terminal 109 checks the MI of each ADF record to identify whether the terminal 109 falls within the MI of any of the ADF records. If an ADF record is found which contains an MI which encompasses the terminal 109 , this ADF record is chosen.
• the terminal 109 may then perform the standard selection processing, based solely on the API and terminal compatibility, as outlined above.
• step 404 the ADF Name of the chosen ADF is used to select the required payment application and a payment transaction continues, for example, via any suitable known transaction process.
• the payment transaction may occur close to or remotely to the user selectable range of merchants.
• the merchant is located remotely from the payment transaction.
• a smart-fridge incorporating the proposed solution may choose different payment credentials depending on the product it attempts to order, for example, to maximise loyalty points for specific merchants.
• MI data would enable the payment credential use preferences of the user to be reflected when a transaction is performed using the multi payment application device 114 , even if the multi payment application device 114 were running on low power mode.
• an MI in one or more of the ADF records provides the user with improved control over which payment card credentials are used with which merchants, thereby providing an enhanced user experience, and in the case of high throughput transit, ensuring quick and efficient movement of people through the transit gates.
• an API may also be included in one or more of the ADF records and the API may be used to perform conventional payment card selection as shown in FIG. 3 .
• Transactions with variable amounts include those commonly performed in transit type transactions where a user presents their multi payment application device 114 (taps in) at the beginning of a journey and presents their multi payment application device 114 once more (taps out) at the end of their journey, at which point the fare is calculated.
• Such a transaction with a variable amount can be detected by a multi payment application device 114 as being a transit transaction with zero value.
• the multi payment application device 114 were to run low on power after the user had tapped in and before the user had tapped out, although the user would be able to perform default transactions using the multi payment application device 114 , the user would be unable to select which of the payment credentials stored on the multi payment application device 114 to use when tapping out. If the payment credential with which the user had chosen to tap in with is not the first application in the PPSE of the user's multi payment application device 114 (i.e. the application of highest priority), the situation could arise where the user is unable to tap out using the same payment credential and is forced to tap out with a different payment credential.
• the proposed solution to this problem is to include automatically setting the payment application which was used by the user to tap as the payment application of highest priority in the PPSE of the multi payment application device 114 . This may be done automatically after a user taps in. This may be done by setting the API of the ADF record associated with this payment application that the user used to tap to the highest priority value.
• FIG. 5 is a message flow diagram depicting the steps involved in a method for setting the payment credential which a user has used in a first transaction as the payment application of highest priority in the PPSE of the multi payment application device 114 .
• Step 501 a user taps in at terminal 509 a with multi payment application device 114 .
• This step may comprise local authentication of the user to the payment application for example, via a wallet application 202 and a transaction being performed using said payment credential.
• the payment credential which was used by the user to tap at a terminal classified as one with a requirement to tap to complete, such as a Merchant Category Code of Transit is set as the payment application of highest priority in the PPSE.
• This step may involve setting the API of the ADF record which was used to perform the tap to the highest priority value.
• the multi payment application device 114 may detect that step 501 is a tap in type transaction with a variable amount billing or the multi payment application device 114 may detect that step 501 is an intermediary tap type transaction (i.e. where a tap in type transaction has already occurred, but a tap out type transaction is still expected to ensue) and may automatically perform step 502 whenever such a transaction, as embodied in step 501 , is performed. This ensures that if the device does fall into low power mode during transit, the default values have already been set in the PPSE so that the correct card can be used when tapping out.
• an intermediary tap type transaction i.e. where a tap in type transaction has already occurred, but a tap out type transaction is still expected to ensue
• the multi payment application device 114 may detect that it is low on power and that it will soon enter low power mode, so it may automatically perform step 502 whenever such a detection is made.
• the PPSE application could support two configurations, one configuration for normal power mode and one configuration for low power mode, in which case the wallet could set the low power mode configuration after detecting a transaction of type 501 , in preparation for a low power mode event.
• the multi payment application device 114 may perform step 502 in response to a user input, via the User Interface 201 of the multi payment application device 114 , which requests that the multi payment application device 114 enter low power mode.
• Step 502 could be completed following agreement from the user, for example with a user prompt, via the UI 201 , of “Do you want to set this card as default to make sure it is used on your exit?”, to which the user could respond via the UI 201 , or step 502 could be completed automatically, notifying the user that the step has occurred, for example, with a user prompt, via the UI 201 , of “Note: This card will be set as your default card if the handset loses power in the next hour”.
• the multi payment application device 114 may perform step 502 whenever a transaction of any type using a particular payment credential is performed and not just when a transaction of type 501 is performed.
• Step 502 might occur where, during step 501 , the multi payment application device 114 is able to detect that the transaction is for a zero value amount, and that the merchant category code is that of a transit agency. The multi payment application device 114 may then deduce that this transaction is a transit “aggregation” transaction, where it is essential that any other taps in this environment use the same set of credentials.
• the PPSE 205 is update to reflect the payment credentials that the user selected for their tap in, so that, should the device enter low power mode whilst travelling, the user is still able to present the same payment credentials upon exiting the transit system, or upon being inspected.
• Step 502 may be reversed after a predetermined period of time has elapsed with the original PPSE ordering being reinstated.
• the multi payment application device 114 enters low power mode.
• the user taps out at terminal 509 b with the multi payment application device 114 .
• terminal 509 b performs a payment application selection using the aforementioned payment application selection process, as detailed in FIG. 3 and the description thereof. Given that the payment application which was used to tap in has been set as the payment application of highest priority, the terminal 509 b will perform the transaction using the credential of the payment application which was previously used to tap.

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• Accounting & Taxation (AREA)
• Theoretical Computer Science (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Finance (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Computer Security & Cryptography (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Cash Registers Or Receiving Machines (AREA)
• User Interface Of Digital Computer (AREA)

Abstract

Description

Claims (18)

Priority Applications (1)

Applications Claiming Priority (4)

Related Parent Applications (1)

Publications (1)

Family

ID=51869305

Family Applications (2)

Family Applications Before (1)

Country Status (9)

Cited By (1)

Families Citing this family (25)

Citations (13)

Family Cites Families (44)

• 2014
  • 2014-09-22 GB GB1416734.0A patent/GB2530345A/en not_active Withdrawn
• 2015
  • 2015-09-18 US US14/857,976 patent/US11455612B2/en active Active
  • 2015-09-21 EP EP15843184.1A patent/EP3198538A4/en not_active Ceased
  • 2015-09-21 AU AU2015321656A patent/AU2015321656A1/en not_active Abandoned
  • 2015-09-21 KR KR1020177010915A patent/KR102117977B1/en active IP Right Grant
  • 2015-09-21 KR KR1020197011980A patent/KR20190047120A/en active Application Filing
  • 2015-09-21 JP JP2017535617A patent/JP6386190B2/en active Active
  • 2015-09-21 CN CN201580065188.0A patent/CN107004189B/en active Active
  • 2015-09-21 CA CA2961898A patent/CA2961898A1/en not_active Abandoned
  • 2015-09-21 BR BR112017005634-8A patent/BR112017005634A2/en not_active Application Discontinuation
• 2018
  • 2018-11-16 AU AU2018264139A patent/AU2018264139A1/en not_active Abandoned
• 2022
  • 2022-09-02 US US17/902,777 patent/US20220414636A1/en active Pending

Patent Citations (13)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events