Siete aspectos que hay que definir antes de crear una función de pago con IA

Resumen clave

La indicación más peligrosa a la hora de delegar la función de pago a la IA es limitarse a pedirle simplemente «añade el pago». El pago no es un código para recibir dinero, sino un sistema de operaciones, contabilidad y atención al cliente que se encarga del flujo de dinero.

Técnicamente, la IA puede implementar rápidamente la integración de la ventana de pago, la llamada a la API de autorización, la recepción de webhooks y el almacenamiento de pedidos. Sin embargo, si no se establecen las siguientes políticas, en el servicio real pueden surgir problemas como pedidos fantasma, pagos duplicados, retrasos en los reembolsos, saturación del servicio de atención al cliente y omisión de avisos legales.

1. Diseño del estado de los pedidos: el estado es el lenguaje operativo

Al crear una función de pago, no basta con establecer un único estado de pedido, como «Pedido completado». En la práctica, un pedido pasa por varias etapas, como intento de pago, autorización, cancelación, reembolso, fallo o caducidad.

Ejemplos de estados recomendados

Principios de diseño de estados

• No se considera que el estado del pedido y el estado del pago sean exactamente lo mismo. Un pedido puede existir aunque el pago haya fallado, y un pago puede haber sido autorizado aunque el pedido no se haya guardado.
• Cada cambio de estado debe incluir la hora en que se produjo, quién lo gestionó, el motivo, el identificador de la transacción de pago y el identificador de la transacción de reembolso.
• Las pantallas de los clientes, las pantallas de los administradores y los mensajes de atención al cliente deben utilizar la misma definición de estado.
• Las transiciones de estado se diseñan de forma unidireccional, y la recuperación de excepciones se gestiona mediante registros con permisos de administrador específicos.

2. Desistimiento del contrato y plazo legal de reembolso: no se trata de una política, sino de un requisito legal

Si se opera en el comercio electrónico dirigido a consumidores en Corea, se debe tener en cuenta la Ley de Protección del Consumidor en el Comercio Electrónico, entre otros ámbitos. Por lo general, el consumidor puede desistir del contrato dentro de un plazo determinado, y el empresario debe reembolsar el importe en el plazo establecido tras la solicitud de reembolso o el procedimiento de devolución.

Los criterios especialmente importantes en la práctica son los siguientes:

• En principio, el consumidor puede desistir del contrato en un plazo de 7 días a partir de la fecha establecida por la ley, como la fecha de recepción de los bienes.
• El comerciante debe reembolsar el importe dentro del plazo legal una vez que se haya producido el motivo del reembolso; en caso de retraso, pueden surgir cuestiones relacionadas con indemnizaciones por demora o intereses de demora.
• Pueden existir excepciones en el caso de contenidos digitales, productos fabricados a medida o productos cuyo valor disminuya notablemente con el uso; sin embargo, para aplicar dichas excepciones, es necesario comprobar cuidadosamente los requisitos, como la notificación previa y el consentimiento.
• La aplicación práctica puede variar en función del tipo de producto, la modalidad del contrato, la información facilitada al consumidor y si se ha iniciado o no el uso, por lo que es necesario un análisis jurídico.

Cómo convertirlo en requisitos de desarrollo

No basta con incluir los criterios legales únicamente en la redacción de las condiciones generales. También deben traducirse en requisitos del sistema.

3. Normas de reembolso parcial: definir previamente los cupones, los gastos de envío y los impuestos

Los reembolsos parciales son mucho más complejos que las cancelaciones totales. Si se pide varios productos a la vez y solo se devuelve una parte, hay que decidir cómo repartir el descuento y los gastos de envío aplicados originalmente.

Aspectos que hay que definir obligatoriamente

• ¿Cómo se distribuirá el importe del pago por producto?
• ¿Se distribuirá el cupón de todo el pedido de forma proporcional por producto?
• ¿Se aplicará el cupón de un producto concreto únicamente a dicho producto?
• ¿Se deducirán los gastos de envío si no se cumplen las condiciones de envío gratuito?
• ¿Cómo se distinguirán los gastos de envío de las devoluciones por simple cambio de opinión de los de las devoluciones por defectos del producto?
• ¿En qué orden se reembolsarán los pagos realizados con puntos, saldo acumulado y tarjetas regalo?
• ¿Cómo se modificarán los datos de la factura fiscal, el recibo de caja y el recibo tras un reembolso parcial?

Ejemplo de cálculo de un reembolso parcial

Si se distribuye el cupón en proporción al importe de cada producto, se aplicará un descuento de 3.000 won al producto A y de 7.000 won al producto B. En este caso, si solo se reembolsa el producto A, el importe de referencia para el reembolso no será de 30.000 won, sino de 27.000 won. Si existen condiciones de envío gratuito, gastos de devolución o restricciones de reembolso según la forma de pago, el importe final del reembolso puede variar aún más.

