Pruebas de escenarios de pago A/B

1) Por qué probar los escenarios de pago

Aumentar las aprobaciones (AR) y reducir las fallas (DR).
Reducir el costo: take-rate (interchange/scheme/markup/fixed) y cost-per-approval.
Reducir el riesgo: menos charjbacks/frod con las mismas aprobaciones.
Sostenibilidad: seleccione un proveedor/estrategia/routing 3DS bajo métodos GEO/BIN específicos.

2) Diseño del experimento

2. 1. Unidad de aleatorización

User-level (recomendado): todos los intentos de un usuario caen en la misma rama → no hay «agitación» de 3DS/tokens.
BIN-level: cuando la prueba es sobre el routing por emisor; riesgo de mezcla entre usuarios.
Order/Attempt-level: permitido para experimentos de UI pequeños (por ejemplo, copia de un error), no deseado para routing/3DS.

2. 2. Estratificación (antes de la aleatorización)

Estratificar por: GEO del jugador, issuer country/BIN6, método de pago, canal (web/app), suma-segmento, riesgo-score. Esto reducirá la varianza y el riesgo de SRM.

2. 3. Lo que estamos probando

Enrutamiento/cascada: PSP_A vs PSP_B, sticky BIN, limite-aware.
3DS-política: frictionless→challenge, 3DS forzado para BIN/geo.
flow UX: secuencia de pasos, texto de error/repetición.
Opciones de retrés: ventanas y códigos soft-decline.
Precios: proveedor con IC++ vs blended y el impacto en el costo de todo-in.

3) Métricas: objetivo, secundario, guardrails

3. 1. Básicos

AR (Approval Rate) = approved/attempted.
Cost-per-Approval = (auth+decline fees)/approved.
Take-rate% (all-in) = fees/volume (en la moneda del informe).
3DS pass-rate; liability shift %.
Latency p95/p99 flow de pago.

3. 2. Métricas de riesgo

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

3. 3. Guardrails (condiciones de parada)

Caiga AR> Y bps o crezca CBR/Refundos por encima del umbral.
SRM (Sample Ratio Mismatch): desequilibrio de tráfico frente a lo esperado.
Spikes: latencia, surge soft-decline, 3DS anomaly.

4) Estadísticas y potencia

4. 1. Tamaño de la muestra (aproximación a los lóbulos)

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

donde 'p' es el AR básico, 'δ' es el uplift esperado en AR, α es el nivel de significación, β es un error del género II.

4. 2. Análisis secuencial (paradas tempranas)

Alpha-spending (O'Brien-Fleming/Pocock): fijamos el horario de verificación y gastamos α por etapas.
SPRT/Bayes - para soluciones operativas, pero fije el protocolo.

4. 3. Varians-redakshn

CUPED: 'Y = Y − θ (X − μ_X)', donde X es covariable preexperimental (AR/DR/riesgo-score), θ es un coeficiente covariante.
Evaluaciones estratificadas, errores de clúster robustos (clústeres user/BIN).
Bootstrap para take-rate/métricas de valor (colas pesadas).

4. 4. Pruebas multivariantes y bandits

MAB (UCB/Thompson): cuando es importante «aprender» sobre la marcha y no perder el giro.
Para métricas críticas de cumplimiento (CBR, liability) - prefiera la clásica A/B con guardrails.

5) Arquitectura de la plataforma de experimentación

1. Servicio de asistencia: hash determinista '(user_id, experiment_id, salt)' → bucket.
2. Banderas de características/Rules-engine: activar la ruta/3DS/retrés a través de la rama.
3. Eventos: intentos/resultados (authorize/capture/refund/cb) → bus (Kafka/PubSub).
4. Idempotencia: total 'idempotency _ key' por cascada.
5. DWH/Vitrinas: estados normalizados, fees, FX, banderas de riesgo.
6. Monitoreo: en línea-SLI (AR/3DS/latency), alertas, cheque SRM.
7. Protocolos: hipótesis pre-registro, criterios finales, friso de datos.

