🚨Альфа-уведомление 🚨 @tempo только что вышел в эфир несколько минут назад. С запуском основной сети они также запускают спецификацию Протокола Машинных Платежей. Я получил ранний доступ к спецификации и у меня есть некоторые первоначальные мысли. Во-первых, спецификация MPP — это новый, альтернативный подход к коду http 402 "запрос на оплату". Она принципиально отличается от x402 тем, что исключает Посредника из архитектуры. С одной стороны, удаление посредника из потока обычно является хорошей идеей. С другой стороны, это перемещает логику обработки, которую обрабатывал Посредник, на сервер торговца. Время покажет, хорошо это или плохо, но, по моему мнению, существует мнение, что агент на стороне сервера сможет оптимизировать потоки торговца, поэтому наличие третьей стороны для этого избыточно. Теперь нам нужно подождать и посмотреть… Спецификация MPP также разрабатывает различные методы оплаты помимо стейблов, включая поддержку фиатных денег через оплату кредитной картой, что, я думаю, является плюсом. Дополняет это подход, не зависящий от PSP, что, по моему мнению, является двойным плюсом. Торговцы должны иметь возможность выбирать любой метод оплаты, обрабатываемый любым поставщиком платежных услуг, который они хотят. Теперь перейдем к вопросам, которые у меня есть. Во-первых, для платежей по картам спецификация имеет новый метод шифрования, при котором Сервер (т.е. Торговец) контролирует расшифровку полезной нагрузки Клиента. К сожалению, это вызывает вопросы о соответствии PCI. Сервер не контролирует, как Клиент (агент, совершающий покупку) управляет своей делегацией карты. Предполагаемый маршрут, похоже, — это DPAN, но необработанные PAN также находятся в области действия спецификации. Поскольку Сервер не контролирует полезную нагрузку CHD, необработанные PAN могут быть зашифрованы и отправлены на Сервер для пересылки к PSP Серверу. Это, в свою очередь, потребует от Сервера соответствия PCI, если он не может гарантировать, что полезная нагрузка всегда будет только DPAN. Требование, чтобы каждый Сервер соответствовал PCI SAQ A или, что еще хуже, SAQ D, не является масштабируемым. Во-вторых, спецификация позволяет использовать несколько методов оплаты, но не решает транзакции глобально. Хотя это может выглядеть нормально, для масштабирования платежей от агента к агенту, по моему мнению, наличие глобального реестра, в который могут подключаться все агенты, является оптимальным подходом. Почему вы спрашиваете? По ряду причин, но одна конкретная причина — это установление идентичности. Идентичность агента будет связана с статистическим моделированием, основанным, отчасти, на транзакционной истории. Современный пример этого — профилирование кредитного риска. Однако сегментированные сети транзакций приведут к разрозненной транзакционной истории, что вызовет проблемы при попытке разрешить поведение. Поздравляю всех участников, включая наших партнеров в Visa и VGS. Эта сфера делает огромные шаги вперед. Вещи начинают складываться, и мы с нетерпением ждем, когда сможем собрать все части вместе.