PT107820A - Sistema e método de processamento de transações - Google Patents

Sistema e método de processamento de transações Download PDF

Info

Publication number
PT107820A
PT107820A PT107820A PT10782014A PT107820A PT 107820 A PT107820 A PT 107820A PT 107820 A PT107820 A PT 107820A PT 10782014 A PT10782014 A PT 10782014A PT 107820 A PT107820 A PT 107820A
Authority
PT
Portugal
Prior art keywords
transaction
application
transaction request
information
notification
Prior art date
Application number
PT107820A
Other languages
English (en)
Inventor
Catarina Rosário Gomes Prior Guerrinha
Jerónimo Alce Pena Ribeiro Ferreira
Luis Miguel Perdigão Alves Ribeiro
Original Assignee
Sibs Sgps S A
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sibs Sgps S A filed Critical Sibs Sgps S A
Priority to PT107820A priority Critical patent/PT107820A/pt
Priority to PCT/IB2015/055889 priority patent/WO2016016876A1/en
Priority to EP15760281.4A priority patent/EP3195205A1/en
Publication of PT107820A publication Critical patent/PT107820A/pt

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (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)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

O SISTEMA DIVULGADO NO PRESENTE PEDIDO RESULTA DA NECESSIDADE DE PROCESSAMENTO DE TRANSAÇÕES EM QUE ESTAS SÃO AUTORIZADAS DE FORMA SEGURA. O SISTEMA COMPREENDE UMA PLATAFORMA MULTISSERVIÇOS (1), UMA APLICAÇÃO (2) COM A QUAL O UTILIZADOR (9) INTERAGE, UM SISTEMA DE ADESÃO (3), UM SISTEMA DE COMERCIANTE (4), PELO MENOS UM CANAL DE COMUNICAÇÃO COM ENTIDADES EXTERNAS (5), UM GESTOR DE COMUNICAÇÕES (6), UM GESTOR DE SEGURANÇA (7) E UM GESTOR DE IDENTIFICADORES CHAVE (8). A SUA APLICABILIDADE É, POR EXEMPLO, TRANSVERSAL A TODOS OS SECTORES DE ATIVIDADE QUE REALIZAM VENDAS EM LOJAS FÍSICAS OU VIRTUAIS, E POR ISSO NECESSITAM DE UMA LIGAÇÃO A UM SISTEMA DE PROCESSAMENTO DE TRANSAÇÕES COM SEGURANÇA E GARANTIA DE AUTENTICAÇÃO.

Description

