O artigo é de pouca utilidade para os países da CEI, mas você pode gostar
Ultimamente, tenho trabalhado muito com a API de vários bancos. Há uma razão para isso - uma nova diretiva chamada PSD2 (Diretiva de Serviço de Pagamento Revisada). Eu vou falar sobre ela.
Entrada
Tudo começou com empresas como o PayPal. Você se registra no site do PayPal, que, por sua vez, pega seu cartão de crédito, retira dinheiro quando necessário, acumula franquias em suas contas e, no dia marcado, envia a enésima quantia total de dinheiro para a conta da loja online. Assim, seu cartão de crédito permanece seguro, a loja online economiza dinheiro, o que significa que você economiza. Parece que todo mundo é bom.
Por outro lado, surge uma pergunta lógica: a loja está perdendo clientes que não têm cartão de crédito ou não querem um para compras individuais na Internet ?!
E aqui empresas menores entram em cena, que não levam seu cartão de crédito para o serviço, mas sua conta bancária. Nem isso, seu banco on-line! Agora você não precisa de cartão de crédito, não precisa de PayPal, nem precisa fazer transferências. Basta digitar seu nome de usuário e senha no site da loja e o intermediário fará o resto por você.
Você insere os dados no formulário no site da loja on-line, o intermediário simultaneamente insere os mesmos dados no formulário do banco on-line e, com a ajuda do mesmo Selenium, clica aqui e ali no seu banco on-line, fazendo uma transferência para onde necessário. Mais precisamente, às suas próprias custas, de onde ele também envia a cada duas semanas todos os fundos para as contas das lojas.
Claro, com qualquer alteração na página do banco on-line, tudo isso imediatamente para de funcionar, o que irrita as pessoas. Mas os bancos raramente mudam alguma coisa, então isso raramente acontece.
Outra coisa é que alguns bancos realmente não gostam de tal brecha na segurança e tentam bloquear esses intermediários. O sucesso e exatamente como eles fazem isso podem ser discutidos por um longo tempo, mas o artigo continuará.
Em geral, a pedido de trabalhadores e trabalhadores nesses sistemas de pagamento intermediários, o Conselho da Europa avançou e emitiu uma diretiva obrigando os bancos a criar uma API que permitisse as mesmas coisas que foram feitas anteriormente com o banco on-line, mas agora apenas com a ajuda de solicitações. Os bancos, é claro, ficaram muito chateados e, mesmo sem esses reguladores, eles têm regras suficientes para seguir, mas não há nada a fazer - eles precisam ser criados.
Naturalmente, os bancos também não são de uma dúzia tímida e sabotam essa lei de maneiras diferentes, porque não recebem nenhum benefício dela. Sim, existem algumas exceções quando tudo imediatamente funciona como deveria e a documentação está no local, mas na maioria dos casos é apenas um massacre de serra elétrica no Texas, não apenas uma serra elétrica e não no Texas, mas e-mails, chamadas e xingamentos na frente da tela do seu monitor no escritório.
Eles sabotam com maestria. Alguns simplesmente não traduzem sua documentação. Ou seja, é, por assim dizer, mas não é, por assim dizer, porque nenhum Google ajudará a traduzir 90 páginas de técnicas em espanhol por algum motivo. Os espanhóis geralmente vivem em seu próprio vácuo e não reconhecem que existe algum tipo de idioma internacional além do espanhol. Muitos outros apresentam a documentação na forma de um arquivo
YAML, no qual não há um único comentário, o que não está claro para onde enviar, os nomes dos campos não têm nenhum padrão e você não entende o que assinar com qual certificado ou não assinar nada.
A parte superior da sabotagem é a página de documentação, onde apenas os pontos de extremidade da API são indicados, mas, em princípio, não há cabeçalho ou corpo com uma descrição. Nem mesmo uma solicitação POST ou GET é indicada. Obviamente, o departamento jurídico segue essas pessoas, dizendo que as queixas à autoridade supervisora podem não resultar em multa, mas no futuro isso pode levar a uma atenção excessiva a esse banco. Na maioria dos casos, isso ajuda, mas o tempo passa.
Eu sabia sobre os bancos de merda, agora você pode escrever sobre a própria lei.
O que é o PSD2?
Esta é uma diretiva emitida pela Comissão Europeia para melhorar o mercado de pagamentos on-line e aumentar a segurança desses pagamentos.
De fato, ainda havia um PSD, mas ele simplesmente regulava os pagamentos entre os estados da UE, sem regular os pagamentos on-line. Embora quais são os pagamentos online em 2007m então.
Eles tomaram o PSD mencionado como base e prenderam uma dúzia de capítulos com o belo nome "banco aberto" (banco aberto). Esses dez capítulos se tornaram uma dor de cabeça para os bancos e uma alegria para os sistemas de pagamento (em teoria, os bancos também causaram dor de cabeça para os pagadores, para não sofrerem).
O PSD2 também regula a segurança do cliente, dizendo como e de que forma as solicitações devem ser transmitidas, quais certificados usar e o que pode ser solicitado ao banco e o que não. Ou seja, para pagamento, você pode solicitar um nome e sobrenome, bem como uma lista de contas de usuário, mas não terá mais nada, mesmo que peça muito.
Agora você precisa solicitar um token do banco, registrar-se como uma organização, que pode e deve executar qualquer ação em nome do cliente, além de ter uma chave secreta, etc., etc. Em geral, a segurança realmente cresceu significativamente. Bem, a responsabilidade de ambas as partes também.
Mas aqui, os bancos são livres para adicionar suas próprias camadas de segurança. Por exemplo, os bancos permitem que você insira os dados do cliente apenas nas páginas do banco. Ou seja, em qualquer caso, você terá que redirecionar o usuário para a página do banco e depois devolvê-lo para você (ok, o Selenium também pode ajudar, mas agora os bancos podem enviar saudações inflamadas e negar acesso à API, se algo estiver errado).
Ok, agora sobre o óbvio, e não tão, vantagens
Como eu disse acima, a segurança cresceu significativamente. Agora, os sistemas de pagamento não inventam bicicletas e não interagem com as APIs heterogêneas dos bancos, mas se conectam a APIs mais ou menos padronizadas, de modo que tudo está bem com a segurança.
Agora, se você é um sistema de pagamento, por exemplo, na Estônia, pode usar a API dos bancos europeus para aceitar pagamentos de clientes europeus. E para isso, você só precisa se registrar como instituição financeira, ler cerca de cem documentos e implementar tudo isso em seu sistema. No entanto, a maior parte da documentação será em inglês; além disso, você terá suporte mais ou menos distinto do banco.
Além disso, se você é um banco fora da UE, pode ingressar nesse banco aberto e seus clientes poderão pagar com sistemas de pagamento europeus.
Bem, aqui você também pode acrescentar que, se você não é uma empresa tão grande para quebrar os preços de transferências e compartilhar parte com bancos, agora pode fazer livremente o mesmo que uma grande empresa, porque o direito de acessar pagamentos agora todo mundo tem igual.
Agora sobre os contras
Existe uma diretiva, mas a API em sua versão de trabalho não é. A situação é bastante comum agora, um ano após os bancos começarem a trabalhar na implementação (e, bem, sim, eles deveriam ter começado a trabalhar ...).
As APIs não são completamente unificadas, assim como o processo de pagamento. Ou seja, você não pode criar algo universal para todos os bancos; é necessário ajustar a funcionalidade de solicitações para cada banco separadamente, o que atrasa bastante o desenvolvimento.
Mesmo o mesmo banco pode ter APIs diferentes em diferentes países. Porque cada país tem seus próprios órgãos reguladores que adicionam algum tipo de “regulamentação” ao processo. Lá você precisa de tokens adicionais, precisa autorizar o usuário três vezes, há outra coisa ...
Bem, agora seus negócios com o sistema de pagamentos dependem completamente do banco, cujos servidores podem cair repentinamente e, enquanto toda a máquina burocrática os executa e os inicia novamente, pode levar um dia ou dois, o que privará seus ganhos decentes. Nesse caso, você não pode apresentar algo ao banco.
Só isso.