A/B Tests de scénarios de paiement

1) Pourquoi tester les scénarios de paiement

Augmenter les approbations (RA) et réduire les échecs (RD).
Réduisez le coût : take-rate (interchange/scheme/markup/fixed) et cost-per-approval.
Réduire le risque : moins de charjbacks/frods avec les mêmes approbations.
Durabilité : choisir un fournisseur/stratégie 3DS/itinérance selon des méthodes/GEO/BIN spécifiques.

2) Conception de l'expérience

2. 1. Unit randomisation

User-level Il (est recommandé) : toutes les tentatives d'un utilisateur se trouvent dans une branche → il n'y a pas de "malaxage" des 3DS/jetons.
Niveau BIN : lorsque le test porte sur le routage par émetteur ; risque de mélange croisé.
Order/Attempt-level : valide pour les petites expériences d'IU (comme une copie d'erreur), non souhaitable pour le routage/3DS.

2. 2. Stratification (avant randomisation)

Stratifier par : GEO du joueur, issuer country/BIN6, mode de paiement, canal (web/app), somme-segment, risque-score. Cela réduira la variance et le risque de MRS.

2. 3. Ce que nous testons

Rowting/cascade : PSP_A vs PSP_B, sticky BIN, limite-aware.
Politique 3DS : frictionless→challenge, forcer 3DS pour BIN/geo.
UX flow : séquence d'étapes, textes d'erreurs/répétitions.
Options de rétraction : fenêtres et codes soft-decline.
Tarification : fournisseur avec IC++ vs blended et impact sur le coût all-in.

3) Métriques : cibles, secondaires, guardrails

3. 1. Les principaux

AR (Approval Rate) = approved/attempted.
Cost-per-Approval = (auth+decline fees)/approved.
Take-rate % (all-in) = fees/volume (dans la monnaie de déclaration).
3DS pass-rate; liability shift %.
Flow de paiement latin p95/p99.

3. 2. Risques-métriques

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

3. 3. Guardrails (conditions d'arrêt)

Chute AR> Y bps ou croissance CBR/Refunds au-dessus du seuil.
SRM (Sample Ratio Mismatch) - déséquilibre du trafic par rapport au trafic attendu.
Spikes : latence, surge soft-decline, anomaly 3DS.

4) Statistiques et puissance

4. 1. Taille de l'échantillon (approximation pour les parts)

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

où 'p' est l'AR de base, 'δ' est l'uplift attendu dans l'AR, α est le niveau de signification, β est une erreur de type II.

4. 2. Analyse séquentielle (arrêts précoces)

Alpha-spending (O'Brien-Fleming/Pocock) : on fixe le calendrier des contrôles et on dépense les α par étapes.
SPRT/Bayes - pour des solutions opérationnelles, mais fixez le protocole.

4. 3. Varians-redakchn

CUPED : « Y = Y − θ (X − μ_X) », où X est un covariat préexpérimental (AR/DR/risque), θ est un coefficient covariant.
Estimations stratifiées, erreurs de cluster-robast (clusters user/BIN).
Bootstrap pour take-rate/métriques de valeur (queues lourdes).

4. 4. Tests multivariants et bandits

MAB (UCB/Thompson) : quand il est important d'apprendre à la volée et de ne pas perdre son chiffre d'affaires.
Pour les mesures de conformité critiques (CBR, liability) - préférez le classique A/B avec guardrails.

5) Architecture de plateforme d'expérimentation

1. Assignment-service : hash déterministe '(user_id, experiment_id, salt)' → bucket.
2. Feature Flags/Rules-engine : Activation de l'itinéraire/3DS/rétro sur la branche.
3. Événements : essais/résultats (autorité/capture/refund/cb) → bus (Kafka/PubSub).
4. Idempotence : général 'idempotency _ key' par cascade.
5. DWH/Vitrines : statuts normalisés, fees, FX, drapeaux à risque.
6. Surveillance : online-SLI (AR/3DS/latency), alertes, chèque SRM.
7. Protocoles : hypothèse pré-enregistrement, critères finaux, date-frise.