No hay una única respuesta correcta. Lo importante es establecer de antemano unas normas coherentes e informarlas de manera que el cliente las comprenda antes de realizar el pago o de solicitar el reembolso.

4. Prevención de pagos duplicados: no basta con desactivar el botón

El pago duplicado es el error de pago que los clientes detectan más rápidamente. Los clientes ven primero el mensaje de autorización de la tarjeta y el extracto de la tarjeta, antes que el estado del pedido en el servicio. Si se cobra dos veces por el mismo pedido, la confianza se ve muy mermada.

Causas

• El cliente hace clic varias veces seguidas en el botón de pago.
• Actualiza la página o pulsa «Atrás» inmediatamente después del pago.
• Se reenvía la misma solicitud debido a un retraso en la red móvil.
• La respuesta de autorización del pago se ha realizado con éxito, pero el almacenamiento en el servidor del servicio ha fallado.
• El webhook y la redirección del cliente modifican simultáneamente el estado del pedido.

Diseño de medidas de protección

Al solicitar un código de pago a la IA, es recomendable especificar que «la aprobación y la finalización del pago de un mismo pedido deben funcionar de forma idempotente», en lugar de centrarse en «evitar clics duplicados».

5. Mensaje de aviso de fallo en el pago: el fallo no es un incidente, sino parte del flujo normal

Los fallos en el pago son situaciones normales que se producen a diario. El exceso de límite, el saldo insuficiente, el fallo en la autenticación de la tarjeta, el error en la contraseña, el fallo en la autenticación 3D Secure, la falta de respuesta de la aplicación de pago simplificado y los errores de red son casos muy habituales.

Un mensaje inadecuado es aquel que termina con «Se ha producido un error». El cliente no sabe si el pago se ha realizado, si puede volver a intentarlo o si el pedido se ha cancelado.

Ejemplos de mensajes de aviso

Elementos clave de los mensajes de error

• Indica claramente si el pago no se ha completado realmente.
• Informa del tiempo durante el que se mantiene el pedido.
• Indica si se puede volver a intentar o si es necesario utilizar otro método de pago.
• Muestra el número de pedido necesario para ponerse en contacto con el servicio de atención al cliente.
• Si el resultado del pago es incierto, no se debe instar a realizar un nuevo pago de forma incondicional, sino indicar que se está comprobando.

6. Página de historial de pagos: la pantalla clave para reducir las consultas al servicio de atención al cliente

Si no existe una página de historial de pagos, los clientes se ven obligados a ponerse en contacto con el servicio de atención al cliente para comprobar el estado de los pagos, las cancelaciones y los reembolsos. El historial de pagos no es una simple pantalla de recibo, sino un mecanismo de confianza que permite al cliente comprobar el estado actual de su dinero.

Información que debe incluirse en la página de historial de pagos

• Número de pedido
• Fecha y hora del pedido y del pago
• Nombre del producto, cantidad y opciones
• Medio de pago y número de autorización o identificador de la transacción
• Importe del producto, descuentos, gastos de envío, puntos utilizados e importe final a pagar
• Estado actual del pedido y estado del reembolso
• Fecha de solicitud del reembolso, fecha de aprobación del reembolso y fecha prevista de finalización del reembolso
• Posibilidad de cancelación o reembolso
• Enlaces para consultar el recibo, el desglose de la transacción y el recibo fiscal
• Información necesaria para ponerse en contacto con el servicio de atención al cliente

Conexión con la pantalla del administrador

La pantalla del cliente y la del administrador deben mostrar los mismos datos. Si al cliente le aparece «Reembolso en curso», pero en la pantalla del administrador se muestra como «Procesado», se producirán confusiones a la hora de atender las consultas del servicio de atención al cliente. Aunque los nombres de los estados puedan expresarse de forma diferente, el código de estado interno y las reglas de transición deben ser los mismos.

7. Ubicación de la notificación de la política de reembolsos: si se oculta, deja de ser una política y se convierte en un riesgo

No basta con colocar la política de reembolsos en un rincón de la página de condiciones generales. El cliente debe poder consultar fácilmente el plazo de reembolso, las condiciones de restricción y el procedimiento de cancelación en la pantalla en la que toma la decisión de pago.

Ubicaciones recomendadas para la notificación

• Cerca del precio o del botón de compra en la página de detalles del producto
• En la pantalla del carrito o del formulario de pedido
• En la zona de aceptación de los términos y condiciones y la política de reembolso, justo encima del botón de pago
• En la página de pago completado
• En la pantalla de detalles del pedido de «Mi cuenta»
• En la pantalla de solicitud de reembolso

Diseños que deben evitarse

• Diseños en los que, aunque la suscripción y el pago se realizan de una sola vez, la cancelación o el reembolso solo pueden realizarse llamando al servicio de atención al cliente
• Diseños en los que el botón de cancelación queda oculto tras varios pasos
• Diseños en los que las condiciones de reembolso solo se muestran después de realizar el pago
• Diseños en los que el color, el texto y el orden de los botones están dispuestos de forma que puedan inducir a error al cliente
• Diseños que no informan claramente de que se realizará un cobro automático una vez finalizado el periodo de prueba gratuito

