Time-to-Wallet : une métrique clé

1) Définition et options TTW

• TTW₍deposit ₎ : 'click' Payer '→ l'argent est disponible pour jouer'.
• Comprend la UX/3DS, l'autorisation auprès de PSP/banque, la confirmation et l'enregistrement du bilan.

TTW₍payout ₎ : « click » Retirer « → de l'argent sur un portefeuille/une banque externe ».
Comprend les contrôles risk/KYC/SoF, same-method/ND-gates, l'orchestration de couloir, la confirmation avec PSP/schémas et l'affichage avec la banque/portefeuille.

2) Pourquoi le TTW est une métrique P&L

Conversion et AR : dépôt rapide ↑ probabilité du premier pari/session.
Rétention et confiance : conclusions rapides ↓ churn et tiquets de Sapport.
Coût : instant-rails est souvent plus cher ⇒ besoin d'un équilibre « vitesse ↔ prix ».
Risque opérationnel : les longues « queues » du TTW créent des grappes d'incidents et des tensions de charge.

3) Décomposition TTW par étapes

3. 1. Dépôts

1. UI/Checkout (rendu, validation, 3DS)

2. PSP Auth (authorize)

3. Capture/Booking (confirmation, mise à jour du solde)

4. Fallback/Retry (при soft-decline)

`TTW₍deposit₎ = t_UI + t_3DS + t_auth + t_capture + t_write_balance`

3. 2. Conclusions

1. Pre-checks (KYC/SoF, ND/same-method, limites RG/AML)

2. Risk decision (auto/manuel)

3. Payout orchestration (choix du couloir : SEPA Instant/PIX/Faster Payments/RTP/push-to-card/A2A/e-wallet)

4. PSP API (initiate → accepted)

5. Network/Banks (clearing/posting)

6. Reconcile & Notify (confirmation à l'utilisateur)

`TTW₍payout₎ = t_precheck + t_risk + t_initiation + t_network + t_posting + t_notify`

4) SLA et niveaux cibles

Dépôt p95 : ≤ 10-20 secondes (portefeuille/one-tap), ≤ 30-60 secondes (cartes avec 3DS).

• Instant rails (SEPA Instant/PIX/FPS/RTP, push-to-wallet/card): ≤ 15–30 мин.
• Standard A2A/SEPA Credit : Т+0/Т+1 banking (les heures/jours).
• SWIFT international : 1-3 jours bancaires.
• p99 est important de rester dans les communications (bandes ETA) pour gérer les attentes.

5) Mesure : unités, fenêtres, sampling

Unité de mesure : transaction (deposit/payout).
Aggrégation : p50/p90/p95/p99, SLA-hit % (proportion dans l'ETA), résidus (tail> 2 × p95).
Tranches : méthode/corridor/PSP/MID/GEO/clusters BIN/heure/canal.
Excepté : annulée/duplicata (idempotence), pauses manuelles sur demande du joueur.

6) Modèle de données (minimum)

sql payments. timeline (
tx_id PK, kind -- DEPOSIT    PAYOUT,
user_id, method, corridor, provider, mid, iso2, currency, amount_minor BIGINT,
t_ui_start TIMESTAMP, t_3ds_start TIMESTAMP, t_3ds_end TIMESTAMP,
t_auth_req TIMESTAMP, t_auth_ok TIMESTAMP,
t_capture_ok TIMESTAMP,     -- депозиты t_precheck_start TIMESTAMP, t_precheck_ok TIMESTAMP, -- выводы t_risk_start TIMESTAMP, t_risk_ok TIMESTAMP,
t_payout_initiated TIMESTAMP, t_network_posted TIMESTAMP,
t_wallet_available TIMESTAMP, -- final availability status TEXT, decline_code TEXT, meta JSONB
);

sla. catalog (
kind, method, corridor, geo, p95_target_seconds INT, p99_target_seconds INT, eta_text TEXT
);

7) modèles de calcul SQL

7. 1. TTW sur les dépôts (général et méthodes)

