Если вы собираетесь написать n-ную платежную систему, рекомендую ознакомиться с типичными ошибками в реализации API, которые я собрал в процессе написания модулей для своего проекта.
1. Анархия в форматах данных. Например, клиент посылает данные как ключ=значение, в ответ получает xml. Если вы выбрали xml как протокол — используйте его в обе стороны. В запросах и ответах используйте единообразное кодирование и подписывание. Если вы не будете это делать — программисты со стороны клиента будут делать минимально рабочий код, а не как вы планировали. Приведу примерный диалог со службой поддержки одной платежной системы:
я: гарантирую, что ни один магазин не отсылает вам ответ на финальной стадии запроса
поддержка: так и есть! из-за этого мы не можем зафиксировать факт получения этого запроса клиентом
я: это естественно — клиент получил нужную ему инфу, а давать вам валидный ответ — это разбираться в нестандартных тонкостях этого ответа, которые вы выдумали. Поэтому код для этого никто не пишет
2. Баг при склеивании данных для подписи. Такое ощущение, что платежная система обязательно должна переболеть этим багом. Обычно подпись формируют так: берем все параметры запроса, конкатенируем с приватным ключем и вычисляем хеш. Допустим, поле description в порядке конкатенации идет перед суммой — убираем у суммы первую цифру и добавляем к description. Хеш не меняется. В итоге оплачиваем заказ меньшей суммой. Что интересно, программисты сначала сопротивляются признавать это багом, а потом сообщают «ну, мы же не можем менять протокол, он уже используется на широкую ногу». Масса проектов болеет этой болезнью в различных вариациях:
2.1 склейка с помощью разделителей и нефильтрация разделителей в парамерах
2.2 необязательные параметры в подписи, проблема: замена одного параметра на другой с установкой такого же значения
2.3 использование разных действий API с одинаковым набором обязательных параметров, проблема: отправка легального запроса на другую точку API (например, после оплаты послать этот же пакет на реверс)
2.4 отбрасывание невалидных необязательных параметров
3. Изобретение своего таймстампа — надоело писать под каждую систему свой парсер ДДММГГГГЧЧММСС, ГГГГ-ММ-ДДлевыйсимволЧЧ: ММ: СС и т.д множество вариантов. Чем стандартный таймстамп не устраивает?
4. Коды ошибок. Я понимаю, что ваша платежная система работает идеально и для кодов ошибок вы предусмотрели только ошибки на моей стороне. Пожалуйста, предусмотрите код ошибки «неверные данные со стороны платежной системы», которым может ответить клиентский код
5. Поскольку ваши протоколы не транзакционные, предусмотрите механизм обработки дублирующих запросов. Хотя бы опишите в документации что нужно вам отвечать в этом случае.
6. Недокументированные и как следствие малозащищенные методы API. Обычно в них не проверяется подпись, проверка по ip и т.д. Тайное рано или поздно станет явным — программисты частенько не засиживаются на одном месте работы и за пивком сольют подобное:
— прикиньте, а банкоматчики к нам ходили без проверки подписи, потому что им было влом менять софт на тысячах банкоматов.
7. Ужасная документация — приходится как кузнечик прыгать по всему документу пока поймешь как оно работает. Хотя..., это общая проблема любого проекта
8. Не давайте дурных примеров: на приводите в документации упрощенный пример, код которого предусматривает явное присутствие секретного ключа в html странице — поверьте, некоторые этот код скопируют в сайты своих магазинов.
Автор:
