Contracargos por productos digitales en Shopify: el modelo de prueba que funciona cuando no hay caja que entregar

El modelo de prueba físico no funciona aquí — empieza por aceptarlo

Abre Panel de administración de Shopify → Pedidos → Disputas. El contracargo es por un producto digital: una licencia de software, un curso, un archivo descargable, una suscripción. El código de motivo dice «producto no recibido» o «transacción no reconocida». El primer error que cometen la mayoría de los comerciantes es buscar el equivalente de un número de seguimiento. No existe. Y el emisor lo sabe.

Los productos digitales exigen un modelo de prueba distinto. No hay transportista, no hay firma, no hay foto de entrega. Lo que tienes son registros de sistema: cuándo se generó el enlace de descarga, desde qué IP se accedió, cuántas veces se abrió la sesión, qué dispositivo usó el cliente. Ese conjunto de datos es tu expediente. Si no lo has estructurado antes de que llegue el contracargo, ya vas tarde.

Este playbook asume que el contracargo ya está abierto. Sigue los pasos en orden.

Paso 1: Identifica el código de motivo exacto antes de recopilar nada

El código de motivo determina qué prueba el emisor espera ver. Para productos digitales, los dos escenarios más frecuentes son:

• Producto no recibido (Visa 13.1, Mastercard 4855): el titular afirma que nunca recibió acceso al producto.
• Transacción no reconocida / fraude (Visa 10.4, Mastercard 4837): el titular niega haber realizado la compra.

La respuesta para cada uno es diferente. Un contracargo 13.1 se gana demostrando entrega funcional — que el acceso se generó, se entregó y se usó. Un contracargo 10.4 exige además demostrar que la persona que compró es la misma que accedió, lo que requiere correlacionar datos de autorización con datos de comportamiento posterior.

Confundir los dos es uno de los fallos más comunes. Un expediente construido para «no recibido» raramente sobrevive una revisión de fraude, aunque el acceso esté documentado.

Paso 2: Extrae los registros de entrega digital desde tu plataforma

Shopify no almacena registros de descarga nativos para todos los tipos de productos digitales. Si usas Shopify Digital Downloads (la app oficial), el historial de descargas está disponible en la app, vinculado al pedido. Si usas una app de terceros — SendOwl, FetchApp, Sky Pilot, Gumroad integrado — los registros están en esa plataforma, no en Shopify Admin.

Extrae y documenta lo siguiente para cada pedido disputado:

• Fecha y hora exacta en que se generó el enlace de descarga o se activó el acceso.
• Fecha y hora de cada descarga o acceso completado.
• Dirección IP desde la que se realizó cada descarga.
• User agent (navegador y sistema operativo) registrado en cada sesión.
• Número total de descargas o accesos realizados.

Si tu plataforma no registra IP por descarga, anótalo explícitamente en tu expediente. Presentar un registro incompleto sin aclarar por qué está incompleto genera desconfianza innecesaria ante el emisor.

Paso 3: Cruza los datos de IP con la información de la compra

Este paso diferencia un expediente débil de uno que aguanta revisión. Compara la IP registrada en el momento de la compra (disponible en Shopify Admin → Pedidos → [pedido] → sección de detalles del cliente) con la IP registrada en el momento del acceso o descarga.

Tres escenarios posibles:

• IP de compra = IP de descarga: señal fuerte. Incluye ambas en el expediente con una nota explícita de coincidencia.
• IP de compra ≠ IP de descarga, pero misma geolocalización aproximada: puede indicar cambio de red (WiFi doméstica vs. datos móviles). Documenta la geolocalización de ambas IPs y explica la discrepancia en la narrativa.
• IP de compra ≠ IP de descarga, geolocalizaciones distintas: punto de decisión crítico — ver más abajo.

Para geolocalizar IPs, herramientas como ipinfo.io o MaxMind son suficientes para uso operativo. Incluye capturas de pantalla de la geolocalización en el expediente, no solo los datos en texto.

Punto de decisión: IPs divergentes — ¿disputar o ceder?

