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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • 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/401—Transaction verification
  • G06Q20/4014—Identity check for transactions
• • 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/085—Payment architectures involving remote charge determination or related payment systems
  • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
• • 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/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
• • 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/401—Transaction verification
  • G06Q20/4012—Verifying personal identification numbers [PIN]
• • 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/401—Transaction verification
  • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing

Definitions

• 3DS 3-D Secure
• FIG. 1 is an illustrative depiction of a system for use in a general cardholder authentication
• FIG. 2 is an illustrative depiction of a system for authentication processing, according to some embodiments herein;
• FIG. 3 is an illustrative depiction of a system for authentication processing, including interfacing with external sources of authentication related data, according to some embodiments herein;
• FIG. 4 is a logical architecture of an authentication platform, according to some embodiments herein;
• FIG. 5 is a schematic block diagram of a system, according to some embodiments herein;
• FIG. 6 is an illustrative depiction of a data exchange flow, according to some embodiments herein.
• FIG. 7 is a schematic block diagram of an apparatus, according to some embodiments herein.
• an authentication security policy relates to a process of verifying cardholder account ownership during a transaction in an online electronic commerce (e-commerce) environment, where that transaction may include a purchase transaction.
• e-commerce online electronic commerce
• the terms purchase transaction and payment transaction or simply transaction may be used interchangeably unless stated otherwise.
• the purchase transactions herein refer to card not present or e- commerce transactions. As such, these transactions may be requested by a merchant or other entity to have the cardholder, user, or other entity presenting a payment device for payment or an account thereof verified as an authorized user of the payment device since, for example, a merchant cannot physically verify the user is even in possession of the payment device.
• a framework for an authentication process, system, and method will be described that includes efficient and flexible data management functions and mechanisms.
• the data management functions and mechanisms of the authentication framework or platform herein include, but are not limited to, providing efficient and accurate control and management of a new customer enrollment process and billing aspects of the authentication platform.
• an authentication framework or platform herein provides median ism(s) supporting customer enrollment/data management and billing solution(s) that are scalable to future business growth and customers' expectations.
• the authentication framework or platform herein supports and facilitates the accurate management of data related to aspects of issuer, payment processor, and merchant information in an authentication ecosystem.
• payment device system, application, or service collects authentication data from various internal and external entities (e.g., applications, devices, services, etc.) of a business, enterprise, or organization within an authentication ecosystem, including but not limited to a 3DS environment, that can provide authentication services and stores the collected authentication data in a data repository such as a data warehouse, local or distributed storage facility, and a cloud based storage service.
• the collected authentication data may be used as a basis for business analytics including, for example, business reporting for internal and external customers of an enterprise or other business organization. Analysis based on the collected authentication data may, in some aspects, be utilized for transactional fraud scoring purposes.
• data derived from the collected authentication data can be shared and used in combination with transaction data (e.g., purchase authorization data) within a data warehouse to provide a view of an end-to-end transaction lifecycle.
• the present disclosure provides, at least in part, processes and systems for reporting an end-to-end or complete view of a transaction including authentication data used in the authorizing and processing of credit and other types of transactions.
• the authentication data determined, processed, collected, analyzed, and stored herein may be used to provide valuable insight into a business and other entities.
• Such insights may relate, but not be limited to, transactional patterns, authentication trends and patterns, card issuer authentication success and failure rates, fraud indicators due to multiple failures within certain card ranges or regions, cardholder trends on authentication abandonment, failure rates of certain authentication service providers, and trends on authentication methods used in particular transactions.
• 3-D SecureTM promulgated by the assignee of the present patent application that defines and provides a level of security relating to a cardholder authentication process.
• the MasterCard® SecureCodeTM process incorporates aspects of the 3-D SecureTM Protocol Specification Core Functions, Version 1.0.2 effective 17 April 2006.
• This particular implementation of 3-D SecureTM (also referred to herein as "3DS") includes support for the SPA (Secure Payment Application) algorithm and Universal Cardholder Authentication Field (UCAF) without changing the 3-D SecureTM specification, messages, or protocol. While some aspects herein may build on, rely on, and leverage various aspects of the 3-D SecureTM specification, the processes and systems herein are not limited to a security authentication protocol or process adhering to that specification or even authentication flows that may fit within the 3DS protocol.
• SPA Secure Payment Application
• UAF Universal Cardholder Authentication Field
• FIG. 1 is an illustrative diagram of a system 100 for implementing a process that may be utilized for verifying a cardholder account ownership (i.e., cardholder authentication) in accordance with the 3-D SecureTM specification.
• FIG. 1 provides, in part, an overview of a cardholder authentication system and process in accordance with the 3-D SecureTM specification.
• all details of the specification are not discussed herein since a complete detailed disclosure of such information may be readily understood by directly referencing the 3-D SecureTM specification and or discussions thereof.
• the concepts and details disclosed herein are not limited to a specific authentication protocol such as 3DS, an exhaustive detailing of the 3DS is not a prerequisite for a complete understanding of the current disclosure.
• System 100 includes a plurality of entities that must interact with each other by exchanging multiple, specifically formatted messages over secure communication channels (as defined in the 3-D SecureTM specification). Accordingly, the cardholder authentication process of FIG 1 is complex given the number and extent of specific entities, messages, and other requirements necessarily involved.
• System 100 includes a cardholder 105 that interacts with a merchant's online presence.
• cardholder 105 visits a merchant's Web site using a browser on their device of choice and selects items (e.g., goods and/or services) for purchase.
• cardholder 105 checks out and finalizes the purchase transaction by providing payment credentials to the merchant.
• the payment credentials may include at least a primary account number (PAN) representative of the account to be used as a source of funds in the transaction, an expiration date associated with the PAN, and (billing) address information of the cardholder.
• PAN primary account number
• the PAN and other information is provided to the merchant's Merchant Server Plug-in (MPI) 110, where the MPI is a software module executed on behalf of the merchant.
• MPI Merchant Server Plug-in
• the MPI 1 10 operates to determine whether payment authentication is available for the PAN received from the cardholder.
• the MPI formats and sends a Verify Enrollment Request (VEReq) message including the PAN to a Directory Sever (DS) 115, where the DS is a computer server that can determine whether the PAN is within a range of PANs enrolled in the authentication service provided by system 100.
• the DS may comprise a computer having at least one processor, a memory to store program instructions and data, and a communication interface to interface with other devices.
• DS 115 Upon receiving the VEReq, DS 115 queries an Access Control Server (ACS) 120 device, where the address of the ACS is specified in the VEReq.
• the address of the ACS may be specified using a Web address URL (uniform resource locator) for the ACS.
• the specified ACS may be an issuer of the account represented by the PAN.
• the ACS may be acting on behalf of the issuer of the PAN and the specified URL points to a Web address other than that of the issuer.
• ACS 120 may respond to the query by providing an indication of whether
• ACS 120 may respond with a Verify Enrollment Response (VERes) message that indicates that authentication is available for the PAN included in the VEReq message.
• ACS 120 uses the PAN from the VEReq to determine whether the cardholder is enrolled in the authentication service.
• VERes Verify Enrollment Response
• the MPI may store data related the ranges of PANS enrolled in the authentication service and determine whether the PAN is within a range of PANs enrolled in the authentication service provided by system 100.
• the VERes may include a flag that authentication is available for the PAN (e.g., a PAN Authentication Available field may be set to "Y" indicating authentication is available).
• ACS 120 may respond with a VERes that indicates that authentication is not available for the PAN (e.g., acquirer BIN and/or PAN not enrolled, ACS unresponsive to query, etc.).
• the VERes may include a flag that authentication is not available for the PAN (e.g., a PAN Authentication Available field may be set to "N" indicating authentication is not available or "U” indicating authentication is unavailable). In the event the VERes includes a flag, a value in a field thereof, or other mechanism to indicate that authentication is not available for the PAN, the authentication process provided by system 100 may be terminate or aborted.
• ACS 120 further sends the VERes including the indication of whether authentication is available to DS 115.
• DS 115 will then forward the VERes to MPI 110. This may conclude the DS's participation in the authentication of the transaction but the authentication process is far from complete.
• MPI 110 Upon receipt of the VERes, MPI 110 reads the response to see if authentication is available for the transaction's PAN. If authentication is available, then MPI 110 sends a message including a Payer Authentication Request (PAReq) message to ACS 120 via the cardholder's browser using the ACS URL included in the VERes.
• the PAReq message requests the issuer ACS to authenticate its cardholder.
• the PAReq may include cardholder, merchant, and transaction-specific information.
• the cardholder information may include security information known only to the cardholder and the issuer. It is noted that the PAReq message is not shared with the merchant (or the MPI).
• ACS 120 receives the PAReq and may proceed to validate the received message to ensure that it is properly formatted and includes the requisite information, including for example, digital certificates and a proper PAN Authentication Available flag (e.g., "Y"). ACS 120 may further determine whether to provide authentication of the cardholder. ACS 120 may provide an indication of that determination by providing a status for the transaction. Values for the status may include, in accordance with 3-D SecureTM, "Y” meaning the customer is fully authenticated, "N” meaning the customer failed or canceled authentication (i.e. transaction denied), "U” meaning the authentication could not be completed (e.g., technical issues such as communication failures, time-outs, etc.), and "A” that provides proof that the authentication was attempted.
• a message is sent from ACS 120 to MPI 110 that includes the transaction status as determined by ACS 120.
• the message may comprise a Payer Authentication Response, PARes message.
• the PARes will include an authentication token, AAV, that is sent to MPI 110.
• the PARes may be digitally signed to offer a level of security regarding the authenticity of the message itself.
• the PARes is received at MPI 110 through the cardholder's browser.
• MPI 110 may operate to validate the signature of the PARes and determine whether to authorize the transaction based, at least in part, on the values comprising the VERes.
• the purchase transaction may proceed to a purchase or payment authorization process and informs the MPI of the AAV value or token.
• the purchase authorization may be accomplished in a conventional manner after the MPI notifies the merchant payment system of the results of the authentication attempt.
• the merchant may still proceed with a conventional transaction authorization without the authentication token, as an unauthenticated transaction. Liability for the processing of an unauthenticated transaction may in some such instances reside with the merchant.
• data including an indication of the unsuccessful cardholder authentication will be documented and maintained.
• a cardholder authentication process may typically be a complex process given the number of parties involved, the number of specific messages that are exchanged between the different entities, the number of determinations that need to be made regarding the content of the exchanged messages, and the secure communication of the messages.
• all relevant phases of the authentication process are maintained in one or more tangible records, messages, or data structures.
• FIG. 2 discloses a system 200 in accordance with some embodiments herein.
• System 200 includes an application 205.
• application 205 may be internal to an enterprise, business, or other organization.
• an "internal" application, service, device, or system is not exposed to a system, device, service, or communication channel outside of the particular enterprise, business, or other organization.
• application 205 may be a software application or service configured in accordance with an API (application program interface) specification herein.
• the API may be referred to as an authentication API herein.
• the authentication API may specify the information to be included in an exchange of information between application 205 and another software application, device, system, or service such as, for example, an enterprise server 210.
• Enterprise server 210 may operate to receive a request for an authentication value or token from application 205 via an API call and in reply to that API call (i.e., request) send an authentication value via an API response to software application 205.
• the requested authentication value may comprise a security code that is compatible with a Universal Cardholder
• UCAF Authentication Field
• the authentication payment environment may comprise a three-domain (3-D) security protocol, although other authentication flows and protocols may be used in some embodiments.
• a process of generating and communicating the API call and the API response in reply thereto and the systems and devices to execute that process are separate and distinct from the security protocol.
• aspects of a method and process herein may, in some instances, provide information to and/or receive information from a process and system comprising a security protocol but be distinct therefrom.
• the request for an authentication value or token may be for a specific, particular transaction, where the authentication value returned or sent to calling application 205 in reply to the API call provides an authentication value that is valid for and specifically associated with the transaction specified in the API call.
• the authentication value or token sent from enterprise server 210 to application 205 may be used by application 205 and/or other applications, systems, devices, and services in one or more processes performed by application 205 and/or the other applications, systems, devices, and services.
• the authentication value generated by enterprise server 210 and sent to application 205 in response to the API call from the application may be used as an indicator (i.e., proof) of a verified authentication and further included in a payment transaction
• the authentication value may be formatted and encoded in a suitable manner (e.g., formatted, encoded, encrypted, etc.) such that a particular authorization request including the
• authentication value herein need not be altered to accommodate the authentication value and otherwise be processed. Accordingly, some embodiments of FIG. 2 may interface with and accommodate systems and processes including those currently known and future developed systems and process that may, at least in part, conform to one or more security protocols. In at least one use-case, the authentication value may be further used in a purchase transaction process including, at least in part, a purchase transaction authorization (e.g., credit card authorization). In some other
• the authentication value obtained by enterprise server 210 in reply to the request by application 205 may be further formatted and/or encoded in a manner to accommodate the request and be compatible with the requesting application 205.
• application 205 makes the authentication request using a single API call to enterprise server 210.
• the enterprise server may provide a reply to application 205 using a single API response.
• an authentication value may be obtained in an efficient process by requesting and receiving an authentication value or token using a single API call from an application. In some aspects, this is in contrast to some
• FIG. 3 discloses logical aspects of an authentication platform including a history server that may record and log an end-to-end transaction flow of every authentication request of an authentication process (e.g., including 3-D SecureTM but not limited thereto). Accordingly, actual systems may include fewer, more, or different devices and entities in arrangements not explicitly shown in FIG, 3, without any loss of generality or applicability.
• system 300 may include a platform that may leverage some aspects of a conventional authentication system such as that disclosed in FIG. 1 (though not limited thereto), as well as some aspects of the system disclosed in FIG. 3.
• system 300 and the processes implemented thereby may operate to process millions of transactions and authentication requests, every single day. Such processing scope and scale, including every authentication request whether the authentication request was completed and the initial purchase transaction is also represented in an associated purchase authorization or whether the authentication request was completed, is made possible by system 300. Accordingly, system 300 necessarily comprises computer devices, systems, and networks that are improved, as opposed to being limited to implementing a known process.
• system 300 includes an application server 310 that may receive payer authentication request (PAReq) messages or other message(s) depending on the authentication protocol being used and payer authentication request (PARes) messages or other message(s) depending on the authentication protocol being used associated with transaction from one or more sources.
• PAReq or other messages and PARes or other messages may be received from an ACS 305 external to an enterprise environment.
• the PAReq messages and PARes messages may be received from an issuer ACS of a system configured, at least in part, similar to system 100 of FIG. 1.
• the transaction PAReq and PARes or other data received from the external ACS's may be requested from external ACS provider(s).
• the PAReq and PARes data received by server 410 may be sent to a database server 425.
• Server 425 also referred to herein as a “history server”, may operate to track, store, format, encode, and/or encrypt the received data to insert the PAReq and PARes or other authentication data into a database table, system, other data structures, and a data storage service.
• server 310 may receive PAReq and PARes data associated with transactions from one or more servers internal to an enterprise environment, such as, for example, from servers 315 and 320.
• Servers 315 and 320 may be one or more devices or systems functioning as, at least in part, an ACS.
• ACS 315 is an internal ACS that may be internal to an enterprise environment such as, for example, the security (ACS) server 215 of FIG. 2.
• system 200 including the enterprise server 210 and other components therein may operate internal to an enterprise environment wherein enterprise 200 generates an authentication value in response to an API call from application or service 205.
• ACS 315 may have transaction PAReq and PARes data or other message(s) depending on the authentication protocol being used.
• server 320 may include an online authentication service ACS provided by an enterprise, whereas in some embodiments server 320 may include other types of ACS servers that may, at least on occasion, communicate with applications, devices, and/or services external to the enterprise environment.
• Server 320 may have transaction PAReq and PARes data or other authentication data associated with certain online and other types of transactions. The PAReq and PARes or other authentication data from servers 315 and 320 may be transmitted to application server 310 and then to history server 325.
• server 315 is the internal ACS that may facilitate the internal generation of an authentication value for a transaction, as discussed with respect to FIG. 2.
• the VEReq and VERes data corresponding to the associated transaction(s) is stored by internal ACS 315. This VEReq and VERes or other message(s) may be transmitted to an application server 340 for, at least, storage purposes.
• VEReq and VERes or other message(s) may be generated with the assistance and in cooperation with external devices, applications, and services, such as system 100 of FIG. 1. Accordingly, the VEReq and VERes or other data associated with some transactions may be received via server 340 from a merchant MPI interface 335 and stored on DS 340.
• server 340 may operate to track, store, format, encode, and/or encrypt the received data to insert the VEReq and VERes or other data into a database table, system, and other data structures.
• an indication of the source or the type of device that provides the VEReq and VERes or other data is included in the VEReq and VERes data or other message(s) depending on the authentication protocol being used. This source indicator may provide insight into whether the authentication token request associated with a particular transaction was generated by an internal process (e.g., FIG. 2) or an external process, device, service, or system.
• the data in both history server 325 i.e., PAReq and PARes or other data
• DS server 345 i.e., VEReq and VERes or other data
• data warehouse 330 may comprise a database management system or an instance of a node of a database management system.
• the combined PAReq PARes or other data and the VEReq VERes or other data may comprise a single data record or data structure representation thereof.
• the combined data record may provide, in addition to other transaction details, an end-to-end view of a transaction flow, including whether authentication was requested by a merchant, whether the authentication was provided by an issuer, whether the authentication was approved or denied, and whether payment authorization for the transaction was requested and whether it was approved or denied.
• the data in the data warehouse 330 may be accessed by other systems and devices (not shown) and used to provide insight into the transactions.
• enterprise level analytics may be used to analyze the data to, for example, generate reports, presentations, and dashboards.
• the data in data warehouse 330 may be used by various organizations of an enterprise to, for example, settle transaction disputes, to manage and respond to issuer or merchant complaints, to manage compliance programs, to manage abandonment rates, etc.
• system 300 facilitates and enables the functionality to determine unique patterns in transactions and better ascertain user and merchant practices (e.g, fraud, etc.) than previous methods of transactional data collection.
• the authentication data processed and collected in accordance with some aspects herein may be used in a process, system, and device to score or provide an indication of a risk level of a particular transaction based on, for example, historical authentication patterns and/or historical authentication velocities of an account or identity.
• the historical authentication activity may, at least in part, be compared to a current request to determine whether the authentication data falls outside (within) observed, expected, desired, calculated, or predicted patterns, ranges, and "norms”.
• the authentication data processed and stored herein may be aggregated in an effort to facilitate analyzing, storing, retrieving, and reporting functions using the data.
• authentication services 505 may be called by an Access Control Server (ACS) or some other system to provide the actual authentication in an "out of band" method, which can include, for example, a one-time passcode generation and validation service, a mobile application, a biometric validation service, and other types of services, processes, applications, and use-cases.
• ACS Access Control Server
• the results of all of these and other requests can also be fed into a data repository within a data warehouse that can be interfaced with other data to provide detailed transactional reporting and analytics.
• an authentication API in accordance with some aspects herein may include one or more data fields.
• Table 1 below is a tabular listing of some data fields that may be specified for implementing an API that may be used by a web service or application in accordance with some embodiments herein.
• the data fields listed in Table 1 may be described in an interface description language (e.g., Web Service Description Language, WSDL) and provided to a developer of a web service or application for use by the developer or other entity to generate a web service or application that may effectively communicate using an appropriately define API.
• WSDL Web Service Description Language
• the authentication API may require or expect a value to be specified for all of the data fields listed in Table 1. That is, the API call may include a corresponding value for each of the data fields listed in the table. In some other embodiments, some but not necessarily all of the data fields specified in Table 1 may have a corresponding value supplied in the API call. For example, some instances of an authentication API herein may specify a value for a PAN (i.e., payment account number), a merchant name, and an expiry date corresponding to the PAN. These minimal values may be included in the API call and may be sufficient for the request of an authentication value in some embodiments herein.
• the data received by or provided to an authentication history server herein contains at least some of the following components:
• Table 1 includes an illustrative sample listing of data for some embodiments herein. The listed data may not be holistic or exhaustive. Accordingly, other data such as high level cardholder information and other transactional data may also be stored or received by and/or provided to an authentication history server in some embodiments herein.
• an application operative in accordance with process 300 may include an electronic payment wallet application developed on behalf of an issuer.
• authentication of the electronic wallet may be assigned or passed to a payment network provider or other entity.
• a payment network provider or other entity At the time of a log-in for the wallet application, there may be some level of authentication that verifies the authenticity or identity of the wallet application with the issuer of the wallet. Accordingly, there may not be a need for a merchant at the time of a purchase involving a customer to authenticate the wallet at a check-out since the wallet application has already been authenticated with the issuer.
• the wallet authentication is done as part of a wallet initiation process.
• the particular authentication may not provide an authentication value or token such as an AAV value that may normally be generated by and/or in accordance with a security protocol.
• the electronic wallet application may request the authentication value via an API call in accordance with the present disclosure.
• the API call may be presented directly to a service to pull an authentication value therefrom.
• the API call from the application may obtain the authentication value without the need to satisfy all of the requirements of one or more security protocols since, for example, the issuer or an entity acting on behalf thereof has agreed to processing of the API call given certain conditions are satisfied.
• an agreement to accept and process the API calls from an application in accordance with the present disclosure are determined before the API call is received by an enterprise server herein (e.g., before an operation 305 of process 300).
• the authentication of the electronic wallet in the present example may be said to comprise a pre-authorized authentication.
• a policy governing the authentication of the electronic wallet or other calling application may vary depending on the calling application, the intended use of the authentication value or token by the calling application, and other considerations.
• the customer registered with the wallet service may be considered to have already been authenticated (i.e., pre-authorized authentication).
• an authentication value or token may be desired for use in a payment authorization request associated with a purchase transaction of the customer.
• the payment authorization request will be expected by an issuer (or entity acting on behalf thereof) to include the authentication value or token.
• the payment authorization may not be processed in the absence of the expected authentication value or token.
• inclusion of the authentication value or token in the payment authorization request may facilitate processing of the payment authorization in accordance with a known, predetermined, or future developed process flow.
• the absence of the expected authentication value or token in the payment authorization request may trigger the processing of the payment authorization in accordance with an alternative or "exceptions" process flow or a termination of the process flow.
• security server 21 may forward a record or representation of the authentication value or token generated by enterprise server 210 to a history server 220.
• History server 220 may further send transaction details to a database 225. The transaction details may be used in further processing, reporting, and analytics.
• FIG. 4 is a block diagram of a system 400 according to some embodiments herein.
• System 400 may include an authentication data management platform 405 that interfaces with or otherwise communicates with one or more authentication systems, devices, applications, services 415.
• authentication management platform 405 may support and facilitate an acquisition, updating, and analysis of customer data and other data related to authentication services.
• authentication systems 415 may include or relate to 3DS authentication systems, services, and applications, although embodiments of the present disclosure including authentication management platform 405 are not limited or restricted to communicating or interfacing with authentication systems
• the one or more authentication systems may or may not be interoperable with each other.
• each of the authentication systems 415 may communicate or otherwise interface with authentication management platform 405.
• communication messages, commands, and/or instructions transmitted and received between authentication systems 415 and authentication management platform 405 may be facilitated by one or more communication interfaces or other devices, services, or applications (not shown) to ensure compatibility of such messages between the authentication systems 415 and authentication management platform 405.
• Authentication management platform 405 may include or at least have access rights to one or more data storage facilities or repositories 410.
• data repository 410 may include a relational database comprising one or more database nodes and manage data for a business enterprise providing, in some instances, data management functions related to authentication services, including but not limited to customer enrollment and customer data management (i.e., also referred to herein as customer enrollment/data management) and billing solution aspects.
• Repository 410 may house and manage all aspects and types of data in various data structures such as, for example, customer contact data related to customers in one or more different organizations within an organization, department, or other business entities of the enterprise.
• Authentication management platform 400 may further include back end systems 420 to support the data acquisition, data processing, and data management functions of authentication platform 405. In some embodiments, back end systems may be organized, at least logically, with business organizations of a business enterprise.
• FIG. 5 is an illustrative depiction of a logical architecture 500 for a system, in accordance with some embodiments herein.
• functions provided, supported, and facilitated by system 500 may be provided or implemented by an authentication management platform such as, for example, platform 400.
• Actual implementations of system 500 may include more or different components than those explicitly depicted in FIG. 5 and may be arranged in other configurations, not just the configuration shown in FIG. 5.
• Other topologies may be used in conjunction with other embodiments.
• each system described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection.
• Each device may include any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions.
• any computing device used in an implementation of some embodiments may include a processor to execute program code such that the computing device operates as described herein
• System 500 includes an authentication portal 505.
• Novel authentication portal 505 provides a mechanism for one or more external users (i.e., users external to an enterprise or business organization providing the services or functions of system 500) to communicate with and otherwise have access to authentication information managed by an authentication management platform herein.
• external users 515 may interface with authentication portal 505 via an external customer main portal 510.
• external customer main portal 510 may include, at least in part, an outwardly facing graphical user interface that can be accessed by a computer or processor-enabled device such as a computer, tablet, or smartphone running an applicable application (e.g., "app").
• External customer main portal 510 may be, in some embodiments, implemented and/or accessed via a browser, a browser extension, or an application programming interface (API).
• external users 515 may include issuers, acquirers, and authorized third parties (e.g., issuer and acquirer service providers) that are enrolled or potentially enrolled in authentication services and applications of an authentication platform herein.
• contact information for external customers 15 may be stored and managed by some implementations of external customer main portal 510.
• EDR 520 An electronic data repository (EDR) 520 is included in system 500.
• EDR 520 may include a data storage facility such as a relational database
• EDR 520 may include, at least in part, a cloud-based storage service, system, or application.
• EDR 520 may be a centralized or a distributed database system comprising one or more database nodes or instances.
• EDR 520 may operate as a validation point for data being entered into or otherwise obtained by system 500 from external customers 500 in an on-going effort to ensure that such data is consistent with and accurately corresponds to data already known and being managed by an enterprise.
• EDR 520 may automatically, based on one or more rules or actionable triggers, updated and validate data herein.
• system 500 further includes a decision management platform or service 525.
• Decision management platform 525 may be a data management device or system (e.g., a relational database system) that stores the externa] customer information for the external customer 1 issuers, acquirers, and authorized third parties.
• decision management platform or service 525 may include an authentication database 530.
• Authentication database 530 may store and maintain records, files, and other data structures representative of customer data including, but not limited to, contracts, notes (e.g., messages, documents, unstructured data, etc.), certification information, credit card ranges, payment device BINs (Bank Identification Numbers), merchant information, and other data.
• System 500 may include an authentication database user interface 35 that provides, internal to an enterprise, an interface for internal authentication users 540 to access and otherwise communicate with decision management platform 525.
• authentication database user interface 535 provides a mechanism for internal authentication users 540 to access authentication information of an authentication platform to provide or at least facilitate customer support functions and business or analyst access to external customer authentication related data (e.g., contact information, billing information, etc.). Access to authentication database via authentication database user interface 535 may be restricted to the internal authentication users depending on a role of the internal authentication user(s).
• FIG. 6 is an illustrative logical depiction for an exchange of data that may be performed by an authentication platform, in accordance with some embodiments herein.
• Data of FIG. 6 may generally be stored and maintained by databases 610 that may be accessed by external users via an external user interface 604 and accessed by internal authentication users through an internal user interface 615.
• databases 610 may be accessed by external users via an external user interface 604 and accessed by internal authentication users through an internal user interface 615.
• a number of different types of data can be provided to databases 610 via external UI 605, including card range information 602, merchant information 604, external user contact information 606, testing and certification data 608, and issuer information 612.
• Other aspects and types of data related to one or more external users of an authentication platform may be encompassed in some instances and
• a number of different types of data can be provided to databases 610 via internal UI 615, including historical card range information 624, merchant information 626, external user contact information 628, testing and certification data 630, and issuer information 632.
• Other aspects and types of data related to one or more internal users of an authentication platform herein may be encompassed in some instances and embodiments herein, in addition to or as a substitute to the specific user information shown in FIG. 6.
• external customer main portal 618 provides similar functionality as the external customer main portal 510 of FIG. 5 and instances of the authentication database 614, 616, 620, and 622 shown in FIG. 6 may provide similar functionality as the authentication database 530 shown in FIG. 5.
• an EDR such as EDR 520 of FIG. 5 provides numerous validation points for the data exchanged between external users, internal users, and the databases represented in FIG. 6.
• FIG. 7 is a block diagram overview of a system or apparatus 700 according to some embodiments.
• System 700 may be, for example, associated with any of the devices described herein, including for example an enterprise server, an authentication database server, and like functionality in accordance with processes disclosed herein.
• System 700 comprises a processor 705, such as one or more commercially available Central Processing Units (CPUs) in the form of one-chip microprocessors or a multi-core processor, coupled to a communication device 715 configured to communicate via a communication network (not shown in FIG. 7) to another device or system.
• CPUs Central Processing Units
• communication device 715 configured to communicate via a communication network (not shown in FIG. 7) to another device or system.
• system 700 comprises a server (e.g., supporting the functions and services provided by an authentication platform herein), communication device 715 may provide a mechanism for system 700 to interface with another device, system, or service (e.g., an instance of an authentication system).
• System 700 may also include a local memory 710, such as RAM memory modules.
• the system further includes an input device 720 (e.g., a touchscreen, mouse and/or keyboard to enter content) and an output device 725 (e.g., a touchscreen, a computer monitor to display, a LCD display).
• Processor 705 communicates with a storage device 730.
• Storage device 730 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, solid state drives, and/or semiconductor memory devices.
• storage device 630 may comprise a database system.
• Storage device 730 may store program code or instructions 735 that may provide computer executable instructions for updating and validating customer authentication data and storing the data records thereof further processing, analysis, and reporting purposes, in accordance with processes herein.
• Processor 705 may perform the instructions of the program instructions 735 to thereby operate in accordance with any of the embodiments described herein.
• Program code 735 may be stored in a compressed, uncompiled and/or encrypted format.
• Program code 735 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 705 to interface with, for example, peripheral devices.
• Storage device 730 may also include data 740 such as database records or look-up tables, including for example records of merchants, issuers, and acquirers participating in a particular authentication program or service and the addresses of the devices used by those entities to implement the service.
• Data 740 may be used by system 700, in some aspects, in performing one or more of the processes herein, including individual processes, individual operations of those processes, and combinations of the individual processes and the individual process operations.
• All systems and processes discussed herein may be embodied in program instructions stored on one or more non-transitory computer-readable, processor-executable media.
• Such media may include, for example, a solid state drive, a floppy disk, a CD-ROM, a DVD-ROM, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units.
• a memory storage unit may be associated with access patterns and may be independent from the device (e.g., magnetic,

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• Accounting & Taxation (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Finance (AREA)
• Computer Security & Cryptography (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Computer Networks & Wireless Communication (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Storage Device Security (AREA)

Priority Applications (6)

Applications Claiming Priority (2)

Publications (1)

Family

ID=56979703

Family Applications (1)

Country Status (8)

Cited By (1)

Families Citing this family (5)

Citations (1)

Family Cites Families (9)

• 2015
  • 2015-09-17 US US14/857,406 patent/US20170083914A1/en not_active Abandoned
• 2016
  • 2016-09-14 CA CA2999236A patent/CA2999236A1/en not_active Abandoned
  • 2016-09-14 WO PCT/US2016/051610 patent/WO2017048766A1/en active Application Filing
  • 2016-09-14 JP JP2018514294A patent/JP2018533131A/ja active Pending
  • 2016-09-14 CN CN201680066001.3A patent/CN108352010A/zh active Pending
  • 2016-09-14 AU AU2016322783A patent/AU2016322783A1/en not_active Abandoned
  • 2016-09-14 BR BR112018004711A patent/BR112018004711A2/pt not_active Application Discontinuation
  • 2016-09-14 EP EP16770182.0A patent/EP3350758A1/en not_active Ceased

Patent Citations (1)

Also Published As

Similar Documents

Legal Events