O que é necessário para construir um ecossistema de serviços não bancários e, de fato, qualquer ecossistema semelhante? Um sistema mestre para armazenamento e processamento de dados, bem como uma API. Neste post, analisaremos duas versões da API que criamos - a primeira e a mais bem-sucedida - e abordaremos quais são as diferenças importantes entre elas.
Para criar um ecossistema de serviços não bancários, foi selecionado um produto-chave da divisão Sberbank Digital Corporate Bank - um banco na Internet para clientes corporativos do Sberbank Business Online. Consequentemente, a API fintech para o ecossistema de serviços não-bancários também foi criada com base.
A primeira versão da API fintech foi lançada em 2016. Foi criado de olho em nossas outras APIs do nosso banco, de acordo com as receitas clássicas das APIs de grandes organizações financeiras. Aqui estão os principais ingredientes:
- Protocolo SOAP para transferência de dados
- Formato XML
- Assinatura eletrônica de todos os pedidos
- Operação assíncrona
- VPN de hardware necessária para canal seguro
- Sistema proprietário de autenticação e autorização
- Formatos historicamente estabelecidos para transferência de informações financeiras (por exemplo, formato bancário direto 1C)
Tomamos essa decisão e iniciamos integrações piloto com vários serviços bancários não clássicos: a loja online da Evotor, o sistema de gerenciamento financeiro de Business Analytics da Seeneco, a contabilidade baseada em nuvem MyOdelo e outros.
Os resultados da integração estavam longe de ser desejados. A partir da API de serviços não financeiros modernos, os parceiros não esperavam o que era habitual no desenvolvimento de produtos bancários clássicos. Queríamos algo semelhante à API dos gigantes modernos da Internet: Facebook, Google, Yandex.
E, no final, eles se depararam com uma API bancária clássica - pesada, obscura, exigindo habilidades altas e específicas, entendendo os meandros dos processos de trabalho, implementando requisitos de segurança excessivos ... em geral, muitas coisas que levam à violação de todos os possíveis prazos de integração.
Analisamos essa experiência e decidimos criar uma nova versão da API fintech do zero. Para obter o máximo de ganho com serviços não financeiros de terceiros, os requisitos mais importantes são descritos com antecedência:
- Não existem formatos universais e pesados que levem em conta as menores nuances. Vamos ser mais fáceis!
- A API deve atender à maior variedade possível de parceiros em potencial que oferecem produtos não financeiros aos clientes do Sberbank. Até a introdução de geladeiras inteligentes - o que diabos não está brincando.
- A API precisa ser projetada usando as práticas e métodos usados para criar interfaces visuais. Para fazer isso, você precisa identificar e analisar os esquemas UX para usar a API. Seguir os cânones clássicos definitivamente não vale a pena.
- Precisamos nos livrar das descrições de vários volumes para que os desenvolvedores possam obter resultados rápidos. Usando a sandbox para testes, você precisa obter os primeiros resultados positivos em uma hora.
- Recusamos soluções proprietárias vinculadas a uma plataforma específica, tanto quanto possível. Tudo deve ser multiplataforma e não limitar o parceiro no ambiente de infraestrutura e desenvolvimento usado.
- Os parceiros não devem se incomodar com o que não fazem - estruturas de dados complexas, mecanismos dos componentes da plataforma bancária e os recursos de nossos sistemas legados. Nós escondemos e não enterramos suas cabeças.
Com esta lista, passamos à implementação e selecionamos soluções para a segunda versão da API fintech:
- Autenticação baseada em OAUTH 2.0
- Arquitetura REST sobre HTTP sem complexidade adicional
- Operação totalmente síncrona
- Formato JSON
- Uso opcional de assinatura eletrônica - quando necessário
- Teste o sandbox com o SWAGGER implantado. Usando esse ambiente de depuração, o desenvolvedor de um parceiro pode simular um fluxo de trabalho comercial e obter resultados sem escrever código
- Aplicando a abordagem Easy Steps usada pelas startups da Internet para criar documentação da API
- Práticas ágeis de desenvolvimento de API - Resultados rápidos e coleta de feedback
O que mudou de fato
Para avaliar a diferença entre as duas versões da API, comparamos a implementação de seus três componentes principais: autorização, a implementação de uma ordem de pagamento de rublo e assinatura eletrônica.
Na primeira versão da API, para autorização, o parceiro solicitou um nome de usuário e senha, certificado e AccessToken, obtidos como resultado da autenticação OAUTH do cliente que aplicou:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/"> <soapenv:Header/> <soapenv:Body> <upg:preLogin> <upg:userLogin>U1</upg:userLogin> <upg:changePassword>!d63NvJ+Sa</upg:changePassword> </upg:preLogin> </soapenv:Body> </soapenv:Envelope>
Na API 2.0, a autorização se tornou muito mais compacta. Para acessar os serviços, você só precisa do AccessToken recebido durante a autenticação OAUTH do cliente:
{ "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1", }
Na API 1.0, o trabalho com a ordem de pagamento do rublo também foi baseado no SOAP:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/"> <soapenv:Header/> <soapenv:Body> <upg:sendRequestsSRP> <upg:requests><![CDATA[ <Request xmlns='http://zzzzz.com/upg/request' orgId='84b70f22-703f-bf04-db60-bd110572f40d' requestId='a81ddc6d-fb92-416d-83f9-6785a59a4b17' version='1.0' sender='PARTNER' clientOrgIdHash='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5' clientAccessToken='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5-1'> <PayDocRuInvoice docExtId='a81decfd-fb92-416d-83f9-6785a59abb65' orderNum='62' deadLine='2017-04-10T17:16:03'> <PersonalAcc>40802810000000000000</PersonalAcc> <AccDoc docDate='2017-02-15' docSum='777' transKind='01' paytKind='01' priority='1'> <Purpose>!!!!! 18%</Purpose> </AccDoc> </PayDocRuInvoice> </Request> ]]></upg:requests> <upg:sessionId>5a869c00-e979-4280-b11a-6dbbb8a90214</upg:sessionId> </upg:sendRequestsSRP> </soapenv:Body> </soapenv:Envelope>
Na API 2.0, de maneira semelhante, tudo se tornou muito mais simples e compreensível:
{ "amount": 12.01, "date": "2018-06-22", "deliveryKind": "", "expirationDate": "2018-06-23", "externalId": "1516ec0c-761c-11e8-adc0-fa7ae01bbebc", "operationCode": "01", "orderNumber": "1237", "payeeAccount": "40706810000000000000", "paymentNumber": "1", "priority": "5", "purpose": " №1237. .", "urgencyCode": "NORMAL", "vat": { "amount": 100.01, "rate": "7", "type": "NO_VAT" }
Também facilitamos a assinatura eletrônica. Foi assim na API 1.0.
Então a solicitação parecia
Aqui está uma lista de atributos
E agora a assinatura finalizadaNa API 2.0, tudo era mais fácil através do JSON:
Solicite-se
Assinatura como resultadoSumário
Os lançamentos piloto da API 2.0 da fintech mostraram que as coisas foram muito melhores. O tempo de integração com os produtos parceiros - desde o início dos trabalhos até o momento do lançamento na operação comercial - foi reduzido em mais de 3 vezes. O número de perguntas para o nosso serviço de acompanhantes foi reduzido em uma ordem de magnitude e, o mais importante, a complexidade desses problemas diminuiu. Finalmente, o número de reclamações sobre a complexidade e a imprevisibilidade da API foi reduzido em duas ordens de magnitude. Em geral, nós fizemos isso. Se você tiver dúvidas, seja bem-vindo aos comentários, teremos o prazer de informar os detalhes.
O material foi preparado por Andrey Khokhlov, Gerente de Projetos, Banco Corporativo Digital Sberbank