6) Modèle de données (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) modèles SQL

7. 1. Chèque SRM (part du trafic par main)

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. Métriques de base par main

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 pour AR (exemple)

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. Vérification des guardrails (exemple)

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) Le processus de test (en fin de compte)

1. Pré-enregistrement : hypothèse, métriques, conception, dimensions, règles d'arrêt.
2. Test SRM/AA sur effet « vide » (quelques jours).
3. Lancement : assignment freeze, logique dans rules-engine/ficheflags.
4. Surveillance en ligne : AR/3DS/latency/health + guardrails.
5. Vérifications intermédiaires par alpha-spending (si prévu).
6. Finition et date-frise : seulement après prise en compte du funding/des réserves/des CB/fonds tardifs.
7. Analyse : CUPED/stratification, sensibilité, hétérogénéité par GEO/BIN/méthode/canal.
8. Solution : roll-out, roll-back, ou follow-up test ; mise à jour des règles/itinérance.
9. Documentation et rétrospective : leçons, mise à jour des seuils/échelles.

9) Anti-modèles et pièges

Peeking/peer-survey sans protocole → de fausses victoires.
Randomisation de niveau d'ordre dans les tests de routage → les fuites entre les mains.
Jeu avec multiplicité (beaucoup de métriques/tranches) sans correction de α.
Coût incomplet (oublié FX/reserve/refund fees) → taux de take incorrect.
L'absence de chèque SRM → des conclusions décalées.
Retraits non impotentes → double autorisation/distorsion AR.

10) Sécurité, conformité et éthique

Same-method/return-to-source ne doit pas être cassé par le test.
Sanctions/licences/GEO-politiques - en dehors des expériences.
RG/jeu responsable : ne pas dégrader les mécanismes de défense pour l'AR.
PCI/GDPR : jetons au lieu de PAN, minimisation des données personnelles, DPA/SOC2.

11) KPI dashboard de l'expérience

AR/DR, uplift et intervalles de confiance selon les mains et les stratifications clés (GEO/BIN/méthode).
Cost-per-Approval, take-rate %, FX slippage (bps).
3DS pass/liability shift, soft-decline share.
Latency p95/p99, erreurs/temporisations.
CB/Refunds (lag-aware), SRM, couverture du trafic, durée.

12) Meilleures pratiques (en bref)

1. Randomiser au niveau de l'utilisateur et stratifier.
2. Utilisez les guardrails et le chèque SRM ; enregistrez le protocole.
3. Comptez le coût total (fees + FX + reserve) et cost-per-approval.
4. Appliquez CUPED, bugs de cluster-robast et bootstrap aux métriques de valeur.
5. Pour les risques critiques - classique A/B ; bandits - pour les tâches principalement de prix/AR.
6. Tenez compte du funding/des réserves/des CB tardifs avant la conclusion finale.
7. Documenter et convertir les règles ; faites post-mortem.

13) Chèque de démarrage

• Hypothèse, métriques, effet, conception, taille de l'échantillon, durée.
• Unit randomisation et stratas, assignment-service, ficheflagi.
• Guardrails/seuils, SRM/AA-precheck, alertes.
• Logi/événements, idempotence, normalisation des statuts.
• Vitrines fees/FX/reserve ; monnaie de déclaration.
• Plan d'arrêt (alpha-spending) et date-frise.
• Pleybooks roll-out/roll-back ; documentation des résultats.

Résumé

Les tests de scénarios de paiement A/B sont une discipline d'ingénierie et de statistique : randomisation et stratification appropriées, métriques complètes de coût et de risque, guardrails et MRS, analyse soignée (CUPED/cluster-robastation/analyse séquentielle) et infrastructure « capable de combattre » (idempotentialité, télémétrie, reconnaissance). En suivant cette méthode, vous augmentez l'AR, réduisez le taux de take-rate tout en ne payant pas pour les « fausses victoires » par la croissance des chargebacks et des risques réglementaires.