Testy scenariuszy płatności A/B

1) Dlaczego scenariusze płatności testowych

Zwiększenie zatwierdzania (AR) i zmniejszenie niepowodzeń (DR).
Obniżenie kosztów: take-rate (interchange/scheme/markup/fixed) i cost-per-approval.
Zmniejszenie ryzyka: mniej obciążeń zwrotnych/oszustw za pomocą tych samych zatwierdzeń.
Zrównoważony rozwój: wybrać strategię provider/3DS/trasę dla określonych metod GEO/BIN/.

2) Projekt eksperymentu

2. 1. Jednostka randomizacyjna

Poziom użytkownika (zalecany): wszystkie próby jednego użytkownika wpadają do jednej gałęzi → nie ma „mieszania” 3DS/tokens.
Poziom BIN: jeżeli test dotyczy trasy przez emitenta; ryzyko pomylenia między użytkownikami.
Kolejność/próba-poziom: dopuszczalne dla małych eksperymentów UI (na przykład kopia błędu), niepożądane dla routing/3DS.

2. 2. Stratyfikacja (przed randomizacją)

Stratyfikuje: gracz GEO, country/BIN6 emitenta, metoda płatności, kanał (web/app), segment kwoty, stopa ryzyka. Zmniejszy to wariancję i ryzyko SRM.

2. 3. Co testujemy

Routing/cascade: PSP_A vs PSP_B, sticky BIN, limit-aware.
Polityka 3DS: frictionless → challenge, enforced 3DS for BIN/GEO.
Przepływ UX: sekwencja kroków, teksty błędów/powtórzeń.
Parametry: okna i kody miękkiego spadku.
Ceny: Dostawca z IC++ vs mieszane i wpływ na koszty all-in.

3) Wskaźniki: ukierunkowane, wtórne, barierki

3. 1. Główny

AR (wskaźnik zatwierdzenia) = zatwierdzony/usiłowany.
Cost-per-Approval = (auth + opłaty spadkowe )/zatwierdzone.
Take-rate% (all-in) = opłaty/wolumen (w walucie sprawozdawczej).
przepustowość 3DS; przesunięcie odpowiedzialności%.
Opóźnienie p95/p99 przepływ płatności.

3. 2. Wskaźniki ryzyka

Współczynnik obciążenia zwrotnego (CBR), stawka zwrotu, powiadomienia o oszustwach/1000 trx.
Poślizg FX (bps) = skuteczny vs reference FX.

3. 3. Poręcze (warunki zatrzymania)

Spadek AR> Y bps lub wzrost CBR/Refundacje powyżej progu.
SRM (niedopasowanie wskaźnika próbek) - nierównowaga ruchu w porównaniu z oczekiwanymi.
Kolce: opóźnienie, miękki spadek przepięcia, anomalia 3DS.

4) Statystyki i moc

4. 1. Wielkość próbki (przybliżenie dla frakcji)

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

gdzie 'p' jest podstawą AR, '' jest oczekiwanym podniesieniem w AR, α jest poziomem znaczenia, β jest błędem typu II.

4. 2. Analiza sekwencyjna (wczesne przystanki)

Wydatki alfa (O'Brien-Fleming/Pocock): ustalamy harmonogram inspekcji i wydajemy α etapami.
SPRT/Bayes - dla rozwiązań operacyjnych, ale naprawić protokół.

4. 3. Varys Editorial

CAPPED: "Y = Y −" (X − μ_X) ", gdzie X jest wstępnie eksperymentalnym kowalancją (wskaźnik ryzyka AR/DR/),

Wyniki stratyfikowane, błędy solidne klastra (klastry użytkownika/BIN).
Bootstrap do mierników szybkości/kosztów (ciężkie ogony).

4. 4. Wielowarstwowe testy i bandyci

MAB (UCB/Thompson): Kiedy ważne jest, aby „nauczyć się” na muchę i nadal obracać.
Dla mierników krytycznych zgodności (CBR, odpowiedzialność) - preferuje klasyczne A/B z barierkami.

5) Architektura platformy eksperymentalnej

1. Usługa przypisania: deterministyczne hash '(user_id, experiment_id, sól)' → wiadro.
2. Feature-flags/Rules-engine: aktywacja route/3DS/retract wzdłuż gałęzi.
3. Wydarzenia: próby/wyniki (autoryzacja/przechwytywanie/zwrot/cb) → autobus (Kafka/PubSub).
4. Idempotency: total 'idempotence _ key' per cascade.
5. DWH/Showcases: znormalizowane statusy, opłaty, FX, flagi ryzyka.
6. Monitorowanie: online-SLI (AR/3DS/latency), wpisy, sprawdzanie SRM.
7. Protokoły: hipoteza przed rejestracją, kryteria końcowe, fryz danych.