Este tipo de diseños no solo perjudican la experiencia del cliente, sino que pueden considerarse «patrones oscuros». En particular, es recomendable diseñar los procesos de cancelación y baja de forma que su dificultad no difiera significativamente de la del registro y el pago.

Lista de verificación que debe incluirse en la indicación para la IA

Al solicitar la implementación de la función de pago a una herramienta de desarrollo de IA, primero hay que comunicar las políticas tal y como se indica a continuación.

Ejemplo de indicación para la función de pago

Implementa la función de pago para un servicio de comercio electrónico dirigido a consumidores coreanos.
Debes reflejar obligatoriamente las siguientes políticas:

1. Utiliza los estados de pedido «payment_pending», «paid», «payment_failed», «cancel_requested», «cancelled», «refund_requested», «refund_processing», «partially_refunded», «refunded» y «expired».
2. Los pedidos pendientes de pago se cambiarán a «expired» tras 30 minutos.
3. Solo se permite una autorización de pago por pedido; utiliza el bloqueo de pedidos a nivel de servidor y una clave de idempotencia.
4. Dado que los webhooks de pago pueden recibirse por duplicado, cada ID de evento solo se procesará una vez.
5. Se almacenan la fecha de solicitud del reembolso, la fecha límite de tramitación del reembolso, la persona encargada, el motivo y el número de transacción del reembolso.
6. Los reembolsos parciales se calculan en función del importe real pagado por cada producto, y los cupones aplicables a todo el pedido se distribuyen proporcionalmente al importe de cada producto.
7. En caso de fallo en el pago, se devuelve un mensaje de aviso al cliente en función del motivo del fallo.
8. Permite que el cliente pueda consultar el historial de pagos y el estado de los reembolsos en «Mi cuenta».
9. Muestra el enlace a la política de reembolsos y la casilla de aceptación antes del pago, y guarda la hora de aceptación y la versión de los términos y condiciones.
10. Si hay alguna política que no esté definida, consulta primero antes de escribir el código.

La última frase, «Si hay alguna política que no esté definida, pregúntame primero», es importante. De este modo, se puede hacer que la IA pregunte sobre políticas que las personas suelen pasar por alto, como si los reembolsos se aprueban automáticamente, quién tiene la autoridad para aprobarlos o cómo se deducen los gastos de envío.

Funciones necesarias en la pantalla del administrador

La función de pago no se completa solo con la pantalla del cliente. Los reembolsos y las cancelaciones son tareas operativas que se gestionan a diario, por lo que es imprescindible contar con una pantalla de administrador.

Configuración mínima del modelo de datos de pagos

Aunque la estructura de datos varía según el servicio, se recomienda separar, como mínimo, los datos que se indican a continuación.

Es importante no sobrescribir el importe aprobado del pago, el importe del reembolso ni el importe total del pedido. Los valores relacionados con el dinero deben conservarse, en la medida de lo posible, por historial y por transacción, para que posteriormente coincidan con los registros contables y la atención al cliente.

Lista de comprobación previa al lanzamiento

• ¿Si se pulsa el botón de pago 10 veces para un mismo pedido, solo se aprueba el pago una vez?
• Si falla el almacenamiento en el servidor tras la aprobación del pago, ¿se puede recuperar?
• ¿El webhook de pago no procesa los eventos de forma duplicada aunque se envíen varias veces?
• ¿El cliente puede comprender el motivo del fallo en el pago y cómo volver a intentarlo?
• ¿Los pedidos pendientes de pago caducan automáticamente tras un tiempo determinado?
• ¿El importe del reembolso parcial se ajusta a la política de cupones, puntos y gastos de envío?
• ¿Se muestra en el panel de administración desde la fecha de solicitud del reembolso hasta la fecha límite de tramitación?
• ¿Se pueden consultar fácilmente las normas de reembolso en la pantalla previa al pago?
• ¿Existen avisos previos y registros de consentimiento para los contenidos digitales o los productos con restricciones de reembolso?
• ¿Puede el cliente consultar directamente el historial de pagos y el estado de los reembolsos en «Mi cuenta»?

Conclusión

La IA permite crear rápidamente el código de las funciones de pago. Sin embargo, un sistema de pago que funcione de forma segura y legal comienza con la definición de políticas, antes incluso de la programación.

Si primero se definen el estado de los pedidos, los plazos legales de reembolso, la fórmula de cálculo de los reembolsos parciales, la prevención de pagos duplicados, las notificaciones de fallos en el pago, la página de historial de pagos y la ubicación de la información sobre la política de reembolsos, y luego se encarga a la IA su implementación, se obtienen resultados mucho más estables. El pago debe diseñarse desde la perspectiva de que no es una «función para recibir dinero», sino una «función para gestionar el dinero de forma responsable».