Guías
Validación de correo al finalizar la compra
Compruebe la dirección antes del pago y proponga una corrección. Decida qué hacer si el correo es la única vía para entregar el pedido. La incertidumbre no debe convertirse en un falso error de dirección.
Qué hacer con cada respuesta
Los mismos cuatro resultados siempre. La instrucción cambia con la situación, porque con ella cambia lo que cuesta equivocarse.
| Resultado | Qué hacer aquí |
|---|---|
| Entregable | Continúe la compra. El resultado positivo respalda el uso de la dirección, pero no garantiza que llegue el recibo ni demuestra quién controla el buzón. |
| Con riesgo | Revise la acción y los motivos. Una dirección genérica o catch-all no indica riesgo en el pago. Continúe si lo permite su política de entrega y confirme el control del buzón por separado si el acceso depende de él. |
| No entregable | Pida corregir la dirección y explique el fallo. Si el pedido puede entregarse de forma segura sin correo, su política puede permitir continuar tras un aviso. Si el correo es imprescindible, resuelva el contacto antes del pago. |
| Desconocido | Trate la dirección como no resuelta. Permita comprar si existe otra vía segura de entrega y revise el contacto después. No la presente como inválida ni como una prueba de fraude. |
Compruebe la dirección antes del pago
La dirección de la compra puede recibir el recibo, una licencia o un aviso de entrega. Compruébela mientras la persona aún puede editar el campo. El navegador ayuda con errores de formato evidentes; el servidor puede llamar a Emvero cuando el campo esté completo o al enviar el formulario. Mantenga la credencial de la API en el servidor.
Una respuesta tardía debe seguir asociada a la dirección comprobada. Si la persona cambia el campo, descarte el resultado anterior y compruebe el valor nuevo. La página de verificación en tiempo real explica la petición y la espera.
Deje elegir la corrección propuesta
Si la respuesta trae LIKELY_DOMAIN_TYPO y una sugerencia, muestre la dirección escrita junto a la propuesta. La persona puede aceptar el cambio o conservar el original. No sustituya el dominio automáticamente ni vacíe el campo.
Un error claro de sintaxis y una posible errata requieren avisos distintos. INVALID_SYNTAX puede justificar una corrección de formato. SMTP_MAILBOX_NOT_FOUND describe un rechazo del destinatario observado por SMTP; no demuestra que falte el buzón ni que haya una errata en el dominio. La política actual devuelve unknown con SMTP_RECIPIENT_REJECTED_AMBIGUOUS. No invente una corrección si la API no la devuelve.
Decida si la entrega depende del correo
Si una cuenta con acceso autenticado u otra vía segura ya permite obtener la compra, un aviso sobre el correo no tiene por qué impedir el pago. Si un buzón operativo es la única vía para recibir una licencia o acceder a la cuenta, resuelva un fallo claro de contacto antes de cobrar. Explique esa condición junto al campo.
La recomendación de la API es un dato más para decidir. La acción reject se refiere a la dirección, no a la autorización del pago. Del mismo modo, ROLE_ACCOUNT, el comportamiento catch-all y un resultado risky no demuestran fraude. Separe los controles de pago e identidad de la política sobre el correo de contacto.
Limite la espera del formulario
Una verificación completa puede devolver pending con id y retry_after_ms. Después del intervalo, consulte GET /v1/verifications/{id} con la misma credencial. Repita solo mientras siga pendiente y deje de esperar al alcanzar el límite del formulario. Emvero no envía callbacks.
Un plazo agotado o un error HTTP no son un veredicto negativo sobre la dirección. Aplique la alternativa de entrega elegida, sin presentar un fallo del servicio como un correo inválido. Si permite continuar la compra, guarde el identificador de la comprobación junto al contacto correspondiente para consultar el resultado después desde su proceso. La página de la API explica los campos.
Permita corregir el contacto de forma segura
Tras el pago, una persona autenticada puede cambiar el correo mediante su flujo de pedidos o soporte. Verifique el valor nuevo y actualice el pedido correcto sin volver a iniciar el pago. No prometa que otra comprobación resolverá cualquier incertidumbre.
Emvero no envía recibos ni mensajes de confirmación. Si el acceso exige controlar el buzón, envíe su propia confirmación; la guía de formularios de registro explica la diferencia. La dirección indicada en la compra tampoco demuestra permiso para mensajes de marketing.
Reason codes que deciden algo aquí
Estos códigos forman parte del vocabulario de la API y explican una comprobación. Las notas también indican qué valores no devuelve la política de verificación o el sondeo actual.
LIKELY_DOMAIN_TYPO | El dominio parece una errata |
INVALID_SYNTAX | La dirección no está bien formada |
SMTP_MAILBOX_NOT_FOUND | Rechazo del destinatario observado por SMTP; la regla actual devuelve unknown con SMTP_RECIPIENT_REJECTED_AMBIGUOUS. |
ROLE_ACCOUNT | El nombre de la dirección indica una función; no identifica a quien usa el buzón |
Términos que conviene conocer antes
Sintaxis de una dirección
Reglas de formato comprobadas antes de consultar la red. Un formato válido no demuestra que funcionen el dominio o el buzón.
Dirección de función
Una dirección para un equipo o una función, como support@. Puede recibir correo; su idoneidad depende del propósito.
Rebote duro y rebote blando
Los fallos de entrega permanentes y temporales describen un intento de envío. Aquí se explica cómo se diferencian de la evidencia de verificación.
La decisión que hay detrás
Pruébelo con una dirección que ya conozca.
El verificador gratuito devuelve el resultado completo: cada etapa, cada reason code, sin ocultar nada.