Перейти до змісту
River

Аркуш RP-10

Рушій

Що стоїть у центрі платформи і як це побудовано?

Рушій веде один журнал кожного платежу й вирішує, що далі, за правилами, збереженими як дані. Усе, що бачать люди, читається з цього журналу.

§ 1

Коротко

Надходять

Замовлення, платники, системи компанії

Правила як записи

Вирішують, що далі

чернетки пише ШІ, приймають люди

Журнал

Кожен факт кожного платежу

лише дописується, не переписується

Зовні

Банки й провайдери

запит іде один раз; відповідь повертається фактом

Читаються з журналу

Подання для людей і агентів

  • замовлення
  • інвойси
  • платежі
  • розрахунки
  • облік
Рис. 2 — журнал у центрі: факти надходять і лише дописуються; правила читають їх і вирішують, що далі; банки відповідають через одну межу; кожне подання читається з журналу.
Один журнал, лише дописування
Замовлення, платники, банки й правила додають факти; нічого не змінюють і не видаляють. Виправлення — новий факт.
Правила як дані
Кожне правило — короткий запис, що відповідає на одне запитання. Правила мають версії; чернетки пише ШІ, приймають люди.
Одна межа назовні
Кожен запит до банку йде один раз. Відповідь повертається фактом; дублікат записують, і він нічого не змінює.
Подання — це читання
Замовлення, інвойси, платежі, розрахунки й облік обчислюються з журналу, і їх можна будь-коли відновити.

§ 2

Докладно

2.1

Один журнал, лише дописування

Платіж — не процедура. Це набір фактів, що надходять від різних сторін у різний час, — замовлення, інвойс, інструмент платника, підтвердження покупця, перевірка, маршрут, відповідь банку, гроші, — і моменти, коли відомо достатньо, щоб рухатися далі. Єдина пам’ять рушія — журнал таких фактів, по одному на кожну спробу, до якого лише дописують.

Журнал росте кроками: спершу факти, що надійшли, потім кожне рішення, яке вони дозволяють, потім запити, які роблять ці рішення, потім відповіді, що повертаються. Факт пізнішого кроку бачить усе, що створив попередній, — тому списання чекає на підтвердження покупця.

2.2

Правила як записи

Те, що робить платіж, — набір правил, які читає рушій. Один вид правил чекає на момент — чи відомо вже достатньо? — а інший діє: записує факт або один раз звертається до банку. Кожне правило формулює своє запитання простими словами, а набір завантажують лише тоді, коли розв’язане кожне посилання. Політики компанії — дані того самого роду, задані на її структурі й успадковані донизу.

2.3

Одна межа назовні

Рушій ніколи не звертається до банку зсередини рішення. Правило записує намір; конектор доносить його до банку-еквайра, сервера 3-D Secure чи людини, що перевіряє, а відповідь повертається фактом, пов’язаним із запитом. Пізня відповідь — вебхук, файл розрахунків — факт того самого роду.

Кожен запит іде один раз. Пізні факти, як-от інвойс після списання чи дублікат вебхука, записують, і вони нічого не змінюють.

  1. #1Замовлення отриманомагазин

  2. #2Картку доданоплатник

    токен і бренд; без номера картки

  3. #3Готово до списанняправило

    є замовлення й картка, платежу ще немає

  4. #4Запит на списання, один разправило

  5. #5Відповідь: списанобанк

  6. #6Пізно надходить дублікат запитумагазин

  7. #7Записано; другого списання немаєправило

Приклад. Кожен запис лишається в журналі; пізній дублікат нічого не змінює.

Рис. 3 — приклад записів одного платежу з пізнім дублікатом, що нічого не змінює.

2.4

Подання — це читання

Нічого з того, що бачить людина, не зберігають як таке. Подання замовлень, інвойсів, спроб, платежів, пакетів розрахунків і обліку обчислюють із фактів; таблиця в кабінеті — прочитання подань зі стовпцями ролі; експорт несе джерело кожного рядка. Усі їх можна будь-коли відновити, і вони виходять тими самими, бо журнал той самий.

2.5

Як приходить зміна

Спершу — погоджені сценарії: чого не має статися ніколи і що має спрацювати. ШІ пише варіант, новий набір правил поруч зі старим; його перевіряють на сценаріях, на тих самих фактах в іншому порядку й на минулих платежах; потім людина його приймає. Прийняту логіку більше не чіпають.

У роботі

Прийнята логіка

працює без змін; її не правлять на місці

без змін

Новий варіант

Банк, правило чи інструмент

пише ШІ

Перевірка

Погоджені сценарії

і минулі платежі

Рішення

Приймає людина

Результат

Працює поруч із прийнятою логікою

Рис. 4 — зміна починає працювати поруч із тим, що працює, після перевірки й рішення людини.

2.6

Що це дає

  • Проаудитовано — кожен крок несе свою причину, а журнал можна відтворити.
  • Проаналізовано — будь-яке запитання про будь-який платіж — прочитання того самого журналу: стратегія, перевірена на минулих платежах, комісія, перевірена рядок за рядком, один період, порівняний з іншим, — без другої системи.
  • Розширено — нове правило, банк чи інструмент — варіант поруч із тим, що працює, перевірений до використання.

§ 3

Модуль ядра

У ядрі — NestVM від CoAgnes: рушій, що веде журнал і виконує правила. Це зовнішній модуль, що входить за окремими угодами, і він не є частиною цих репозиторіїв.

Довкола нього River будує те, що потрібно платіжній платформі: словник фактів і п’ять записів платежу; структуру з політиками й доступом; договори й умови еквайрингу; перевірку, інструменти й розподіл грошей; облік, маршрутизацію, сторінку оплати, інтеграції й агентів; і подання кожного кабінету.

Демо-стенд цього сайту працює за тією самою структурою на власному середовищі платформи в пам’яті: журнал фактів для кожної спроби, подання, прочитані з нього, і агенти, що лише читають.