DESCRIÇÃO "SISTEMA E MÉTODO DE PROCESSAMENTO DE TRANSAÇÕES" Domínio técnico 0 presente pedido diz respeito a um método e sistema de processamento de transações financeiras.
Estado da técnica
Conhecem-se soluções centralizadas para o processamento de transações de pagamento, como por exemplo o documento WO2013078898A1 que divulga um método de pagamento online em que as transações se realizam a partir de informações obtidas num dispositivo com capacidade de leitura de códigos de barras dos produtos. As informações da conta do cliente e as informações de conta de comerciante são enviadas através do dispositivo para uma plataforma de processamento de pagamentos.
Neste tipo de sistema de processamento de transações, o pedido de pagamento compreende os dados de autenticação do cliente. 0 encapsulamento referido coloca informações privadas dos utilizadores em canais que, embora protegidos, são monitorizados por outros agentes para além da plataforma central e do utilizador, como por exemplo os comerciantes.
Numa outra abordagem, o documento EP1710980A2 divulga um tipo de autenticação que se serve da capacidade instalada ao nivel do cartão Módulo de Identificação do Assinante (Subscriber Identity Module - SIM) para autenticar um dispositivo móvel. Esta solução permite isolar a etapa de autenticação, no entanto tem um alto grau de dependência dos Operadores de Redes Moveis (Mobile Network Operator - MNO) .
Sumário 0 presente pedido divulga um método de operação de um sistema de processamento de transações financeiras implementado por computador, que compreende as seguintes etapas: - a plataforma multisserviços recebe um pedido de transação, que compreende: - um identificador chave, e - informações sobre a transação a requerer; - a plataforma multisserviços correlaciona um identificador chave com pelos menos um identificador de aplicação; - a plataforma multisserviços envia uma notificação de pedido de transação para pelo menos um identificador de aplicação, que compreende informação sobre a transação requerida; - a plataforma multisserviços recebe uma resposta de notificação de pedido de transação, que compreende: - informação de aceitação do pedido de transação, e - informação de autenticação; - a plataforma multisserviços realiza uma transação em pelo menos uma entidade externa através do pelo menos um canal de comunicação com entidades externas; e - a plataforma multisserviços envia uma notificação em resposta ao pedido de transação e à resposta de notificação de pedido de transação, que compreende informação do sucesso ou insucesso da transação.
Numa forma de realização, a etapa de envio de uma notificação de pedido de transação, compreende ainda pelo menos um instrumento de pagamento disponível.
Numa outra forma de realização, a etapa de recebimento de uma resposta de notificação de pedido de transação, compreende pelo menos uma escolha de instrumento de pagamento.
Ainda numa outra forma de realização, a etapa de recebimento de uma resposta de notificação de pedido de transação, compreende um Token Dinâmico de Autenticação (TDA).
Numa forma de realização, a etapa de envio de uma notificação (217), compreender um TDA novo.
Numa outra forma de realização, o método compreende ainda as seguintes etapas: - um sistema de comerciante recolhe e envia um pedido de transação para a plataforma multisserviços, que compreende: - um identificador chave, e - informações sobre a transação a requerer; - o sistema de comerciante recebe uma notificação, que compreende informação do sucesso ou insucesso da transação requerida.
Numa outra forma de realização, o método compreende ainda as seguintes etapas: - uma aplicação recebe e apresenta uma notificação de pedido de transação, que compreende: - informação sobre uma transação requerida, e - informação de pedido de autenticação; - a aplicação recolhe e envia uma resposta de notificação de pedido de transação, que compreende informação de aceitação de um pedido de transação; e - a aplicação recebe uma notificação, que compreende informação do sucesso ou insucesso de um pedido de transação.
Ainda numa outra forma de realização, a etapa de uma aplicação receber e apresentar uma notificação de pedido de transação, compreende pelo menos um instrumento de pagamento disponível.
Numa forma de realização, a etapa de uma aplicação recolher e enviar uma resposta de notificação de pedido de transação, compreende pelo menos uma escolha de um instrumento de pagamento.
Numa outra forma de realização, a etapa de uma aplicação recolher e enviar uma resposta de notificação de pedido de transação, compreende um TDA.
Ainda numa outra forma de realização, a etapa de a aplicação receber uma notificação, compreende um TDA novo. 0 presente pedido divulga também um sistema para o processamento de transações financeiras implementado por computador, que compreende: - uma plataforma multisserviços, que compreende um gestor de comunicações; - pelo menos um canal de comunicação com entidades externas; - pelo menos um sistema de comerciante; e - pelo menos uma aplicação, configurado para implementar o método descrito em qualquer uma das reivindicações anteriores. 0 presente pedido divulga uma loja física, que compreende o sistema aqui descrito. 0 presente pedido divulga ainda uma loja virtual, que compreende o sistema aqui descrito.
Descrição geral 0 sistema divulgado no presente pedido resulta da necessidade de processamento de transações em que estas são autorizadas de forma segura.
Verifica-se uma tendência de alargamento dos canais ao dispor de utilizadores e comerciantes para realizar transações de pagamento. Dos principais canais disponibilizados destaca-se a Internet, o telemóvel e a televisão. A tendência vem acentuar a criticidade do pagamento simples, cómodo e seguro. 0 sistema divulgado no presente pedido compreende um ambiente de processamento de transações financeiras, chamado de plataforma multisserviços, que recebe um pedido de transação num canal e a instrução de aceitação e autenticação consequente num outro canal de comunicação seguro com pelo menos uma aplicação.
Recorrendo a um canal de comunicação isolado, a introdução de uma etapa de aceitação e autenticação anterior à concretização efetiva da transação garante maior segurança à transação. 0 processamento efetivo das transações realiza-se posteriormente à aceitação e autenticação positiva na aplicação, através de um canal de comunicação com instituições de processamento de transações.
Para que a etapa de aceitação e autenticação se realize, é necessário que a plataforma multisserviços notifique a aplicação de uma entidade da existência de um pedido de transação. Mais especificamente, é necessário resolver o problema de encaminhar um pedido de transação para uma aplicação com base no identificador chave (alias) fornecido no pedido de transação. Nesse sentido, a plataforma multisserviços compreende uma base de dados que relaciona identificadores chave com identificadores de aplicação. 0 serviço de processamento de transações fornecido pelo sistema é agnóstico ao tipo de operação financeira de cada transação, podendo o lado cliente do serviço assentar em duas vertentes: - utilizador, disponibilizando, por exemplo, uma forma de efetuar uma compra ou uma maneira de realizar uma transferência para outra entidade; - comerciante, disponibilizando, por exemplo, uma forma de aceitar pagamentos numa loja física ou virtual. A sua aplicabilidade é, por exemplo, transversal a todos os sectores de atividade que realizam vendas em lojas físicas ou virtuais, e por isso necessitam de uma ligação a um sistema de processamento de transações com segurança e garantia de autenticação.
Breve descrição das figuras
Para uma mais fácil compreensão do presente pedido juntam-se em anexo figuras, as quais, representam realizações preferenciais que, contudo, não pretendem limitar a técnica aqui divulgada. A figura 1 ilustra a arquitetura do sistema, em que os sinais de referência representam: 1 - Plataforma multisserviços; 2 - Dispositivo e Aplicação; 3 - Canal de adesão; 4 - Sistemas de comerciante; 5 - Sistemas das entidades externas; 6 - Gestor de comunicações; 7 - Gestor de segurança; 8 - Gestor de identificador chave; e 9 - Utilizador A figura 2 ilustra os elementos envolvidos no processo de adesão, em que os sinais de referência representam: 1 - Plataforma multisserviços; 2 - Dispositivo e aplicação; 3 - Canal de adesão; 5 - Sistemas das entidades externas; 9 - Utilizador; 101 - Cliente acede a frontend de pré registo de adesão de serviço; 102 - Adesão de serviço enviada para plataforma multisserviços, plataforma multisserviços pronta para aceitar adesão via aplicação; 103 - Aplicação realiza um primeiro acesso da aplicação, enviando um pedido de registo de indentificador de aplicação com o identificador chave (por exemplo o número de telemóvel), o código de autenticação do utilizador e o identificador de aplicação; 104 - Plataforma multisserviços envia mensagem para o identificador chave (por exemplo o número de telemóvel) com um código de ativação; 105 - Envio para a plataforma multisserviços do código de ativação lido a partir da mensagem; 106 - Plataforma multisserviços envia notificação com a informação de sucesso do pedido de registo de identificador de aplicação; 107 - Gestão de informação financeira; 108 - Plataforma multisserviços envia dados de informação financeira, e sincroniza Token Dinâmico de
Autenticação (TDA) para a aplicação; 109 - Ações de gestão do serviço via canal de adesão; e 110 - Ações de gestão do serviço através da aplicação. A figura 3 ilustra a os elementos envolvidos no processamento de uma transação, em que os sinais de referência representam: 1 - Plataforma multisserviços; 2 - Dispositivo e aplicação; 4 - Sistemas de comerciante; 5 - Sistemas das entidades externas; 9 - Utilizador; 212 - Cliente interage com comerciante fornecendo o seu identificador chave; 213 - Pedido de transação enviado à plataforma multisserviços; 214 - Envio de notificação de pedido de transação ao cliente; 215 - Resposta a notificação de pedido de transação com informação sobre autorização. Plataforma
Multisserviços valida dispositivo de cliente com base no TDA; 216 - Processamento da autorização da transação financeira em real time; e 217 - Informação sobre o resultado da transação.
Descrição de formas de realização
Fazendo referência às figuras, algumas formas de realização vão ser agora descritas de forma mais pormenorizada, as quais não pretendem contudo limitar o âmbito do presente pedido.
Numa forma de realização, a arquitetura do sistema, ilustrada na figura 1, para receber, tratar e encaminhar pedidos de pagamentos efetuados em canais remotos com base num identificador chave, por exemplo o número de telemóvel utilizado por um cliente de uma loja, compreende: - uma plataforma multisserviços (1) para a autenticação, encaminhamento e processamento de transações; - pelo menos uma aplicação (2), que irá garantir a segurança na captura do código pessoal do utilizador e a sua comunicação para a plataforma, e permite a transmissão de instruções de gestão de transações financeiras e não financeiras inerentes à gestão do serviço, como por exemplo alterar o código de autenticação ou associar um identificador chave; - pelo menos um canal de adesão (3), para que o utilizador possa aderir ao serviço de forma segura; - pelo menos um sistema de comerciante (4), utilizado por parte dos comerciantes nos seus canais de venda, com acesso a Interfaces de Programação de Aplicação (Application Programming Interface - API) disponibilizadas através de serviços web, para acesso ao processamento das suas transações através da plataforma multisserviços; - pelo menos um canal de comunicação com entidades externas (5), para realizar o processamento de transações; - um gestor de comunicações (6) que é responsável por fornecer uma camada de serviços em formato standard da arquitetura para o envio e receção de mensagens. Esta componente deve fornecer uma interface aplicacional que permita outras componentes da arquitetura fornecerem os dados para envio de mensagens, como por exemplo, a origem, o destino, o modelo e meios de mensagem a utilizar, os dados a incluir na mensagem e outros que sejam cruciais ao cumprimento das suas funções. É responsabilidade desta componente a obtenção do modelo a utilizar, a partir de repositório próprio ou externo, e realizar as correspondentes substituições pelos dados fornecidos via interface aplicacional; - um gestor de identificadores chave (8), para associar e identificar dados financeiros, evitando que estes sejam colocados ou dados a conhecer através dos canais de comunicação. A plataforma multisserviços (1) será central na solução, sendo responsável pela gestão integral do serviço, nas vertentes de configuração de serviço e seus parâmetros, gestão de identificadores chave, como por exemplo o registo de associações entre identificadores chave de serviço, e.g. n° de telemóvel, matricula automóvel, ID set-top-box, etc., a dados financeiros, e.g. cartões bancários e contas, gestão de transações de pagamentos, obtenção de dados estatísticos de utilização de serviço, entre outras que possam ser identificadas como importantes para a correta prestação do serviço. A aplicação (2) é a ferramenta do utilizador final para interação e gestão do serviço. A aplicação tem como função principal a implementação do processo de aceitação e autenticação do cliente em resposta a um pedido de transação. Essa autenticação deverá fornecer o grau suficiente de segurança e confidencialidade, de modo a evitar potenciais utilizações fraudulentas. Caso o utilizador (9) tenha vários dispositivos, como por exemplo um tablet e um smartphone, com a aplicação instalada, este receberá notificações de pedido de transação e notificações replicadas nos vários identificadores de aplicação.
Numa forma de realização, a plataforma multisserviços compreende ainda um gestor de segurança (7), que permite a verificação e reatribuição do TDA. 0 TDA serve para estabelecer uma sequência de confiança e é sempre gerado pela plataforma multisserviços (1) . 0 envio de um novo TDA para a aplicação é realizado na instalação da mesma para inicialização, e sempre que uma transação com o servidor ocorre com sucesso. 0 gestor de segurança trata ainda da verificação e gestão dos códigos de autenticação e de ativação da aplicação auxiliando a gestão segura do ciclo de vida da aplicação. A aplicação que recolhe o código de autenticação está registada e é unívoca sendo a sua segurança mantida por uma gestão interna de TDAs.
Esta robustez é incrementada através da utilização de um método dinâmico de autenticação atualizado em cada interação entre a plataforma e a aplicação, e de um jogo de dinâmica associadas ao uso e time out de códigos de autenticação e processos de verificação de uso de terminais ou identificador chave. Associado a estas medidas de segurança estão definidos vários parâmetros de gestão do serviço que passam pela visualização de estado das aplicações a partir do próprio dispositivo, e gestão do funcionamento dos mesmos pelo utilizador, meios de gestão do ciclo de vida do serviço e da aplicação, e regras de ativação de aplicações ou associação de produtos financeiros ao serviço.
De modo a garantir essa função principal é necessário que a aplicação detenha a capacidade de gerir instrumentos de pagamento, como por exemplo referências para contas bancárias ou virtuais em diferentes entidades externas, associados ao serviço do cliente, assegurando, entre outras, as seguintes funcionalidades: - receber notificações de novos instrumentos de pagamento associados, bem como os dissociados do serviço; - permitir que o cliente veja que instrumentos de pagamento se encontram associados ao serviço; - permitir ao cliente a escolha de instrumentos de pagamento a utilizar no momento do pagamento e que este defina um novo instrumentos de pagamento por omissão; e - permitir ao cliente a consulta dos pagamentos: a) que efetuou através deste serviço independentemente do instrumentos de pagamento de pagamento; b) que efetuou por instrumentos de pagamento associado ao serviço.
Como funções acessórias, o utilizador deve poder definir algumas personalizações, como por exemplo: - visualização e gestão dos dispositivos ligados ao serviço; - consultar identificadores chave associado à aplicação; e - definir o seu perfil financeiro, como por exemplo informação sobre o número de contribuinte e outros dados financeiros.
Instalação na vertente de utilizador
Um utilizador (9), enquanto cliente final, realiza transações com base no seu identificador chave na introdução de um código de autenticação numa aplicação (2). 0 utilizador (9) da aplicação (2), para poder utilizar o serviço, terá que aderir ao mesmo através de um canal de adesão (3) seguro, tal como ilustrado na figura 2, associar o seu identificador chave ao instrumento de pagamento, definir o seu código de autenticação para o serviço e definir um valor de gasto máximo diário.
Uma vez terminado este registo inicial, o utilizador (9) deverá descarregar a aplicação (2) para, por exemplo, um dispositivo móvel. Além disso, o utilizador (9) deverá aceitar os termos de utilização do serviço e efetuar o seu primeiro inicio de sessão, com base no identificador chave e código definido previamente no canal de adesão (3) seguro.
Qualquer identificador chave associado pelo cliente ou comerciante, carece sempre de validação de existência e ligação ao utilizador. Se estivermos a considerar um identificador chave pessoal, as verificações são direcionadas ao utilizador e obrigam a uma ação manual por parte do utilizador, como por exemplo, a receção de um código através de mensagem curta no dispositivo móvel ou através de correio eletrónico que tem que ser manualmente copiado para a aplicação móvel. No caso de um identificador chave atribuído por uma entidade, como por exemplo uma matrícula, uma Set Top Box, ou um cartão de sócio de um clube, a verificação é feita tendo por base que o pedido chega à plataforma multisserviços através de um comerciante, ou mesmo que tenha origem no utilizador, o mesmo terá interação com um comerciante na verificação da elegibilidade do identificador chave.
Ao efetuar o primeiro início de sessão, é enviado uma mensagem com um código de ativação através do gestor de comunicações (6), componente interna da plataforma multisserviços (1), nomeadamente através de uma forma de comunicação relacionada com um identificador chave. Este código de ativação deverá ser inserido na aplicação para ativar o serviço com sucesso. Este passo representa a troca de um conjunto de informação e de dados de cliente e aplicação do serviço com a plataforma multisserviços (1). A partir do momento em que o código for colocado com o sucesso esperado, a aplicação é configurada com os dados do cliente e o serviço estará pronto a ser utilizado. 0 envio da mensagem valida assim a titularidade do identificador chave do cliente, e da aplicação, ao utilizar processos de autenticação seguros utilizados, por exemplo, em redes de telecomunicações.
Instalação na vertente de comerciante
Para que um comerciante aceite pagamentos através do serviço, este tem que implementar interfaces próprios, como por exemplo funções na frente de loja para recolha do identificador chave do cliente para processamento da transação, que permitirão canalizar as transações de pagamento para processamento na plataforma multisserviços (1). A loja do comerciante pode existir em vários ambientes, como por exemplo fisicamente ou remotamente na Internet.
Todas as comunicações entre os sistemas do comerciante (4) e a plataforma multisserviços (1) serão efetuadas através de um protocolo seguro, como por exemplo o Hypertext Transfer Protocol Secure (HTTPS). As comunicações entre o comerciante e plataforma são autenticadas em ambos os lados do canal de comunicação através de certificados digitais, emitidos por uma entidade de certificação de confiança.
Em algumas formas de realização, o pagamento pode ser iniciado a partir de sistemas de comerciantes que tenham os interfaces técnicos implementados, como por exemplo: websites de comércio online (e-commerce), comércio móvel (m-commerce), comércio televisivo (tv commerce), máquinas de pagamento de estacionamento, máquinas de venda automática (vending machines) ou caixas de pagamento self-service.
Exemplo 1: Compra presencial ou remota A figura 3 ilustra um exemplo de uma transação de pagamento numa loja física ou virtual em que o cliente tem em seu poder um dispositivo móvel com a aplicação instalada. 0 cliente começa por indicar ao comerciante o seu identificador chave. Com essa informação, o comerciante utiliza um sistema de comerciante (4) , para dar início do pedido de pagamento, realizando neste caso o papel de requerente de transação. Este pedido compreende o valor a cobrar ao cliente e o identificador chave indicado, entre outros dados necessários e críticos ao correto processamento financeiro da transação.
Após efetuar algumas validações da informação do pedido, como por exemplo verificar se o identificador chave está registado no serviço ou se o instrumento de pagamento associado é válido, a plataforma multisserviços envia uma notificação de pedido de transação para a aplicação (2) instalada no dispositivo móvel do cliente. 0 pedido de autenticação da operação é feito com base numa conversão interna da plataforma multisserviços onde interpreta os identificadores chave do cliente e converte num identificador de aplicação que vai permitir a aceitação, escolha do instrumento de pagamento e autenticação da operação. 0 cliente recebe a notificação de pedido de autenticação de transação no seu dispositivo móvel que o direciona para um ecrã da aplicação (2) . Aqui são apresentados os dados de pagamento, permitindo ao utilizador selecionar o instrumento de pagamento a utilizar. Em seguida, é solicitado ao cliente que digite o seu código de autenticação. Depois de digitar e confirmar o código, é enviada resposta para a plataforma multisserviços que permitirá dar início ao processamento do pagamento.
Numa outra forma de realização, pode não ser solicitado o código, ficando-se pela confirmação dos dados de pagamento.
Numa forma de realização, se o utilizador (9) possuir dois dispositivos móveis com aplicações (2) instaladas de forma correta e completa, a notificação enviada pela plataforma multisserviços (1) é recebida nos dois dispositivos. Um identificador chave é assim associado a mais do que uma aplicação na base de dados de identificação de aplicações. 0 processo termina com a comunicação da plataforma multisserviços (1) quer para o sistema de comerciante (4), quer para a aplicação (2). Esta mensagem transmite a informação relacionada com o resultado de sucesso ou insucesso da transação financeira. São exemplos de insucesso o saldo insuficiente ou código errado. A presente realização não é, naturalmente, de modo algum restrita às realizações descritas neste documento e uma pessoa com conhecimentos médios da área poderá prever muitas possibilidades de modificação da mesma sem se afastar da ideia geral, tal como definido nas reivindicações.
As realizações preferenciais acima descritas são obviamente combináveis entre si. As seguintes reivindicações definem adicionalmente realizações preferenciais.
Lisboa, 29 de julho de 2015