sql
SELECT method,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start))) AS p95_ttw_sec,
PERCENTILE_CONT(0. 99) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start))) AS p99_ttw_sec,
COUNT() AS attempts,
100. 0 AVG((EXTRACT(EPOCH FROM (t_wallet_available - t_ui_start)) <= s. p95_target_seconds)::int) AS sla_hit_p95_pct
FROM payments. timeline t
JOIN sla. catalog s ON s. kind='DEPOSIT' AND s. method=t. method
WHERE t. kind='DEPOSIT'
AND t. status='SUCCESS'
AND t. t_ui_start BETWEEN:from AND:to
GROUP BY 1;

7. 2. TTW sur les conclusions (corridors)

sql
SELECT corridor,
PERCENTILE_CONT(0. 50) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p50_sec,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p95_sec,
PERCENTILE_CONT(0. 99) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start))) AS p99_sec,
100. 0 AVG((EXTRACT(EPOCH FROM (t_wallet_available - t_precheck_start)) <= s. p95_target_seconds)::int) AS sla_hit_p95_pct,
COUNT() AS payouts
FROM payments. timeline t
JOIN sla. catalog s ON s. kind='PAYOUT' AND s. corridor=t. corridor
WHERE t. kind='PAYOUT' AND t. status='SUCCESS'
AND t. t_precheck_start BETWEEN:from AND:to
GROUP BY 1;

7. 3. Décomposition des « goulets d'étranglement » (conclusions)

sql
SELECT corridor,
AVG(EXTRACT(EPOCH FROM (t_precheck_ok - t_precheck_start))) AS precheck_sec,
AVG(EXTRACT(EPOCH FROM (t_risk_ok - t_risk_start)))     AS risk_sec,
AVG(EXTRACT(EPOCH FROM (t_network_posted - t_payout_initiated))) AS network_sec,
AVG(EXTRACT(EPOCH FROM (t_wallet_available - t_network_posted))) AS posting_sec
FROM payments. timeline
WHERE kind='PAYOUT' AND status='SUCCESS'
AND t_precheck_start BETWEEN:from AND:to
GROUP BY 1
ORDER BY network_sec DESC;

7. 4. SLA-brichi et « longues queues »

sql
SELECT method, corridor,
COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_wallet_available - COALESCE(t_ui_start, t_precheck_start))) > s. p95_target_seconds) AS breaches,
COUNT() AS total,
100. 0 COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_wallet_available - COALESCE(t_ui_start, t_precheck_start))) > s. p95_target_seconds)
/ NULLIF(COUNT(),0) AS breach_pct
FROM payments. timeline t
JOIN sla. catalog s ON s. kind=t. kind AND COALESCE(s. method, t. method)=t. method AND COALESCE(s. corridor, t. corridor)=t. corridor
WHERE t. status='SUCCESS' AND (t. t_ui_start BETWEEN:from AND:to OR t. t_precheck_start BETWEEN:from AND:to)
GROUP BY 1,2
ORDER BY breach_pct DESC;

8) Dashboards et KPI

TTW p50/p95/p99 sur les méthodes/corridors/PSP/GEO/BIN.
SLA-hit %, tail share (> 2 × p95), incidents (annotations).
Vortex de conclusions : Requested → Pre-check OK → Risk OK → Initiated → Posted → Available.
Corrélations : TTW vs AR/conversion de dépôt, TTW vs tickets sappport/CSAT, TTW vs churn.
Coût : 'cost _ per _ payout' et 'take-rate' le long du couloir vs gagnant par TTW.

9) Alert

p95 breach : p95 TTW le long du corridor/PSP> SLA X minutes.
Tail spike : la part> 2 × p95 a augmenté> Y % pour Z.
Pre-check stall : t_precheck_start est, t_precheck_ok non> 15 min (auto-escalade).
Risk backlog : t_risk_start existe, t_risk_ok pas> seuil (file d'attente manuelle).
Network/posting anomaly : croissance spectaculaire de 'network _ sec' par GEO/banque.
Policy drift : événements sans horodatages nécessaires.

10) Comment accélérer les TTW (pratiques)

Dépôts

Portefeuille one-tap/Apple Pay/Google Pay, tokens réseau.
Frictionless 3DS par risque, incorporer 3DS dans la mode.
Cascade PSP par BIN/GEO/santé, retraits uniquement sur soft-decline.
Prefetch 3DS/ACS les canaux, les délais de dégradation agressifs.

Conclusions