6) Modelo de datos (mínimo)

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

7. 1. Cheque SRM (porcentaje de tráfico de mano)

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étricas básicas de mano

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 para AR (ejemplo)

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. Validación de guardrails (ejemplo)

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) Proceso de realización de la prueba (end-to-end)

1. Pre-registro: hipótesis, métricas, diseño, dimensiones, reglas de parada.
2. Prueba SRM/AA en efecto «vacío» (un par de días).
3. Lanzamiento: assignment freeze, lógica en rules-engine/fichflags.
4. Monitoreo en línea: AR/3DS/latency/health + guardrails.
5. Comprobaciones intermedias de alpha-spending (si se han planeado).
6. Acabado y friso de datos: sólo después de contabilizar funding/reservas/CB/refundidos tardíos.
7. Análisis: CUPED/estratificación, sensibilidad, heterogeneidad por GEO/BIN/método/canal.
8. Solución: roll-out, roll-back, o prueba de seguimiento; actualización de reglas/routing.
9. Documentación y retrospectiva: lecciones, actualización de umbrales/escalas.

9) Anti-patrones y trampas

Peeking/pluma sin protocolo → falsas victorias.
Orden-nivel aleatorio en pruebas de routing → fugas entre las manos.
Juego con multiplicidad (muchas métricas/cortes) sin corrección de α.
El costo incompleto (olvidado FX/reserva/refund fees) → una tarifa de toma incorrecta.
La ausencia de un cheque SRM → conclusiones sesgadas.
Retraídas no idempotentes → doble autorización/distorsión de AR.

10) Seguridad, cumplimiento y ética

Same-method/return-to-source no debe romperse con la prueba.
Sanciones/licencias/políticas de GEO - fuera de los experimentos.
RG/juego responsable: no deteriorar los mecanismos de defensa por el bien de AR.
PCI/GDPR: tokens en lugar de PAN, minimización de datos personales, DPA/SOC2.

11) KPI dashboard experimento

AR/DR, uplift e intervalos de confianza por mano y estratificación clave (GEO/BIN/método).
Cost-per-Approval, take-rate %, FX slippage (bps).
3DS pass/liability shift, soft-decline share.
Latency p95/p99, errores/temporizadores.
CB/Refundidos (lag-aware), SRM, cobertura de tráfico, duración.

12) Mejores prácticas (corto)

1. Aleatorice a nivel de usuario y estratifique.
2. Utilice guardrails y un cheque SRM; fije el protocolo.
3. Considere el costo total (fees + FX + reserve) y el costo-per-approval.
4. Aplique CUPED, clúster de errores robustos y bootstrap para las métricas de valor.
5. Para los riesgos críticos - clásico A/B; bandits - para tareas predominantemente de precio/AR.
6. Tenga en cuenta funding/reservas/CB posteriores antes de la salida final.
7. Documente y versione las reglas; hacer post-mortem.

13) Lista de comprobación de inicio

• Hipótesis, métricas, efecto, diseño, tamaño de muestra, plazo.
• Unidad de aleatorización y estratificación, servicio de assignment, fichflagi.
• Guardrails/umbrales, SRM/AA-precheck, alertas.
• Registros/eventos, idempotencia, normalización de los estados.
• Vitrinas fees/FX/reserve; moneda de referencia.
• Plan de paradas (alpha-spending) y friso de datos.
• Playbucks roll-out/roll-back; Documentación de resultados.

Resumen

Las pruebas A/B de escenarios de pago son una disciplina de ingeniería y estadística: aleatorización y estratificación correctas, métricas completas de costo y riesgo, guardrails y SRM, analítica ordenada (CUPED/cluster-robastin/análisis secuencial) e infraestructura «combativa» (idempotencia, telemetría, reconciliation). Siguiendo esta técnica, se aumenta la RA, se reduce todo el tiempo y, al mismo tiempo, no se paga por «falsas victorias» por el aumento de los chargbacks y los riesgos regulatorios.