Claims (14)

  1. REIVINDICAÇÕES 1. Um método de operação de um sistema de processamento de transações financeiras implementado por computador, caracterizado por compreender as seguintes etapas: - a plataforma multisserviços recebe um pedido de transação (213), que compreende: - um identificador chave, e - informações sobre a transação a requerer; - a plataforma multisserviços correlaciona um identificador chave com pelos menos um identificador de aplicação; - a plataforma multisserviços envia uma notificação de pedido de transação (214) para pelo menos um identificador de aplicação, que compreende informação sobre a transação requerida; - a plataforma multisserviços recebe uma resposta de notificação de pedido de transação (215), que compreende: - informação de aceitação do pedido de transação (213), e - informação de autenticação; - a plataforma multisserviços realiza uma transação em pelo menos uma entidade externa através do pelo menos um canal de comunicação com entidades externas; e - a plataforma multisserviços envia uma notificação (217) em resposta ao pedido de transação (213) e à resposta de notificação de pedido de transação (215), que compreende informação do sucesso ou insucesso da transação.
  2. 2. Método de acordo com a reivindicação anterior, caracterizado por a etapa de envio de uma notificação de pedido de transação (214), compreender ainda pelo menos um instrumento de pagamento disponível.
  3. 3. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por a etapa de recebimento de uma resposta de notificação de pedido de transação (215), compreender pelo menos uma escolha de instrumento de pagamento.
  4. 4. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por a etapa de recebimento de uma resposta de notificação de pedido de transação (215), compreender um Token Dinâmico de Autenticação (TDA).
  5. 5. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por a etapa de envio de uma notificação (217), compreender um TDA novo.
  6. 6. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por compreender ainda as seguintes etapas: - um sistema de comerciante recolhe e envia um pedido de transação (213) para a plataforma multisserviços, que compreende: - um identificador chave, e - informações sobre a transação a requerer; - o sistema de comerciante recebe uma notificação (217), que compreende informação do sucesso ou insucesso da transação requerida.
  7. 7. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por compreender ainda as seguintes etapas: - uma aplicação recebe e apresenta uma notificação de pedido de transação (214), que compreende: - informação sobre uma transação requerida, e - informação de pedido de autenticação; - a aplicação recolhe e envia uma resposta de notificação de pedido de transação (215), que compreende informação de aceitação de um pedido de transação; e - a aplicação recebe uma notificação (217), que compreende informação do sucesso ou insucesso de um pedido de transação.
  8. 8. Método de acordo com a reivindicação anterior, caracterizado por a etapa de uma aplicação receber e apresentar uma notificação de pedido de transação (214), compreender pelo menos um instrumento de pagamento disponível.
  9. 9. Método de acordo com qualquer uma das reivindicações de 7 a 8, caracterizado por a etapa de uma aplicação recolher e enviar uma resposta de notificação de pedido de transação (215), compreender pelo menos uma escolha de um instrumento de pagamento.
  10. 10. Método de acordo com qualquer uma das reivindicações de 7 a 9, caracterizado por a etapa de uma aplicação recolher e enviar uma resposta de notificação de pedido de transação (215), compreender um TDA.
  11. 11. Método de acordo com qualquer uma das reivindicações de 7 a 10, caracterizado por a etapa de a aplicação receber uma notificação (217), compreender um TDA novo.
  12. 12. Um sistema para o processamento de transações financeiras implementado por computador, caracterizado por compreender: - uma plataforma multisserviços, que compreende um gestor de comunicações; - pelo menos um canal de comunicação com entidades externas; - pelo menos um sistema de comerciante; e - pelo menos uma aplicação, configurado para implementar o método descrito em qualquer uma das reivindicações anteriores.
  13. 13. Loja física, caracterizada por compreender o sistema descrito na reivindicação anterior.
  14. 14. Loja virtual, caracterizada por compreender o sistema descrito na reivindicação 12. Lisboa, 29 de julho de 2015
