🚨Альфа-тривога 🚨 @tempo щойно вийшов у ефір кілька хвилин тому. З запуском основної мережі вони також запускають специфікацію Machine Payments Protocol. Я отримав ранній доступ до специфікації і маю деякі початкові враження. По-перше, специфікація MPP — це нова, альтернативна версія http-коду 402 «request for payment». Він принципово відрізняється від x402 тим, що видаляє Фасилітатор з архітектури. З одного боку, виключення посередника з потоку зазвичай є хорошою ідеєю. З іншого боку, він переносить логіку обробки, яку обробляє фасилітатор, на торговий сервер. Час покаже, чи це добре чи погано, але я припускаю, що існує переконання, що серверний агент зможе оптимізувати торгові потоки, тому залучення сторонньої сторони до цього зайве. Тепер нам треба почекати і подивитися... Специфікація MPP також розраховує на різні способи оплати, окрім стабільних, зокрема підтримку фіатної оплати кредитною карткою, що, на мою думку, є перевагою. До цього додається підхід, незалежний від PSP, який, на мою думку, подвійний виграш. Продавці повинні мати змогу обрати будь-який спосіб оплати, який обробляє будь-який платіжний сервіс, який вони хочуть. Тепер до моїх питань. По-перше, для оплати картками специфікація має новий метод шифрування, де сервер (тобто торговець) контролює розшифрування корисного навантаження клієнта. На жаль, це викликає питання щодо відповідності PCI. Сервер не контролює, як клієнт (агент покупця) керує делегуванням карт. Визначений шлях, здається, — це DPAN, але сирі PAN також входять у сферу дії залежно від специфікації. Оскільки сервер не контролює корисне навантаження CHD, сирі PAN можна зашифрувати і надіслати на сервер для пересилання на PSP. Це, у свою чергу, вимагатиме від сервера сумісності з PCI, якщо він не може гарантувати, що корисне навантаження завжди буде лише DPAN. Вимагати, щоб кожен сервер був PCI SAQ A або, що ще гірше, відповідав SAQ D, не є масштабованим. По-друге, специфікація дозволяє використовувати кілька способів оплати, але не вирішує транзакції глобально. Хоча це може виглядати нормально, для масштабування платежів між агентами, на мою думку, оптимальним підходом є глобальний реєстр, до якого всі агенти можуть підключатися. Чому, питаєте? З кількох причин, але одна конкретна причина — це встановлення ідентичності. Ідентичність агента буде пов'язана зі статистичним моделюванням, частково заснованим на історії транзакцій. Сучасним прикладом цього є профілювання кредитного ризику. Однак розділені транзакційні мережі призводять до різнорідної історії транзакцій, що створює проблеми при спробах вирішити поведінку. Вітаємо всіх учасників, включаючи наших партнерів з Visa та VGS. Простір робить величезні кроки вперед. Все починає складатися, і ми з нетерпінням чекаємо, щоб розкласти все на свої місця.