Saltar al contenido principal

Tu acuse de entrega de SMS miente (y en qué países)

· 4 min de lectura

Si envías SMS por API, tu panel te dice delivered y tú das el mensaje por recibido. En España casi siempre es verdad. Fuera de España, muchas veces no: ese delivered significa solo que la red del operador aceptó el mensaje, no que apareciera en la pantalla de nadie.

La diferencia parece un detalle técnico. No lo es: es la razón por la que un cliente jura que no le llegó el código de verificación mientras tú tienes un registro que dice que sí.

Los cuatro significados de "entregado"

El acuse de entrega —el DLR, delivery report— viaja de vuelta desde la red móvil hasta tu proveedor, y no todas las redes informan de lo mismo:

Lo que confirma el acuse Qué sabes de verdad
Entrega en el terminal El mensaje llegó al teléfono. Es el caso bueno.
Aceptación por la red La operadora se hizo cargo. Puede acabar entregado, retenido o descartado.
Parcial Unas redes del país informan de la entrega real y otras no.
Sin acuse No hay información: el estado se queda en "enviado" y ahí termina.

España, Portugal, Alemania o Reino Unido suelen dar entrega en el terminal. Buena parte de Latinoamérica, África y Asia dan aceptación de red, y algunos destinos no dan nada. Un mismo prefijo puede tener los dos comportamientos: en el +1 conviven redes que informan y redes que no, así que una regla para "+1" es directamente falsa.

Por qué esto cuesta dinero, no solo precisión

Tres consecuencias concretas, en orden de gravedad:

1. El reembolso automático se cierra para siempre. Si tu plataforma considera delivered un estado final —y debe considerarlo— un acuse de red cierra el caso. El mensaje nunca llegó, nadie lo reintentó y el fallo fue silencioso: sin error, sin alerta, sin nada que mirar.

2. Tus métricas mienten hacia arriba. En un destino que solo informa de aceptación, tu tasa de "entregados" no mide entregas: mide aceptaciones. Si tomas decisiones de ruta con ese número, las tomas con un dato que no dice lo que crees.

3. Los OTP se pierden en silencio. Es el caso más caro: el usuario no puede entrar, no vuelve a intentarlo y se va. Tú ves un delivered y no hay nada que investigar.

Cómo saber qué te está diciendo tu proveedor

Pregunta esto por escrito, país por país, antes de cerrar tarifas:

Si la respuesta es "entregado es entregado", desconfía: nadie que opere rutas internacionales de verdad puede decir eso sin matizar.

Qué hacemos nosotros con este problema

En SMSverifica el nivel de acuse de cada destino es un dato del sistema, no una nota en un correo. Cada país tiene declarado qué confirma su acuse, con su fuente y su fecha, y eso tiene tres efectos:

Y hay un sitio donde no basta con avisar: en la mensajería certificada, lo que se vende es precisamente la afirmación de entrega. Ahí el sistema es estricto: si el destino no confirma entrega en el terminal, no se emite el certificado. Preferimos perder ese envío a firmar un documento que no podríamos sostener ante un tercero.

Qué puedes hacer hoy en tu integración

  1. No trates delivered como prueba en destinos que solo confirman red. Guarda el nivel de acuse junto al mensaje.
  2. Para OTP, añade un segundo canal: si el SMS no se confirma en 30-60 segundos, ofrece WhatsApp, una llamada o un reenvío. Es más barato que perder al usuario.
  3. Mide por destino, no en global. Una tasa media esconde justo el país que te está fallando.
  4. Pide el dato por escrito a tu proveedor y guárdalo con la fecha: cambia con el tiempo y con las rutas.

Nosotros publicamos el precio de cada destino y avisamos de lo que confirma su acuse antes de que envíes. Puedes verlo en precios y destinos o probarlo con tu propio código: al verificar tu correo se abre el modo prueba y la API funciona sin gastar un euro.


← Todos los artículos

Pruébalo con tu propio código

Crea la cuenta gratis: al verificar tu correo se abre el modo prueba y puedes integrar la API sin gastar un euro.