Pre-KYC/pre-SoF pour les joueurs fréquents ; pre-approval sur les montants du seuil ≤.
Couloirs d'instance : SEPA Instant/Faster Payments/RTP/PIX/push-to-card/wallet.
Cascade de couloirs : instant → fast A2A → standard SEPA/SWIFT (avec ETA).
La logique same-method & ND est automatisée, sans contrôles manuels.
Fenêtres horaires : éviter les heures coupées et les heures « étroites » bancaires.
Provider health-feed et auto-failover avec la croissance de 'network _ sec'.

Communications

ETA au départ + état de progression (« Vérification », « Initié », « Crédité »).
Alertes proactives en cas de retard> SLA, raisons honnêtes et temps attendu.

11) Économie et compromis

Instant est plus cher : comparer uplift CSAT/churn/retentation vs bps/fixed.
Les queues sont plus chères que p50 : les optimisations sur p95 donnent plus d'effet P & L.
Différences locales : dans certains GEO, le canal « rapide mais cher » est mieux payé.

12) Incident de playbooks

1. Croissance p95 par PSP/corridor spécifique

Auto-reroute sur le couloir de secours, réduction de la limite de dégradation.
Communication aux joueurs avec ETA mis à jour, ticket au fournisseur.

2. Risk backlog (contrôles manuels)

Activer le pré-approval sur les montants de ≤ X, redistribuer la file d'attente, augmenter temporairement les seuils auto-pass.

3. Banque postale de retard par GEO

Contournement avec une autre banque correspondante/portefeuille, désactiver temporairement le couloir « lent » pour de nouvelles demandes.

4. Dégradation 3DS/ACS (dépôts)

Forcer frictionless/alternate DS là où la politique de risque le permet, ou une cascade sur un autre PSP.

13) Tests A/B autour de TTW

Instant vs Standard corridor sur une partie du trafic (guardrails : CBR bps, cost/payout, CSAT).
Pre-KYC copyright/flow, formulation ETA, ordre des méthodes.
Métriques : TTW p95, SLA-hit%, tiquets/1000 trx, AR/conversion, churn 7/30.

14) Meilleures pratiques (en bref)

1. Mesurez par étapes et gardez les horodateurs dans un schéma unique.
2. Optimisez p95/p99, pas seulement la médiane.
3. Incorporez des rails instantanés là où l'économie converge.
4. Faites pré-KYC/SoF/approval pour des scripts répétitifs.
5. Auto-cascade couloirs et PSP, répondre à la santé.
6. Parlez honnête ETA et les statuts, alertez les retards.
7. Stockez SLA dans le catalogue et vérifiez SLA-hit % pour chaque tranche.
8. Attachez le TTW au CSAT/tickets/churn dans les dashboards.
9. Post-incidents : enregistrez les causes, changez les règles/les temporisateurs de seuil.
10. Versez le schéma des événements, validez l'exhaustivité des horodatages.

15) Chèque de mise en œuvre

• Définitions de TTW pour les dépôts/retraits convenues avec le produit/le financement.
• Timing par étape dans 'payments. timeline`; annuaire SLA.
• Dashboards p50/p95/p99, SLA-hit %, queues ; alerte p95/tails/backlogs.
• Cascades PSP/corridors, santé-feed et auto-failover.
• Politiques pre-KYC/SoF et pre-approval ; ND/same-method sont automatisés.
• Communication ETA et suivi de statut pour l'utilisateur.
• Modèle économique « vitesse ↔ prix » le long des couloirs.
• Pleybooks d'incidents et processus post-mortem.
• Tests A/B des améliorations de TTW avec guardrails.
• Vérification régulière de l'exhaustivité des données et de l'exactitude des calculs.

Résumé

Time-to-Wallet n'est pas seulement une « vitesse de sortie ». C'est une métrique de l'expérience de paiement de bout en bout qui affecte la conversion, la rétention et P & L. Mesurez le TTW par étapes, optimisez le p95/p99, connectez les rails instantanés et les cascades, éliminez les frottements via le pré-KYC/approval et automatisez les vérifications ND/same-method. Une télémétrie forte, des ETA honnêtes et des playbooks prêts à l'emploi rendront les paiements rapides, prévisibles et économiquement justifiés.