Навіщо взагалі потрібне «гео QA» у платіжній воронці
У реальному житті платіжна воронка майже ніколи не є «однакова для всіх». Для різних країн відрізняються доступні методи оплати, вимоги до автентифікації картки, обмеження банків, правила KYC/AML, локалізація Checkout, навіть те, які поля адреси є обов’язковими. Тому qa платежів гео — це окремий напрям тестування, який перевіряє, що ваш продукт коректно працює в різних країнах і не ламає конверсію через дрібні, але критичні нюанси.
Під «платіжною воронкою» у цій статті маємо на увазі шлях: ціна/валюта → форма оплати → 3DS2/Strong Customer Authentication (SCA) → успіх/відмова → пост‑оплата (вебхуки, квитанції, оновлення підписки) → за потреби KYC (Identity/Connect). Якщо ви тестуєте Stripe, найчастіше це комбінація Stripe Payments + Stripe Checkout, а у складніших продуктах — Stripe Connect та/або Stripe Identity.
Що саме залежить від гео у Stripe, Checkout і 3DS2
- Доступність методів оплати: картки, місцеві перекази, гаманці — різняться за країнами й валютою.
- 3DS2/SCA: у ЄЕЗ частіше спрацьовує SCA, а для окремих транзакцій може вимагатися челендж. Потрібно перевіряти і «frictionless», і «challenge» сценарії.
- Поведінка банків-емітентів: один і той самий флоу може поводитися по‑різному для «міжнародних» карток та карток певних країн.
- Валюта та ціноутворення: округлення, податки, відображення ціни, локальні формати (коми/крапки).
- Локалізація Checkout: мова, порядок полів, підказки, доступність адресних атрибутів.
- KYC: країна користувача впливає на набір документів, підтримувані перевірки, обов’язкові поля та «пороги» (особливо у Connect‑онбордингу).
Чому саме мобільні проксі, а не «звичайний VPN»
Для перевірки гео‑поведінки багато хто починає з VPN, але в QA це часто дає «шум»: частина платіжних сторінок, антифрод‑систем і 3DS2‑флоу реагують на датацентрові IP‑адреси інакше, ніж на «живі» мобільні. Мобільні проксі (4G/LTE/5G) зазвичай мають більш «натуральний» профіль для банків та антифроду: вони схожі на звичайного користувача зі смартфона або домашнього роутера з LTE‑модемом.
Ключовий плюс для тестування — можливість швидко міняти країну/оператора і відтворювати «побутові» умови: реальні мережі, NAT, змінність IP. Це важливо, коли ви ловите баги на межі: наприклад, коли Stripe/банківська сторінка 3DS віддає інший сценарій через підозру на бот‑трафік або нестандартний фингерпринт.
Важливо: проксі потрібні не для обходу правил, а для відтворення середовища користувача під час тестування. Працюйте у test mode, з тестовими картками та валідними тестовими сценаріями.
Архітектура тестування: що підготувати до першого прогону
- Середовище: Stripe test mode (або Sandboxes, якщо ви тестуєте окремі фічі), окремий тестовий домен/стенд.
- Інструменти: браузерні профілі (щоб не змішувати cookies), DevTools, проксі‑менеджер/розширення, за потреби — Stripe CLI для вебхуків.
- Логи: кореляційний ID для замовлення/сесії, логування client_secret, payment_intent.id, checkout.session.id, outcome (success/failure) та причини відмови.
- Матриця гео: список країн/регіонів, які реально важливі для бізнесу (топ‑трафік, топ‑дохід, країни з підвищеним ризиком).
- Набір сценаріїв: мінімальний набір «золотих» флоу + негативні кейси (відмова 3DS, timeout, відхилений платіж, помилки адреси).
Базова матриця сценаріїв для Stripe Checkout
Нижче — практична матриця, яка добре покриває найчастіші регресії у воронці. Її можна розширювати під ваш продукт.
- Ціна/валюта: правильне відображення валюти для гео; коректне округлення; коректна ціна після промо/купонів.
- Метод оплати: картка (Visa/Mastercard), міжнародна картка «не з країни користувача», наявність/відсутність локальних методів.
- 3DS2: сценарій без челенджу (frictionless), сценарій з челенджем (challenge), відмова користувача у 3DS‑вікні, повторна спроба.
- Адреса та індекси: обов’язкові поля в Checkout, помилки формату, автозаповнення.
- Мобільний vs десктоп: різна поведінка 3DS‑вікна/редіректів, блокування поп‑апів.
- Після оплати: редірект на success/cancel, коректний статус у бекенді, правильна обробка вебхуків.
Це і є ядро stripe qa: перевірка, що на будь‑якому з кроків не з’являється регресія, яка «вбиває» оплату в окремій країні.
3DS2 тестування: як відтворити frictionless і challenge
3DS2 (EMV 3‑D Secure) працює як протокол автентифікації: для частини транзакцій банк може провести її без видимого кроку для користувача (frictionless), а для частини — показати челендж (OTP/підтвердження в застосунку). У тестовому середовищі Stripe дає тестові картки та «мок»‑сторінку автентифікації, де ви можете підтвердити або скасувати челендж.
- Перевіряйте обидва режими: «успішний frictionless» та «успішний/неуспішний challenge».
- Перевіряйте edge‑кейси: користувач закрив вкладку 3DS, повернувся назад, оновив сторінку, змінив мову браузера.
- Перевіряйте відновлення: повторна спроба оплати, збереження кошика, відсутність дублювання замовлення.
У багатьох командах 3ds2 тестування провалюється не через сам протокол, а через UI/UX та обробку станів: некоректні повідомлення, нескінченні спінери, неправильний статус у кабінеті користувача.
Гео‑пастки в 3DS2: що ламається найчастіше
- Невідповідність країни IP і країни картки: у частини банків це підвищує ризик і частіше запускає челендж або відмову.
- Зміна IP під час редіректів: мобільні мережі можуть змінити IP. Якщо ваш фронт/бекенд жорстко прив’язаний до IP, можливі помилки сесії.
- Блокування third‑party cookies: у деяких браузерах/налаштуваннях 3DS‑фрейм може «посипатись».
- Локаль і час: різні формати дат/адрес, різні часові пояси, що впливають на таймаути.
KYC гео: як тестувати, не потрапляючи у пастку «живих документів»
KYC‑частина може з’являтися у двох типових випадках: (1) ви онбордите мерчантів/партнерів у Stripe Connect, (2) ви верифікуєте кінцевих користувачів через Stripe Identity або інший провайдер. У будь‑якому разі гео впливає на те, які документи і які поля будуть потрібні.
- Почніть з правил: зафіксуйте, для яких країн KYC обов’язковий, а де — тригериться умовами (пороги, ризик‑сигнали, тип продукту).
- Тестуйте стани: pending → verified, pending → requires_more_information, rejected.
- Тестуйте UX: зрозумілі підказки по документам, локалізація, повторне завантаження, підтримка мобільної камери.
Фокусуйтеся на процесі та статусах, а не на «підборі реальних документів». Для QA важливо відтворити стани й обробку інтеграції, а не обходити комплаєнс. Саме таке kyc гео тестування дає найбільшу користь продукту.
Чек‑лист: що перевіряти в кожній країні (коротко)
- Вхідні умови: IP країни (мобільний), мова браузера, часовий пояс, валюта ціни.
- Checkout UI: локалізація, поля адреси, повідомлення про помилки.
- Оплата: успіх/відмова, відображення комісій/податків (якщо є).
- 3DS2: frictionless + challenge + cancel у челенджі + повторна спроба.
- Вебхуки: отримали події, ідемпотентність, відсутність дублювань, коректні статуси в БД.
- Пост‑оплата: email‑квитанції, сторінка успіху, доступ до контенту/підписки.
- KYC: правильний набір полів/документів, стани та повторні спроби.
Практичний підхід: як організувати прогін з мобільними проксі
Щоб мобільні проксі реально допомагали, а не створювали хаос, потрібна дисципліна: одна сесія браузера = один прогін, одна країна = окремий профіль/контейнер, жорстка прив’язка до тестового сценарію.
- Крок 1. Виберіть країну з матриці й підніміть мобільний проксі під неї.
- Крок 2. Встановіть мову браузера/локаль відповідно до країни (або тестуйте «неочікувані» комбінації, якщо це ваша ціль).
- Крок 3. Пройдіть сценарій «успішна оплата» і зафіксуйте всі ідентифікатори (Checkout Session, PaymentIntent, customer).
- Крок 4. Повторіть 3DS2 кейси (challenge/cancel) та негативні кейси (decline) — і перевірте, що бекенд поводиться коректно.
- Крок 5. Перевірте вебхуки та стани в адмінці/кабінеті користувача.
Типові баги, які ловляться тільки на «гео»
- Неправильна валюта в Checkout після редіректу з локалізованої сторінки.
- Помилка індексу/адреси лише для конкретних країн, бо валідатор очікує інший формат.
- 3DS‑вікно не відкривається на мобільних браузерах або блокується політиками поп‑апів.
- Подвійне створення замовлення при поверненні з 3DS (неідеальна ідемпотентність).
- Неправильний статус підписки через затримки або втрату вебхуків у певних регіонах.
- KYC зациклюється: користувач завантажив документ, але UI лишився в pending без оновлення.
Як робити це «по‑дорослому»: метрики й автоматизація
Ручне тестування потрібне, але в платежах важливо мати і вимірювання. Мінімальний набір:
- Конверсія по країнах (від старту Checkout до success).
- Частка 3DS‑челенджів і частка відмов у челенджі.
- Причини відмов (insufficient_funds, do_not_honor, authentication_required тощо).
- Час до success (з урахуванням 3DS).
- Доля помилок KYC та час проходження верифікації.
Для регресійних прогонів корисно автоматизувати частину сценаріїв на рівні API (створення PaymentIntent/Checkout Session, перевірка вебхуків, перевірка статусів). Але 3DS2 і KYC завжди матимуть компонент «людського» флоу — його треба тестувати як UX.
Висновок
Мобільні проксі — це практичний інструмент для відтворення реальних умов користувача у різних країнах. Якщо ви тестуєте Stripe/Checkout, 3DS2 та KYC, підхід «одна країна = один дисциплінований прогін» допоможе знайти баги, які не видно у локальному середовищі. Будуйте матрицю гео, тестуйте 3DS2 у frictionless і challenge режимах, контролюйте вебхуки та стани, і вимірюйте метрики — тоді qa платежів гео стане не разовою перевіркою, а системною частиною якості продукту.