И так продолжим по предыдущей теме. Вот вам подборка реалистичных, но не заведомо очевидных примеров кода и кейсов, с которыми QA-инженер может (и должен!) столкнуться при тестировании платежных API — особенно в сложных или банковских интеграциях. Будет смесь:
• REST (с JSON)
• SOAP (с XML)
• подписи (HMAC)
• нестандартных багов
• и реальных «граблей», которые часто упускают

⸻

💥 Пример 1: Простой POST-запрос на создание платежа

POST /api/v1/payment/create
Content-Type: application/json
X-Signature: 95f39e3aa28c49cfcaf60321f9be2d76edbc0c4b234…

{
«amount»: 99.95,
«currency»: «USD»,
«order_id»: «ORD-78910»,
«customer_id»: «cust_123456»,
«description»: «Test payment»,
«callback_url»: «https://merchant.example.com/payment-callback»,
«success_url»: «https://merchant.example.com/success»,
«fail_url»: «https://merchant.example.com/fail»,
«timestamp»: «2025-06-03T12:00:00Z»,
«payment_method»: «card»,
«metadata»: {
«campaign_id»: «SUMMER2025»,
«promo_used»: true
}
}

⸻

⚠️ Пример 2: Ошибка в подписи — изменён amount

Платёжная система вычисляет HMAC-подпись от сырого тела запроса. Если даже на 1 символ что-то поменялось — она должна сломаться.

— «amount»: 99.95,
+ «amount»: 99.950,

💣 Многие баги случаются, когда фронт округляет с точностью до 3 знаков, а сервер ожидает 2. Подпись ломается, а разработчики часами ищут, где ошибка.

⸻

🔐 Пример 3: Проверка HMAC-подписи на сервере (Node.js)

const crypto = require(‘crypto’);

function isValidSignature(payload, signature, secret) {
const computedSignature = crypto
.createHmac(‘sha256’, secret)
.update(payload)
.digest(‘hex’);

return crypto.timingSafeEqual(
Buffer.from(signature, ‘hex’),
Buffer.from(computedSignature, ‘hex’)
);
}

🧪 Тест-кейс: изменить payload, оставить подпись прежней → сервер должен отказать.

⸻

☠️ Пример 4: Валидный JSON, но невалидный бизнес-кейс

{
«amount»: 0.01,
«currency»: «USD»,
«payment_method»: «card»,
«customer_id»: «cust_deleted»,
«order_id»: «reused-order-id»
}

• customer_id удалён → отказ
• order_id уже использовался → конфликт
• сумма подозрительно маленькая → fraud-flag

⸻

🛑 Пример 5: SOAP-запрос к банковскому API

500.00 EUR DE12345678901234567890 QA test transaction 2025-06-03T11:45:00Z

🧪 Банки могут ответить 200 OK с ошибкой внутри XML, что ломает REST-рефлексы QA.

⸻

🔄 Пример 6: Webhook (callback) от платёжки

POST /payment-callback
Content-Type: application/json
X-Signature: f3c4a68ba5f…

{
«event»: «payment_success»,
«order_id»: «ORD-78910»,
«status»: «success»,
«amount»: 99.95,
«currency»: «USD»,
«processed_at»: «2025-06-03T12:01:45Z»
}

⚠️ Ошибки:
• приходят повторно (5-10 раз при 500-ответах)
• могут прийти раньше, чем ответ клиенту
• содержат поля, которых нет в официальной доке

⸻

🧨 Пример 7: Broken timestamp

«timestamp»: «2038-01-19T03:14:08Z» // UNIX overflow edge

Или:

«timestamp»: «not-a-date»

Проверка:
• сломается ли валидация?
• подпись остаётся валидной?
• будет ли баг при обработке времени (например, +3 часа к UTC)?

⸻

🛡 Пример 8: Anti-fraud флаг (internal-only)

Некоторые платёжные API возвращают поле, которое не документировано, но влияет на отображение:

«fraud_check»: {
«score»: 85,
«action»: «hold»,
«reason»: «unusual_country»
}

💡 Эти данные:
• могут быть вырезаны в Sandbox-режиме
• не логируются, но приходят
• влияют на финальный статус

⸻

🧠 Пример 9: Race condition в order_id

// JS-псевдокод, отправка двух запросов с одинаковым order_id
Promise.all([
axios.post(‘/payment/create’, data),
axios.post(‘/payment/create’, data),
]);

Система должна:
• принять только 1 платёж
• второй отклонить как дубликат (идемпотентность)

На практике:
• бывают случаи двойного списания
• или оба запроса возвращают 200 — но один “мёртвый”

⸻

📊 Пример 10: Лог trace_id

{
«trace_id»: «8df991fe01ad42dba0a26d404dd1»,
«span_id»: «fc3b3c5dca42b6c7»,
«request_id»: «REQ-123456»
}

Если у платёжной системы есть observability-инфраструктура (например, Jaeger + OpenTelemetry), она может:
• показывать все сервисы, через которые прошёл платёж
• логгировать ошибки только если span_id != expected

QA может сравнивать трассировку успешного и неуспешного платежа, чтобы найти точку сбоя…