{"content_id":"dtvo1yuy0p","slug":"ai-payment-feature-7-core-decisions","locale":"es","schema_type":"TechArticle","category":"how_to","category_name":"Cómo hacer","title":"Siete aspectos que hay que definir antes de crear una función de pago con IA","summary":"Aunque la IA permite generar códigos de pago rápidamente, la seguridad de la función de pago depende del diseño de políticas como el estado de los pedidos, los plazos de devolución, las devoluciones parciales y la prevención de pagos duplicados. En particular, en el caso de los servicios de comercio electrónico de Corea, es necesario reflejar claramente en los requisitos de desarrollo aspectos como el derecho de desistimiento, los intereses por demora en la devolución, la notificación de las normas de devolución y la prevención de los «patrones oscuros».","author":{"name":"Equipo editorial de Injoys","url":"https://injoys.com/ko/about"},"key_points":["La función de pago no es una simple función de autorización de tarjetas, sino un sistema operativo que integra pedidos, liquidaciones, devoluciones, atención al cliente y avisos legales.","Los estados de los pedidos, como «Pendiente de pago», «Pago completado», «Cancelado», «Reembolso en curso» y «Reembolso completado», deben definirse de manera que tanto el cliente como el administrador puedan interpretarlos con el mismo significado.","En el comercio electrónico de Corea, por lo general, hay que tener en cuenta el plazo de desistimiento del consumidor, el plazo de tramitación del reembolso por parte del comerciante y la normativa sobre intereses de demora.","Para evitar los pagos duplicados, no basta con desactivar el botón, sino que es necesario utilizar una clave de idempotencia en el servidor, bloquear el pedido y realizar una comprobación de la duplicación de la autorización de pago.","Un diseño que oculte las normas de reembolso y los procedimientos de cancelación, o que dificulte la rescisión del contrato, socava la confianza de los clientes y aumenta el riesgo de que se apliquen regulaciones contra los «patrones oscuros»."],"content_markdown":"## Resumen clave\n\nLa 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.\n\nTé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.\n\n| Área de decisión | Preguntas que hay que definir de antemano | Riesgos en caso de fallo |\n|---|---|---|\n| Estado del pedido | ¿Qué etapas sigue el pedido en orden cronológico? | Aparecen pedidos fantasma en los que se ha realizado el pago pero no existe el pedido |\n| Plazo de reembolso | ¿Cómo se reflejarán los plazos de desistimiento y tramitación de reembolsos? | Incumplimiento de los plazos legales, intereses de demora, riesgo de litigios |\n| Reembolso parcial | ¿Cómo se calcularán las devoluciones parciales de productos, los cupones y los gastos de envío? | Cálculo manual por parte del operador en cada caso, desconfianza de los clientes |\n| Doble pago | ¿Cómo se evitará que se registre un pago dos veces en el mismo pedido? | Quejas de los clientes basadas en el extracto de la tarjeta, pérdida de confianza |\n| Notificaciones de error | ¿Cómo se notificarán los casos de límite superado, saldo insuficiente o fallo en la autenticación? | Disminución de la tasa de conversiones por reintentos, aumento de consultas innecesarias |\n| Historial de pagos | ¿Dónde puede el cliente consultar el estado de sus pagos y reembolsos? | Aumento de las consultas al servicio de atención al cliente, falta de transparencia en el estado |\n| Aviso de reembolso | ¿Dónde se colocan las normas de reembolso y el botón de cancelación? | Polémica sobre los «patrones oscuros», riesgo de regulación |\n\n## 1. Diseño del estado de los pedidos: el estado es el lenguaje operativo\n\nAl 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.\n\n### Ejemplos de estados recomendados\n\n| Ejemplos de códigos de estado | Estado visible para el cliente | Significado |\n|---|---|---|\n| `payment_pending` | Pago pendiente | El pedido se ha creado, pero el pago no se ha completado |\n| `paid` | Pago completado | La autorización del pago se ha completado y el pedido es válido |\n| `payment_failed` | Pago fallido | El intento de pago ha fallado y hay que determinar si es posible volver a intentarlo |\n| `cancel_requested` | Solicitud de cancelación | El cliente ha solicitado la cancelación y está pendiente de tramitación |\n| `cancelled` | Cancelación completada | Se ha completado la cancelación del pedido antes del pago o la revocación de la autorización |\n| `refund_requested` | Solicitud de reembolso | Se ha recibido una solicitud de reembolso tras el pago |\n| `refund_processing` | Reembolso en curso | Se está tramitando la autorización del reembolso o la devolución al medio de pago |\n| `partially_refunded` | Reembolso parcial completado | Solo se ha reembolsado una parte del importe del pedido |\n| `refunded` | Reembolso completado | Se ha completado el reembolso |\n| `expired` | Pedido caducado | El pedido ha caducado al haber vencido el plazo de pago |\n\n### Principios de diseño de estados\n\n- 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.\n- 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.\n- 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.\n- 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.\n\n## 2. Desistimiento del contrato y plazo legal de reembolso: no se trata de una política, sino de un requisito legal\n\nSi 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.\n\nLos criterios especialmente importantes en la práctica son los siguientes:\n\n- 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.\n- 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.\n- 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.\n- 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.\n\n### Cómo convertirlo en requisitos de desarrollo\n\nNo basta con incluir los criterios legales únicamente en la redacción de las condiciones generales. También deben traducirse en requisitos del sistema.\n\n| Requisitos legales y normativos | Requisitos del sistema |\n|---|---|\n| Determinación de la posibilidad de desistimiento en un plazo de 7 días | Cálculo automático del plazo de reembolso a partir de la fecha de recepción del pedido o de prestación del servicio |\n| Necesidad de tramitar el reembolso en un plazo de 3 días hábiles | Visualización en el panel de administración de la fecha de solicitud de reembolso y la fecha límite de tramitación |\n| Riesgo de retraso en el reembolso | Visualización de notificaciones de plazo inminente o vencido |\n| Necesidad de notificar los productos excepcionales | Indicar claramente antes del pago que se trata de un producto con restricciones de reembolso y guardar el registro de consentimiento |\n| Necesidad de gestionar disputas | Conservar la versión de los términos y condiciones, la hora de la notificación, la hora del consentimiento, la IP del cliente o el registro de la cuenta |\n\n## 3. Normas de reembolso parcial: definir previamente los cupones, los gastos de envío y los impuestos\n\nLos 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.\n\n### Aspectos que hay que definir obligatoriamente\n\n- ¿Cómo se distribuirá el importe del pago por producto?\n- ¿Se distribuirá el cupón de todo el pedido de forma proporcional por producto?\n- ¿Se aplicará el cupón de un producto concreto únicamente a dicho producto?\n- ¿Se deducirán los gastos de envío si no se cumplen las condiciones de envío gratuito?\n- ¿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?\n- ¿En qué orden se reembolsarán los pagos realizados con puntos, saldo acumulado y tarjetas regalo?\n- ¿Cómo se modificarán los datos de la factura fiscal, el recibo de caja y el recibo tras un reembolso parcial?\n\n### Ejemplo de cálculo de un reembolso parcial\n\n| Concepto | Importe |\n|---|---:|\n| Producto A | 30 000 won |\n| Producto B | 70 000 won |\n| Cupón del pedido completo | -10 000 won |\n| Importe real pagado | 90 000 won |\n\nSi 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.\n\nNo 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.\n\n## 4. Prevención de pagos duplicados: no basta con desactivar el botón\n\nEl 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.\n\n### Causas\n\n- El cliente hace clic varias veces seguidas en el botón de pago.\n- Actualiza la página o pulsa «Atrás» inmediatamente después del pago.\n- Se reenvía la misma solicitud debido a un retraso en la red móvil.\n- La respuesta de autorización del pago se ha realizado con éxito, pero el almacenamiento en el servidor del servicio ha fallado.\n- El webhook y la redirección del cliente modifican simultáneamente el estado del pedido.\n\n### Diseño de medidas de protección\n\n| Mecanismo de protección | Descripción |\n|---|---|\n| Bloqueo del botón del cliente | Impide que se vuelva a hacer clic en el botón de pago tras el primer clic, pero se utiliza solo como medida complementaria |\n| Bloqueo de pedidos en el servidor | Se gestiona para que no se ejecuten simultáneamente solicitudes de autorización de pago para el mismo ID de pedido |\n| Clave de idempotencia | Se utiliza un identificador que garantiza que, aunque se envíe la misma solicitud de pago varias veces, el resultado solo se genere una vez |\n| Número de transacción único | Evita el almacenamiento duplicado del número de pedido y del número de transacción de pago mediante restricciones de la base de datos |\n| Validación basada en el estado | Impide que se envíen solicitudes de autorización adicionales a pedidos que ya estén en estado «paid» |\n| Procesamiento de duplicados de webhooks | Garantiza que, aunque se reciba el mismo evento de webhook varias veces, el cambio de estado solo se produzca una vez |\n\nAl 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».\n\n## 5. Mensaje de aviso de fallo en el pago: el fallo no es un incidente, sino parte del flujo normal\n\nLos 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.\n\nUn 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.\n\n### Ejemplos de mensajes de aviso\n\n| Situación | Mensaje recomendado |\n|---|---|\n| Saldo insuficiente | El pago no se ha completado porque el saldo del medio de pago es insuficiente. Selecciona otro medio de pago o comprueba el saldo y vuelve a intentarlo. |\n| Límite superado | El pago ha fallado porque se ha superado el límite de la tarjeta o el límite por transacción. Comprueba el límite en la aplicación de la entidad emisora de la tarjeta o realiza el pago con otra tarjeta. |\n| Fallo en la autenticación | La autenticación del pago no se ha completado, por lo que el pedido permanece en estado de espera de pago. Podrá volver a realizar el pago en un plazo de 30 minutos. |\n| Error de red | Se está produciendo un retraso en la confirmación del resultado del pago. Para evitar pagos duplicados, compruebe el historial de pagos más tarde. |\n| Pedido caducado | El tiempo de espera para el pago ha expirado y el pedido ha caducado. Vuelve a seleccionar los productos y realiza el pedido de nuevo. |\n\n### Elementos clave de los mensajes de error\n\n- Indica claramente si el pago no se ha completado realmente.\n- Informa del tiempo durante el que se mantiene el pedido.\n- Indica si se puede volver a intentar o si es necesario utilizar otro método de pago.\n- Muestra el número de pedido necesario para ponerse en contacto con el servicio de atención al cliente.\n- 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.\n\n## 6. Página de historial de pagos: la pantalla clave para reducir las consultas al servicio de atención al cliente\n\nSi 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.\n\n### Información que debe incluirse en la página de historial de pagos\n\n- Número de pedido\n- Fecha y hora del pedido y del pago\n- Nombre del producto, cantidad y opciones\n- Medio de pago y número de autorización o identificador de la transacción\n- Importe del producto, descuentos, gastos de envío, puntos utilizados e importe final a pagar\n- Estado actual del pedido y estado del reembolso\n- Fecha de solicitud del reembolso, fecha de aprobación del reembolso y fecha prevista de finalización del reembolso\n- Posibilidad de cancelación o reembolso\n- Enlaces para consultar el recibo, el desglose de la transacción y el recibo fiscal\n- Información necesaria para ponerse en contacto con el servicio de atención al cliente\n\n### Conexión con la pantalla del administrador\n\nLa 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.\n\n## 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\n\nNo 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.\n\n### Ubicaciones recomendadas para la notificación\n\n- Cerca del precio o del botón de compra en la página de detalles del producto\n- En la pantalla del carrito o del formulario de pedido\n- 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\n- En la página de pago completado\n- En la pantalla de detalles del pedido de «Mi cuenta»\n- En la pantalla de solicitud de reembolso\n\n### Diseños que deben evitarse\n\n- 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\n- Diseños en los que el botón de cancelación queda oculto tras varios pasos\n- Diseños en los que las condiciones de reembolso solo se muestran después de realizar el pago\n- 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\n- Diseños que no informan claramente de que se realizará un cobro automático una vez finalizado el periodo de prueba gratuito\n\nEste 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.\n\n## Lista de verificación que debe incluirse en la indicación para la IA\n\nAl 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.\n\n### Ejemplo de indicación para la función de pago\n\n```text\nImplementa la función de pago para un servicio de comercio electrónico dirigido a consumidores coreanos.\nDebes reflejar obligatoriamente las siguientes políticas:\n\n1. Utiliza los estados de pedido «payment_pending», «paid», «payment_failed», «cancel_requested», «cancelled», «refund_requested», «refund_processing», «partially_refunded», «refunded» y «expired».\n2. Los pedidos pendientes de pago se cambiarán a «expired» tras 30 minutos.\n3. Solo se permite una autorización de pago por pedido; utiliza el bloqueo de pedidos a nivel de servidor y una clave de idempotencia.\n4. Dado que los webhooks de pago pueden recibirse por duplicado, cada ID de evento solo se procesará una vez.\n5. 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.\n6. 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.\n7. En caso de fallo en el pago, se devuelve un mensaje de aviso al cliente en función del motivo del fallo.\n8. Permite que el cliente pueda consultar el historial de pagos y el estado de los reembolsos en «Mi cuenta».\n9. 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.\n10. Si hay alguna política que no esté definida, consulta primero antes de escribir el código.\n```\n\nLa ú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.\n\n## Funciones necesarias en la pantalla del administrador\n\nLa 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.\n\n| Funciones de administrador | Motivo por el que son necesarias |\n|---|---|\n| Lista de reembolsos pendientes | Necesaria para no pasar por alto ningún reembolso que deba tramitarse |\n| Indicación de los plazos legales de tramitación | Necesario para reducir el riesgo de retrasos en los reembolsos |\n| Avisos de plazos inminentes o vencidos | Necesario para que el operador se percate inmediatamente de criterios internos como los 3 días hábiles |\n| Selección del motivo del reembolso | Necesario para las estadísticas y la distribución de costes (cambio de opinión, defecto del producto, envío erróneo, etc.) |\n| Vista previa del cálculo de reembolsos parciales | Necesario para reducir los errores de cálculo manual del operador |\n| Registro de tramitación | Necesario para gestionar disputas y auditorías |\n| Gestión de permisos | Necesario para restringir la aprobación de reembolsos y los cambios forzados de estado |\n\n## Configuración mínima del modelo de datos de pagos\n\nAunque la estructura de datos varía según el servicio, se recomienda separar, como mínimo, los datos que se indican a continuación.\n\n| Tabla u objeto | Campos clave |\n|---|---|\n| Pedido | ID del pedido, ID del cliente, estado del pedido, importe del pedido, importe del descuento, gastos de envío, fecha y hora de creación, fecha y hora de vencimiento |\n| Productos del pedido | ID del producto, nombre del producto, opciones, cantidad, importe por producto, importe del descuento por producto |\n| Pago | ID del pago, ID del pedido, método de pago, número de autorización, importe autorizado, estado del pago, fecha y hora de autorización |\n| Reembolso | ID del reembolso, ID del pedido, importe del reembolso, motivo del reembolso, estado del reembolso, fecha y hora de solicitud, fecha y hora de finalización |\n| Historial de estados | ID del objeto, estado anterior, nuevo estado, autor de la modificación, motivo de la modificación, fecha y hora de la modificación |\n| Aceptación de las condiciones | Tipo de condiciones, versión de las condiciones, aceptación, fecha y hora de la aceptación, ID del cliente |\n\nEs 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.\n\n## Lista de comprobación previa al lanzamiento\n\n- ¿Si se pulsa el botón de pago 10 veces para un mismo pedido, solo se aprueba el pago una vez?\n- Si falla el almacenamiento en el servidor tras la aprobación del pago, ¿se puede recuperar?\n- ¿El webhook de pago no procesa los eventos de forma duplicada aunque se envíen varias veces?\n- ¿El cliente puede comprender el motivo del fallo en el pago y cómo volver a intentarlo?\n- ¿Los pedidos pendientes de pago caducan automáticamente tras un tiempo determinado?\n- ¿El importe del reembolso parcial se ajusta a la política de cupones, puntos y gastos de envío?\n- ¿Se muestra en el panel de administración desde la fecha de solicitud del reembolso hasta la fecha límite de tramitación?\n- ¿Se pueden consultar fácilmente las normas de reembolso en la pantalla previa al pago?\n- ¿Existen avisos previos y registros de consentimiento para los contenidos digitales o los productos con restricciones de reembolso?\n- ¿Puede el cliente consultar directamente el historial de pagos y el estado de los reembolsos en «Mi cuenta»?\n\n## Conclusión\n\nLa 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.\n\nSi 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».","content_html":"\u003ch2\u003e\n\u003ca href=\"#resumen-clave\" class=\"anchor\" id=\"resumen-clave\"\u003e\u003c/a\u003eResumen clave\u003c/h2\u003e\n\u003cp\u003eLa 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.\u003c/p\u003e\n\u003cp\u003eTé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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eÁrea de decisión\u003c/th\u003e\n\u003cth\u003ePreguntas que hay que definir de antemano\u003c/th\u003e\n\u003cth\u003eRiesgos en caso de fallo\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisión\"\u003eEstado del pedido\u003c/td\u003e\n\u003ctd data-label=\"Preguntas que hay que definir de antemano\"\u003e¿Qué etapas sigue el pedido en orden cronológico?\u003c/td\u003e\n\u003ctd data-label=\"Riesgos en caso de fallo\"\u003eAparecen pedidos fantasma en los que se ha realizado el pago pero no existe el pedido\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisión\"\u003ePlazo de reembolso\u003c/td\u003e\n\u003ctd data-label=\"Preguntas que hay que definir de antemano\"\u003e¿Cómo se reflejarán los plazos de desistimiento y tramitación de reembolsos?\u003c/td\u003e\n\u003ctd data-label=\"Riesgos en caso de fallo\"\u003eIncumplimiento de los plazos legales, intereses de demora, riesgo de litigios\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisión\"\u003eReembolso parcial\u003c/td\u003e\n\u003ctd data-label=\"Preguntas que hay que definir de antemano\"\u003e¿Cómo se calcularán las devoluciones parciales de productos, los cupones y los gastos de envío?\u003c/td\u003e\n\u003ctd data-label=\"Riesgos en caso de fallo\"\u003eCálculo manual por parte del operador en cada caso, desconfianza de los clientes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisión\"\u003eDoble pago\u003c/td\u003e\n\u003ctd data-label=\"Preguntas que hay que definir de antemano\"\u003e¿Cómo se evitará que se registre un pago dos veces en el mismo pedido?\u003c/td\u003e\n\u003ctd data-label=\"Riesgos en caso de fallo\"\u003eQuejas de los clientes basadas en el extracto de la tarjeta, pérdida de confianza\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisión\"\u003eNotificaciones de error\u003c/td\u003e\n\u003ctd data-label=\"Preguntas que hay que definir de antemano\"\u003e¿Cómo se notificarán los casos de límite superado, saldo insuficiente o fallo en la autenticación?\u003c/td\u003e\n\u003ctd data-label=\"Riesgos en caso de fallo\"\u003eDisminución de la tasa de conversiones por reintentos, aumento de consultas innecesarias\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisión\"\u003eHistorial de pagos\u003c/td\u003e\n\u003ctd data-label=\"Preguntas que hay que definir de antemano\"\u003e¿Dónde puede el cliente consultar el estado de sus pagos y reembolsos?\u003c/td\u003e\n\u003ctd data-label=\"Riesgos en caso de fallo\"\u003eAumento de las consultas al servicio de atención al cliente, falta de transparencia en el estado\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisión\"\u003eAviso de reembolso\u003c/td\u003e\n\u003ctd data-label=\"Preguntas que hay que definir de antemano\"\u003e¿Dónde se colocan las normas de reembolso y el botón de cancelación?\u003c/td\u003e\n\u003ctd data-label=\"Riesgos en caso de fallo\"\u003ePolémica sobre los «patrones oscuros», riesgo de regulación\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#1-dise%C3%B1o-del-estado-de-los-pedidos-el-estado-es-el-lenguaje-operativo\" class=\"anchor\" id=\"1-diseño-del-estado-de-los-pedidos-el-estado-es-el-lenguaje-operativo\"\u003e\u003c/a\u003e1. Diseño del estado de los pedidos: el estado es el lenguaje operativo\u003c/h2\u003e\n\u003cp\u003eAl 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#ejemplos-de-estados-recomendados\" class=\"anchor\" id=\"ejemplos-de-estados-recomendados\"\u003e\u003c/a\u003eEjemplos de estados recomendados\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEjemplos de códigos de estado\u003c/th\u003e\n\u003cth\u003eEstado visible para el cliente\u003c/th\u003e\n\u003cth\u003eSignificado\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003epayment_pending\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003ePago pendiente\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eEl pedido se ha creado, pero el pago no se ha completado\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003epaid\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003ePago completado\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eLa autorización del pago se ha completado y el pedido es válido\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003epayment_failed\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003ePago fallido\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eEl intento de pago ha fallado y hay que determinar si es posible volver a intentarlo\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003ecancel_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003eSolicitud de cancelación\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eEl cliente ha solicitado la cancelación y está pendiente de tramitación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003ecancelled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003eCancelación completada\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eSe ha completado la cancelación del pedido antes del pago o la revocación de la autorización\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003erefund_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003eSolicitud de reembolso\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eSe ha recibido una solicitud de reembolso tras el pago\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003erefund_processing\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003eReembolso en curso\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eSe está tramitando la autorización del reembolso o la devolución al medio de pago\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003epartially_refunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003eReembolso parcial completado\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eSolo se ha reembolsado una parte del importe del pedido\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003erefunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003eReembolso completado\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eSe ha completado el reembolso\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Ejemplos de códigos de estado\"\u003e\u003ccode\u003eexpired\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Estado visible para el cliente\"\u003ePedido caducado\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eEl pedido ha caducado al haber vencido el plazo de pago\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#principios-de-dise%C3%B1o-de-estados\" class=\"anchor\" id=\"principios-de-diseño-de-estados\"\u003e\u003c/a\u003ePrincipios de diseño de estados\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eNo 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.\u003c/li\u003e\n\u003cli\u003eCada 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.\u003c/li\u003e\n\u003cli\u003eLas 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.\u003c/li\u003e\n\u003cli\u003eLas 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.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-desistimiento-del-contrato-y-plazo-legal-de-reembolso-no-se-trata-de-una-pol%C3%ADtica-sino-de-un-requisito-legal\" class=\"anchor\" id=\"2-desistimiento-del-contrato-y-plazo-legal-de-reembolso-no-se-trata-de-una-política-sino-de-un-requisito-legal\"\u003e\u003c/a\u003e2. Desistimiento del contrato y plazo legal de reembolso: no se trata de una política, sino de un requisito legal\u003c/h2\u003e\n\u003cp\u003eSi 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.\u003c/p\u003e\n\u003cp\u003eLos criterios especialmente importantes en la práctica son los siguientes:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEn 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.\u003c/li\u003e\n\u003cli\u003eEl 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.\u003c/li\u003e\n\u003cli\u003ePueden 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.\u003c/li\u003e\n\u003cli\u003eLa 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.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#c%C3%B3mo-convertirlo-en-requisitos-de-desarrollo\" class=\"anchor\" id=\"cómo-convertirlo-en-requisitos-de-desarrollo\"\u003e\u003c/a\u003eCómo convertirlo en requisitos de desarrollo\u003c/h3\u003e\n\u003cp\u003eNo basta con incluir los criterios legales únicamente en la redacción de las condiciones generales. También deben traducirse en requisitos del sistema.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eRequisitos legales y normativos\u003c/th\u003e\n\u003cth\u003eRequisitos del sistema\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Requisitos legales y normativos\"\u003eDeterminación de la posibilidad de desistimiento en un plazo de 7 días\u003c/td\u003e\n\u003ctd data-label=\"Requisitos del sistema\"\u003eCálculo automático del plazo de reembolso a partir de la fecha de recepción del pedido o de prestación del servicio\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Requisitos legales y normativos\"\u003eNecesidad de tramitar el reembolso en un plazo de 3 días hábiles\u003c/td\u003e\n\u003ctd data-label=\"Requisitos del sistema\"\u003eVisualización en el panel de administración de la fecha de solicitud de reembolso y la fecha límite de tramitación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Requisitos legales y normativos\"\u003eRiesgo de retraso en el reembolso\u003c/td\u003e\n\u003ctd data-label=\"Requisitos del sistema\"\u003eVisualización de notificaciones de plazo inminente o vencido\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Requisitos legales y normativos\"\u003eNecesidad de notificar los productos excepcionales\u003c/td\u003e\n\u003ctd data-label=\"Requisitos del sistema\"\u003eIndicar claramente antes del pago que se trata de un producto con restricciones de reembolso y guardar el registro de consentimiento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Requisitos legales y normativos\"\u003eNecesidad de gestionar disputas\u003c/td\u003e\n\u003ctd data-label=\"Requisitos del sistema\"\u003eConservar la versión de los términos y condiciones, la hora de la notificación, la hora del consentimiento, la IP del cliente o el registro de la cuenta\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#3-normas-de-reembolso-parcial-definir-previamente-los-cupones-los-gastos-de-env%C3%ADo-y-los-impuestos\" class=\"anchor\" id=\"3-normas-de-reembolso-parcial-definir-previamente-los-cupones-los-gastos-de-envío-y-los-impuestos\"\u003e\u003c/a\u003e3. Normas de reembolso parcial: definir previamente los cupones, los gastos de envío y los impuestos\u003c/h2\u003e\n\u003cp\u003eLos 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#aspectos-que-hay-que-definir-obligatoriamente\" class=\"anchor\" id=\"aspectos-que-hay-que-definir-obligatoriamente\"\u003e\u003c/a\u003eAspectos que hay que definir obligatoriamente\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e¿Cómo se distribuirá el importe del pago por producto?\u003c/li\u003e\n\u003cli\u003e¿Se distribuirá el cupón de todo el pedido de forma proporcional por producto?\u003c/li\u003e\n\u003cli\u003e¿Se aplicará el cupón de un producto concreto únicamente a dicho producto?\u003c/li\u003e\n\u003cli\u003e¿Se deducirán los gastos de envío si no se cumplen las condiciones de envío gratuito?\u003c/li\u003e\n\u003cli\u003e¿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?\u003c/li\u003e\n\u003cli\u003e¿En qué orden se reembolsarán los pagos realizados con puntos, saldo acumulado y tarjetas regalo?\u003c/li\u003e\n\u003cli\u003e¿Cómo se modificarán los datos de la factura fiscal, el recibo de caja y el recibo tras un reembolso parcial?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#ejemplo-de-c%C3%A1lculo-de-un-reembolso-parcial\" class=\"anchor\" id=\"ejemplo-de-cálculo-de-un-reembolso-parcial\"\u003e\u003c/a\u003eEjemplo de cálculo de un reembolso parcial\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eConcepto\u003c/th\u003e\n\u003cth\u003eImporte\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Concepto\"\u003eProducto A\u003c/td\u003e\n\u003ctd data-label=\"Importe\"\u003e30 000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Concepto\"\u003eProducto B\u003c/td\u003e\n\u003ctd data-label=\"Importe\"\u003e70 000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Concepto\"\u003eCupón del pedido completo\u003c/td\u003e\n\u003ctd data-label=\"Importe\"\u003e-10 000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Concepto\"\u003eImporte real pagado\u003c/td\u003e\n\u003ctd data-label=\"Importe\"\u003e90 000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eSi 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.\u003c/p\u003e\n\u003cp\u003eNo 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-prevenci%C3%B3n-de-pagos-duplicados-no-basta-con-desactivar-el-bot%C3%B3n\" class=\"anchor\" id=\"4-prevención-de-pagos-duplicados-no-basta-con-desactivar-el-botón\"\u003e\u003c/a\u003e4. Prevención de pagos duplicados: no basta con desactivar el botón\u003c/h2\u003e\n\u003cp\u003eEl 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#causas\" class=\"anchor\" id=\"causas\"\u003e\u003c/a\u003eCausas\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eEl cliente hace clic varias veces seguidas en el botón de pago.\u003c/li\u003e\n\u003cli\u003eActualiza la página o pulsa «Atrás» inmediatamente después del pago.\u003c/li\u003e\n\u003cli\u003eSe reenvía la misma solicitud debido a un retraso en la red móvil.\u003c/li\u003e\n\u003cli\u003eLa respuesta de autorización del pago se ha realizado con éxito, pero el almacenamiento en el servidor del servicio ha fallado.\u003c/li\u003e\n\u003cli\u003eEl webhook y la redirección del cliente modifican simultáneamente el estado del pedido.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#dise%C3%B1o-de-medidas-de-protecci%C3%B3n\" class=\"anchor\" id=\"diseño-de-medidas-de-protección\"\u003e\u003c/a\u003eDiseño de medidas de protección\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMecanismo de protección\u003c/th\u003e\n\u003cth\u003eDescripción\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de protección\"\u003eBloqueo del botón del cliente\u003c/td\u003e\n\u003ctd data-label=\"Descripción\"\u003eImpide que se vuelva a hacer clic en el botón de pago tras el primer clic, pero se utiliza solo como medida complementaria\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de protección\"\u003eBloqueo de pedidos en el servidor\u003c/td\u003e\n\u003ctd data-label=\"Descripción\"\u003eSe gestiona para que no se ejecuten simultáneamente solicitudes de autorización de pago para el mismo ID de pedido\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de protección\"\u003eClave de idempotencia\u003c/td\u003e\n\u003ctd data-label=\"Descripción\"\u003eSe utiliza un identificador que garantiza que, aunque se envíe la misma solicitud de pago varias veces, el resultado solo se genere una vez\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de protección\"\u003eNúmero de transacción único\u003c/td\u003e\n\u003ctd data-label=\"Descripción\"\u003eEvita el almacenamiento duplicado del número de pedido y del número de transacción de pago mediante restricciones de la base de datos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de protección\"\u003eValidación basada en el estado\u003c/td\u003e\n\u003ctd data-label=\"Descripción\"\u003eImpide que se envíen solicitudes de autorización adicionales a pedidos que ya estén en estado «paid»\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de protección\"\u003eProcesamiento de duplicados de webhooks\u003c/td\u003e\n\u003ctd data-label=\"Descripción\"\u003eGarantiza que, aunque se reciba el mismo evento de webhook varias veces, el cambio de estado solo se produzca una vez\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAl 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».\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-mensaje-de-aviso-de-fallo-en-el-pago-el-fallo-no-es-un-incidente-sino-parte-del-flujo-normal\" class=\"anchor\" id=\"5-mensaje-de-aviso-de-fallo-en-el-pago-el-fallo-no-es-un-incidente-sino-parte-del-flujo-normal\"\u003e\u003c/a\u003e5. Mensaje de aviso de fallo en el pago: el fallo no es un incidente, sino parte del flujo normal\u003c/h2\u003e\n\u003cp\u003eLos 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.\u003c/p\u003e\n\u003cp\u003eUn 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#ejemplos-de-mensajes-de-aviso\" class=\"anchor\" id=\"ejemplos-de-mensajes-de-aviso\"\u003e\u003c/a\u003eEjemplos de mensajes de aviso\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituación\u003c/th\u003e\n\u003cth\u003eMensaje recomendado\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situación\"\u003eSaldo insuficiente\u003c/td\u003e\n\u003ctd data-label=\"Mensaje recomendado\"\u003eEl pago no se ha completado porque el saldo del medio de pago es insuficiente. Selecciona otro medio de pago o comprueba el saldo y vuelve a intentarlo.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situación\"\u003eLímite superado\u003c/td\u003e\n\u003ctd data-label=\"Mensaje recomendado\"\u003eEl pago ha fallado porque se ha superado el límite de la tarjeta o el límite por transacción. Comprueba el límite en la aplicación de la entidad emisora de la tarjeta o realiza el pago con otra tarjeta.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situación\"\u003eFallo en la autenticación\u003c/td\u003e\n\u003ctd data-label=\"Mensaje recomendado\"\u003eLa autenticación del pago no se ha completado, por lo que el pedido permanece en estado de espera de pago. Podrá volver a realizar el pago en un plazo de 30 minutos.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situación\"\u003eError de red\u003c/td\u003e\n\u003ctd data-label=\"Mensaje recomendado\"\u003eSe está produciendo un retraso en la confirmación del resultado del pago. Para evitar pagos duplicados, compruebe el historial de pagos más tarde.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situación\"\u003ePedido caducado\u003c/td\u003e\n\u003ctd data-label=\"Mensaje recomendado\"\u003eEl tiempo de espera para el pago ha expirado y el pedido ha caducado. Vuelve a seleccionar los productos y realiza el pedido de nuevo.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#elementos-clave-de-los-mensajes-de-error\" class=\"anchor\" id=\"elementos-clave-de-los-mensajes-de-error\"\u003e\u003c/a\u003eElementos clave de los mensajes de error\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIndica claramente si el pago no se ha completado realmente.\u003c/li\u003e\n\u003cli\u003eInforma del tiempo durante el que se mantiene el pedido.\u003c/li\u003e\n\u003cli\u003eIndica si se puede volver a intentar o si es necesario utilizar otro método de pago.\u003c/li\u003e\n\u003cli\u003eMuestra el número de pedido necesario para ponerse en contacto con el servicio de atención al cliente.\u003c/li\u003e\n\u003cli\u003eSi el resultado del pago es incierto, no se debe instar a realizar un nuevo pago de forma incondicional, sino indicar que se está comprobando.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-p%C3%A1gina-de-historial-de-pagos-la-pantalla-clave-para-reducir-las-consultas-al-servicio-de-atenci%C3%B3n-al-cliente\" class=\"anchor\" id=\"6-página-de-historial-de-pagos-la-pantalla-clave-para-reducir-las-consultas-al-servicio-de-atención-al-cliente\"\u003e\u003c/a\u003e6. Página de historial de pagos: la pantalla clave para reducir las consultas al servicio de atención al cliente\u003c/h2\u003e\n\u003cp\u003eSi 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#informaci%C3%B3n-que-debe-incluirse-en-la-p%C3%A1gina-de-historial-de-pagos\" class=\"anchor\" id=\"información-que-debe-incluirse-en-la-página-de-historial-de-pagos\"\u003e\u003c/a\u003eInformación que debe incluirse en la página de historial de pagos\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eNúmero de pedido\u003c/li\u003e\n\u003cli\u003eFecha y hora del pedido y del pago\u003c/li\u003e\n\u003cli\u003eNombre del producto, cantidad y opciones\u003c/li\u003e\n\u003cli\u003eMedio de pago y número de autorización o identificador de la transacción\u003c/li\u003e\n\u003cli\u003eImporte del producto, descuentos, gastos de envío, puntos utilizados e importe final a pagar\u003c/li\u003e\n\u003cli\u003eEstado actual del pedido y estado del reembolso\u003c/li\u003e\n\u003cli\u003eFecha de solicitud del reembolso, fecha de aprobación del reembolso y fecha prevista de finalización del reembolso\u003c/li\u003e\n\u003cli\u003ePosibilidad de cancelación o reembolso\u003c/li\u003e\n\u003cli\u003eEnlaces para consultar el recibo, el desglose de la transacción y el recibo fiscal\u003c/li\u003e\n\u003cli\u003eInformación necesaria para ponerse en contacto con el servicio de atención al cliente\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#conexi%C3%B3n-con-la-pantalla-del-administrador\" class=\"anchor\" id=\"conexión-con-la-pantalla-del-administrador\"\u003e\u003c/a\u003eConexión con la pantalla del administrador\u003c/h3\u003e\n\u003cp\u003eLa 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-ubicaci%C3%B3n-de-la-notificaci%C3%B3n-de-la-pol%C3%ADtica-de-reembolsos-si-se-oculta-deja-de-ser-una-pol%C3%ADtica-y-se-convierte-en-un-riesgo\" class=\"anchor\" id=\"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\"\u003e\u003c/a\u003e7. 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\u003c/h2\u003e\n\u003cp\u003eNo 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#ubicaciones-recomendadas-para-la-notificaci%C3%B3n\" class=\"anchor\" id=\"ubicaciones-recomendadas-para-la-notificación\"\u003e\u003c/a\u003eUbicaciones recomendadas para la notificación\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eCerca del precio o del botón de compra en la página de detalles del producto\u003c/li\u003e\n\u003cli\u003eEn la pantalla del carrito o del formulario de pedido\u003c/li\u003e\n\u003cli\u003eEn la zona de aceptación de los términos y condiciones y la política de reembolso, justo encima del botón de pago\u003c/li\u003e\n\u003cli\u003eEn la página de pago completado\u003c/li\u003e\n\u003cli\u003eEn la pantalla de detalles del pedido de «Mi cuenta»\u003c/li\u003e\n\u003cli\u003eEn la pantalla de solicitud de reembolso\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#dise%C3%B1os-que-deben-evitarse\" class=\"anchor\" id=\"diseños-que-deben-evitarse\"\u003e\u003c/a\u003eDiseños que deben evitarse\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDiseñ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\u003c/li\u003e\n\u003cli\u003eDiseños en los que el botón de cancelación queda oculto tras varios pasos\u003c/li\u003e\n\u003cli\u003eDiseños en los que las condiciones de reembolso solo se muestran después de realizar el pago\u003c/li\u003e\n\u003cli\u003eDiseñ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\u003c/li\u003e\n\u003cli\u003eDiseños que no informan claramente de que se realizará un cobro automático una vez finalizado el periodo de prueba gratuito\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEste 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#lista-de-verificaci%C3%B3n-que-debe-incluirse-en-la-indicaci%C3%B3n-para-la-ia\" class=\"anchor\" id=\"lista-de-verificación-que-debe-incluirse-en-la-indicación-para-la-ia\"\u003e\u003c/a\u003eLista de verificación que debe incluirse en la indicación para la IA\u003c/h2\u003e\n\u003cp\u003eAl 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#ejemplo-de-indicaci%C3%B3n-para-la-funci%C3%B3n-de-pago\" class=\"anchor\" id=\"ejemplo-de-indicación-para-la-función-de-pago\"\u003e\u003c/a\u003eEjemplo de indicación para la función de pago\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eImplementa la función de pago para un servicio de comercio electrónico dirigido a consumidores coreanos.\n\u003c/span\u003e\u003cspan\u003eDebes reflejar obligatoriamente las siguientes políticas:\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Utiliza los estados de pedido «payment_pending», «paid», «payment_failed», «cancel_requested», «cancelled», «refund_requested», «refund_processing», «partially_refunded», «refunded» y «expired».\n\u003c/span\u003e\u003cspan\u003e2. Los pedidos pendientes de pago se cambiarán a «expired» tras 30 minutos.\n\u003c/span\u003e\u003cspan\u003e3. Solo se permite una autorización de pago por pedido; utiliza el bloqueo de pedidos a nivel de servidor y una clave de idempotencia.\n\u003c/span\u003e\u003cspan\u003e4. Dado que los webhooks de pago pueden recibirse por duplicado, cada ID de evento solo se procesará una vez.\n\u003c/span\u003e\u003cspan\u003e5. 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.\n\u003c/span\u003e\u003cspan\u003e6. 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.\n\u003c/span\u003e\u003cspan\u003e7. En caso de fallo en el pago, se devuelve un mensaje de aviso al cliente en función del motivo del fallo.\n\u003c/span\u003e\u003cspan\u003e8. Permite que el cliente pueda consultar el historial de pagos y el estado de los reembolsos en «Mi cuenta».\n\u003c/span\u003e\u003cspan\u003e9. 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.\n\u003c/span\u003e\u003cspan\u003e10. Si hay alguna política que no esté definida, consulta primero antes de escribir el código.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLa ú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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#funciones-necesarias-en-la-pantalla-del-administrador\" class=\"anchor\" id=\"funciones-necesarias-en-la-pantalla-del-administrador\"\u003e\u003c/a\u003eFunciones necesarias en la pantalla del administrador\u003c/h2\u003e\n\u003cp\u003eLa 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eFunciones de administrador\u003c/th\u003e\n\u003cth\u003eMotivo por el que son necesarias\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Funciones de administrador\"\u003eLista de reembolsos pendientes\u003c/td\u003e\n\u003ctd data-label=\"Motivo por el que son necesarias\"\u003eNecesaria para no pasar por alto ningún reembolso que deba tramitarse\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Funciones de administrador\"\u003eIndicación de los plazos legales de tramitación\u003c/td\u003e\n\u003ctd data-label=\"Motivo por el que son necesarias\"\u003eNecesario para reducir el riesgo de retrasos en los reembolsos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Funciones de administrador\"\u003eAvisos de plazos inminentes o vencidos\u003c/td\u003e\n\u003ctd data-label=\"Motivo por el que son necesarias\"\u003eNecesario para que el operador se percate inmediatamente de criterios internos como los 3 días hábiles\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Funciones de administrador\"\u003eSelección del motivo del reembolso\u003c/td\u003e\n\u003ctd data-label=\"Motivo por el que son necesarias\"\u003eNecesario para las estadísticas y la distribución de costes (cambio de opinión, defecto del producto, envío erróneo, etc.)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Funciones de administrador\"\u003eVista previa del cálculo de reembolsos parciales\u003c/td\u003e\n\u003ctd data-label=\"Motivo por el que son necesarias\"\u003eNecesario para reducir los errores de cálculo manual del operador\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Funciones de administrador\"\u003eRegistro de tramitación\u003c/td\u003e\n\u003ctd data-label=\"Motivo por el que son necesarias\"\u003eNecesario para gestionar disputas y auditorías\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Funciones de administrador\"\u003eGestión de permisos\u003c/td\u003e\n\u003ctd data-label=\"Motivo por el que son necesarias\"\u003eNecesario para restringir la aprobación de reembolsos y los cambios forzados de estado\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#configuraci%C3%B3n-m%C3%ADnima-del-modelo-de-datos-de-pagos\" class=\"anchor\" id=\"configuración-mínima-del-modelo-de-datos-de-pagos\"\u003e\u003c/a\u003eConfiguración mínima del modelo de datos de pagos\u003c/h2\u003e\n\u003cp\u003eAunque la estructura de datos varía según el servicio, se recomienda separar, como mínimo, los datos que se indican a continuación.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTabla u objeto\u003c/th\u003e\n\u003cth\u003eCampos clave\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabla u objeto\"\u003ePedido\u003c/td\u003e\n\u003ctd data-label=\"Campos clave\"\u003eID del pedido, ID del cliente, estado del pedido, importe del pedido, importe del descuento, gastos de envío, fecha y hora de creación, fecha y hora de vencimiento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabla u objeto\"\u003eProductos del pedido\u003c/td\u003e\n\u003ctd data-label=\"Campos clave\"\u003eID del producto, nombre del producto, opciones, cantidad, importe por producto, importe del descuento por producto\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabla u objeto\"\u003ePago\u003c/td\u003e\n\u003ctd data-label=\"Campos clave\"\u003eID del pago, ID del pedido, método de pago, número de autorización, importe autorizado, estado del pago, fecha y hora de autorización\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabla u objeto\"\u003eReembolso\u003c/td\u003e\n\u003ctd data-label=\"Campos clave\"\u003eID del reembolso, ID del pedido, importe del reembolso, motivo del reembolso, estado del reembolso, fecha y hora de solicitud, fecha y hora de finalización\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabla u objeto\"\u003eHistorial de estados\u003c/td\u003e\n\u003ctd data-label=\"Campos clave\"\u003eID del objeto, estado anterior, nuevo estado, autor de la modificación, motivo de la modificación, fecha y hora de la modificación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabla u objeto\"\u003eAceptación de las condiciones\u003c/td\u003e\n\u003ctd data-label=\"Campos clave\"\u003eTipo de condiciones, versión de las condiciones, aceptación, fecha y hora de la aceptación, ID del cliente\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEs 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#lista-de-comprobaci%C3%B3n-previa-al-lanzamiento\" class=\"anchor\" id=\"lista-de-comprobación-previa-al-lanzamiento\"\u003e\u003c/a\u003eLista de comprobación previa al lanzamiento\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e¿Si se pulsa el botón de pago 10 veces para un mismo pedido, solo se aprueba el pago una vez?\u003c/li\u003e\n\u003cli\u003eSi falla el almacenamiento en el servidor tras la aprobación del pago, ¿se puede recuperar?\u003c/li\u003e\n\u003cli\u003e¿El webhook de pago no procesa los eventos de forma duplicada aunque se envíen varias veces?\u003c/li\u003e\n\u003cli\u003e¿El cliente puede comprender el motivo del fallo en el pago y cómo volver a intentarlo?\u003c/li\u003e\n\u003cli\u003e¿Los pedidos pendientes de pago caducan automáticamente tras un tiempo determinado?\u003c/li\u003e\n\u003cli\u003e¿El importe del reembolso parcial se ajusta a la política de cupones, puntos y gastos de envío?\u003c/li\u003e\n\u003cli\u003e¿Se muestra en el panel de administración desde la fecha de solicitud del reembolso hasta la fecha límite de tramitación?\u003c/li\u003e\n\u003cli\u003e¿Se pueden consultar fácilmente las normas de reembolso en la pantalla previa al pago?\u003c/li\u003e\n\u003cli\u003e¿Existen avisos previos y registros de consentimiento para los contenidos digitales o los productos con restricciones de reembolso?\u003c/li\u003e\n\u003cli\u003e¿Puede el cliente consultar directamente el historial de pagos y el estado de los reembolsos en «Mi cuenta»?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclusi%C3%B3n\" class=\"anchor\" id=\"conclusión\"\u003e\u003c/a\u003eConclusión\u003c/h2\u003e\n\u003cp\u003eLa 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.\u003c/p\u003e\n\u003cp\u003eSi 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».\u003c/p\u003e\n","tags":["Desarrollo de IA","Sistema de pago","Política de reembolso","Ley de comercio electrónico","Patrones oscuros"],"faqs":[{"question":"¿Qué es lo primero que hay que decidir cuando se le pide a la IA que cree una función de pago?","answer":"Lo primero que hay que hacer es definir el flujo de los estados de los pedidos y de los pagos. Es necesario definir estados como «Pago pendiente», «Pago completado», «Pago fallido», «Solicitud de cancelación», «Reembolso en trámite» y «Reembolso completado» para que la IA pueda crear una estructura de datos y un flujo de pantallas seguros."},{"question":"¿Por qué es peligroso limitar el estado de un pedido únicamente a «pedido completado»?","answer":"Esto se debe a que en los pagos reales se producen muchas situaciones excepcionales, como fallos, cancelaciones, reembolsos o caducidades. Si el estado es demasiado simple, pueden surgir problemas como que el pago se haya realizado pero no aparezca en el historial de pedidos, o que el reembolso se haya completado pero en la pantalla del cliente siga apareciendo como «pago completado»."},{"question":"¿Se aplica siempre la norma de los 7 días para el desistimiento en el comercio electrónico de Corea?","answer":"Por lo general, el consumidor puede desistir de la contratación en un plazo de 7 días a partir de la fecha establecida por la ley. No obstante, pueden existir excepciones en el caso de contenidos digitales, productos fabricados a medida o productos cuyo valor se reduzca con el uso, por lo que es necesario analizarlos individualmente, teniendo en cuenta los requisitos de notificación previa y consentimiento."},{"question":"¿Hasta cuándo hay que tramitar el reembolso?","answer":"En el comercio electrónico de Corea, los comerciantes deben reembolsar el importe dentro del plazo legal una vez que se haya producido el motivo del reembolso; en la práctica, es recomendable reflejar el plazo de tres días hábiles en la pantalla de administración y en las notificaciones. Dado que los retrasos pueden dar lugar a indemnizaciones por demora, es aconsejable disponer de una función de aviso automático."},{"question":"¿Cuáles son los conceptos que suelen plantear más problemas en los reembolsos parciales?","answer":"A menudo surgen problemas con los cupones aplicados al pedido completo, las condiciones de envío gratuito, los gastos de envío de las devoluciones, el importe de los puntos utilizados y el reparto de los descuentos por producto. Para evitar que el administrador tenga que tomar una decisión cada vez que se reciba una solicitud de reembolso, es necesario establecer de antemano unas normas, como el importe real pagado por cada producto o un método de reparto proporcional."},{"question":"¿Se puede evitar el doble pago simplemente desactivando un botón en la interfaz de usuario?","answer":"Desactivar los botones ayuda, pero no es suficiente. Dado que pueden producirse reintentos de conexión, actualizaciones o la recepción duplicada de webhooks, es necesario combinar esta medida con el bloqueo de pedidos en el servidor, claves de idempotencia, restricciones de números de transacción únicos y la validación basada en el estado."},{"question":"¿Qué debe incluir el mensaje de aviso de fallo en el pago?","answer":"Debe indicarse si el pago no se ha completado, cuál es el motivo del error, si se puede volver a intentarlo, cuánto tiempo se mantiene el pedido y cuál es el número de pedido necesario para realizar consultas. Si solo se muestra un mensaje indicando que se ha producido un error, aumentarán las bajas de clientes y las consultas."},{"question":"¿Por qué es imprescindible la página de historial de pagos?","answer":"Esto se debe a que los clientes deben poder comprobar por sí mismos cuándo y qué importe han pagado, así como en qué fase se encuentra el proceso de reembolso. Si no existe una página de historial de pagos, todas las solicitudes de confirmación se concentrarán en el servicio de atención al cliente, y los clientes pueden tener la sensación de que el servicio no gestiona adecuadamente el flujo de dinero."},{"question":"¿Es suficiente con que la política de devoluciones figure únicamente en la página de condiciones generales?","answer":"No es suficiente. El cliente debe poder consultar fácilmente el plazo de devolución y las condiciones de la misma cerca de la ficha del producto, el formulario de pedido y el botón de pago, que son los elementos que influyen en su decisión de compra. Ocultar la política de devoluciones o dificultar la localización del botón de cancelación puede dar lugar a acusaciones de uso de «patrones oscuros»."},{"question":"¿Qué frases es imprescindible incluir en las indicaciones para la IA?","answer":"Si hay alguna política que no esté definida, es recomendable incluir una frase en la que se pida que se consulte antes de escribir el código. Esta frase actúa como medida de seguridad para que la IA vuelva a preguntar sobre políticas que suelen pasarse por alto, como el procedimiento de aprobación de reembolsos, los criterios de deducción de los gastos de envío o las excepciones en los cambios de estado."},{"question":"¿Qué funciones de reembolso deben incluirse en el panel de administración?","answer":"Se necesitan una lista de espera de reembolsos, la fecha de solicitud, la fecha límite de tramitación, avisos de plazo inminente, una vista previa del cálculo del reembolso parcial, el motivo del reembolso, el registro del responsable de la tramitación y la gestión de permisos. Dado que los reembolsos son una tarea operativa recurrente, si la interfaz de administración es deficiente, resulta difícil cumplir los plazos legales y garantizar la calidad de la atención al cliente."},{"question":"¿Se pueden aplicar las mismas normas de reembolso a los pagos de contenidos digitales?","answer":"En el caso de los contenidos digitales, las restricciones al desistimiento del contrato pueden plantear problemas en función de si se ha iniciado la prestación del servicio, si se ha informado previamente al cliente y si este ha dado su consentimiento. Por lo tanto, es necesario informar claramente de las condiciones de restricción de reembolso en la pantalla previa al pago y registrar la hora en que se dio el consentimiento y la versión de los términos y condiciones."}],"sources":[{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"Centro de Información sobre Legislación Nacional: Ley de Protección de los Consumidores en el Comercio Electrónico, entre otros ámbitos","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령","title":"Centro de Información sobre Legislación Nacional: Reglamento de aplicación de la Ley de protección de los consumidores en el comercio electrónico, etc.","type":"source"},{"url":"https://stripe.com/docs/idempotency","title":"Documentación de Stripe: Solicitudes idempotentes","type":"source"},{"url":"https://docs.tosspayments.com/guides/v2/get-started/payment-flow","title":"Documentación de Toss Payments: Flujo de integración de pagos","type":"source"},{"url":"https://www.ftc.go.kr/","title":"Comisión de Comercio Justo","type":"source"}],"images":[{"id":252,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제·배송·보안 아이콘과 연결된 중앙의 AI 두뇌 일러스트","caption":"AI 두뇌가 쇼핑, 카드 결제, 배송, 보안 등 결제 흐름의 요소와 연결되어 있다.","description":null},"en":{"alt":"Central AI brain connected to payment, shopping, delivery, security, and support icons","caption":"The illustration links an AI brain to key parts of an online payment flow.","description":null},"ja":{"alt":"決済、買い物、配送、セキュリティのアイコンにつながる中央のAI脳","caption":"AIの脳がオンライン決済フローの主要な要素につながっている。","description":null},"es":{"alt":"Cerebro de IA central conectado a iconos de pago, compras, entrega, seguridad y soporte","caption":"La ilustración conecta un cerebro de IA con partes clave del flujo de pago en línea.","description":null},"id":{"alt":"Otak AI di tengah terhubung ke ikon pembayaran, belanja, pengiriman, keamanan, dan dukungan","caption":"Ilustrasi ini menghubungkan otak AI dengan bagian penting dalam alur pembayaran online.","description":null},"pt":{"alt":"Cérebro de IA central conectado a ícones de pagamento, compras, entrega, segurança e suporte","caption":"A ilustração liga um cérebro de IA a etapas importantes do fluxo de pagamento online.","description":null},"zh-hant":{"alt":"中央 AI 大腦連接付款、購物、配送、安全與客服圖示","caption":"插圖呈現 AI 大腦與線上付款流程中的關鍵元素相連。","description":null}}},{"id":253,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제 화면을 중심으로 보안, 분석, 구독, 배송, 오류 흐름이 연결된 일러스트","caption":"AI로 결제 기능을 설계할 때 고려할 핵심 요소들을 한눈에 보여준다.","description":null},"en":{"alt":"Checkout screen connected to panels for security, analytics, subscriptions, delivery, and errors","caption":"The illustration summarizes key areas to decide before building AI-powered payments.","description":null},"ja":{"alt":"決済画面を中心に、セキュリティ、分析、定期課金、配送、エラーがつながるイラスト","caption":"AIで決済機能を作る前に決めるべき要素を整理して示している。","description":null},"es":{"alt":"Pantalla de pago conectada con paneles de seguridad, análisis, suscripción, envío y errores","caption":"La ilustración resume aspectos clave antes de crear pagos con IA.","description":null},"id":{"alt":"Layar checkout terhubung ke panel keamanan, analitik, langganan, pengiriman, dan kesalahan","caption":"Ilustrasi ini merangkum hal penting sebelum membangun pembayaran dengan AI.","description":null},"pt":{"alt":"Tela de checkout conectada a painéis de segurança, análise, assinatura, entrega e erros","caption":"A ilustração resume decisões importantes antes de criar pagamentos com IA.","description":null},"zh-hant":{"alt":"結帳畫面連接安全、分析、訂閱、配送與錯誤流程面板的插圖","caption":"這張插圖概述用 AI 建立付款功能前需先決定的重點。","description":null}}}],"published_at":"2026-07-22T08:42:09+09:00","updated_at":"2026-07-22T08:42:09+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/es/articles/ai-payment-feature-7-core-decisions"}