A/B тесты платежных сценариев

1) Зачем тестировать платежные сценарии

Увеличить одобрения (AR) и снизить отказы (DR).
Уменьшить стоимость: take-rate (interchange/scheme/markup/fixed) и cost-per-approval.
Снизить риск: меньше чарджбеков/фрода при тех же одобрениях.
Устойчивость: подобрать провайдера/3DS-стратегию/роутинг под конкретные GEO/BIN/методы.

2) Дизайн эксперимента

2.1. Юнит рандомизации

User-level (рекомендуется): все попытки одного пользователя попадают в одну ветку → нет «перемешивания» 3DS/токенов.
BIN-level: когда тест — о роутинге по эмитенту; риск кросс-пользовательского смешения.
Order/Attempt-level: допустимо для мелких UI-экспериментов (например, копия ошибки), нежелательно для роутинга/3DS.

2.2. Стратификация (до рандомизации)

Стратифицируйте по: GEO игрока, issuer country/BIN6, метод оплаты, канал (web/app), сумма-сегмент, риск-скор. Это уменьшит дисперсию и риск SRM.

2.3. Что тестируем

Роутинг/каскад: PSP_A vs PSP_B, sticky BIN, лимит-aware.
3DS-политика: frictionless→challenge, принудительный 3DS для BIN/гео.
UX флоу: последовательность шагов, тексты ошибок/повторов.
Параметры ретрая: окна и коды soft-decline.
Ценообразование: провайдер с IC++ vs blended и влияние на all-in стоимость.

3) Метрики: целевые, вторичные, guardrails

3.1. Основные

AR (Approval Rate) = approved/attempted.
Cost-per-Approval = (auth+decline fees)/approved.
Take-rate % (all-in) = fees/volume (в отчетной валюте).
3DS pass-rate; liability shift %.
Latency p95/p99 платежного флоу.

3.2. Риск-метрики

Chargeback ratio (CBR), refund rate, fraud alerts/1000 trx.
FX slippage (bps) = effective vs reference FX.

3.3. Guardrails (стоп-условия)

Падение AR > Y bps или рост CBR/Refunds выше порога.
SRM (Sample Ratio Mismatch) — дисбаланс трафика против ожидаемого.
Spikes: латентность, soft-decline surge, 3DS anomaly.

4) Статистика и мощность

4.1. Размер выборки (приближение для долей)

n_per_group ≈ 2 (Z_{1-α/2} + Z_{1-β})^2 p(1-p) / δ^2

где `p` — базовый AR, `δ` — ожидаемый uplift в AR, α — уровень значимости, β — ошибка II рода.

4.2. Последовательный анализ (ранние остановки)

Alpha-spending (O’Brien–Fleming/Pocock): фиксируем график проверок и расходуем α по этапам.
SPRT/Bayes — для оперативных решений, но фиксируйте протокол.

4.3. Варианс-редакшн

CUPED: `Y = Y − θ (X − μ_X)`, где X — предэкспериментальный ковариат (AR/DR/риск-скор), θ — ковариантный коэффициент.
Стратифицированные оценки, кластер-робастные ошибки (user/BIN-кластеры).
Bootstrap для take-rate/стоимостных метрик (тяжелые хвосты).

4.4. Мультивариантные тесты и bandits

MAB (UCB/Thompson): когда важно «учиться» на лету и не терять оборот.
Для комплаенс-критичных метрик (CBR, liability) — предпочитайте классический A/B с guardrails.

5) Архитектура платформы экспериментов

1. Assignment-сервис: детерминированный хэш `(user_id, experiment_id, salt)` → bucket.
2. Feature-флаги/Rules-engine: активация маршрута/3DS/ретрая по ветке.
3. События: попытки/результаты (authorize/capture/refund/cb) → шина (Kafka/PubSub).
4. Идемпотентность: общий `idempotency_key` на каскад.
5. DWH/Витрины: нормализованные статусы, fees, FX, риск-флаги.
6. Мониторинг: online-SLI (AR/3DS/latency), алерты, SRM-чек.
7. Протоколы: pre-register гипотезу, финальные критерии, дата-фриз.

