EP3195205A1

EP3195205A1 - Transactions processing system and method

Info

Publication number: EP3195205A1
Application number: EP15760281.4A
Authority: EP
Inventors: Catarina Rosário GOMES PRIOR GUERRINHA; Jerónimo ALCE PENA RIBEIRO FERREIRA; Luís Miguel PERDIGÃO ALVES RIBEIRO
Original assignee: Sibs - Sgps SA
Current assignee: Sibs - Sgps SA
Priority date: 2014-08-01
Filing date: 2015-08-03
Publication date: 2017-07-26
Also published as: WO2016016876A1; PT107820A

Abstract

The system disclosed in this application results from the need of transactions processing in which they are authorized in a secure way. The system comprises a multiservices platform (1), an application (2) with which the user (9) interacts, an accession system (3), a merchant system (4), at least one communication channel with external entities (5), a communications manager (6), a security manager (7) and a key identifiers manager (8). Its applicability is, for example, transverse to all business sectors who perform sales in physical or virtual stores, and therefore require a connection to a transaction processing system in a secure way and with authentication insurance.

Description

DESCRIPTION

"TRANSACTIONS PROCESSING SYSTEM AND METHOD"

Technical field

The present application relates to a method and system for processing financial transactions.

Background

There are known centralized solutions for processing payment transactions, such as those in document WO2013078898A1 that discloses a method of online payment in which transactions take place, based on information obtained in a device capable of reading the product's bar codes. The information of the customer account and the information of the merchant account are sent through the device to a payment processing platform.

In this type of transaction processing system, 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 .

In another approach, 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. This solution allows isolating the authentication step, however, it has a high degree of dependence of Mobile Network Operators (MNO) . Summary

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:

- a key identifier, and

- information about the transaction to be required;

- 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;

- the multiservices platform receives a transaction request notification response, which comprises:

- acceptance information of the request transaction, and

- authentication information;

- the multiservices platform performs a transaction in at least one external entity via at least one communication channel with external entities; and

- 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.

In one embodiment, 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.

In another embodiment, the step of receiving a transaction request notification response, comprises a Dynamic Authentication Token (DAT) .

In one embodiment, the step of sending a notification (217) comprises a new DAT.

In another embodiment, the method further comprises the following steps:

- a merchant system collects and sends a transaction request to the multiservices platform, which comprises:

- a key identifier, and

- information about the transaction to be required;

- the merchant system receives a notification that comprises information about the success or failure of the required transaction.

In another embodiment, the method further comprises the following steps:

- an application receives and presents a transaction request notification, which comprises:

- information about a required transaction, and

- authentication request information;

- the application collects and sends a transaction request notification response, which comprises acceptance information of a transaction request; and

- the application receives a notification, which comprises information about the success or failure of a transaction request. In one embodiment, the step of an application to receive and present a transaction request notification, comprises at least one available payment instrument.

In one embodiment, the step of an application to collect and send a transaction request notification response comprises at least one choice of a payment instrument.

In one embodiment, the step of an application to collect and send a transaction request notification response, comprises a DAT.

In yet another embodiment, 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;

- at least one communication channel with external entities ;

- at least one merchant system; and

- at least one application,

configured to implement the method described above.

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. General description

The system disclosed in this application results from the need for processing transactions in which these are securely authorized.

There is a tendency of extending the available channels to users and merchants, so they can carry out payment transactions. From the major channels made available, the Internet, mobile phone and television are highlighted. The tendency emphasizes the criticality of a simple, convenient and secure payment.

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.

Resorting to a single communication channel, the introduction of an acceptance and authentication step prior to effective completion of the transaction provides greater security to the transaction. The effective processing of the transactions is carried out after the acceptance and positive authentication in the application, through a communication channel with transaction processing institutions .

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:

- user, by providing, for example, a way to make a purchase or a way to carry out a transfer to another entity;

- merchant, by providing, for example, a way to accept payment in physical or virtual shops.

Its applicability is, for example, transverse to all business sectors who perform sales in physical or virtual stores, and therefore require a connection to a transaction processing system in a secure way and with authentication insurance .

Brief description of drawings

For an easier understanding of the invention, drawings are herein attached, which represent preferred embodiments of the invention which, however, do not intend to limit the scope of the present invention.

Figure 1 illustrates the system architecture, wherein the reference signals represent:

1 - Multiservices platform;

2 - Device and Application;

3 - Accession channel;

4 - Merchant systems; 5 - Systems of the external entities;

6 - Communications manager;

7 - Security manager;

8 - Key identifier manager; and

9 - User

Figure 2 illustrates the elements involved in the accession process, wherein the reference signals represent:

1 - Multiservices platform;

2 - Device and Application;

3 - Accession channel;

5 - Systems of the external entities;

9 - User;

101 - Customer accesses the pre-registration frontend of service accession;

102 - Service accession is sent to multiservices platform, multiservices platform is ready to accept accession via application;

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;

104 - Multiservices platform sends message to the key identifier (e.g. phone number) with an activation code ;

105 - The activation code read from the message is sent to the multiservices platform;

106 - Multiservices platform sends notification with the information concerning the success of the registration request for the application identifier;

107 - Management of financial information; 108 - Multiservices platform sends data to financial information, and synchronizes Dynamic

Authentication Token (DAT) for the application;

109 - Service management actions by means of the accession channel; and

110 - Service management actions through the application.

Figure 3 illustrates the elements involved in processing a transaction, wherein the reference signals represent:

1 - Multiservices platform;

