De quoi a-t-on besoin pour construire un écosystème de services non bancaires, et en fait tout écosystème similaire? Un système maître pour le stockage et le traitement des données, ainsi qu'une API. Dans cet article, nous analyserons deux versions de l'API que nous avons créée - la première et la plus réussie - et nous attarderons sur leurs différences importantes.
Pour créer un écosystème de services non bancaires, un produit clé de la division Sberbank Digital Corporate Bank a été sélectionné - une banque Internet pour les entreprises clientes de Sberbank Business Online. En conséquence, l'API fintech pour l'écosystème des services non bancaires a également été réalisée sur cette base.
La première version de l'API fintech a été lancée en 2016. Il a été créé en tenant compte de nos autres API de notre banque, selon les recettes classiques des API des grandes organisations financières. Voici les principaux ingrédients:
- Protocole SOAP pour le transfert de données
- Format XML
- Signature électronique de toutes les demandes
- Fonctionnement asynchrone
- VPN matériel requis pour le canal sécurisé
- Système d'authentification et d'autorisation propriétaire
- Formats historiquement établis pour le transfert d'informations financières (par exemple, format bancaire direct 1C)
Nous avons pris une telle décision et commencé des intégrations pilotes avec plusieurs services bancaires non classiques: la boutique en ligne Evotor, le système de gestion financière Business Analytics de Seeneco, la comptabilité cloud MyOdelo et d'autres.
Les résultats de l'intégration étaient loin d'être souhaités. De l'API des services non financiers modernes, les partenaires ne s'attendaient pas du tout à ce qui était habituel dans le développement des produits bancaires classiques. Nous voulions obtenir quelque chose de similaire à l'API des géants Internet modernes: Facebook, Google, Yandex.
Et à la fin, ils sont tombés sur une API bancaire classique - lourde, obscure, nécessitant des compétences élevées et spécifiques, comprenant les subtilités des processus de travail, mettant en œuvre des exigences de sécurité excessives ... en général, beaucoup de choses qui conduisent à la violation de toutes les échéances d'intégration possibles.
Nous avons analysé cette expérience et décidé de créer une nouvelle version de l'API fintech à partir de zéro. Pour obtenir le maximum de gains avec les services non financiers tiers, les exigences les plus importantes sont définies à l'avance:
- Pas de formats universels et lourds qui prennent en compte les moindres nuances. Soyons plus facile!
- L'API devrait convenir à l'éventail le plus large possible de partenaires potentiels offrant des produits non financiers aux clients de Sberbank. Jusqu'à l'introduction des réfrigérateurs intelligents - ce n'est pas une blague.
- L'API doit être conçue en utilisant les pratiques et méthodes utilisées pour créer des interfaces visuelles. Pour ce faire, vous devez identifier et analyser les schémas UX pour l'utilisation de l'API. Suivre les canons classiques n'en vaut vraiment pas la peine.
- Nous devons nous débarrasser des descriptions multi-volumes afin que les développeurs puissent obtenir des résultats rapides. En utilisant le bac à sable pour les essais, vous devez obtenir les premiers résultats positifs en une heure.
- Nous refusons autant que possible les solutions propriétaires liées à une plateforme spécifique. Tout doit être multiplateforme et ne pas limiter le partenaire dans l'infrastructure et l'environnement de développement utilisés.
- Les partenaires ne devraient pas être dérangés par ce qu'ils ne font pas - les structures de données complexes, les mécanismes des composants de la plate-forme bancaire et les caractéristiques de nos anciens systèmes. Nous nous cachons et n'enterrons pas leurs têtes.
Avec cette liste, nous sommes passés à l'implémentation et aux solutions sélectionnées pour la deuxième version de l'API fintech:
- Authentification basée sur OAUTH 2.0
- Architecture REST sur HTTP sans complexité supplémentaire
- Fonctionnement entièrement synchrone
- Format JSON
- Utilisation facultative de la signature électronique - si nécessaire
- Testez le bac à sable avec SWAGGER déployé. À l'aide de cet environnement de débogage, le développeur d'un partenaire peut simuler un flux de travail métier et obtenir des résultats sans écrire de code
- Application de l'approche Easy Steps utilisée par les startups Internet pour créer la documentation de l'API
- API Development Agile Practices - Résultats rapides et collecte de commentaires
Ce qui a changé en fait
Pour évaluer la différence entre les deux versions de l'API, nous comparons la mise en œuvre de ses trois composantes clés: l'autorisation, la mise en place d'un ordre de paiement en rouble et la signature électronique.
Dans la première version de l'API, pour l'autorisation, le partenaire exigeait un nom d'utilisateur et un mot de passe, un certificat et un AccessToken, obtenus à la suite de l'authentification OAUTH du client qui avait postulé:
<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>
Dans l'API 2.0, l'autorisation est devenue beaucoup plus compacte. Pour accéder aux services, vous n'avez besoin que du AccessToken reçu lors de l'authentification OAUTH du client:
{ "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1", }
Dans l'API 1.0, le travail avec l'ordre de paiement en rouble était également basé sur 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>
Dans l'API 2.0, de manière similaire, tout est devenu beaucoup plus simple et plus compréhensible:
{ "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" }
Nous avons également facilité la signature électronique. C'est comme ça dans l'API 1.0.
Donc, la demande avait l'air
Voici une liste d'attributs
Et maintenant la signature finieDans l'API 2.0, tout était plus simple grâce à JSON:
Se demander
Signature en conséquenceRésumé
Le lancement du pilote fintech API 2.0 a montré que les choses allaient beaucoup mieux. Le temps d'intégration avec les produits partenaires - du début des travaux au moment de la mise en service commerciale - a été réduit de plus de 3 fois. Le nombre de questions pour notre service d'escorte a été réduit d'un ordre de grandeur et, surtout, la complexité de ces problèmes a diminué. Enfin, le nombre de plaintes concernant la complexité et l'imprévisibilité de l'API a été réduit de deux ordres de grandeur. En général, nous l'avons fait. Si vous avez des questions, bienvenue aux commentaires, nous nous ferons un plaisir de vous en dire les détails.
Le matériel a été préparé par Andrey Khokhlov, chef de projet, Digital Corporate Bank Sberbank