Field of the invention
[001] The present invention relates to the field of electronic payment transactions, and more
specifically to methods and systems for reducing user interventions necessary for authentication of
payment card based electronic payment transactions.
Background of the invention
[002] Electronic transactions and payments using payment cards or electronic payment
accounts are increasingly common – with the number of electronic payment transactions and ubiquity
of electronic transaction mechanisms and services growing steadily.
[003] Electronic transaction systems uniformly implement one or more authentication
mechanisms to ensure that requested transactions are only permitted if received from an authorized
individual/entity. Authentication mechanisms include several different approaches, including for
example, single-factor authentication or multi-factor authentication. Authentication mechanisms can
also vary depending on a required level of security – for example, low security transactions can rely
on static password/passcode type authentication, while higher security transactions can require one
or more of multi-factor authentication, dynamic password generation, biometric authentication, etc.
[004] Figure 1 illustrates a prior art system 100 that can be used for implementing electronic
transactions based on a payment card or payment card information presented by a card holder at a
terminal device 102. In certain embodiments of the present invention, system 100 may be modified
to implement the invention. System 100 includes terminal device 102, acquirer network 104, card
network 106 and issuer network 108. While Figure 1 has been used to illustrate a payment card based
network, it would be understood that similar principles and one or more entities having some or all
of the same functions may be used to effect payments through any electronic transaction account.
[005] Acquirer network 104 may be communicably coupled with terminal device 102, and
comprises acquirer server 104a, acquirer network database 104b and interface gateway 104c. Acquirer
3
server 104a may be configured to receive and process information relating to payment card
transactions. In an embodiment, the acquirer network may receive or process transactions received
only from merchants having a merchant account with the acquirer – which determination may be
made based on information retrieved from acquirer network database 104b. Interface gateway 104c
may include a hardware or software network gateway configured to enable acquirer network 104 to
communicate with card network 106.
[006] Card network 106 may be communicably coupled to both acquirer network 104 and issuer
network 108.
[007] Issuer network 108 comprises issuer server 108a, issuer network database 108b and
interface gateway 108c. Issuer server 108a may be configured to receive and process information
relating to payment card transactions. In an embodiment, the issuer network may only receive or
process transactions received from merchants having a merchant account with the issuer – which
determination may be made based on information retrieved from issuer network database 108b.
Interface gateway 108c may include a hardware or software network gateway configured to enable
issuer network 108 to communicate with card network 106.
[008] Terminal device 102 may comprise any terminal device including without limitation a POS
terminal device 102a, computing device 102b, or mobile phone or smartphone 102c.
[009] In the system of Figure 1, issuer network 108 may be configured to authenticate the
identity of an individual presenting a payment card for executing a payment transaction – as a
precondition to authorizing a requested payment transaction received from a POS terminal 102a or
other terminal devices 102. In various embodiments known in the prior art, this authentication is
implemented through a password / personal identification number (PIN) / one time password (OTP),
wherein the issuer network implements a challenge-response type authentication mechanism, through
which the user who seeks to execute a payment transaction can submit a password / PIN / OTP to
the issuer network, and the submitted password / PIN / OTP can be compared against a stored
password / PIN / OTP associated with the legitimate / authorized holder of the payment card.
4
[0010] Subject to a match between the submitted password / PIN / OTP and the stored
password / PIN / OTP associated with the legitimate or authorized holder of the payment card, the
identity of said user is authenticated and the issuer network proceeds to authorize the requested
payment transaction.
[0011] Figure 2 illustrates an exemplary sub-system 200 within issuer network 108, comprising
issuer server 202 communicably coupled with authentication server 204. In the illustrated
embodiment, responsive to issuer server 202 receiving a payment transaction request from acquirer
network 104 through card network 106, issuer server 202 initiates an authentication process flow at
authentication server 204 – whereinafter authentication server 204 initiates and concludes a challengeresponse
type authentication process (for example, static password/passcode type authentication,
multi-factor authentication, dynamic password based authentication, biometric authentication) with
the terminal device 102.
[0012] It has however been found that incorporation of an authentication process using one or
more of passwords / passcodes / dynamic passwords, personal identification numbers, biometric
authentication etc., is viewed by card holders as being inconvenient. This view is held even more
widely for situations where a card holder may be splitting a transaction among multiple cards, or where
several card holders may be splitting a total transaction cost among their individual payment cards. In
such cases, card holders often prefer to forego electronic payment transactions entirely, and rely on
cash based payments instead – instead of having to swipe each card and then go through an
authentication process for each card that has been swiped.
[0013] There is accordingly a need to streamline the authentication process for payment card
based transactions, by reducing user interventions necessary for authentication of such transactions –
particularly for cases where (i) a card holder may be splitting a transaction among multiple cards, or
(ii) several card holders may be splitting a total transaction cost among their individual payment cards,
or (iii) multiple card holders periodically use their payment cards for payment transactions in
geographical and chronological proximity of each other.
5
Summary
[0014] The invention relates to methods and systems for reducing user interventions necessary
for authentication of transactions.
[0015] The invention provides a method for authentication of an electronic transaction. The
method comprises (i) receiving from a terminal device, (a) a payment transaction request, and (b)
information identifying a first payment card for implementing the payment transaction request, (ii)
identifying a first set of transaction parameters corresponding to the payment transaction request,
wherein said first set of transaction parameters are identified based on information received from the
terminal device, (iii) determining proximity of the requested payment transaction in relation to at least
one other payment card transaction that has been authorized based on a second payment card
associated with the first payment card, wherein said proximity determination is based on at least one
of location proximity parameters and chronological proximity parameters, and (iv) responsive to the
determined proximity of the requested payment transaction satisfying one or more predefined
proximity requirements retrieved from one or more transaction authorization rules, implementing the
requested payment transaction based on the first payment card.
[0016] In an embodiment of the method, responsive to the determined proximity of the requested
payment transaction satisfying one or more predefined proximity requirements retrieved from one or
more transaction authorization rules, the requested payment transaction is implemented based on the
first payment card without a prior authentication of identity of the individual presenting the first
payment card for the requested payment card transaction.
[0017] A further method embodiment may include authenticating identity of the individual
presenting the first payment card for the requested payment card transaction in response to the
determined proximity of the requested payment transaction failing to satisfy one or more predefined
proximity requirements retrieved from one or more transaction authorization rules associated with
the first payment card.
[0018] In a particular embodiment, the one or more transaction authorization rules may be
defined based on user inputs received from a client terminal.
6
[0019] The one or more transaction authorization rules may be defined based on one or more
historical transactions implemented using the first payment card and which one or more historical
transactions have been implemented within a defined location proximity or chronological proximity
of one or more other historical transactions that have been performed using the second payment card.
[0020] In an embodiment of the method, authenticating identity of the individual presenting the
first payment card comprises a challenge-response type authentication. Said challenge-response type
authentication may include authentication based on any of a password, passcode, personal
identification number, one time password and biometric information received from the terminal
device.
[0021] The invention additionally provides a system for authentication of an electronic
transaction. The system comprises (i) a processor implemented server configured to (a) receive from
a terminal device, (1) a payment transaction request, and (2) information identifying a first payment
card for implementing the payment transaction request, (b) identify a first set of transaction parameters
corresponding to the payment transaction request, wherein said first set of transaction parameters are
identified based on information received from the terminal device, (c) determine proximity of the
requested payment transaction in relation to at least one other payment card transaction that has been
authorized based on a second payment card associated with the first payment card, wherein said
proximity determination is based on at least one of location proximity parameters and chronological
proximity parameters, and (d) responsive to the determined proximity of the requested payment
transaction satisfying one or more predefined proximity requirements retrieved from one or more
transaction authorization rules, implement the requested payment transaction based on the first
payment card.
[0022] The system may be configured such that responsive to the determined proximity of the
requested payment transaction satisfying one or more predefined proximity requirements retrieved
from one or more transaction authorization rules, the requested payment transaction is implemented
based on the first payment card without a prior authentication of identity of the individual presenting
the first payment card for the requested payment card transaction.
7
[0023] In an embodiment, the server may be further configured to authenticate identity of the
individual presenting the first payment card for the requested payment card transaction in response
to the determined proximity of the requested payment transaction failing to satisfy one or more
predefined proximity requirements retrieved from one or more transaction authorization rules
associated with the first payment card.
[0024] In a specific system embodiment, the one or more transaction authorization rules may be
defined based on user inputs received from a client terminal.
[0025] The one or more transaction authorization rules may be defined based on one or more
historical transactions implemented using the first payment card and which one or more historical
transactions have been implemented within a defined location proximity or chronological proximity
of one or more other historical transactions that have been performed using the second payment card.
[0026] In an embodiment of the system, the server may be configured such that authenticating
identity of the individual presenting the first payment card comprises a challenge-response type
authentication.
[0027] Said challenge-response type authentication may include authentication based on any of a
password, passcode, personal identification number, one time password and biometric information
received from the terminal device.
[0028] The invention additionally provides a computer program product for authentication of an
electronic transaction, comprising a non-transitory computer usable medium having computer
readable program code embodied therein, the computer readable program code comprising
instructions for implementing any of the method embodiments described in the disclosure herein.
Brief description of the accompanying drawings
[0029] Figure 1 illustrates a prior art system for authenticating and implementing electronic
transactions through a payment card transaction system.
8
[0030] Figure 2 illustrates issuer network components of the system of Figure 1.
[0031] Figure 3 illustrates a system for authenticating and implementing electronic transactions
through a payment card transaction system in accordance with the present invention.
[0032] Figure 4 illustrates issuer network components within the system of Figure 3.
[0033] Figures 5 and 8 illustrate method embodiments of the present invention.
[0034] Figures 6A and 6B illustrate communication flow diagrams illustrating communication
flow within the system of Figure 3, for implementing methods of the present invention.
[0035] Figure 7 illustrates a method for defining transaction authorization rules in accordance
with an embodiment of the invention.
[0036] Figure 9 illustrates an exemplary embodiment of an issuer server.
[0037] Figure 10 illustrates an exemplary computer system according to which various
embodiments of the present invention may be implemented.
Detailed description
[0038] The present invention provides secure authentication mechanisms for electronic payment
transactions while reducing user interventions necessary to effect such electronic payment
transactions.
[0039] The invention is premised on the understanding that the requirement for a separate
authentication step as a prerequisite to authorizing a payment card based transaction can be done away
with, by identifying patterns of payment card usage based on past transaction data, comparing
parameters of a requested payment card transaction with such past transaction data, and authorizing
the transaction if the parameters of a requested payment card transaction match or are similar to
parameters of prior transactions executed using the same payment card.
9
[0040] In particular, it has been found that groups of individuals (for example, families, or groups
of friends) tend to periodically go out together and as a result members of the group tend to carry out
payment transactions in physical and / or chronological proximity to each other using individual
payment cards.
[0041] One such instance is where a group goes shopping, and individual members of the group
pay for their purchases using individual payment cards at the same store – in which case, the payments
on individual payment cards would be executed at the same store / merchant location / POS terminal,
and within a certain chronological proximity of each other (for example within a period of between 5
minutes to an hour). In another such instance, a group goes out dining together, and individual
members pay for their own meals – for which separate checks have been issued – in which case the
payments on individual payment cards would be executed at the same restaurant / diner / POS
terminal, and within a certain chronological proximity of each other (for example within a period of
between 5 to 10 minutes). In yet another instance, a group goes out dining together, and a single check
is generated – but individual members decide to split the payment amount among their individual
payment cards – in which case the payments on individual payment cards would be executed at the
same restaurant / diner / POS terminal, and within a certain chronological proximity of each other
(for example within a period of between 1 to 5 minutes). In another somewhat different situation, a
person chooses to go shopping or dining, and chooses to split payment for her / his purchases among
multiple payment cards issued to such person – in which case the payments on individual payment
cards corresponding to such person would be executed at the same store / shop / mall / restaurant /
diner / POS terminal, and within a certain chronological proximity of each other (for example within
a period of between 1 minute to a few hours).
[0042] All of the above instances (and other instances involving the same or similar
considerations) result in creation of patterns of payment card usage – which patterns may be defined
in terms of physical (i.e. location based) and chronological (i.e. time based) proximity of payment card
spends involving two or more payment cards, such that if in future a similar pattern of payment card
usage is identified, such usage may be determined as being legitimate / authorized / conducted by the
legitimate card holders, and may be subjected to a less stringent authentication procedure, or may be
permitted without any authentication whatsoever.
10
[0043] For the purposes of the present invention, the following terms shall be understood to have
the corresponding meanings provided below:
[0044] “Acquirer” shall mean a business (e.g., a financial institution or a merchant bank) that
contracts with a merchant to coordinate with the issuer network of a customers’ payment card.
[0045] “Acquirer network” shall refer to a communication network, including hardware,
software and other equipment used by an acquirer to transmit and process card based transactions
and information related to merchants, customers, payment cards and transactions.
[0046] “Card holder” or “Customer” shall mean an authorized payment card user who is
making a purchase or effecting an electronic transaction with a payment card.
[0047] “Card network” shall refer to the intermediary between the merchant’s acquirer and the
customer’s issuer (for example, Mastercard® or Visa®). The card network primarily coordinates
payment card transactions between acquirers and issuers, and additionally coordinates clearing and
settlement services to transfer payments from issuers to merchants.
[0048] “Issuer” shall mean a financial institution that issues payment cards and maintains a
contract with a customer or card holder for repayment or settlement of purchases made on the
payment card.
[0049] “Issuer network” shall refer to a communication network, including hardware, software
and other equipment used by an issuer to transmit and process payment card transactions and
information related to customers, payment cards and transactions.
[0050] “Merchant” shall mean an authorized acceptor of payment cards for the payment of
goods or services sold by the merchant.
[0051] “Payment card” shall mean a card or data associated with a payment account that may
be provided to a merchant in order to fund a financial transaction via the associated payment account.
11
Payment cards may include credit cards, debit cards, charge cards, stored-value cards, prepaid cards,
fleet cards, virtual payment numbers, virtual card numbers, controlled payment numbers, etc. A
payment card may be a physical card that may be provided to a merchant, or may be data representing
the associated payment account (e.g., as stored in a communication device, such as a smart phone or
computer). For example, in some instances, data including a payment account number may be
considered a payment card for the processing of a transaction funded by the associated payment
account. In some instances, a check may be considered a payment card where applicable.
[0052] “Payment account” shall mean any account that may be used for the purposes of
effecting an electronic payment or electronic transaction, and shall include any electronic transaction
account, payment card account, bank account or electronic wallet account.
[0053] Figure 3 illustrates a system 300 configured for implementing electronic payment
transactions based on a payment card or payment card information presented by a card holder at a
terminal device 302 – in accordance with the present invention.
[0054] System 300 includes terminal device 302, acquirer network 304, card network 306 and
issuer network 308.
[0055] Acquirer network 304 may be communicably coupled with terminal device 302, and
comprises acquirer server 304a, acquirer network database 304b and interface gateway 304c. Acquirer
server 304a may be configured to receive and process information relating to payment card
transactions. In an embodiment, the acquirer network may receive or process transactions received
only from merchants having a merchant account with the acquirer – which determination may be
made based on information retrieved from acquirer network database 304b. Interface gateway 304c
may include a hardware or software network gateway configured to enable acquirer network 304 to
communicate with card network 306.
[0056] Card network 306 may be communicably coupled to both acquirer network 304 and issuer
network 308.
12
[0057] Issuer network 308 comprises issuer server 308a, issuer network database 308b and
interface gateway 308c. Issuer server 308a may be configured to receive and process information
relating to payment card transactions. In an embodiment, the issuer network may only receive or
process transactions received from merchants having a merchant account with the issuer – which
determination may be made based on information retrieved from issuer network database 308b.
Interface gateway 308c may include a hardware or software network gateway configured to enable
issuer network 308 to communicate with card network 306.
[0058] As shown in Figures 3 and 4, issuer server 308a may be communicatively coupled with an
authentication server 308d, transaction historian database 308e, and transaction authorization rules
database 308f. As discussed in more detail below, issuer server 308a may determine whether the
transaction may be authorized based on evaluation of the detected transaction parameters against one
or more transaction authorization rules, or alternatively whether the transaction requires initiation of
an identity authentication process flow (for example where the detected transaction parameters do not
satisfy threshold parameters set out in the one or more transaction authorization rules). The evaluation
of detected transaction parameters may be implemented by issuer server 308a based on data retrieved
from one or both of transaction historian database 308e and transaction authorization rules database
308f. Issuer server 308a may also be configured to forward to authentication server 308d, a request
for challenge-response type authentication (or authentication based on any other methodology) of a
requested payment transaction, in the event that the detected transaction parameters do not satisfy
threshold parameters set out in the one or more transaction authorization rules.
[0059] Figure 5 illustrates a method of implementing a payment transaction in accordance with
the present invention.
[0060] Step 502 comprises receiving a payment transaction request and information
corresponding to a first payment card intended to be used to implement a first payment transaction.
The information corresponding to the first payment card may include a card number, and one or more
other elements of card information including for example the card expiry date and / or CVC or CVV
number. In an embodiment of the invention, the payment transaction request and information
corresponding to the first payment card may be received at a POS terminal 302a, or at an acquirer
server 304a or at an issuer server 308a – which acquirer server 304a or issuer server 308a receives said
13
request and information from the POS terminal 302a or from one or more network intermediaries
communicatively interpositioned between POS terminal 302a and the acquirer server 304a or issuer
server 308a. The payment transaction request may include a transaction amount, and may also include
information identifying a merchant account to which the transaction amount requires to be credited.
[0061] Step 504 comprises initiating a process for transaction authorization at issuer server 308a.
[0062] At step 506, in response to initiation of the process for transaction authorization at issuer
server 308a, said issuer server 308a determines whether a first set of transaction parameters associated
with the payment transaction request complies with or satisfies a set of transaction authorization rules
associated with the first payment card. Said transaction authorization rules may in an embodiment
comprise rules retrieved from transaction authorization rules database 308f. In an embodiment, the
first set of transaction parameters may be determined based on payment transaction request
information received from POS terminal 302a.
[0063] In an illustrative embodiment of the invention, the transaction authorization rules may
describe or define one or more transaction events that require to be satisfied or detected as a prerequisite
to permitting a requested payment transaction to be implemented based on either an
abbreviated or lower security identity authentication mechanism or by eliminating identity
authentication entirely. In various embodiments of the invention, the transaction authorization rules
may set out or define one or more transaction proximity requirements associated with the first
payment card. Said one or more transaction proximity requirements may identify at least one other
payment card, and may require that the payment card transaction of step 502 be requested within a
predefined location proximity and / or predefined chronological proximity of another payment card
transaction that has been successfully authorized and / or completed using the at least one other
payment card. For example, the transaction proximity requirement(s) may specify that the payment
card transaction based on a first payment card should have been requested at the same POS terminal
and within 3 minutes of a successfully completed payment transaction using a second payment card –
and which second payment card has been associated with the first payment card.
[0064] It would be understood from the above that the step of evaluating compliance of requested
payment card transaction parameters with a set of transaction authorization rules at step 506 may
14
include comparing the first set of transaction parameters against either a second set of transaction
parameters or against a set of transaction proximity requirements that have been defined in the
transaction authorization rules. In one embodiment, the second set of transaction parameters or the
transaction proximity requirements (including the location proximity requirements and / or
chronological proximity requirements) may be defined based on user inputs. In another embodiment,
the second set of transaction parameters or the transaction proximity requirements (including location
proximity requirements and / or chronological proximity requirements) may be identified based on
an analysis of prior transactions that a card holder may have successfully implemented using the first
payment card and which prior transaction(s) using the first payment card have been performed within
a defined location proximity and / or chronological proximity of another earlier transaction that has
been performed using a second payment card.
[0065] Responsive to determining that the first set of transaction parameters satisfies the
transaction authorization rules associated with the first payment card and / or matches a second set
of transaction parameters or transaction proximity requirements established by the transaction
authorization rules, step 508 comprises authorizing the requested payment card transaction – further
to which issuer server 308a proceeds to initiate the process for debiting the transaction amount from
an account associated with the first payment card and crediting the transaction amount to an account
associated with the merchant – without requiring prior authentication of identity of the individual
presenting the first payment card for the requested payment transaction.
[0066] Alternatively, responsive to determining that the first set of transaction parameters does
not comply with transaction authorization rules associated with the first payment card and / or does
not match a second set of transaction parameters or transaction proximity requirements established
by the transaction authorization rules, step 510 comprises initiating an identity authentication process
to authenticate the identity of the person requesting the payment transaction – for example by
initiating a challenge-response type authentication process (for example, authentication based on static
password/passcode type authentication, multi-factor authentication, dynamic password based
authentication, biometric authentication etc.) with the terminal device 302a.
[0067] Although the flowchart of Figure 5 describes step 508 in terms of authorizing the payment
transaction without an authentication process, and step 510 in terms of initiating a challenge-response
15
type identity authentication process, it would be understood that in other embodiments, step 508 may
involve initiating a first identity authentication process that involves a lower level of user intervention,
whereas step 510 may involve initiating an identity authentication process requiring a higher level of
user intervention.
[0068] Figure 6A illustrates a communication flow between components of system 300 (shown
in Figure 3) in implementing the method of Figure 5 – wherein the method involves implementation
of step 508 after step 506.
[0069] The method commences at step 602a by receiving at POS terminal 302a, payment
transaction information – comprising at least a payment amount and payment card information. Said
payment card information may in an embodiment include information corresponding to a first
payment card intended to be used to implement a first payment transaction (which information may
include a card number, and one or more other elements of card information, including for example
the card expiry date and / or CVC or CVV number). At step 604a, POS terminal 302a generates and
forwards a payment transaction request to card network 306 – which payment transaction request may
be forwarded to card network 306 through an acquirer server (not shown) that is in network
communication with POS terminal 302a and card network 306. Said payment transaction request may
include the payment transaction information received at POS terminal 302a, as well as information
identifying a merchant account to which the transaction amount requires to be credited.
[0070] Card network 306 (or a server within card network 306) identifies the issuer bank
corresponding to the first payment card, and at step 606a transmits the payment transaction request
to an issuer server 308a associated with said issuer bank. Steps 608a and 610a involve issuer server
308a requesting and receiving (i) from transaction authorization rules database 308f, predefined
transaction authorization rules that define a required location proximity and / or a required
chronological proximity that have been associated with said first payment card and that describe a
required transaction proximity between transactions implemented using the first payment card and
transactions implemented using a second payment card that has been associated with said first
payment card, and optionally (ii) from transaction historian database 308e, historical card transaction
data associated with at least the first payment card and the second payment card.
16
[0071] Issuer server 308a thereafter determines whether a first set of transaction data parameters
corresponding to the requested payment transaction satisfy transaction proximity requirements set out
in the received transaction authorization rules – which determination may in an embodiment involve
a comparison between the first set of transaction data parameters and a second set of transaction data
parameters comprising data parameters corresponding to at least a first payment transaction that has
been previously implemented using the first payment card and a second payment transaction that has
been implemented using the second payment card.
[0072] At step 612a, responsive to determining that the first set of transaction data parameters
corresponding to the requested payment transaction satisfies transaction proximity requirements set
out in the transaction authorization rules associated with the first payment card, issuer server 308a
initiates execution of the requested payment transaction (without requiring prior identity
authentication of the individual presenting the first payment card for executing the requested payment
transaction), and at step 614a card network 306 subsequently forwards a transaction confirmation
message to POS terminal 302a (for example, through an acquirer server that is not shown in Figure
6A).
[0073] Figure 6B illustrates a communication flow between components of system 300 (shown
in Figure 3) in implementing the method of Figure 5 – wherein the method involves implementation
of step 510 after step 506.
[0074] The method again commences at step 602b by receiving at POS terminal 302a, payment
transaction information – comprising at least a payment amount and payment card information. Said
payment card information may in an embodiment include information corresponding to a first
payment card intended to be used to implement a first payment transaction (which information may
include a card number, and one or more other elements of card information, including for example
the card expiry date and / or CVC or CVV number). At step 604b POS terminal 302a generates and
forwards a payment transaction request to card network 306 – which payment transaction request may
be forwarded to card network 306 through an acquirer server (not shown) that is in network
communication with POS terminal 302a and card network 306. Said payment transaction request
including the payment transaction information received at POS terminal 302a, as well as information
identifying a merchant account to which the transaction amount requires to be credited.
17
[0075] Card network 306 (or a server within card network 306) identifies the issuer bank
corresponding to the first payment card, and at step 606b transmits the payment transaction request
to an issuer server 308a associated with said issuer bank. Steps 608b and 610b respectively involve
issuer server 308a requesting and receiving (i) from transaction authorization rules database 308f,
predefined transaction authorization rules that define a required location proximity and / or a required
chronological proximity that have been associated with said first payment card and that describe a
required transaction proximity between transactions implemented using the first payment card and
transactions implemented using a second payment card that has been associated with said first
payment card, and optionally (ii) from transaction historian database 308e, historical card transaction
data associated with at least the first payment card and the second payment card.
[0076] Issuer server 308a thereafter determines whether a first set of transaction data parameters
corresponding to the requested payment transaction satisfy transaction proximity requirements set out
in the received transaction authorization rules – which determination may in an embodiment involve
a comparison between the first set of transaction data parameters and a second set of transaction data
parameters comprising data parameters corresponding to at least a first payment transaction that has
been previously implemented using the first payment card and a second payment transaction that has
been implemented using the second payment card.
[0077] At step 612b, responsive to determining that the first set of transaction data parameters
corresponding to the requested payment transaction does not satisfy the transaction proximity
requirements set out in the transaction authorization rules associated with the first payment card,
issuer server 308a transmits an instruction / request for initiation of an identity authentication process
to authentication server 308d – whereafter authentication server 308d initiates a challenge-response
type (or any other type) process for authentication of identity of the person requesting the payment
card transaction. As shown in Figure 6B, initiation of said authentication process is followed at step
614b by transmission of an identity authentication process initiation message from authentication
server 308d to card network 306 (and onward to an acquirer server, which is not shown in Figure 6B)
and at step 616b said message is transmitted onward to POS terminal 302a. Thereafter, said identity
authentication process can be implemented between POS terminal 302a and authentication server
308d in any number of ways that would be apparent to the skilled person.
18
[0078] Figure 7 comprises a flowchart illustrating an embodiment of a method for defining or
generating transaction authorization rules of the type that have been described in connection with
Figures 5, 6A and 6B above. In various embodiments, said transaction authorization rules may be
defined by a user or cardholder, or by a system administrator at the server back end.
[0079] Step 702 comprises receiving information identifying a first payment card for which one
or more transaction authorization rules are intended to be defined. In an embodiment, said
information may be received through any terminal device 302 (including any of terminal devices 302a
to 302c). Step 704 comprises authenticating an identity of the person seeking to obtain system access
to define the transaction authorization rules – with a view to ensure that such person is authorized to
define transaction authorization rules for the first payment card. Said authentication step may be
implemented by issuer server 308a or authentication server 308d.
[0080] Responsive to authentication of the user identity, step 706 comprises receiving from a
client terminal 302, information identifying (i) a second payment card intended to be associated with
the first payment card for the purpose of defining transaction authorization rules and (ii) one or more
transaction proximity parameters for the purpose of defining the transaction authorization rules. In
an embodiment, the one or more transaction proximity parameters may comprise one or more
location based proximity parameters and / or one or more chronology based proximity parameters
that define an acceptable proximity between a payment card transaction using the second payment
card, and a subsequent payment card transaction using the first payment card – such that in cases
where transactions that have been requested using the first and second payment cards satisfy the
defined proximity requirement, identity authentication in respect of one of the two payment cards is
considered sufficient, and the payment transaction that has been requested based on the other of the
two payment cards can be implemented without requiring identity authentication in connection with
said other of the two payment cards.
[0081] While Figure 7 illustrates a method of defining transaction authorization rules based on
specific user interventions, it would additionally be understood that said transaction authorization
rules may also be generated based on artificial intelligence based pattern identification using historical
19
transaction data associated with payment cards that may be stored in and retrieved from transaction
historian database 308e.
[0082] Figure 8 comprises a flowchart illustrating a particular method embodiment of the method
more generally described in connection with Figure 5.
[0083] Step 802 comprises receiving from a POS terminal, a first payment request comprising
first payment card information and a first set of authorization information associated with the first
payment card from a POS terminal. In an embodiment, the first payment card information may
include one or more of a card number, and one or more other elements of card information including
for example the card expiry date and / or CVC or CVV number). In an embodiment, the first set of
authorization information may include any one or more of static password, passcode, dynamic
passcode, PIN, OTP or biometric information.
[0084] Step 804 comprises authorizing the first payment request in response to or based on
successful identity authentication of the individual presenting said first payment request. The step of
identity authentication may be implemented based on the first set of authorization information
received at step 802 – and in particular based on a successful comparison and matching of the first set
of authorization information received from the POS terminal against authorization information
associated with the first payment card that has been retrieved from the issuer network.
[0085] Step 806 comprises receiving from the POS terminal, a second payment request
comprising second payment card information. In an embodiment, the second payment card
information may include one or more of a card number, and one or more other elements of card
information including for example the card expiry date and / or CVC or CVV number).
[0086] Step 808 comprises determining whether a first set of transaction parameters comprising
at least (i) the first payment card information, (ii) transaction parameters corresponding to the first
payment request, (iii) the second payment card information and (iv) transaction parameters
corresponding to the second payment request – satisfies a set of transaction authorization rules that
have been associated with the second payment card. Determining whether the first set of transaction
parameters satisfies the set of transaction authorization rules may include comparing the first set of
20
transaction parameters with at least a second set of set of transaction parameters - which second set
of transaction parameters corresponds to at least a first historical payment transaction that has been
previously implemented using the first payment card and a second historical payment transaction that
has been previously implemented using the second payment card. In an embodiment, said comparison
seeks to determine whether the location proximity and / or chronological proximity between the
transaction parameters associated with the first and second payment requests matches or is sufficiently
similar to one or more identified patterns of location proximity and / or chronological proximity
between the first and second historical payment transactions.
[0087] In an alternate embodiment, the determination at step 808 regarding whether the first set
of transaction parameters satisfies a set of transaction authorization rules, involves determining
whether the location proximity and / or chronological proximity between the transaction parameters
associated with the first and second payment requests matches, or is sufficiently similar to, one or
more defined location proximity and / or chronological proximity parameters retrieved from
transaction authorization rules associated with the second payment card.
[0088] Responsive to determining that the first set of transaction parameters satisfies proximity
parameter requirements established by the set of transaction authorization rules and / or matches a
second set of transaction parameters or transaction proximity requirements established by the
transaction authorization rules, step 808 comprises authorizing the requested second payment
transaction based on the second payment card – further to which issuer server 308a proceeds to initiate
the process for debiting the transaction amount from an account associated with the second payment
card and crediting the transaction amount to an account associated with the merchant – without
requiring prior authentication of identity of the individual presenting the second payment card for the
requested second payment transaction.
[0089] Alternatively, responsive to determining that the first set of transaction parameters does
not comply with the set of transaction authorization rules associated with the second payment card,
step 810 comprises initiating an identity authentication process to authenticate the identity of the
person requesting the second payment transaction – for example by initiating a challenge-response
type authentication process (for example, an authentication process based on matching of static
21
password/passcode type authentication, multi-factor authentication, dynamic password based
authentication, or biometric authentication) with the terminal device 302a.
[0090] Figure 9 illustrates a block diagram illustrating components of an issuer server 308a that
has been configured to implement the various features of the present invention. In an embodiment
according to the illustration of Figure 9, issuer server 308a comprises (i) issuer server processor 3082,
comprising one or more processors configured to process data and execute functions of issuer server
308a, (ii) payment transaction request handler 3084 configured to receive requests for payment card
based payment transactions from acquirer network 304 and to queue requests for authorization of
payment card based payment transactions, (iii) communication interface 3086 comprising a processor
implemented interface configured for enabling network communication to and from issuer server
308a, (iv) transaction parameter comparator 3088 comprising a processor implemented comparator
configured to compare transaction parameters corresponding to a requested payment card transaction
against transaction authorization rules associated with the concerned payment card for the purpose of
determining whether a requested payment card transaction satisfies said transaction authorization
rules, and (v) authentication controller 3090 configured to selectively initiate and implement an identity
authentication process in connection with requested payment card transactions. It will be understood
that in certain embodiments, authentication controller 3090 may comprise a controller within issuer
server 308a, while in other embodiments, authentication controller 3090 may be located externally to
issuer server 308a, while remaining communicatively coupled to said issuer server 308a.
[0091] Figure 10 illustrates an exemplary system 1000 for implementing the present invention.
[0092] System 1000 includes computer system 1002 which in turn comprises one or more
processors 1004 and at least one memory 1006. Processor 1004 is configured to execute program
instructions - and may be a real processor or a virtual processor. It will be understood that computer
system 1002 does not suggest any limitation as to scope of use or functionality of described
embodiments. The computer system 1002 may include, but is not be limited to, one or more of a
general-purpose computer, a programmed microprocessor, a micro-controller, an integrated circuit,
and other devices or arrangements of devices that are capable of implementing the steps that constitute
the method of the present invention. Exemplary embodiments of a computer system 1002 in
accordance with the present invention may include one or more servers, desktops, laptops, tablets,
22
smart phones, mobile phones, mobile communication devices, tablets, phablets and personal digital
assistants. In an embodiment of the present invention, the memory 1006 may store software for
implementing various embodiments of the present invention. The computer system 1002 may have
additional components. For example, the computer system 1002 may include one or more
communication channels 1008, one or more input devices 1010, one or more output devices 1012,
and storage 1014. An interconnection mechanism (not shown) such as a bus, controller, or network,
interconnects the components of the computer system 1002. In various embodiments of the present
invention, operating system software (not shown) provides an operating environment for various
softwares executing in the computer system 1002 using a processor 1004, and manages different
functionalities of the components of the computer system 1002.
[0093] The communication channel(s) 1008 allow communication over a communication medium to
various other computing entities. The communication medium provides information such as program
instructions, or other data in a communication media. The communication media includes, but is not
limited to, wired or wireless methodologies implemented with an electrical, optical, RF, infrared,
acoustic, microwave, Bluetooth or other transmission media.
[0094] The input device(s) 1010 may include, but is not limited to, a touch screen, a keyboard, mouse,
pen, joystick, trackball, a voice device, a scanning device, or any another device that is capable of
providing input to the computer system 1002. In an embodiment of the present invention, the input
device(s) 1010 may be a sound card or similar device that accepts audio input in analog or digital form.
The output device(s) 1012 may include, but not be limited to, a user interface on CRT, LCD, LED
display, or any other display associated with any of servers, desktops, laptops, tablets, smart phones,
mobile phones, mobile communication devices, tablets, phablets and personal digital assistants,
printer, speaker, CD/DVD writer, or any other device that provides output from the computer system
1002.
[0095] The storage 1014 may include, but not be limited to, magnetic disks, magnetic tapes, CDROMs,
CD-RWs, DVDs, any types of computer memory, magnetic stripes, smart cards, printed
barcodes or any other transitory or non-transitory medium which can be used to store information
and can be accessed by the computer system 1002. In various embodiments of the present invention,
23
the storage 1014 may contain program instructions for implementing any of the described
embodiments.
[0096] In an embodiment of the present invention, the computer system 1002 is part of a distributed
network or a part of a set of available cloud resources.
[0097] The present invention may be implemented in numerous ways including as a system, a method,
or a computer program product such as a computer readable storage medium or a computer network
wherein programming instructions are communicated from a remote location.
[0098] The present invention may suitably be embodied as a computer program product for use with
the computer system 1002. The method described herein is typically implemented as a computer
program product, comprising a set of program instructions that is executed by the computer system
1002 or any other similar device. The set of program instructions may be a series of computer readable
codes stored on a tangible medium, such as a computer readable storage medium (storage 1014), for
example, diskette, CD-ROM, ROM, flash drives or hard disk, or transmittable to the computer system
1002, via a modem or other interface device, over either a tangible medium, including but not limited
to optical or analogue communications channel(s) 1008. The implementation of the invention as a
computer program product may be in an intangible form using wireless techniques, including but not
limited to microwave, infrared, Bluetooth or other transmission techniques. These instructions can be
preloaded into a system or recorded on a storage medium such as a CD-ROM, or made available for
downloading over a network such as the Internet or a mobile telephone network. The series of
computer readable instructions may embody all or part of the functionality previously described
herein.
[0099] Based on the above, it would be apparent that the present invention offers significant
advantages – in particular, by reducing the requirement for user interventions and by offering
convenient and secure ways for facilitating passive authentication of a user in connection with
electronic or payment card based transactions. The invention offers significant improvement in
customer experience due to the fact that the degree of effort or active intervention on the part of the
user for commencing and/or carrying out an electronic or payment card based transaction is reduced,
while maintaining and improving on security standards.
24
[00100] While the exemplary embodiments of the present invention are described and illustrated
herein, it will be appreciated that they are merely illustrative. It will be understood by those skilled in
the art that various modifications in form and detail may be made therein without departing from or
offending the spirit and scope of the invention as defined by the appended claims. Additionally, the
invention illustratively disclose herein suitably may be practiced in the absence of any element which
is not specifically disclosed herein – and in a particular embodiment that is specifically contemplated,
the invention is intended to be practiced in the absence of any one or more element which are not
specifically disclosed herein.

