Artem Lyashanov – підприємець, фінтех-експерт та інвестор, понад 10 років досвіду в побудові платіжних продуктів в Україні та світі.
Процесори на кшталт Stripe обробляють мільярди транзакцій на рік, утримуючи доступність на рівні 99,99%, надійний захист і відповіді швидше за секунду. Artem Lyashanov розібрав, з чого складається мистецтво СТО-консалтингу для платіжних компаній і чому масштабування грошового руху вимагає зовсім іншого підходу, ніж масштабування звичайного софту.
Платіжний пайплайн
Платіжна система перетворює намір клієнта заплатити на реальний рух грошей і це ніколи не проста транзакція запит-відповідь. Це складна оркестрація кількох сервісів, кожен із чітко визначеною відповідальністю.
Типова архітектура складається з кількох рівнів:
- API Gateway. Точка входу, що відповідає за автентифікацію, обмеження частоти запитів і маршрутизацію;
- Ядро обробки транзакцій. Де живе сама платіжна логіка;
- Система виявлення шахрайства. Оцінка ризику в реальному часі для кожної транзакції;
- Облікова система (ledger. Єдине джерело правди для всіх фінансових записів;
- Двигун реконсиляції. Гарантує, що жодна копійка не загубилася між системами.
Перше, на що СТО-консультант звертає увагу під час аудиту платіжної архітектури клієнта, чи розділені ці шари свідомо, чи виросли стихійно з одного монолітного сервісу. Друге часто й стає причиною, чому масштабування буксує.
Властивість, на якій не можна економити
Платіжні системи мають одночасно задовольняти кілька конкуруючих вимог, сувору консистентність для фінансової точності, високу доступність для клієнтського досвіду і низьку затримку для конверсії.
Найважливіша властивість тут ідемпотентність. У світі, де мережі падають і клієнти повторюють запити, потрібна гарантія, що обробка того самого платіжного запиту кілька разів дає той самий результат. Це не просто про виявлення дублікатів це про вбудовування детермінованої поведінки в розподілену систему.
На практиці це означає, що кожен платіжний запит одразу отримує унікальний ідентифікатор транзакції та ключ ідемпотентності, навіть якщо клієнт сам його не передав. Якщо мережа обірвалася й клієнт повторив запит — система розпізнає, що це той самий платіж, а не новий.
Компроміс, якого не уникнути
Платіжні системи стикаються з особливим викликом у застосуванні теореми CAP. Жертвувати консистентністю, коли йдеться про гроші, неможливо, але й неприпустимо бути недоступним під час мережевих розривів.
Artem Lyashanov
Рішення зазвичай використовувати різні моделі консистентності для різних компонентів. Критичні фінансові операції отримують сувору консистентність із синхронною репликацією між кількома дата-центрами. Менш критичні операції, як оновлення дашборду мерчанта, можуть працювати на eventual consistency, щоб зберегти доступність. Ключове завдання СТО-консультанта тут, це правильно категоризувати, яка операція потребує якої гарантії, а не застосовувати одну модель консистентності до всієї системи.
Масштабування обсягу транзакцій
Сучасні платіжні процесори обробляють мільйони транзакцій на день, з масивними піками під час подій типу Чорної п’ятниці. Архітектура повинна масштабуватися горизонтально, зберігаючи суворі гарантії порядку для фінансових операцій.
Практичне рішення це ретельне партиціонування: транзакції шардуються за ідентифікатором мерчанта і методом платежу, що дозволяє незалежно масштабувати різні клієнтські сегменти. Але глобальні операції все одно вимагають координації між усіма шардами одночасно.
Відповідність PCI DSS фундаментально формує архітектуру: чутливі платіжні дані мають бути ізольовані в захищених анклавах з мінімальною кількістю точок доступу. Для цього застосовується токенізація як заміна чутливих даних картки на безпечні токени на більшості етапів обробки.