PT107820A 2014-08-01 2014-08-01 Sistema e método de processamento de transações PT107820A (pt)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PT107820A PT107820A (pt) 2014-08-01 2014-08-01 Sistema e método de processamento de transações
PCT/IB2015/055889 WO2016016876A1 (en) 2014-08-01 2015-08-03 Transactions processing system and method
EP15760281.4A EP3195205A1 (en) 2014-08-01 2015-08-03 Transactions processing system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PT107820A PT107820A (pt) 2014-08-01 2014-08-01 Sistema e método de processamento de transações

Publications (1)

Publication Number Publication Date
PT107820A true PT107820A (pt) 2016-02-01

Family

ID=54065414

Family Applications (1)

Application Number Title Priority Date Filing Date
PT107820A PT107820A (pt) 2014-08-01 2014-08-01 Sistema e método de processamento de transações

Country Status (3)

Country Link
EP (1) EP3195205A1 (pt)
PT (1) PT107820A (pt)
WO (1) WO2016016876A1 (pt)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7606560B2 (en) 2002-08-08 2009-10-20 Fujitsu Limited Authentication services using mobile device
US20130054461A1 (en) * 2011-08-23 2013-02-28 Infosys Limited Methods, systems, and computer-readable media for electronic financial transfers
CN102542443A (zh) 2011-12-02 2012-07-04 惠州Tcl移动通信有限公司 一种在线支付方法及相应的设备
US10515359B2 (en) * 2012-04-02 2019-12-24 Mastercard International Incorporated Systems and methods for processing mobile payments by provisioning credentials to mobile devices without secure elements