Un comerciante vendió una licencia de software de 89 € a través de Shopify. El pedido se procesó desde una IP en Madrid. La descarga se realizó desde una IP en Bucarest, 14 horas después. El cliente disputó alegando que nunca recibió el producto.

El comerciante tenía el registro de descarga completo, la confirmación de pago y los términos de no reembolso aceptados en el checkout. Pero la divergencia de IP era real y no tenía explicación documentada.

Opción A — Disputar con el expediente completo: presentas todos los registros, explicas que el acceso se realizó desde una IP diferente pero que el enlace de descarga es de un solo uso vinculado al email del comprador, y que no hay mecanismo técnico para que un tercero acceda sin las credenciales del pedido. Resultado probable: depende del emisor. Algunos aceptan la lógica técnica; otros pesan la divergencia geográfica como señal de fraude real y fallan a favor del titular. Tasa de éxito estimada en este escenario: 40–55% (confirma con tu procesador el historial de resoluciones similares).

Opción B — Aceptar el contracargo: si el importe es bajo, si el cliente no tiene historial de compras previas y si la divergencia de IP no tiene explicación técnica plausible, ceder puede ser la decisión correcta. Acumular disputas perdidas afecta tu ratio de contracargos con Shopify Payments y con las redes de tarjetas.

La regla operativa: si no puedes explicar la divergencia de IP con lógica técnica documentada, el expediente tiene una grieta que el emisor puede usar para fallar en contra. Evalúa el importe y el ratio antes de decidir.

Paso 4: Documenta la aceptación de términos en el checkout

Para productos digitales, la aceptación explícita de términos en el momento de la compra es evidencia de primer orden — especialmente para disputas de «producto no conforme» o «no recibido» donde el cliente alega que no sabía que el producto era digital o no reembolsable.

Documenta lo siguiente:

• Captura de pantalla de la página de checkout mostrando la casilla de aceptación de términos o el aviso de política de no reembolso para productos digitales, tal como aparecía en la fecha de la compra.
• Si usas Shopify, el campo Política de reembolso en Configuración → Políticas debe estar actualizado y debe mencionar explícitamente los productos digitales. Captura esa página con fecha visible.
• El email de confirmación de pedido enviado al cliente, que debe incluir el enlace de descarga o las instrucciones de acceso. Extrae este email desde Shopify Admin → Pedidos → [pedido] → Ver historial de emails.

Si tu checkout no incluye aceptación explícita de términos para productos digitales, ese es un fallo estructural que te costará disputas futuras. Corrígelo antes del próximo contracargo, no después.

Paso 5: Construye la narrativa de respuesta en este orden

El emisor lee el expediente en orden. La narrativa debe ir de lo más concreto a lo más contextual:

1. Confirmación de que el pedido fue procesado y autorizado correctamente (fecha, importe, últimos cuatro dígitos).
2. Confirmación de que el acceso digital fue generado y entregado al email del comprador (fecha y hora exactas).
3. Registro de que el acceso fue utilizado (fecha, hora, IP, número de descargas o sesiones).
4. Correlación entre los datos de la compra y los datos de acceso.
5. Referencia a los términos aceptados en el checkout.

Ejemplo de párrafo de apertura para la narrativa de respuesta (adapta los datos):

«El pedido #[NÚMERO] fue procesado el [FECHA] por un importe de [IMPORTE] con autorización confirmada. El enlace de descarga fue generado automáticamente y enviado al email [EMAIL] a las [HORA]. El archivo fue descargado [N] veces entre [FECHA INICIO] y [FECHA FIN] desde la dirección IP [IP], geolocalizada en [CIUDAD, PAÍS]. El cliente aceptó los términos de compra, que incluyen la política de no reembolso para productos digitales, durante el proceso de checkout. Adjuntamos registros de descarga, captura del checkout con términos y confirmación de email de entrega.»

No uses lenguaje emocional ni argumentes sobre la buena fe del cliente. El emisor evalúa evidencia, no intenciones.

Paso 6: Adjunta los documentos en el orden correcto

