Soporte Shopify en Madrid: la historia detrás de una tienda que casi cierra por un error de checkout

No fue un problema específico de Madrid como ciudad —el fallo técnico podía haber ocurrido en cualquier tienda Shopify que usara esa combinación de pasarela de pago y configuración regional de IVA— pero sí fue un problema típico de una tienda sin nadie técnico asignado: la actualización de la pasarela llegó sin aviso visible, y nadie estaba revisando los logs de transacciones para detectarlo a tiempo.

La marca, como la mayoría de las tiendas Shopify de tamaño medio en España, operaba con un equipo pequeño centrado en producto, marketing y atención al cliente, sin nadie dedicado exclusivamente a la infraestructura técnica. Es un patrón extremadamente común: la tienda crece en ventas mucho más rápido de lo que crece en capacidad técnica interna, y ese desequilibrio es invisible hasta que algo como esto lo expone de golpe.

Para el martes, el volumen de quejas había crecido lo suficiente como para que la fundadora empezara a buscar ayuda externa, pero sin saber exactamente qué tipo de ayuda necesitaba: ¿un desarrollador?, ¿la pasarela de pago?, ¿el propio soporte de Shopify? Contactó primero al soporte oficial de Shopify, que confirmó que la plataforma en sí no tenía ningún incidente reportado, lo cual, aunque correcto, no ayudó a resolver nada: el problema no estaba en Shopify, estaba en la interacción entre Shopify y la pasarela de pago específica que usaba esta tienda.

El miércoles, dos clientes más habían iniciado disputas directamente con su banco, el peor escenario posible, porque una disputa bancaria no solo es un dolor de cabeza administrativo: puede afectar la reputación de la cuenta de pagos de la propia tienda frente al proveedor de la pasarela, con el riesgo de que esta decida suspender temporalmente el procesamiento de pagos como medida de precaución.

El jueves llegó, por fin, el contacto correcto: un técnico con acceso directo a los logs de transacciones de la pasarela de pago, capaz de leer exactamente qué estaba pasando a nivel de API, no solo a nivel de interfaz de Shopify.

El diagnóstico tomó horas, no días, una vez que alguien técnico tuvo acceso al panel y a los logs de la pasarela. La causa: un cambio en cómo la pasarela interpretaba el campo de moneda en las solicitudes de reembolso, que Shopify no controlaba directamente pero que afectaba el comportamiento de la tienda.

La corrección fue relativamente simple una vez identificada. Lo difícil no fue arreglarlo: fue encontrarlo, porque nadie estaba mirando esa parte del sistema hasta que los clientes empezaron a quejarse en masa. Una vez aplicado el ajuste de configuración en la integración de la pasarela, los reembolsos volvieron a procesarse correctamente de inmediato, sin necesidad de ningún cambio en el tema ni en ninguna app de la tienda.

Los cargos duplicados se revirtieron en los días siguientes sin pérdida económica neta para los clientes afectados, pero el daño reputacional ya estaba hecho: varias clientas compartieron su experiencia en grupos locales de Madrid, y al menos dos reseñas negativas mencionando específicamente 'problemas con los reembolsos' quedaron publicadas de forma permanente en perfiles de redes sociales de la marca.

Para una tienda pequeña que depende en buena parte de la confianza de una comunidad local relativamente reducida, ese tipo de daño reputacional tarda mucho más en repararse que el propio incidente técnico. El dinero se devolvió en días; la confianza tardó meses en recuperarse del todo.

La marca contrató mantenimiento mensual Shopify después de ese episodio, con monitoreo activo de transacciones y reembolsos, algo que antes nadie supervisaba de forma proactiva. El cambio no fue dramático ni caro: fue simplemente tener a alguien revisando regularmente lo que antes solo se miraba cuando ya había una queja. Un equipo fijo, no una persona suelta —algo que desarrollamos con más detalle aquí— marcó la diferencia en la rapidez del diagnóstico.

Desde entonces, cualquier anomalía en el patrón de reembolsos —más de una queja similar en 24 horas, por ejemplo— dispara una revisión técnica inmediata, en lugar de esperar a que el volumen de quejas obligue a actuar. Es el mismo principio que falló durante esos cuatro días: detectar la anomalía en el primer caso, no en el quinto.

Madrid es, junto con Barcelona, la plaza con mayor concentración de tiendas Shopify activas en España. Más volumen de tiendas significa, estadísticamente, más incidentes de este tipo simplemente por número: no porque Madrid tenga un problema particular, sino porque hay más tiendas operando ahí que en ciudades más pequeñas, y por tanto más superficie donde estos fallos pueden ocurrir.

Esta concentración también significa que el boca a boca entre marcas madrileñas —muchas se conocen entre sí, comparten proveedores, asisten a los mismos eventos de comercio local— hace que historias como esta circulen rápido dentro del ecosistema, lo cual, visto en positivo, también acelera la adopción de buenas prácticas de mantenimiento preventivo entre tiendas que antes no le daban prioridad.