Төлем сценарийлерінің A/B тестілері

1) Төлем сценарийлерін тестілеудің қажеті

Мақұлдауды ұлғайту (AR) және істен шығуды азайту (DR).
Құнын азайту: take-rate (interchange/scheme/markup/fixed) және cost-per-approval.
Тәуекелді төмендету: сол мақұлдаулар кезінде шарджбек/фрод аз.
Тұрақтылық: нақты GEO/BIN/әдістерге провайдерді/3DS-стратегияны/роутингті таңдау.

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, BIN/гео үшін мәжбүрлі 3DS.
UX флоу: қадамдар тізбегі, қате/қайталау мәтіндері.
Қайта қарау параметрлері: терезелер және soft-decline кодтары.
Баға белгілеу: IC++ vs blended бар провайдер және барлық-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, 'δ' - AR күтілетін uplift, α - маңыздылық деңгейі, β - II түрдегі қате.

4. 2. Жүйелі талдау (ерте тоқтау)

Alpha-spending (O'Brien-Fleming/Pocock): тексеру кестесін бекітеміз және α кезеңдер бойынша жұмсаймыз.
SPRT/Bayes - жедел шешімдер үшін, бірақ хаттаманы белгілеңіз.

4. 3. Редакциялау нұсқасы

CUPED: 'Y = Y − θ (X − μ_X)', мұнда X - эксперименталды ковариат (AR/DR/тәуекел-скор), θ - ковариантты коэффициент.
Стратификацияланған бағалау, кластер-қателер (user/BIN-кластерлер).
take-rate/құндық метриктер үшін Bootstrap (ауыр құйрықтар).

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

MAB (UCB/Thompson): ұшу кезінде «үйрену» және айналымды жоғалтпау маңызды болғанда.
Комплаенс-критикалық метриктер үшін (CBR, liability) - guardrails бар классикалық A/B таңдаңыз.

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. AR үшін CUPED (мысал)

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. Талдау: GEO/BIN/әдісі/арнасы бойынша CUPED/стратификация, сезімталдық, гетерогенділік.
8. Шешім: roll-out, roll-back, немесе follow-up тест; ережелерді/роутингті жаңарту.
9. Құжаттама және ретроспектива: сабақтар, шектерді/таразыларды жаңарту.

9) Қарсы үлгілер мен тұзақтар

Peeking/хаттамасыз қайта қарау → жалған жеңістер.
Роутинг тесттерінде Order-level рандомизациясы → қол арасында жылыстау.
Көптікпен ойнау (көп метрика/кесінді) α түзетусіз.
Толық емес құны (ұмытылған FX/резерв/refund fees) → дұрыс емес take-rate.
SRM-чектің жоқтығы → ығыстырылған қорытындылар.
Демпотенттік емес ретрациялар → R қосарланған авторизациялары/бұрмалаулары.

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 төмендетесіз және «жалған жеңістер» үшін шарджбектер мен реттеуші тәуекелдердің өсуімен төлемейсіз.