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
  • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
  • G06Q40/02—Banking, e.g. interest calculation or account maintenance
• • 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/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
• • 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

Definitions

• the present application relates to a method and system for processing financial transactions.
• the payment request includes the customer's authentication data.
• Said encapsulation places private user information in channels that, although protected, are monitored by other agents besides the central platform and the user, such as merchants .
• EP1710980A2 discloses a type of authentication that makes use of the installed capacity in terms of the Subscriber Identity Module (SIM) card to authenticate a mobile device.
• SIM Subscriber Identity Module
• MNO Mobile Network Operators
• the present application discloses a method of operating a financial transaction processing system implemented by computer, comprising the following steps:
• the multiservices platform receives a transaction request, which comprises:
• the multiservices platform correlates a key identifier with at least one application identifier
• the multiservices platform sends a transaction request notification to at least one application identifier, which comprises information about the requested transaction;
• a transaction request notification response which comprises:
• the multiservices platform performs a transaction in at least one external entity via at least one communication channel with external entities
• the multiservices platform sends a notification in response to the transaction request and to the transaction request notification response, which comprises information about the success or failure of the transaction.
• the step of sending a transaction request notification further comprises at least one available payment instrument. In another embodiment, the step of receiving a transaction request notification response comprises at least one choice of payment instrument.
• the step of receiving a transaction request notification response comprises a Dynamic Authentication Token (DAT) .
• DAT Dynamic Authentication Token
• the step of sending a notification (217) comprises a new DAT.
• the method further comprises the following steps:
• a merchant system collects and sends a transaction request to the multiservices platform, which comprises:
• the merchant system receives a notification that comprises information about the success or failure of the required transaction.
• the method further comprises the following steps:
• an application receives and presents a transaction request notification, which comprises:
• the application collects and sends a transaction request notification response, which comprises acceptance information of a transaction request;
• the application receives a notification, which comprises information about the success or failure of a transaction request.
• the step of an application to receive and present a transaction request notification comprises at least one available payment instrument.
• the step of an application to collect and send a transaction request notification response comprises at least one choice of a payment instrument.
• the step of an application to collect and send a transaction request notification response comprises a DAT.
• the step of the application to receive a notification comprises a new DAT.
• the present application also discloses a financial transactions processing system implemented by computer, which comprises:
• - a multiservices platform, which comprises a communications manager
• the present application discloses a physical store, which comprises the system described herein.
• the present application discloses a virtual store, which comprises the system described herein.
• the system disclosed in this application comprises a financial transaction processing environment, called multiservices platform, which receives a transaction request in a channel and the acceptance instruction and subsequent authentication in another secure communication channel with at least one application.
• the multiservices platform In order to perform the acceptance and authentication step, it is necessary that the multiservices platform notifies the application of an entity about the existence of a transaction request. More specifically, it is necessary to solve the problem of forwarding a transaction request to an application based on the key identifier (alias) provided in the transaction request. Accordingly, the multiservices platform comprises a database that relates key identifiers with application identifiers.
• the transaction processing service provided by the system is agnostic to the type of financial operation of each transaction, allowing the customer-side of the service to be based on two strands:
• Figure 1 illustrates the system architecture, wherein the reference signals represent:
• Figure 2 illustrates the elements involved in the accession process, wherein the reference signals represent:
• 103 - Application carries out a first application access by sending an identifier registration request with the key identifier (e.g. mobile phone number), the user authentication code and the application identifier;
• the key identifier e.g. mobile phone number
• 104 - Multiservices platform sends message to the key identifier (e.g. phone number) with an activation code ;
• the activation code read from the message is sent to the multiservices platform;
• DAT Authentication Token
• Figure 3 illustrates the elements involved in processing a transaction, wherein the reference signals represent:
• Multiservice Platform validates customer device based on DAT
• the system's architecture illustrated in figure 1 to receive, process and forward requests for payments made in remote channels based on a key identifier, for example the mobile phone number used by a customer in a shop, comprises:
• At least one application (2) which will ensure security in the capture of the user's personal code and its communication to the platform, and allows the transmission of financial and non- financial transaction management inherent to the management of the service, such as changing the authentication code or associating a key identifier;
• accession channel (3) at least one accession channel (3), so that the user can join the service in a secure way
• At least one merchant system (4) used by merchants in their sales channels, with access to Application Programming Interfaces (API) made available through web services, for access to the processing of their transactions through the multiservices platform;
• API Application Programming Interfaces
• This component which is responsible for providing a layer of services in the standard format of the architecture to send and receive messages.
• This component must provide an applicational interface that allows other architectural components to provide the data for sending messages, such as the origin, destination, model and message means to be used, the data to include in the message and others deemed crucial to the fulfilment of its functions. It is the responsibility of this component to obtain the model to be used, based on own or external repository, and perform the corresponding replacements by the data provided via applicational interface;
• a key identifiers manager (8) to associate and identify financial data, preventing it from being placed or made known through communication channels.
• the multiservices platform (1) will be central in the solution, being responsible for the overall management of the service, in the service configuration strands and its parameters, management of key identifiers, such as the registration of associations between service key identifiers, e.g. mobile phone number, vehicle registration number, ID set-top box, etc., to financial data, e.g. bank cards and accounts, payment transactions management, gathering of statistical data on service usage, among others that may be identified as important for proper service delivery.
• key identifiers such as the registration of associations between service key identifiers, e.g. mobile phone number, vehicle registration number, ID set-top box, etc.
• financial data e.g. bank cards and accounts
• payment transactions management gathering of statistical data on service usage, among others that may be identified as important for proper service delivery.
• the application (2) is the end-user tool for interaction and service management.
• the main function of the application is the implementation of the acceptance and authentication process of the customer in response to a transaction request. This authentication should provide the sufficient degree of security and confidentiality in order to avoid potential misuse. If the user (9) has multiple devices, such as a tablet and a smartphone with the installed application, he will receive transaction request notifications and notifications replicated in the various application identifiers.
• the multiservices platform further comprises a security manager (7), which allows the verification and reallocation of the DAT.
• DAT is used to establish a reliable sequence and is always generated by the multiservices platform (1) . Sending a new DAT to the application is made in the facility thereof for initialization, and whenever a transaction with the server occurs successfully.
• the security manager also deals with the verification and management of authentication codes and the activation of the application, assisting the safe management of the application life cycle.
• the application that collects the authentication code is registered and is univocal, the security being maintained by internal management of DATs.
• the user (9) of the application (2) in order to use the service, will have to accede through a secure accession channel (3), as illustrated in figure 2, to associate its key identifier to the payment instrument, to define its authentication code for the service and to set a maximum daily amount spent.
• the user (9) must download the application (2) for, e.g., a mobile device.
• the user (9) must accept the terms of use of the service and carry out his first login, based on the key identifier and code previously defined in the secure accession channel (3) .
• Any key identifier associated with by the customer or merchant always lacks existence of validation and connection to the user. If we are to consider a personal key identifier, the verifications are directed to the user and require a manual action by the user, such as the reception of a code via short message on the mobile device or through email that has to be manually copied to the mobile application. In the case of a key identifier assigned by an entity, such as a registration number, a Set Top Box, or a club member card, the verification is made on the basis that the request reaches the multiservices platform through a merchant, or even if it is originated in the user it will have interaction with a merchant in the eligibility verification of the key identifier.
• an entity such as a registration number, a Set Top Box, or a club member card
• a message is sent with an activation code via the communications manager (6), internal component of the multiservices platform (1), namely through a form of communication related to a key identifier.
• This activation code must be inserted in the application to enable the service successfully.
• This step represents the exchange of a set of information and customer data and application of the service with the multiservices platform (1) . From the moment the code is placed with the expected success, the application is configured with customer data and the service will be ready for use.
• Sending the message thus validates the ownership of the key customer identifier, and the application, by using secure authentication processes used, for instance, in telecommunications networks.
• a merchant In order for a merchant to accept payments through the service, it has to implement own interfaces, for example functions in the store front for the collection of the customer's key identifier for transaction processing, which will allow channelling the payment transactions for processing in the multiservices platform (1) .
• the merchant's store can exist in various environments, such as physically or remotely over the Internet.
• HTTPS Hypertext Transfer Protocol Secure
• the payment can be started from traders systems having the technical interfaces implemented, for example: e-commerce, m-commerce, television commerce, parking payment machines, vending machines or self-service cash registers. All communications between the merchant's systems (4) and the multiservices platform (1) will be effected through a secure protocol such as the Hypertext Transfer Protocol Secure (HTTPS) . Communications between the merchant and platform are certified on both sides of the communication channel through digital certificates, issued by a trusted certification authority.
• HTTPS Hypertext Transfer Protocol Secure
• the payment can be started from traders systems having the technical interfaces implemented, for example: e-commerce, m-commerce, television commerce, parking payment machines, vending machines or self-service cash registers.
• the multiservices platform After performing some validations of the request information, for example verify whether the key identifier is registered in the service or if the associated payment instrument is valid, the multiservices platform sends a transaction request notification for the application (2) installed on the costumer ' s mobile device.
• the request for authentication of the operation is based on an internal conversion of the multiservices platform where the customer's key identifiers are interpreted and which converts in an application identifier that will allow acceptance, choice of payment instrument and authentication of the operation.
• the customer receives the transaction authentication request notification on his mobile device that directs him to an application screen (2) .
• the payment data are presented, allowing the user to select the payment instrument to be used.
• the customer is prompted to enter his authentication code. After typing and confirming the code, an answer is sent to the multiservices platform that will allow to initiate the payment processing.
• the code may not be required, the confirmation of payment information being sufficient.
• the notification sent by the multiservices platform (1) is received in both devices.
• a key identifier is thus associated with more than one identification application in the applications database.
• the process ends with the communication of the multiservices platform (1) either to the merchant system (4) or to the application (2) .
• This message transmits the information related to the result of success or failure of the financial transaction. Examples of failure are insufficient funds or wrong code.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Engineering & Computer Science (AREA)
• Finance (AREA)
• Physics & Mathematics (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Economics (AREA)
• Marketing (AREA)
• Technology Law (AREA)
• Development Economics (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=54065414

Family Applications (1)

Country Status (3)

Family Cites Families (4)

• 2014
  • 2014-08-01 PT PT107820A patent/PT107820A/pt unknown
• 2015
  • 2015-08-03 WO PCT/IB2015/055889 patent/WO2016016876A1/en active Application Filing
  • 2015-08-03 EP EP15760281.4A patent/EP3195205A1/en not_active Withdrawn

Also Published As

Similar Documents

Legal Events