Pruebas de carga para picos de transacciones en la pasarela de pagos

Los flujos de pago son la peor superficie para aprender lecciones de load testing. Una auth fallida es un pedido perdido, una captura duplicada es un chargeback, un backlog de webhooks se convierte en fulfillment desfasado. Esta plantilla apunta a los modos de fallo que encontramos empujando flujos de tarjeta reales bajo carga.

Nunca apunte carga a un procesador en vivo

No apunte VUs a api.stripe.com ni a ningún PSP en vivo. Le aplicarán rate-limit, podría incumplir su acuerdo con el adquirente, y puede arrastrarse a un scope de PCI-DSS al que no se apuntó. Use Stripe test mode, la API de test de Adyen, el sandbox de Braintree. Para ejercitar su capa de orquestación — token vaulting, idempotencia, reintentos, escrituras al ledger — emule el PSP detrás de WireMock o un pequeño servicio Express que devuelva latencia realista y los mismos códigos de error que emite el procesador real (card_declined, processing_error, rate_limited).

Idempotencia bajo tormentas de reintentos

La mayoría de bugs de pagos a escala no son "la API se puso lenta" — son "dos reintentos colisionaron y cobramos dos veces." Una clave de idempotencia por pedido lógico, reutilizada en todos los reintentos; verifique que su backend deduplica cuando 1.000 VUs martillean el mismo endpoint con la misma clave. Después rómpalo: misma clave, distinto monto, confirme el rechazo. Stripe devuelve HTTP 400 idempotency_error — trátelo como un timeout de red.

3DS y auth asíncrona

El p95 de auth síncrona debería quedar bajo 800 ms, captura p99 bajo 2 s, pero 3DS hace saltar eso por los aires — presupueste 5 s para el round-trip del challenge y 1-2 s para el callback del resultado. Modele 3DS como un escenario separado, no como un cubo de percentil. Aproximadamente 10-25% del volumen de tarjeta europeo toca un challenge según el issuer y las exenciones SCA; una mezcla de test con 0% challenges no es la realidad. Aparque el VU en la URL del challenge para un think-time realista, no entre directo en bucle a un nuevo auth.

Los webhooks son el segundo sistema

La respuesta de auth es la mitad de la historia. Eventos de liquidación, reembolso, disputa y 3DS-completed llegan async y el receptor tiene que mantener el ritmo. Apunte a 99,9% de webhooks procesados en 30 s, SLO duro 5 min. Reproduzca payloads firmados de Stripe o Adyen a 10×, 50×, 100× del ritmo esperado; vigile la profundidad de cola, la CPU de verificación de firma, la contención de escritura en BD. Fallo común: el handler hace un upsert síncrono más un envío de email, y a 200 eventos/seg el pool se queda sin recursos. Mueva los side effects a una cola, ack en < 200 ms.

Rate limits del PSP y circuit breakers

Stripe publica ~100 ops/seg de lectura y 100 de escritura por cuenta; Adyen y Checkout.com tienen los suyos y devolverán 429 con Retry-After mucho antes de que termine el ramp. Su cliente debe leer esa cabecera, no hacer back-off a ciegas, y su breaker debe abrir antes de que el PSP empiece a tirar tráfico. Inyecte 429s desde su stub al 5%, 20%, 50% y confirme que las transacciones encolan o fallan rápido en vez de apilar reintentos que empeoran la tormenta.

Ejecutarlo en LoadFocus

Use modo JMeter si ya tiene un .jmx con tarjetas de test desde CSV y claves de idempotencia parametrizadas, o k6 si prefiere scriptear en JS. Ambos corren desde 26+ regiones cloud con miles de VUs, gráficas en tiempo real de auth/captura/webhook y hooks de CI (GitHub Actions, GitLab, Jenkins) para que una regresión de p95 de auth falle el build. Empiece al 10% de su minuto pico de Black Friday, valide idempotencia y manejo de 429 ahí, después escale.