Was ist erforderlich, um ein Ökosystem von Nichtbankdienstleistungen und in der Tat ein ähnliches Ökosystem aufzubauen? Ein Mastersystem zum Speichern und Verarbeiten von Daten sowie eine API. In diesem Beitrag werden wir zwei Versionen der von uns erstellten API analysieren - die erste und die erfolgreichste - und uns mit den wichtigsten Unterschieden befassen.
Um ein Ökosystem von Nichtbankdienstleistungen zu schaffen, wurde ein Schlüsselprodukt des Geschäftsbereichs Sberbank Digital Corporate Bank ausgewählt - eine Internetbank für Firmenkunden von Sberbank Business Online. Dementsprechend wurde auch die Fintech-API für das Ökosystem der Nichtbankdienstleistungen auf ihrer Grundlage erstellt.
Die erste Version der Fintech-API wurde 2016 veröffentlicht. Es wurde mit Blick auf unsere anderen APIs unserer Bank nach den klassischen Rezepten der APIs großer Finanzorganisationen erstellt. Hier sind die Hauptzutaten:
- SOAP-Protokoll für die Datenübertragung
- XML-Format
- Elektronische Signatur aller Anfragen
- Asynchroner Betrieb
- Erforderliches Hardware-VPN für sicheren Kanal
- Proprietäres Authentifizierungs- und Autorisierungssystem
- Historisch etablierte Formate für die Übertragung von Finanzinformationen (z. B. 1C-Direktbankformat)
Wir haben eine solche Entscheidung getroffen und Pilotintegrationen mit mehreren nicht klassischen Bankdienstleistungen gestartet: dem Evotor-Onlineshop, dem Business Analytics-Finanzmanagementsystem von Seeneco, dem Cloud-basierten MyOdelo-Rechnungswesen und anderen.
Die Integrationsergebnisse waren alles andere als erwünscht. Von der API moderner nichtfinanzieller Dienstleistungen erwarteten die Partner überhaupt nicht, was bei der Entwicklung klassischer Bankprodukte üblich war. Wir wollten etwas Ähnliches wie die API moderner Internetgiganten: Facebook, Google, Yandex.
Am Ende stießen sie auf eine klassische Bank-API - schwer, undurchsichtig, die hohe und spezifische Fähigkeiten erfordert, die Feinheiten von Arbeitsprozessen versteht, übermäßige Sicherheitsanforderungen implementiert ... im Allgemeinen viele Dinge, die zur Verletzung aller möglichen Integrationsfristen führen.
Wir haben diese Erfahrung analysiert und beschlossen, eine neue Version der Fintech-API von Grund auf neu zu erstellen. Um die maximale Win-Win-Situation mit nichtfinanziellen Dienstleistungen von Drittanbietern zu erzielen, werden die wichtigsten Anforderungen im Voraus festgelegt:
- Keine universellen und schweren Formate, die die geringsten Nuancen berücksichtigen. Lass uns einfacher sein!
- API sollte für ein möglichst breites Spektrum potenzieller Partner geeignet sein, die Sberbank-Kunden nichtfinanzielle Produkte anbieten. Bis zur Einführung intelligenter Kühlschränke - was zum Teufel kein Scherz ist.
- Die API muss unter Verwendung der Methoden und Methoden entworfen werden, die zum Erstellen visueller Schnittstellen verwendet werden. Dazu müssen Sie die UX-Schemata für die Verwendung der API identifizieren und analysieren. Es lohnt sich definitiv nicht, den klassischen Kanonen zu folgen.
- Wir müssen mehrbändige Beschreibungen entfernen, damit Entwickler schnelle Ergebnisse erzielen können. Wenn Sie die Sandbox für Testversuche verwenden, müssen Sie die ersten positiven Ergebnisse innerhalb einer Stunde erzielen.
- Wir lehnen proprietäre Lösungen, die an eine bestimmte Plattform gebunden sind, so weit wie möglich ab. Alles sollte plattformübergreifend sein und den Partner in der verwendeten Infrastruktur und Entwicklungsumgebung nicht einschränken.
- Partner sollten nicht durch das gestört werden, was sie nicht tun - komplexe Datenstrukturen, Mechanismen von Bankplattformkomponenten und die Merkmale unserer Legacy-Systeme. Wir verstecken uns und begraben ihre Köpfe nicht.
Mit dieser Liste gingen wir zur Implementierung über und wählten Lösungen für die zweite Version der Fintech-API aus:
- OAUTH 2.0-basierte Authentifizierung
- REST-Architektur über HTTP ohne zusätzliche Komplexität
- Vollsynchroner Betrieb
- JSON-Format
- Optionale Verwendung der elektronischen Signatur - falls erforderlich
- Testen Sie die Sandbox mit dem bereitgestellten SWAGGER. Mithilfe dieser Debugging-Umgebung kann der Entwickler eines Partners einen Geschäftsworkflow simulieren und Ergebnisse erzielen, ohne Code schreiben zu müssen
- Anwenden des Easy-Steps-Ansatzes, der von Internet-Startups zum Erstellen einer API-Dokumentation verwendet wird
- Agile Praktiken für die API-Entwicklung - Schnelle Erfassung von Ergebnissen und Feedback
Was hat sich tatsächlich geändert?
Um den Unterschied zwischen den beiden Versionen der API zu bewerten, vergleichen wir die Implementierung ihrer drei Schlüsselkomponenten: Autorisierung, Implementierung eines Rubel-Zahlungsauftrags und elektronische Signatur.
In der ersten Version der API benötigte der Partner für die Autorisierung einen Benutzernamen und ein Kennwort, ein Zertifikat und AccessToken, die als Ergebnis der OAUTH-Authentifizierung des Clients erhalten wurden, der sich beworben hat:
<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>
In API 2.0 ist die Autorisierung viel kompakter geworden. Für den Zugriff auf die Dienste benötigen Sie nur das AccessToken, das während der OAUTH-Authentifizierung des Clients empfangen wurde:
{ "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1", }
In API 1.0 basierte die Arbeit mit dem Rubel-Zahlungsauftrag auch auf 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>
In API 2.0 ist auf ähnliche Weise alles viel einfacher und verständlicher geworden:
{ "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" }
Wir haben auch die elektronische Signatur erleichtert. So war es in API 1.0.
Also sah die Anfrage aus
Hier ist eine Liste von Attributen
Und jetzt die fertige UnterschriftIn API 2.0 war durch JSON alles einfacher:
Fordern Sie sich an
Unterschrift als ErgebnisZusammenfassung
Die Pilotstarts der Fintech API 2.0 zeigten, dass die Dinge viel besser liefen. Die Integrationszeit für Partnerprodukte - vom Beginn der Arbeiten bis zur Freigabe in den kommerziellen Betrieb - wurde um mehr als das Dreifache verkürzt. Die Anzahl der Fragen an unseren Escortservice wurde um eine Größenordnung reduziert, und vor allem hat sich die Komplexität dieser Probleme verringert. Schließlich wurde die Anzahl der Beschwerden über die Komplexität und Unvorhersehbarkeit der API um zwei Größenordnungen reduziert. Im Allgemeinen haben wir es geschafft. Wenn Sie Fragen haben, begrüßen Sie Kommentare, wir werden Ihnen gerne die Details mitteilen.
Das Material wurde von Andrey Khokhlov, Projektmanager der Digital Corporate Bank Sberbank, vorbereitet