company_banner

История одного API: как мы превратили Франкенштейна в красавчика

    Что нужно, чтобы построить экосистему небанковских сервисов, да и вообще любую подобную экосистему? Мастер-система хранения и обработки данных, а также API. В этом посте мы разберем две версии созданного нами API — первую и удачную — и подробно остановимся на том, в чем их важные отличия друг от друга.



    Для создания экосистемы небанковских сервисов был выбран ключевой продукт дивизиона «Цифровой Корпоративный Банк» Сбербанка — интернет-банк для корпоративных клиентов Сбербанк Бизнес Онлайн. Соответственно, fintech API для экосистемы небанковских сервисов тоже делали на его основе.

    Первую версию fintech API запустили в 2016 году. Создавалась она с оглядкой на другие наши API нашего банка, по классическим рецептам API крупных финансовых организаций. Вот основные ингредиенты:

    • Протокол SOAP для передачи данных
    • XML-формат
    • Электронная подпись всех запросов
    • Асинхронный режим работы
    • Обязательный hardware-VPN для организации защищенного канала
    • Проприетарная система аутентификации и авторизации
    • Исторически сложившиеся форматы для передачи финансовой информации (например, формат 1С direct banking)

    Мы сделали такое решение и начали пилотные интеграции с несколькими неклассическими банковскими сервисами: интернет-магазином «Эвотор», системой управления финансами «Бизнес-аналитика» компании Seeneco, облачной бухгалтерией «МоёДело» и другими.

    Результаты интеграций оказались далеки от желаемых. От API современных нефинансовых сервисов партнеры ждали совсем не того, что принято в области разработки классических банковских продуктов. Хотели получить что-нибудь подобное API современных интернет-гигантов: Facebook, Google, Yandex.

    А в итоге столкнулись с классическим API банка — тяжелым, малопонятным, требующим высокой и специфической квалификации, понимания тонкостей рабочих процессов, реализации избыточных требований безопасности… в общем, множества вещей, которые приводят к нарушению всех возможных дедлайнов по интеграции.

    Мы проанализировали этот опыт и решили сделать новую версию fintech API с чистого листа. Чтобы получить максимальный win-win со сторонними нефинансовыми сервисами, важнейшие требования изложили заранее:

    • Никаких универсальных и тяжелых форматов, которые учитывают малейшие нюансы. Будем проще!
    • API должен подходить максимально широкому кругу потенциальных партнеров, предлагающих нефинансовые продукты клиентам Сбербанка. Вплоть до внедрения в умные холодильники — с чем черт не шутит.
    • API нужно проектировать с помощью практик и способов, которые используются при создании визуальных интерфейсов. Для этого нужно выявить и проанализировать UX-схемы использования API. Следовать классическим канонам точно не стоит.
    • Нужно избавиться от многотомных описаний, чтобы разработчики могли достичь быстрого результата. С помощью песочницы для тестовых испытаний нужно получать первые положительные результаты уже за час.
    • Максимально отказываемся от проприетарных решений, привязанных к определенной платформе. Все должно быть кроссплатформенным и не ограничивать партнера в используемой инфраструктуре и среде разработки.
    • Партнерам не должно мешать то, чем они не занимаются — сложные структуры данных, механизмы компонентов банковской платформы, особенности работы наших legacy-систем. Скрываем и не забиваем им головы.

    С этим списком мы перешли к реализации и выбрали решений для второй версии fintech API:

    • Аутентификация на базе протокола OAUTH 2.0
    • REST-архитектура поверх HTTP без дополнительных сложностей
    • Полностью синхронная работа
    • Формат JSON
    • Опциональное применение электронной подписи — там, где это необходимо
    • Тестовая песочница с развернутым SWAGGER. С помощью этой среды отладки разработчик партнера может смоделировать бизнес-процесс работы и получить результат без написания кода
    • Применение используемого интернет-стартапами подхода Easy Steps при создании документации к API
    • Agile-практики при разработке API — быстрый результат и сбор обратной связи

    Что изменилось по факту


    Чтобы оценить разницу между двумя версиями API, сравним реализации трех его ключевых компонентов: авторизации, реализации рублевого платежного поручения и электронной подписи.

    В первой версии API для авторизации партнеру требовались логин и пароль, сертификат и AccessToken, полученный в результате OAUTH-аутентификации обратившегося клиента:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/">
       <soapenv:Header/>
       <soapenv:Body>
          <upg:preLogin>
             <!--Optional:-->
             <upg:userLogin>U1</upg:userLogin>
             <!--Optional:-->
             <upg:changePassword>!d63NvJ+Sa</upg:changePassword>
          </upg:preLogin>
       </soapenv:Body>
    </soapenv:Envelope>

    В API 2.0 авторизация стала гораздо компактнее. Для доступа к сервисам нужен только AccessToken,  полученный при OAUTH-аутентификации клиента:

    {
    "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1",
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1",
    }

    В API 1.0 работа с рублевым платежным поручением также была основана на SOAP:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/">
       <soapenv:Header/>
       <soapenv:Body>
          <upg:sendRequestsSRP>
             <!--Zero or more repetitions:-->
             <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>
             <!--Optional:-->
             <upg:sessionId>5a869c00-e979-4280-b11a-6dbbb8a90214</upg:sessionId>
          </upg:sendRequestsSRP>
       </soapenv:Body>
    </soapenv:Envelope>

    В API 2.0 аналогичным образом все стало гораздо проще и понятнее:

    { 
       "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"  
    }

    Электронную подпись мы также облегчили. Вот как все было в API 1.0.


    Так выглядел запрос


    Вот список атрибутов


    И вот готовая подпись

    В версии API 2.0 через JSON реализовали все проще:


    Сам запрос


    Подпись в результате

    Итоги


    Пилотные запуски fintech API 2.0 показали, что дела пошли значительно лучше. Время интеграции с продуктами партнеров —  от старта работ до момента выпуска в промышленную эксплуатацию — сократилось более чем в 3 раза. На порядок сократилось количество вопросов нашей службе сопровождения, и что самое ценное, снизилась сложность этих вопросов. Наконец, на целых два порядка сократилось количество жалоб на сложность и непредсказуемость работы API. В общем, мы сделали это. Если есть вопросы — добро пожаловать в комментарии, с удовольствием расскажем подробности.

    Материал подготовил Андрей Хохлов, руководитель проектов дивизиона «Цифровой Корпоративный Банк» Сбербанка
    • +21
    • 4,5k
    • 7

    Сбербанк

    184,00

    Компания

    Поделиться публикацией
    Комментарии 7
      0
      За интеграцию с «Моё Дело», спасибо. Действительно удобно оплатить налоги и другие выплаты в фонды парой кликов. Тот же Райффайзенбанк не осилил даже подгрузку данных из формы. Приходилось кучу информации в ручную вбивать каждый раз. Вроде КБК и другой многозначной ереси.
      И может передадите пожелание разрабам приложения для андроид «Сбербанк бизнес»?
      При выходе из приложения выходит в экран с паролем, а не полностью. В Сбербанк онлайн так то же раньше было, но переделали.
      Очень долго входит проверяя на вирусы и еще чем то занимаясь. Хотя у меня стоят оба приложения и сбер онлайн постоянно сканирует телефон на вирусы, определяя их быстрей той же мобильной версии KIS(было не раз и не два). Т.е. два приложения занимаются одним и тем же.
      У бизнес версии приложения 4х значный пароль при входе, а у обычной 5ти значный что странно с точки зрения безопасности.
      В идеале хотелось бы слияния приложений с выбором на экране ввода пароля в какую версию приложения заходить. Т.к. если установлена Сбербанк бизнес, то и обычная версия уже установлена.
        0

        Конечно передадим. Скиньте в личку email для обратной связи

        +1

        Перед открытием счета летом этого года обращался в банк с вопросом наличия API, путем долгих переговоров (более 20 дней), мне сообщили, что подобного нет. От API требовалась поддержка выгрузки выписки поступлений для их обработки в собственном биллинге. Подскажите, где можно ознакомиться с информацией по API? Заранее благодарен за ответ.

        0
        зануда mode on:
        Только чудовище Франкенштейна. А сам Франкенштейн — это доктор.
          0
          А меня в красавчика можно превратить? =)
            +1
            Тот неловкий момент, когда, увидев рисованное чудовище Франкенштейна на КДПВ, думаешь, что Milfgard написал эссе для Сбербанка… но нет.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое