Cancelación de un pedido API si el cliente envió un enlace incorrecto

Primero compruebe si el pedido ya se transmitió al proveedor

Un enlace incorrecto no siempre significa que la promoción ya esté en marcha. En la base interna el pedido puede estar creado, pero aún no enviado por API. En ese caso, la cancelación depende solo de su lógica de procesamiento: basta con marcar el pedido como cancelado, detener el pago automático y no iniciar la transferencia.

Compruebe el identificador del pedido, la hora de creación, el enlace, el tipo de servicio y el registro de solicitudes API. Si la solicitud al proveedor no se ha enviado, no cree un pedido nuevo sobre el anterior. Primero registre la cancelación de la solicitud original, de lo contrario el cliente podría recibir dos lanzamientos en enlaces distintos.

Determine el estado del pedido en el proveedor

Si la solicitud API ya se envió, consulte el estado actual en el proveedor. Los nombres de los estados varían, pero normalmente se pueden agrupar en varias categorías: en espera, en proceso, ejecución parcial, finalización y cancelación. Para tomar la decisión no importa el estado en su panel, sino la respuesta de la parte que ejecuta el servicio.

• En espera: el pedido aún puede admitir cancelación.
• En proceso: a veces es posible detenerlo, pero parte del volumen ya puede estar en marcha.
• Ejecución parcial: solo se puede cancelar el resto, si el proveedor admite esa operación.
• Finalización: ya no se puede corregir el enlace mediante cancelación.

La desventaja de comprobar solo el estado interno es que puede actualizarse con retraso. Guíese por la última respuesta de la API y la hora en que se recibió.

Cancele el pedido antes de que se inicie el servicio

Para un pedido en cola, utilice el método de cancelación si la documentación del proveedor lo contempla. Envíe el identificador recibido al crear el pedido, no su número interno, si son valores distintos. Guarde la respuesta completa: código de operación, estado, texto del error y hora de la solicitud.

No considere el pedido cancelado hasta que la API confirme la cancelación. La respuesta de aceptación de la solicitud y la detención real del servicio pueden ser eventos distintos. En algunas integraciones primero llega la confirmación de aceptación y el estado final cambia más tarde.

La desventaja de esta opción es que el proveedor puede no llegar a retirar el pedido del procesamiento. En ese caso, la cancelación devolverá un rechazo o solo se aplicará a la parte no ejecutada.

No cambie el enlace en un pedido ya creado sin confirmación

En muchas API el enlace se fija en el momento de crear el pedido. El intento de enviar un nuevo enlace con el mismo identificador puede ignorarse, procesarse como error o generar un estado impredecible. No cuente con que el reenvío de la solicitud sustituya automáticamente la dirección.

Si la documentación admite explícitamente la edición del enlace, primero asegúrese de que el servicio aún no haya empezado a ejecutarse. Después guarde el valor anterior, el nuevo valor y la respuesta de la API. Esto será útil en caso de disputa con el cliente o el proveedor.

La desventaja de la edición es que, incluso con el método disponible, parte de las acciones podrían haber llegado a la página antigua antes de la actualización. El enlace corregido no transfiere el resultado ya obtenido.

Qué hacer en caso de ejecución parcial

Cuando la promoción ya ha comenzado sobre el enlace incorrecto, solicite la cancelación del resto. En la comunicación con el proveedor indique el identificador del pedido, el enlace incorrecto, el enlace correcto, el estado actual y la hora en que se detectó el error. No modifique los detalles de la comunicación varias veces: esto dificulta la revisión del historial.

Si se confirma la cancelación del resto, registre el volumen que ya se ha ejecutado. El reembolso, si las reglas del proveedor lo contemplan, normalmente solo afecta a la parte no ejecutada. El volumen ejecutado no se puede transferir técnicamente de un canal, vídeo o perfil a otro.

La desventaja de la cancelación parcial es evidente: el cliente ya puede haber recibido el resultado en la página incorrecta, y el presupuesto de esa parte del pedido no siempre se devuelve.

Si el pedido está finalizado, tramite la corrección con una solicitud aparte

Un pedido finalizado normalmente no se puede cancelar por API. En tal situación no elimine el registro ni cambie el enlace en el historial: los datos originales son necesarios para la verificación. Compruebe si el servicio realmente se prestó en la dirección errónea y no solo se muestra con retraso.

Después hay dos caminos: negociar una compensación con el proveedor según sus reglas o crear un nuevo pedido con el enlace correcto tras acordarlo con el cliente. El nuevo pedido debe tener un identificador propio, un importe y una nota clara sobre el motivo de su creación.

La desventaja del nuevo lanzamiento es que requiere presupuesto adicional, y la compensación por un servicio finalizado puede no estar disponible.

Informe al cliente de la situación antes de un nuevo lanzamiento

No lance una sustitución por su cuenta si el enlace pertenece al cliente y el error provino de su parte. Envíele el enlace original, el estado del pedido, la posibilidad de cancelación y las consecuencias de cada opción. Esto es especialmente importante si parte del servicio ya se ha ejecutado.

• Si el pedido no se ha transmitido, solicite el enlace correcto y confirme la cancelación de la solicitud anterior.
• Si el pedido está en cola, comunique que la cancelación se ha enviado, pero se espera la respuesta del proveedor.
• Si hay ejecución parcial, indique que solo se puede detener el resto.
• Si el pedido está finalizado, acuerde un nuevo lanzamiento u otra forma de solución.

La desventaja de una negociación prolongada es que, durante ese tiempo, el pedido en cola puede pasar a procesamiento. Por eso, primero envíe la solicitud técnica de cancelación si existe esa posibilidad, y luego aclare los siguientes pasos.

Guarde los registros y las pruebas de la operación

Para cada pedido en disputa guarde el enlace original del cliente, la fecha de recepción, el número interno, el identificador en el proveedor, las solicitudes y respuestas de la API. Si el cliente envió el enlace en una conversación, no sustituya el mensaje por una versión editada en la ficha del pedido sin conservar el original.

Registre por separado quién y cuándo detectó el error. Esto ayuda a separar los datos transmitidos incorrectamente de un error del gestor, del formulario de pedido o de una sustitución automática. En las comunicaciones repetidas con el proveedor utilice una única cadena de datos para que no surjan contradicciones.

La desventaja del registro manual de logs es que lleva tiempo. Pero sin historial es más difícil confirmar el estado de la cancelación y explicar al cliente por qué no se puede devolver el importe completo.

Revise el tratamiento de errores en la integración

Tras un caso así, compruebe cómo el sistema transmite los enlaces a la API. El error puede aparecer no solo por culpa del cliente: a veces el formulario recorta parámetros, sustituye un valor antiguo de la caché, acepta un enlace al perfil en lugar de un enlace a la publicación o deja pasar un enlace con caracteres sobrantes.

Añada una validación del formato antes de crear el pedido: correspondencia con la plataforma, el tipo de servicio y el objeto esperado. Para los servicios en vídeo, el sistema debe distinguir el enlace al vídeo del enlace al canal, y para las redes sociales, el perfil de una publicación concreta. La validación no garantiza que el enlace sea correcto, pero descarta parte de los errores evidentes.

Es mejor separar la transmisión del pedido de su creación con una breve comprobación de los datos. La desventaja del paso adicional es que el pedido no entrará en trabajo al instante, pero tendrá tiempo para detectar una dirección incorrecta.

Configure un escenario de cancelación claro para el equipo

Describa un procedimiento único: detener el envío automático, comprobar el estado en el proveedor, enviar la cancelación, guardar la respuesta, informar al cliente y solo después acordar un nuevo lanzamiento. Este escenario no es una formalidad, sino que evita que distintos empleados realicen acciones mutuamente excluyentes.

No conceda acceso a la cancelación sin limitar los permisos y sin un registro de acciones. Si varios gestores trabajan a la vez con un mismo pedido, uno puede solicitar la cancelación y otro crear una sustitución antes de recibir la respuesta. Esto genera gastos innecesarios y confusión en los cálculos.

La desventaja de un escenario estricto es que hay menos flexibilidad en casos urgentes. Pero para los pedidos API es más importante el control de qué enlace se envió realmente a trabajo que la velocidad de una acción concreta.