El orden de los adjuntos importa porque muchos emisores leen solo los primeros documentos si el caso parece resuelto. Orden recomendado:

1. Registro de descarga o acceso (exportado desde tu plataforma, con IP y timestamps).
2. Captura del email de entrega enviado al cliente.
3. Captura del checkout con términos aceptados.
4. Geolocalización de IPs (compra y descarga).
5. Política de reembolso vigente en la fecha de la compra.
6. Historial de comunicación con el cliente, si existe.

Si el emisor usa un portal de disputas propio (no Shopify Payments), confirma el límite de páginas o MB antes de adjuntar. Algunos portales rechazan expedientes superiores a 5 MB sin aviso explícito.

El caso que tenía registros completos y aun así perdió

Un comerciante vendía plantillas de diseño descargables a 34 € la unidad. El cliente disputó alegando «producto no recibido». El comerciante tenía: registro de descarga con IP, email de entrega con timestamp, captura del checkout con política de no reembolso visible, y tres descargas del mismo archivo en un período de dos días.

Perdió el contracargo.

El emisor falló a favor del titular porque el comerciante no había incluido el user agent en el registro de descarga, y la IP de descarga era un nodo de salida de VPN conocido. El emisor interpretó que no había prueba suficiente de que el titular de la tarjeta — y no un tercero — hubiera realizado las descargas.

El fallo operativo no fue la falta de evidencia. Fue que el expediente no anticipó la objeción del emisor. Tres descargas desde una VPN, sin user agent, sin correlación con el dispositivo usado en el checkout, dejaron una grieta suficiente para perder.

La lección: los registros de acceso prueban que alguien accedió. Los emisores quieren evidencia de que ese alguien era el titular de la tarjeta. Cuando hay VPN, dispositivo desconocido o IP anómala, necesitas más correlación, no más volumen de documentos.

Dónde falla el modelo de prueba digital antes de que llegue el contracargo

La mayoría de los contracargos de productos digitales se pierden por fallos estructurales anteriores al contracargo, no por falta de respuesta:

• La plataforma de entrega no registra IP por descarga. Si usas una app que solo registra «descargado: sí/no», no tienes evidencia de acceso real. Cambia de plataforma o añade logging externo antes de que llegue el siguiente contracargo.
• Los términos de no reembolso no mencionan productos digitales explícitamente. Una política genérica de reembolso no cubre productos digitales en la mayoría de las redes de tarjetas. Visa y Mastercard tienen reglas específicas para bienes digitales — confirma con tu procesador qué lenguaje exigen.
• El email de entrega no queda registrado en Shopify Admin. Si el enlace de descarga se envía desde una app de terceros y no desde Shopify, el historial de emails en Admin no lo refleja. Guarda copias externas de esos envíos.
• No hay correlación entre el email de compra y el email de acceso. Si el cliente compra con un email y accede con otro (cuenta de plataforma diferente), el expediente tiene una brecha que el emisor puede explotar.

Nota interna para el equipo de operaciones

Cuando proceses un contracargo de producto digital, añade esta nota al registro interno del pedido antes de construir el expediente:

«Contracargo digital — [FECHA]. Código: [MOTIVO]. Registros de descarga: [SÍ/NO]. IP de compra: [IP]. IP de descarga: [IP]. Coincidencia: [SÍ/PARCIAL/NO]. VPN detectada: [SÍ/NO]. Términos aceptados en checkout: [SÍ/NO]. Decisión: [DISPUTAR/CEDER]. Responsable: [NOMBRE].»

Esta nota no es para el emisor. Es para que el siguiente contracargo del mismo cliente — o del mismo patrón — no empiece desde cero.

Automatización y límites operativos

DisputeDesk organiza y estructura los registros de acceso, IPs y documentación de términos en un expediente coherente. La automatización mejora la consistencia del formato y reduce el tiempo de preparación. No resuelve el problema de fondo si los registros de tu plataforma de entrega son incompletos o si la correlación de IP es débil. Los casos con VPN, IPs divergentes o registros parciales requieren revisión manual antes de enviar — la automatización no puede tomar esa decisión por ti.