¿Qué se necesita para construir un ecosistema de servicios no bancarios, y de hecho cualquier ecosistema similar? Un sistema maestro para almacenar y procesar datos, así como una API. En esta publicación, analizaremos dos versiones de la API que creamos, la primera y la más exitosa, y analizaremos cuáles son sus diferencias importantes entre sí.
Para crear un ecosistema de servicios no bancarios, se seleccionó un producto clave de la división Sberbank Digital Corporate Bank: un banco de Internet para clientes corporativos de Sberbank Business Online. En consecuencia, la API fintech para el ecosistema de servicios no bancarios también se hizo sobre la base.
La primera versión de la API fintech se lanzó en 2016. Fue creado teniendo en cuenta nuestras otras API de nuestro banco, de acuerdo con las recetas clásicas de las API de las grandes organizaciones financieras. Aquí están los ingredientes principales:
- Protocolo SOAP para transferencia de datos
- Formato XML
- Firma electrónica de todas las solicitudes.
- Operación asincrónica
- Hardware-VPN requerido para un canal seguro
- Sistema de autenticación y autorización patentado
- Formatos establecidos históricamente para transferir información financiera (por ejemplo, formato de banca directa 1C)
Tomamos esa decisión e iniciamos integraciones piloto con varios servicios bancarios no clásicos: la tienda en línea Evotor, el sistema de gestión financiera Business Analytics de Seeneco, la contabilidad basada en la nube MyOdelo y otros.
Los resultados de integración estaban lejos de ser deseados. Desde el API de los servicios no financieros modernos, los socios no esperaban en absoluto lo que era habitual en el desarrollo de productos bancarios clásicos. Queríamos obtener algo similar a la API de los gigantes modernos de Internet: Facebook, Google, Yandex.
Y al final, se encontraron con una API bancaria clásica: pesada, oscura, que requiere habilidades altas y específicas, comprender las complejidades de los procesos de trabajo, implementar requisitos de seguridad excesivos ... en general, muchas cosas que conducen a la violación de todos los posibles plazos de integración.
Analizamos esta experiencia y decidimos hacer una nueva versión de la API fintech desde cero. Para obtener el máximo beneficio mutuo con servicios no financieros de terceros, los requisitos más importantes se describen de antemano:
- No hay formatos universales y pesados que tengan en cuenta los más mínimos matices. ¡Seamos más fáciles!
- API debería adaptarse a la gama más amplia posible de socios potenciales que ofrecen productos no financieros a los clientes de Sberbank. Hasta la introducción de los refrigeradores inteligentes, qué demonios no son bromas.
- La API debe diseñarse utilizando las prácticas y los métodos que se utilizan para crear interfaces visuales. Para hacer esto, debe identificar y analizar los esquemas UX para usar la API. Seguir los cánones clásicos definitivamente no vale la pena.
- Necesitamos deshacernos de las descripciones de varios volúmenes para que los desarrolladores puedan lograr resultados rápidos. Usando el sandbox para pruebas de prueba, necesita obtener los primeros resultados positivos en una hora.
- Rechazamos las soluciones propietarias vinculadas a una plataforma específica tanto como sea posible. Todo debe ser multiplataforma y no limitar al socio en la infraestructura utilizada y el entorno de desarrollo.
- Los socios no deben ser molestados por lo que no hacen: estructuras de datos complejas, mecanismos de los componentes de la plataforma bancaria y las características de nuestros sistemas heredados. Nos escondemos y no enterramos sus cabezas.
Con esta lista, pasamos a la implementación y soluciones seleccionadas para la segunda versión de la API fintech:
- Autenticación basada en OAUTH 2.0
- Arquitectura REST sobre HTTP sin complejidad adicional
- Operación totalmente sincrónica
- Formato JSON
- Uso opcional de firma electrónica - cuando sea necesario
- Prueba sandbox con SWAGGER desplegado. Con este entorno de depuración, el desarrollador de un socio puede simular un flujo de trabajo empresarial y obtener resultados sin escribir código
- Aplicación del enfoque de Pasos sencillos utilizado por las startups de Internet para crear documentación de API
- Prácticas ágiles de desarrollo de API: resultados rápidos y recopilación de comentarios
Lo que ha cambiado de hecho
Para evaluar la diferencia entre las dos versiones de la API, comparamos la implementación de sus tres componentes clave: autorización, la implementación de una orden de pago en rublos y la firma electrónica.
En la primera versión de la API, para la autorización, el socio requería un nombre de usuario y contraseña, un certificado y un AccessToken, obtenido como resultado de la autenticación OAUTH del cliente que solicitó:
<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>
En API 2.0, la autorización se ha vuelto mucho más compacta. Para acceder a los servicios, solo necesita el AccessToken recibido durante la autenticación OAUTH del cliente:
{ "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1", }
En API 1.0, el trabajo con la orden de pago del rublo también se basó en 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>
En API 2.0, de manera similar, todo se ha vuelto mucho más simple y más comprensible:
{ "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" }
También facilitamos la firma electrónica. Así fue en API 1.0.
Entonces la solicitud parecía
Aquí hay una lista de atributos
Y ahora la firma terminadaEn API 2.0, todo fue más fácil a través de JSON:
Solicitar a sí mismo
Firma como resultadoResumen
Los lanzamientos piloto de fintech API 2.0 mostraron que las cosas fueron mucho mejor. El tiempo de integración con productos asociados, desde el inicio del trabajo hasta el momento de su lanzamiento a la operación comercial, se redujo en más de 3 veces. El número de preguntas para nuestro servicio de acompañantes se ha reducido en un orden de magnitud, y lo más importante, la complejidad de estos problemas ha disminuido. Finalmente, el número de quejas sobre la complejidad e imprevisibilidad de la API se redujo en dos órdenes de magnitud. En general, lo hicimos. Si tiene alguna pregunta, bienvenido a los comentarios, con gusto le informaremos los detalles.
El material fue preparado por Andrey Khokhlov, Gerente de Proyecto, Digital Corporate Bank Sberbank