6) Model danych (minimum)

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) szablony SQL

7. 1. Kontrola SRM (udział ruchu ręcznie)

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. Kluczowe mierniki ręcznie

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. OGRANICZONY dla AR (przykład)

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. Sprawdzanie barier ochronnych (przykład)

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) Proces badania (od końca do końca)

1. Wstępna rejestracja: hipoteza, metryka, konstrukcja, wymiary, zasady stop.
2. Test SRM/AA na „pusty” efekt (kilka dni).
3. Start: przydział zamrażania, logika w rules-engine/phicheflags.
4. Monitoring Online: AR/3DS/latency/health + barierki.
5. Pośrednie kontrole wydatków alfa (jeżeli są planowane).
6. Zakończenie i data zamrożenia: tylko po rozliczaniu środków/rezerw/spóźnionych BC/zwrotów.
7. Analityka: CUPED/stratyfikacja, wrażliwość, GEO/BIN/metoda/heterogeniczność kanału.
8. Rozwiązanie: test roll-out, roll-back lub następczy; aktualizacja zasad/routingu.
9. Dokumentacja i retrospektywne: lekcje, aktualizacje progów/wag.

9) Anty-wzory i pułapki

Podglądanie/ponowna recenzja bez protokołu → fałszywe zwycięstwa.
Randomizacja na poziomie zamówienia w testach routingu → wyciek między rękami.
Gra wielopoziomowa (wiele metryk/plasterków) bez korekty α.
Niekompletny koszt (zapomniane opłaty FX/rezerwy/zwrotu) → nieprawidłowy wskaźnik odbioru.
Brakujące SRM sprawdzić → błędne piny.
Retreaty nieidempotentne → podwójne zezwolenia/zniekształcenia AR.

10) Bezpieczeństwo, zgodność i etyka

Badanie nie powinno łamać tej samej metody/powrotu do źródła.
Sankcje/licencje/polityka GEO wykraczają poza eksperymenty.
RG/odpowiedzialna gra: nie degradować mechanizmów obronnych dla dobra AR.
PCI/RODO: żetony zamiast PAN, minimalizacja danych osobowych, DPA/SOC2.

11) Deska rozdzielcza eksperymentu KPI

AR/DR, podniesienie i przedziały ufności przez ramiona i stratyfikację klucza (metoda GEO/BIN/).
Cost-per-Approval, take-rate%, FX slippage (bps).
3DS pass/liability shift, soft-decrease share.
Latency p95/p99, błędy/timeouts.
BC/Zwroty (z opóźnieniem), SRM, zasięg ruchu, czas trwania.

12) Najlepsze praktyki (krótkie)

1. Randomizować na poziomie użytkownika i stratyfikować.
2. Użyj barier ochronnych i kontroli SRM; naprawić protokół.
3. Weź pod uwagę pełny koszt (opłaty + FX + rezerwy) i koszt za zatwierdzenie.
4. Użyj CAPPED, klastra-solidne błędy, i bootstrap do mierników kosztów.
5. w przypadku ryzyka krytycznego - klasyczne A/B; bandyci - głównie za zadania cenowe/AR.
6. Rozważyć finansowanie/rezerwy/opóźnienia BC przed ostatecznym wycofaniem.
7. Dokument i wersja reguł; zrób pośmiertnie.

13) Lista kontrolna rozruchu

• Hipoteza, metryki, efekt, projekt, wielkość próbki, termin.
• Randomizacja jednostek i warstwy, usługa cesji, phicheflags.
• Poręcze/progi, SRM/AA-precheck, wpisy.
• Dzienniki/wydarzenia, idempotencja, normalizacja statusu.
• Wyświetlanie opłat za sprawy/FX/rezerwa; waluta sprawozdawcza.
• Plan wydatków alfa i zamrożenie danych.
• Playbooks roll-out/roll-back; dokumentacja wyników.

Podsumowanie

A/B testy scenariuszy płatniczych są inżynieryjną dyscypliną statystyczną: prawidłowa randomizacja i stratyfikacja, pełne mierniki kosztów i ryzyka, poręcze i SRM, schludna analiza (CUPED/cluster-solidność/sekwencyjna analiza) oraz infrastruktura gotowa do walki (idempotencja, telemetria, pojednanie). Stosując tę technikę, można zwiększyć AR, zmniejszyć all-in-take, a jednocześnie nie płacić za „fałszywe zwycięstwa” ze wzrostem obciążeń zwrotnych i ryzyka regulacyjnego.