Anatomía de los datos de test de Stripe
Stripe provee test card numbers específicos que simulan comportamientos reales sin tocar dinero. '4242424242424242' es el comodín de éxito: siempre funciona, útil para smoke tests. '4000000000009995' simula declinación genérica. La diferencia está en el dígito de control: Stripe lo valida con algoritmo Luhn, así que números random fallan.
Los tokens como 'tok_visa' son shortcuts para testing rápido en el dashboard de Stripe, pero en código real deberías usar Stripe.js para tokenizar. Los Payment Methods ('pm_card_visa') son la API moderna; los tokens son legacy pero todavía válidos para backward compatibility.
Los IDs de recursos (cus_, ch_, pi_) siguen patrones: prefijo + underscore + string alfanumérico. En test mode, cualquier string después del prefijo es válido ('cus_123', 'cus_fake') siempre que el prefijo coincida con el resource type. En producción, Stripe genera IDs reales de 24-28 caracteres.
Estrategia de testing: más allá del happy path
El error más común: solo testear '4242424242424242' y asumir que todo funciona. Tu código debe manejar al menos 5 escenarios: éxito, declinación genérica, requires_action (3DS), processing error, insufficient funds. Cada uno retorna estructuras diferentes en la respuesta.
Para 3D Secure (SCA), usá '4000002760003184'. Este card number trigger el flujo completo: tu frontend debe mostrar el modal de auth, el usuario 'aprueba', y recién ahí el payment succeeds. Si tu test pasa sin modal, no implementaste SCA correctamente y fallarás en producción europea.
Los webhooks son el pain point #1. En local dev, usá Stripe CLI ('stripe listen --forward-to localhost:3000/webhook') para recibir eventos reales. Testeá idempotency: Stripe puede enviar el mismo webhook múltiples veces; tu endpoint debe ser idempotent (chequear 'event.id' antes de procesar).
Casos edge que rompen integraciones
Montos en decimales: Stripe usa integers, no floats. $10.00 = 1000 (en USD). Yen no tiene decimales, ¥1000 = 1000. Si pasás '10.00' como número, Stripe lo rechaza. La conversión correcta es: Math.round(amount * 100) para monedas con 2 decimales.
Metadata limits: podés pasar hasta 50 keys de metadata, cada valor max 500 caracteres. Útil para tracking interno, pero si tratás de pasar un JSON gigante serializado, falla silenciosamente. Testeá con metadata excesivo para catchear este edge case.
Webhooks out-of-order: podés recibir 'payment_intent.succeeded' ANTES que 'payment_intent.created'. Stripe no garantiza orden. Tu lógica debe ser stateless o checkear estado actual del recurso con un GET antes de procesar. Un bug clásico: asumir que 'created' siempre llega primero y setear flags que después no se actualizan.
Setup de entorno de test robusto
Separación de keys: usá variables de entorno distintas para test/prod. Pattern común: STRIPE_SECRET_KEY en prod, STRIPE_TEST_SECRET_KEY en dev. Nunca commitees las keys a git. Usá un .env local y gestión de secrets en producción (AWS Secrets Manager, Doppler, etc).
Para CI/CD, creá un Stripe test account separado (no uses tu account personal). Esto permite que múltiples devs y pipelines corran tests sin colisiones. Cada PR puede crear recursos efímeros (customers, subscriptions) que se limpian automáticamente después.
Test data factories: en vez de hardcodear '4242424242424242' en cada test, creá helpers: createSuccessfulCard(), createDeclinedCard(), create3DSCard(). Esto centraliza los test data y facilita actualizarlos si Stripe cambia números. Ejemplo: cuando 3DS2 reemplazó 3DS1, solo tuviste que actualizar una función en vez de 50 tests.