6) Модель данных (минимум)

sql ref. experiments (
exp_id PK, name, hypothesis, owner, start_at, end_at,
unit -- USER      BIN      ORDER,
target_metric, guardrails JSONB, design JSONB, alpha NUMERIC, power NUMERIC, meta JSONB
);

ref. experiment_arms (
exp_id FK, arm_id, name, traffic_share NUMERIC, params JSONB, enabled BOOLEAN
);

assignments. buckets (
exp_id, user_id, assigned_arm, assigned_at, salt, hash_key, PRIMARY KEY (exp_id, user_id)
);

events. payments (
attempt_id PK, user_id, exp_id, arm_id,
provider, method, bin, iso2, risk_score,
status, decline_code, three_ds_used BOOLEAN, liability_shift BOOLEAN,
amount_minor BIGINT, currency, latency_ms INT,
authorized_at, captured_at, settled_at, meta JSONB
);

finance. fees (
attempt_id FK, interchange_amt NUMERIC, scheme_amt NUMERIC, markup_amt NUMERIC,
auth_amt NUMERIC, refund_amt NUMERIC, cb_amt NUMERIC, gateway_amt NUMERIC,
fx_slippage_amt NUMERIC, reporting_currency TEXT
);

risk. outcomes (
attempt_id FK, is_refund BOOLEAN, is_chargeback BOOLEAN, fraud_alert BOOLEAN
);

7) SQL-шаблоны

7.1. SRM-чек (доля трафика по рукам)

sql
SELECT arm_id,
COUNT() AS n,
ROUND(100. 0 COUNT() / SUM(COUNT()) OVER (), 2) AS share_pct
FROM assignments. buckets
WHERE exp_id =:exp
GROUP BY 1;

7.2. Основные метрики по рукам

sql
WITH base AS (
SELECT e. arm_id,
COUNT()                  AS attempts,
COUNT() FILTER (WHERE status='APPROVED') AS approvals,
AVG(latency_ms)              AS latency_avg_ms,
AVG((three_ds_used)::int)         AS three_ds_share
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
GROUP BY 1
),
cost AS (
SELECT e. arm_id,
SUM(f. interchange_amt + f. scheme_amt + f. markup_amt +
f. auth_amt + f. refund_amt + f. cb_amt + f. gateway_amt + f. fx_slippage_amt) AS fees_rep,
SUM(e. amount_minor)/100. 0 AS volume_rep
FROM events. payments e
JOIN finance. fees f USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT b. arm_id,
approvals::numeric/NULLIF(attempts,0)             AS ar,
fees_rep/NULLIF(volume_rep,0)                 AS take_rate,
(SELECT COUNT() FROM risk. outcomes r
JOIN events. payments e2 USING (attempt_id)
WHERE e2. exp_id=:exp AND e2. arm_id=b. arm_id AND r. is_chargeback)=0
AS cb_zero_flag,
latency_avg_ms, three_ds_share
FROM base b LEFT JOIN cost c ON c. arm_id=b. arm_id;

7.3. CUPED для AR (пример)

sql
WITH pre AS (
SELECT user_id, AVG((status='APPROVED')::int) AS ar_pre
FROM events. payments
WHERE authorized_at <:pre_from_end
GROUP BY 1
),
cur AS (
SELECT e. user_id, e. arm_id, (e. status='APPROVED')::int AS ar_flag
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
)
SELECT arm_id,
AVG(ar_flag - theta (ar_pre - mu_pre)) AS ar_cuped
FROM cur
LEFT JOIN pre USING (user_id),
LATERAL (SELECT AVG(ar_pre) AS mu_pre FROM pre) mu,
LATERAL (SELECT COVAR_SAMP(ar_flag, ar_pre)/VAR_SAMP(ar_pre) AS theta FROM cur LEFT JOIN pre USING(user_id)) t
GROUP BY arm_id;

7.4. Проверка guardrails (пример)

sql
SELECT arm_id,
100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) AS cbr_pct,
100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) AS refund_pct
FROM risk. outcomes r
JOIN events. payments e USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
HAVING 100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) >:cbr_threshold
OR 100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) >:refund_threshold;

