GlobalKeyMarket
Marketplace SaaS multi-vendor para activos digitales. Pedido, pago, conciliación y entrega automática post-pago en un solo flujo, con panel de operaciones unificado para soporte y proveedores.
Antes / Después
Qué cambió en la operativa real desde que el sistema entró en producción.
Antes
- Pedidos confirmados manualmente tras revisar pagos en panel de Stripe.
- Entrega de credenciales por correo manual, con riesgo de error humano.
- Stock por proveedor en hojas de cálculo descoordinadas.
- Sin auditoría real: si un cliente reclamaba, había que buscar evidencias entre emails.
- Soporte saturado en momentos de pico (lanzamientos, promociones).
Después
- Entrega tras pago en menos de 30 segundos, sin tocar el panel.
- Stock por proveedor en base de datos, con bloqueo optimista al asignar.
- Cada operación crítica genera evento auditable persistido (no solo log).
- Reembolsos y disputas con trazabilidad completa hasta el evento original.
- Soporte centralizado en una consola: pedido, pagos, entrega, vendor.
Arquitectura
Vista lógica del sistema. Tres capas claras: frontend, dominio y datos. Stripe es la fuente de verdad del estado de pago; los workers absorben los efectos.
Línea continua: llamada síncrona. Línea discontinua: efecto asíncrono o redirect del cliente.
Decisiones técnicas (y por qué)
Los detalles que distinguen un MVP rápido de un sistema que se sostiene en producción.
Stripe es la fuente de verdad; nuestro endpoint es idempotente
Stripe reintenta webhooks ante fallos. Si no se trata, eso significa pedidos duplicados, dobles entregas y soporte saturado. Cada evento entra con su event-id, se guarda en Redis con TTL prudente; si ya se procesó, se devuelve 200 OK sin reejecutar. Resultado: cero duplicados aun con caídas momentáneas del receptor.
Bloqueo optimista al asignar stock
En lanzamientos con stock limitado, varios clientes compiten por la misma plaza. Se usa optimistic locking en la transacción: si el contador cambió desde la lectura, la transacción rola y el cliente recibe un mensaje claro en checkout. Más justo que bloquear toda la tabla y más rápido que serializar.
Eventos auditables, no solo logs
Cada operación crítica (pedido, intento de pago, entrega, refund) genera un evento persistido con su payload firmado. Los logs sirven para depurar; los eventos sirven para responder a un cliente o a un proveedor con evidencia tres meses después. Esa diferencia es la que hace que soporte deje de ser reactivo.
Workers separados del receptor de webhooks
El receptor solo valida, persiste y responde rápido a Stripe (debajo del timeout). Los efectos largos —entregar producto, mandar correo, notificar al vendor— viven en workers asíncronos con reintentos. Si una notificación falla, el pedido sigue entregado: no se acopla disponibilidad de terceros al checkout.
Permisos por rol (cliente, vendor, ops, admin)
RBAC con políticas declarativas a nivel de API: cada endpoint declara qué rol puede consumirlo y sobre qué recursos. Vendor solo ve su catálogo y sus pedidos; ops ve todo pero no toca configuración financiera; admin la toca pero deja rastro auditable. Sin esto, multi-vendor es una bomba.
Stack completo
El detalle real, no «JavaScript y bases de datos».
Frontend
- Next.js (SSR + ISR para catálogo)
- React 18 · TypeScript
- Tailwind para tokens de diseño
- Componentes accesibles (a11y básica)
Backend
- API Node.js (TypeScript)
- Validación de input con esquemas
- RBAC declarativo por endpoint
- Endpoints idempotentes para webhooks
Datos
- PostgreSQL con migraciones versionadas
- Redis: dedupe, colas y cache breve
- Backups automáticos diarios
- Restauración probada (no solo backup)
Pagos
- Stripe Checkout + Customer Portal
- Webhooks con firma verificada
- Reconciliación por
event-id - Reembolsos auditables
Operación
- Nginx reverse proxy + TLS + CSP
- Despliegue reproducible por entornos
- Logs estructurados centralizados
- Alertas por canal del equipo
Notificaciones
- Email transaccional (verificación, entrega)
- Notificación a vendor (nuevo pedido)
- Telegram/Discord opcional para ops
- Plantillas auditables y versionadas
Resultado para el negocio
Para operaciones
- Soporte centralizado en una única consola.
- Trazabilidad de cada pedido en segundos, no en horas.
- Picos de tráfico absorbidos sin reescritura.
- Onboarding de un nuevo vendor en horas, no días.
Para el negocio
- Entrega post-pago automatizada como ventaja competitiva real.
- Reembolsos y disputas resueltos con evidencia, no con intuición.
- Base lista para añadir nuevos vendors, categorías o métodos de pago.
- Coste de operación bajo respecto al volumen procesado.
¿Necesitas algo así?
Si tu operativa pierde tiempo en pasos manuales que un sistema bien hecho podría absorber —entrega post-pago, conciliación, reporting multi-vendor, paneles internos— cuéntanos el contexto por correo. Respondemos normalmente en menos de 30 minutos con viabilidad y siguiente paso.
Otros servicios relacionados
Desarrollo web con React y Next.js · Backend Node.js y APIs · Dashboards y paneles internos · Integración de pagos (Stripe, Redsys, Bizum)