Я QA-инженер, который любит истину больше, чем шпаргалки. Если вы работаете с финтехом, рано или поздно вы упрётесь в необходимость тестировать создание платёжного запроса — будь то локальный банк, кастомная биллинговая система или интеграция с провайдером уровня Adyen.

И да, если вы думаете, что /payment/create — это просто JSON с amount и currency, вы либо ещё не сталкивались с реальной продакшн-системой, либо вам пока везло.

В этой статье — не просто чеклист. А взгляд под капот. Что на самом деле важно? Где тестировщик может стать ключевым элементом успеха платёжного продукта, а не просто очередным “прогнал Postman-ом, ответ 200, всё ОК”.

⸻

📦 Базовые поля, которые нужно тестировать

Да, это основа. Да, многие пишут её в шпаргалки. Но не переписывай, пока не поймёшь, зачем оно всё нужно:

Поле /// На что тестировать
amount тип (float/int), округление, отрицательные/нулевые/большие значения
currency ISO-код, обязательность, поддержка валют, поведение при ошибке
order_id уникальность, идемпотентность
customer_id привязка к существующему клиенту, реакция на несуществующий
description длина, язык, спецсимволы
callback_url валидность, доступность, формат нотификаций
success_url / fail_url редиректы, работа при ошибках
signature криптографическая проверка, чувствительность к изменениям
timestamp актуальность (±5 мин), ISO 8601, работа с будущими/старыми датами
payment_method поддерживаемые методы, проверка отказов
metadata вложенность, типизация, ошибки сериализации

⸻

🧨 Что тестировать обязательно

✅ Позитивные кейсы:
• валидный запрос → успешный платёж
• правильный редирект
• получение уведомления на callback

❌ Негативные кейсы:
• некорректный JSON
• неверная подпись
• просроченный timestamp
• повторный запрос с тем же order_id
• неподдерживаемый payment_method

⸻

🚧 Куда шпаргалки не заглядывают: реальность банков и финтеха

«Со всей моей любовью к тебе, но ты не прав!» — это про тех, кто думает, будто все платёжные API — это JSON, Stripe и удобные OpenAPI схемы.

🧼 SOAP, XML и кастомные ада:

Если ты тестируешь реальный банк, будь готов к:
• XML на SOAP с вложенностью уровня «Ловец снов»
• кастомным XSD-схемам
• отсутствию REST вообще
• обязательным TLS-сертификатам для каждого запроса

Да, в 2025-м это живо и доминирует в старых кор-системах.

⸻

🔐 Продвинутая логика: о чём не пишут в документации

🧠 Скоринг и антифрод
• Даже если платёж прошёл, он может быть silently declined через пару секунд, если антифрод ML-модель посчитает пользователя подозрительным.
• Факторы: IP, geolocation, история клиента, браузер, device fingerprint.

Тестируй:
• Поведение при странной географии (например, внезапно из Бангладеша)
• Повторные транзакции от одного клиента
• Транзакции сразу после регистрации

⸻

🔄 Идемпотентность

order_id должен гарантировать, что второй такой же запрос не создаст новый платёж. Но в сложных микросервисах это легко ломается.

Тестируй:
• Два запроса одновременно
• Два запроса с разной сигнатурой, но одинаковым order_id
• Поведение при падении БД между двумя запросами

⸻

🔐 Токенизация и PCI DSS
• Вообще-то ты не должен видеть номер карты ни в логах, ни в базе, ни в Postman. Только токен.
• Платёж идёт через iframe или SDK → токен → backend.

Тестируй:
• Что номер карты не попадает в багрепорты и мониторинг (например, в Sentry)
• Ошибки токенизации (CVV missing, expired token)

⸻

🔁 Callback и Webhook: боль QA и DevOps

• Некоторые системы делают до 10 попыток доставки callback.
• Некоторые — только одну.
• Подпись webhook’а часто подписывается HMAC-SHA256.

Тестируй:
• Что callback приходит в правильном формате
• Что он приходит только один раз
• Что повтор не дублирует платёж
• Что сигнатура проверяется
• Что система не умирает при 500 от callback-url

⸻

🕵️‍♂️ Observability и Traceability

В современных системах используют:
• OpenTelemetry
• Jaeger
• Sentry + APM

Тестируй:
• Наличие trace_id и span_id в логах
• Алёрты на превышение SLA (например, платёж > 3 сек)
• Полная цепочка от клиента до PSP

⸻

💥 Chaos Testing и отказоустойчивость

Реальные кейсы, которые тестируют финтех-команды:
• Выключили Redis, как это повлияло на платёж
• Отключили webhook — где об этом узнали?
• Упал внешний PSP — сработал ли fallback?

⸻

📊 Финальное: вопросы, которые должен задать себе крутой QA

1. Кто владеет логикой проверки подписей?
2. Какие статусы бывают в системе, кроме success и fail?
3. Что будет, если платёж прошёл, но webhook не доставился?
4. Можно ли один order_id использовать повторно?
5. Какой SLA по времени ответа?

⸻

🧠 Выводы

🧾 Да, чеклисты важны.
🤖 Но если ты понимаешь, что происходит от момента, когда вставляешь карту в банкомат, до момента, когда деньги списываются со счёта — ты становишься не просто QA, а полноценным участником платёжного продукта.

💥 И да — реальный платёжный API — это всегда борьба между безопасностью, надёжностью, UX и здравым смыслом.