8) Процесс проведения теста (энд-ту-энд)

1. Pre-registration: гипотеза, метрики, дизайн, размеры, стоп-правила.
2. SRM/AA-тест на «пустом» эффекте (пару дней).
3. Запуск: assignment freeze, логика в rules-engine/фичефлагах.
4. Мониторинг онлайн: AR/3DS/latency/health + guardrails.
5. Промежуточные проверки по alpha-spending (если планировались).
6. Финиш и дата-фриз: только после учета funding/резервов/поздних CB/refunds.
7. Аналитика: CUPED/стратификация, чувствительность, гетерогенность по GEO/BIN/методу/каналу.
8. Решение: roll-out, roll-back, или follow-up тест; обновление правил/роутинга.
9. Документация и ретроспектива: уроки, обновление порогов/весов.

9) Анти-паттерны и ловушки

Peeking/пере-смотр без протокола → ложные победы.
Order-level рандомизация в тестах роутинга → утечки между руками.
Игра с множественностью (много метрик/срезов) без коррекции α.
Неполная стоимость (забыли FX/резерв/refund fees) → неверный take-rate.
Отсутствие SRM-чека → смещенные выводы.
Неидемпотентные ретраи → двойные авторизации/искажения AR.

10) Безопасность, комплаенс и этика

Same-method/return-to-source не должны ломаться тестом.
Санкции/лицензии/GEO-политики — вне экспериментов.
RG/ответственная игра: не ухудшать защитные механизмы ради AR.
PCI/GDPR: токены вместо PAN, минимизация персональных данных, DPA/SOC2.

11) KPI дашборда эксперимента

AR/DR, uplift и доверительные интервалы по рукам и ключевым стратификациям (GEO/BIN/метод).
Cost-per-Approval, take-rate %, FX slippage (bps).
3DS pass/liability shift, soft-decline share.
Latency p95/p99, ошибки/таймауты.
CB/Refunds (lag-aware), SRM, охват трафика, длительность.

12) Best practices (коротко)

1. Рандомизируйте на уровне пользователя и стратифицируйте.
2. Используйте guardrails и SRM-чек; фиксируйте протокол.
3. Считайте полную стоимость (fees+FX+reserve) и cost-per-approval.
4. Применяйте CUPED, кластер-робастные ошибки и bootstrap для стоимостных метрик.
5. Для критичных рисков — классический A/B; bandits — для преимущественно ценовых/AR задач.
6. Учитывайте funding/резервы/поздние CB перед финальным выводом.
7. Документируйте и версионируйте правила; делайте post-mortem.

13) Чек-лист запуска

• Гипотеза, метрики, эффект, дизайн, размер выборки, срок.
• Юнит рандомизации и страты, assignment-сервис, фичефлаги.
• Guardrails/пороги, SRM/AA-precheck, алерты.
• Логи/события, идемпотентность, нормализация статусов.
• Витрины fees/FX/reserve; отчетная валюта.
• План остановок (alpha-spending) и дата-фриз.
• Плейбуки roll-out/roll-back; документация результатов.

Резюме

A/B тесты платежных сценариев — это инженерно-статистическая дисциплина: правильная рандомизация и стратификация, полные метрики стоимости и риска, guardrails и SRM, аккуратная аналитика (CUPED/кластер-робастность/последовательный анализ) и «боеспособная» инфраструктура (идемпотентность, телеметрия, reconciliation). Следуя этой методике, вы повышаете AR, снижаете all-in take-rate и при этом не платите за «ложные победы» ростом чарджбеков и регуляторных рисков.