Also Published As

Publication number Publication date
EP3195205A1 (en) 2017-07-26
WO2016016876A1 (en) 2016-02-04

Similar Documents

Publication Publication Date Title
US10572874B1 (en) Dynamic authorization with adaptive levels of assurance
KR102420969B1 (ko) 네트워크 아키텍처 내에 인증 서비스를 통합하기 위한 시스템 및 방법
US20210006410A1 (en) Method for providing virtual asset service based on decentralized identifier and virtual asset service providing server using them
CA2662033C (en) Transaction authorisation system & method
JP2020517201A (ja) ブロックチェーン基盤のトークンidを利用してカード使用を承認する方法及びこれを利用したサーバ{method for approving use of card by using blockchain−based token id and server using method}
US20150135279A1 (en) Personal identity control
US20130226813A1 (en) Cyberspace Identification Trust Authority (CITA) System and Method
CN108369700A (zh) 移动支付系统
US20180026970A1 (en) Preventing Unauthorized Access to Secured Information Systems Using Multi-Device Authentication Techniques
CN106664208A (zh) 使用安全传输协议建立信任的系统和方法
US11240220B2 (en) Systems and methods for user authentication based on multiple devices
KR102050271B1 (ko) 블록체인 기반의 결제 방법 및 이를 이용한 지급 결제 서버
WO2018222730A1 (en) System of hardware and software to prevent disclosure of personally identifiable information
CA2930752A1 (en) System and method for location-based financial transaction authentication
KR20110107311A (ko) 모바일 네트워크를 이용한 결제 서비스 시스템 및 그 방법, 그리고 이를 위한 컴퓨터 프로그램
KR20070092400A (ko) 닉네임을 이용한 지불결제 처리 방법 및 시스템
KR20070029537A (ko) 무선단말기와 연동한 개인별고유코드를 활용한인증시스템과 그 방법
Neeharika et al. A Novel Interoperable Mobile Wallet Model with Capability Based Access Control Framework
PT107820A (pt) Sistema e método de processamento de transações
PT11178T (pt) Sistema e método de processamento de transações
JP6009521B2 (ja) 利用者特定システム、方法、およびプログラム
US11531991B1 (en) Home router authentication device
KR20070092391A (ko) 닉네임을 이용한 비대면 채널 유저인터페이스 제공방법 및시스템과 이를 위한 프로그램 기록매체
KR101812240B1 (ko) 사용자단말과 휴대폰을 이용한 인터넷뱅킹용 보안카드 정보입력 시스템 및 그 방법
KR20070021867A (ko) 무선단말기와 연동한 무선인증시스템과 그 방법

Legal Events

Date Code Title Description
BB1A Laying open of patent application

Effective date: 20151112