Comments 26
Подписываюсь под каждым пунктом. Сейчас подсключаем систему бронирования noname поставщика. Так у них документация — это набор xml докуметов с примерами запросов и ответов. Об их назначении я должен догадываться по названию.
Что еще смущает, так это то, что полгода назад отправил пулреквест одной фирме, где прислал им примеры кода для их документации (документация в открытом виде лежит у них). Ибо их примеры были написанны на версии языка 5-летней давности. И что же. Спустя полгода они даже не удосужились проверить мой коммит. И такое отношение кругом: не работает — разбирайтесь сами.
Хотя встречаются API с отличной документацией и отзывчивым сапортом. Таких на руках носить хочется.
Что еще смущает, так это то, что полгода назад отправил пулреквест одной фирме, где прислал им примеры кода для их документации (документация в открытом виде лежит у них). Ибо их примеры были написанны на версии языка 5-летней давности. И что же. Спустя полгода они даже не удосужились проверить мой коммит. И такое отношение кругом: не работает — разбирайтесь сами.
Хотя встречаются API с отличной документацией и отзывчивым сапортом. Таких на руках носить хочется.
> Чем стандартный таймстамп не устраивает?
Очевидно, отсутствием стандарта на таймстемп.
Очевидно, отсутствием стандарта на таймстемп.
А вот, кстати, есть ли причины, почему их протоколы не могут таки быть транзакционными?
наверное потому, что у них REST-архтектура
Разве нельзя REST-запросами определить начало транзакции, коммит или откат и всё такое?
Можно. Но во-первых, зачем тогда REST? А во-вторых, квалификация программистов клиентов системы обычно невысок — подстраиваются под них в пользу простоты, а не надежности
REST — это не только структура самих URL'ов, но и логика обработки запросов. По REST сервер является stateless, т.е. не хранит состояние между запросами, а все действия — атомарны и самодостаточны. Для обеспечения транзакционности сервер должен быть statefull.
Вы почти правы, однако если бы все было точно так, мы не могли бы аутентифицировать пользователей в REST…
Состояние возможно, просто оно должно определяться запросом…
Что мешает скажем сделать 2 метода:
— start — возвращает уникальный токен транзакции
— commit — завершает транзакцию, определяемую переданным токеном
ну и rollback аналогично…
Если от обычной аутентификации наш сервис не перестал быть REST, то и от этого не перестанет.
Состояние возможно, просто оно должно определяться запросом…
Что мешает скажем сделать 2 метода:
— start — возвращает уникальный токен транзакции
— commit — завершает транзакцию, определяемую переданным токеном
ну и rollback аналогично…
Если от обычной аутентификации наш сервис не перестал быть REST, то и от этого не перестанет.
если сервер ничего не хранит между запросами, то каким образом работает аплоад файлов, регистрация заказов, проводка платежей и прочие замечательные вещи? про это есть замечательная статья, где в терминах непривычных REST интерфейсов описаны особенности привычных платежных систем и популярной системы массового кофейного обслуживания — How to GET a Cup of Coffee (и про транзакции тоже, куда без них). кто бы перевел для хабра…
Всё бы ничего, но у меня был проект, в котором мы общались напрямую с платежным шлюзом одной оооочень крупной компании, клиентами которой тут так или иначе являются очень многие, я просто ох**ренел, когда до реализации валидации данных на клиенте, решил отправить отрицательную сумму платежа, а шлюз ее принял и выдал мне общую сумму: сумма_с_клиента + коммиссия -> отрицательная_сумма
Например: сумма_с_клиента = -2000 руб, коммисия = 20 руб, общая_сумма_платежа = -1980 руб, то есть платежная система осталась должна пользователю 1980 руб!
Количество же архитектурных косяков было просто неимоверным, по-моему они реализовали все грабли из статьи
Например: сумма_с_клиента = -2000 руб, коммисия = 20 руб, общая_сумма_платежа = -1980 руб, то есть платежная система осталась должна пользователю 1980 руб!
Количество же архитектурных косяков было просто неимоверным, по-моему они реализовали все грабли из статьи
А мне больше всего нравится когда пользователь может оплатить заказ после отмены и перехода на failurl… Особенно это весело когда нет возможности проверить статут платежа и нужна сложная обработка заказа (например, начисление бонусов) :)
2. Баг при склеивании данных для подписи.
Простите, но я верно не понял в чем тут проблема.
Провайдер просит платежную систему снять (ПС) с пользователя N денег. Формируется запрос, подписывается и отправляется в ПС.
Если сам провайдер поменял сумму и подписал транзакцию своим же ключиком — почему это должно заботить ПС?
Я согласен с комментарием выше по поводу отрицательной суммы, но в данном случае, какая разница для ПС прислал мне провайдер валидную транзакцию на 10 или 100 денег?
Посмотрел недавно API приёма платежей российских платёжных систем. Иногда за такое хочется взять и, извините, уе… уехать подальше от интернета.
Такое впечатление, что некоторые мелочи туда добавили прямо специально чтобы добавить граблей в реализацию.
Причем неочевидных граблей. Вскользь описанных граблей. Или совсем никак не описанных граблей. Причем у кого три версии API, количество граблей возрастает от версии к версии.
Веселее всего у динозара российских онлайн-платежей.
Параметр «тестовый режим», который
А) не входит в «хеш/дайждест счёта/платежа» (мало кто в здравом уме после прочтения документации этот флаг будет проверять )
Б) типа выключается в контрольной панели (на самом деле фиг, флаг в контрольной панели — всего лишь значение по-умолчанию), что нигде не написано
B) в любом режиме можно провести платёж описанной на сайте «тестовой» карточкой с номером 4222 2222 2222 2222/CVC123 (выключается, но где-то в дебрях, упоминание есть только в английской версии сайта).
Где-то году в 2010 я делал платёжный шлюз webmoney(и др., но этот самый популярный) для биллинга whmcs (и других), по договорённости с первыми пользователями и по сей день я получаю логи обо всех попытках «считерить».
За 4 года попыток «считерить» набралось более нескольких тысяч, если просуммировать рублёвые эквиваленты платежей (здесь учтены только те случаи, где мне известна оригинальная сумма платежа), это более 2млн рублей. И это только несколько довольно небольших предприятий.
Мораль такова: «Если вы владелец магазина, который принимает интернет-платежи, проверяйте транзакции руками, поскольку некоторые ПС работать головой уже, к сожалению, не в состоянии».
Может прямо сейчас у вас за спиной, а возможно и с ведома ваших сотрудников, неустановленные клиенты-физлица выносят, к примеру, диван за 200 тысяч.
Такое впечатление, что некоторые мелочи туда добавили прямо специально чтобы добавить граблей в реализацию.
Причем неочевидных граблей. Вскользь описанных граблей. Или совсем никак не описанных граблей. Причем у кого три версии API, количество граблей возрастает от версии к версии.
Веселее всего у динозара российских онлайн-платежей.
Параметр «тестовый режим», который
А) не входит в «хеш/дайждест счёта/платежа» (мало кто в здравом уме после прочтения документации этот флаг будет проверять )
Б) типа выключается в контрольной панели (на самом деле фиг, флаг в контрольной панели — всего лишь значение по-умолчанию), что нигде не написано
B) в любом режиме можно провести платёж описанной на сайте «тестовой» карточкой с номером 4222 2222 2222 2222/CVC123 (выключается, но где-то в дебрях, упоминание есть только в английской версии сайта).
Где-то году в 2010 я делал платёжный шлюз webmoney(и др., но этот самый популярный) для биллинга whmcs (и других), по договорённости с первыми пользователями и по сей день я получаю логи обо всех попытках «считерить».
За 4 года попыток «считерить» набралось более нескольких тысяч, если просуммировать рублёвые эквиваленты платежей (здесь учтены только те случаи, где мне известна оригинальная сумма платежа), это более 2млн рублей. И это только несколько довольно небольших предприятий.
Мораль такова: «Если вы владелец магазина, который принимает интернет-платежи, проверяйте транзакции руками, поскольку некоторые ПС работать головой уже, к сожалению, не в состоянии».
Может прямо сейчас у вас за спиной, а возможно и с ведома ваших сотрудников, неустановленные клиенты-физлица выносят, к примеру, диван за 200 тысяч.
Кстати, а есть какие-нибудь «гайды» для написания и документирования API? Какой-нибудь ГОСТ
Посмотрите тут: www.restapitutorial.com/
Там есть видео с объяснением основных тем (вверху в меню можно выбрать)
Там есть видео с объяснением основных тем (вверху в меню можно выбрать)
Sign up to leave a comment.
Типичные ошибки API платежных систем