2 - Device and Application;

4 - Merchant systems;

5 - Systems of the external entities;

9 - User;

212 - Customer interacts with merchant providing its key identifier;

213 - Transaction request sent to the multiservices platform;

214 - Transaction request notification sent to customer;

215 - Response to transaction request notification with information about authorization. Multiservice Platform validates customer device based on DAT;

216 - Real time authorization processing of the financial transaction; and

217 - Information on the result of the transaction.

Description of embodiments

Referring to the figures, some embodiments will now be described in more detail, which however are not intended to limit the scope of the present application.

In one embodiment, 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:

- a multiservices platform (1) for authentication, forwarding and processing of transactions;

- 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;

- 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;

- at least one communication channel with external entities (5), to carry out the transactions processing;

- one communications manager (6) 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.

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.

In one embodiment, 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.

This robustness is increased by using a dynamic authentication method updated at each interaction between the platform and the application, and a dynamic game associated with use and time out of authentication codes and terminal use or key identifier verification processes. Associated with these security measures, several service management parameters are defined that pass through the status display of the applications from the device itself, and operation management thereof by the user, means of the service life cycle management and the application, and activation rules of applications or association of financial products to the service.

In order to ensure that main function it is necessary that the application has the capacity to manage payment instruments, such as references for banking or virtual accounts in different external entities associated with the customer service, ensuring, among others, the following features : - receive notifications of new associated payment instruments, as well as the ones dissociated from the service ;

- allow the customer to see which payment instruments are associated with the service;

- allow the customer the choice of payment instruments to be used at the time of payment and that he set a new one default payment instruments; and

- allow the customer to consult the payments: a) made through this service, regardless the payment instruments; b) made by payment instruments associated with the service.

As accessory functions, the user should be able to set some customizations, such as:

- visualization and management of devices connected to the service;

- to consult key identifiers associated with the application; and

- set your financial profile, such as information on the taxpayer number and other financial data.

Installation on the user strand

One user (9), as the final customer, carries out transactions based on its key identifier in the introduction of an authentication code in an application (2) .

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.

Once this initial registration is completed, the user (9) must download the application (2) for, e.g., a mobile device. In addition, 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.

When making the first login, 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.

Installation on the merchant strand

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.

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.

In some embodiments, 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.

In some embodiments, 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.

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) . Here the payment data are presented, allowing the user to select the payment instrument to be used. Then, 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.

In another embodiment, the code may not be required, the confirmation of payment information being sufficient.

In one embodiment, if the user (9) has two mobile devices with applications (2) correctly and fully installed, 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.

The present embodiment is naturally not in any way restricted to the embodiments described herein and a person of ordinary skill in the art can provide many modification possibilities thereof without departing from the general idea, as defined in the claims.

The preferred embodiments described above are of course combinable with one another. The following claims further define preferred embodiments.

Claims

1. A method of operating a financial transaction processing system implemented by computer, characterized in that it comprises the following steps:

- the multiservices platform receives a transaction request (213), which comprises:

- a key identifier, and

- information about the transaction to be required;

- the multiservices platform sends a transaction request notification (214) to at least one application identifier, which comprises information about the requested transaction;

- the multiservices platform receives a transaction request notification response (215) , which comprises :

- acceptance information of the transaction request (213), and

- authentication information;

- the multiservices platform sends a notification (217) in response to the transaction request (213) and to the transaction request notification response (215) , which comprises information about the success or failure of the transaction.

2. Method according to the previous claim, characterized in that the step of sending a transaction request notification (214) further comprises at least one available payment instrument.

3. Method according to any one of the previous claims, characterized in that the step of receiving a transaction request notification response (215) comprises at least one choice of payment instrument.

4. Method according to any one of the previous claims, characterized in that the step of receiving a transaction request notification response (215) comprises at least one Dynamic Authentication Token (DAT) .

5. Method according to any one of the previous claims, characterized in that the step of sending a notification (217) comprises a new DAT.

6. Method according to any one of the previous claims, characterized by further comprising the following steps :

- a merchant system collects and sends a transaction request (213) to the multiservices platform, which comprises :

- a key identifier, and

- information about the transaction to be required;

- the merchant system receives a notification (217), that comprises information about the success or failure of the required transaction.

7. Method according to any one of the previous claims, characterized by further comprising the following steps :

- an application receives and presents a transaction request notification (214), which comprises:

- information about a required transaction, and

- authentication request information;

- the application collects and sends a transaction request notification response (215) , which comprises acceptance information of a transaction request; and

the application receives a notification (217), which comprises information about the success or failure of a transaction request.

8. Method according to the previous claim, characterized in that the step of an application to receive and present a transaction request notification (214), comprises at least one available payment instrument.

9. Method according to any one of the claims 7 to 8, characterized in that the step of an application to collect and send a transaction request notification response (215) , comprises at least one choice of payment instrument.

Method according to any one of the claims 7 to 9, characterized in that the step of an application to collect and send a transaction request notification response (215), comprises a DAT.

11. Method according to any one of the claims 7 to 10, characterized in that the step of an application receives a notification (217), comprises a new DAT.

12. A financial transactions processing system implemented by computer, characterized in that it comprises:

- a multiservices platform, which comprises a communications manager;

- at least one communication channel with external entities ;

- at least one merchant system; and

- at least one application,

configured to implement the method described in any one of the previous claims.

13. Physical store, characterized in that it comprises the system described in the previous claim.

14. Virtual store, characterized in that it comprises the system described in claim 12.