We claim:
1. A method for authentication of an electronic transaction, comprising:
receiving from a terminal device,
a payment transaction request; and
information identifying a first payment card for implementing the payment
transaction request;
identifying a first set of transaction parameters corresponding to the payment transaction
request, wherein said first set of transaction parameters are identified based on information
received from the terminal device;
determining proximity of the requested payment transaction in relation to at least one other
payment card transaction that has been authorized based on a second payment card associated
with the first payment card, wherein said proximity determination is based on at least one of
location proximity parameters and chronological proximity parameters; and
responsive to the determined proximity of the requested payment transaction satisfying one
or more predefined proximity requirements retrieved from one or more transaction
authorization rules, implementing the requested payment transaction based on the first
payment card.
2. The method as claimed in claim 1, wherein responsive to the determined proximity of the
requested payment transaction satisfying one or more predefined proximity requirements retrieved
from one or more transaction authorization rules, the requested payment transaction is implemented
based on the first payment card without a prior authentication of identity of the individual presenting
the first payment card for the requested payment card transaction.
26
3. The method as claimed in claim 1, comprising authenticating identity of the individual
presenting the first payment card for the requested payment card transaction in response to the
determined proximity of the requested payment transaction failing to satisfy one or more predefined
proximity requirements retrieved from one or more transaction authorization rules associated with
the first payment card.
4. The method as claimed in claim 3, wherein the one or more transaction authorization rules
are defined based on user inputs received from a client terminal.
5. The method as claimed in claim 3, wherein the one or more transaction authorization rules
are defined based on one or more historical transactions implemented using the first payment card
and which one or more historical transactions have been implemented within a defined location
proximity or chronological proximity of one or more other historical transactions that have been
performed using the second payment card.
6. The method as claimed in claim 3, wherein authenticating identity of the individual
presenting the first payment card comprises a challenge-response type authentication.
7. The method as claimed in claim 6, wherein said challenge-response type authentication
includes authentication based on any of a password, passcode, personal identification number, one
time password and biometric information received from the terminal device.
8. A system for authentication of an electronic transaction, comprising:
a processor implemented server configured to:
receive from a terminal device,
a payment transaction request; and
information identifying a first payment card for implementing the payment
transaction request;
27
identify a first set of transaction parameters corresponding to the payment transaction
request, wherein said first set of transaction parameters are identified based on information
received from the terminal device;
determine proximity of the requested payment transaction in relation to at least one other
payment card transaction that has been authorized based on a second payment card
associated with the first payment card, wherein said proximity determination is based on
at least one of location proximity parameters and chronological proximity parameters; and
responsive to the determined proximity of the requested payment transaction satisfying
one or more predefined proximity requirements retrieved from one or more transaction
authorization rules, implement the requested payment transaction based on the first
payment card.
9. The system as claimed in claim 8, configured such that responsive to the determined
proximity of the requested payment transaction satisfying one or more predefined proximity
requirements retrieved from one or more transaction authorization rules, the requested payment
transaction is implemented based on the first payment card without a prior authentication of identity
of the individual presenting the first payment card for the requested payment card transaction.
10. The system as claimed in claim 8, wherein the server is further configured to authenticate
identity of the individual presenting the first payment card for the requested payment card transaction
in response to the determined proximity of the requested payment transaction failing to satisfy one or
more predefined proximity requirements retrieved from one or more transaction authorization rules
associated with the first payment card.
11. The system as claimed in claim 10, wherein the one or more transaction authorization rules
are defined based on user inputs received from a client terminal.
12. The system as claimed in claim 10, wherein the one or more transaction authorization rules
are defined based on one or more historical transactions implemented using the first payment card
28
and which one or more historical transactions have been implemented within a defined location
proximity or chronological proximity of one or more other historical transactions that have been
performed using the second payment card.
13. The system as claimed in claim 10, wherein the server is configured such that
authenticating identity of the individual presenting the first payment card comprises a challengeresponse
type authentication.
14. The system as claimed in claim 13, wherein said challenge-response type authentication
includes authentication based on any of a password, passcode, personal identification number, one
time password and biometric information received from the terminal device.
15. A computer program product for authentication of an electronic transaction, comprising
a non-transitory computer usable medium having computer readable program code embodied therein,
the computer readable program code comprising instructions for:
receiving from a terminal device,
a payment transaction request; and
information identifying a first payment card for implementing the payment
transaction request;
identifying a first set of transaction parameters corresponding to the payment transaction
request, wherein said first set of transaction parameters are identified based on information
received from the terminal device;
determining proximity of the requested payment transaction in relation to at least one other
payment card transaction that has been authorized based on a second payment card associated
with the first payment card, wherein said proximity determination is based on at least one of
location proximity parameters and chronological proximity parameters; and
29
responsive to the determined proximity of the requested payment transaction satisfying one
or more predefined proximity requirements retrieved from one or more transaction
authorization rules, implementing the requested payment transaction based on the first
payment card.