---
title: "7 coisas a definir antes de criar pagamentos com IA"
locale: pt
category: how_to
category_name: "Como Fazer"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/ai-payment-feature-7-core-decisions
published_at: 2026-07-22T08:42:09+09:00
---

# 7 coisas a definir antes de criar pagamentos com IA

> A IA pode criar código de pagamento rapidamente, mas a segurança da função de pagamento depende do desenho de políticas como status do pedido, prazo de reembolso, reembolso parcial e prevenção de pagamento duplicado. Especialmente para serviços de comércio eletrônico na Coreia, é preciso refletir claramente nos requisitos de desenvolvimento o direito de arrependimento, juros por atraso no reembolso, aviso das regras de reembolso e prevenção de dark patterns.

## Key Points

- A função de pagamento não é uma simples função de autorização de cartão, mas um sistema operacional que conecta pedidos, liquidações, reembolsos, atendimento ao cliente e avisos legais.
- Os status do pedido devem ser definidos de modo que clientes e operadores entendam o mesmo significado, como aguardando pagamento, pagamento concluído, cancelado, reembolso em andamento e reembolso concluído.
- No comércio eletrônico da Coreia, geralmente é preciso considerar o prazo de arrependimento do consumidor, o prazo de processamento de reembolso do vendedor e as regras sobre juros por atraso.
- Para prevenir pagamento duplicado, não basta desativar o botão; são necessários chave de idempotência no servidor, bloqueio do pedido e verificação de duplicidade na autorização do pagamento.
- Um design que oculta as regras de reembolso e os métodos de cancelamento, ou dificulta o encerramento, prejudica a confiança do cliente e aumenta o risco de regulação sobre dark patterns.

## Resumo essencial

O prompt mais perigoso ao delegar uma função de pagamento à AI é simplesmente pedir “adicione pagamento”. Pagamento não é um código que recebe dinheiro, mas um sistema operacional, contábil e de atendimento ao cliente que se responsabiliza pelo fluxo do dinheiro.

Tecnicamente, a AI consegue implementar rapidamente a integração da janela de pagamento, a chamada da API de aprovação, o recebimento de webhooks e o armazenamento de pedidos. No entanto, se as políticas abaixo não estiverem definidas, em um serviço real podem ocorrer problemas como pedidos fantasma, pagamentos duplicados, atraso em reembolsos, explosão de demandas no atendimento ao cliente e ausência de avisos legais.

| Área de decisão | Pergunta a definir antecipadamente | Risco em caso de falha |
|---|---|---|
| Status do pedido | Por quais status o pedido passa, e em que ordem? | Ocorrência de pedidos fantasma: o pagamento foi feito, mas o pedido não existe |
| Prazo de reembolso | Como refletir o prazo de arrependimento e processamento de reembolso? | Violação de prazo legal, juros por atraso, risco de disputa |
| Reembolso parcial | Como calcular devolução de alguns produtos, cupons e frete? | O operador calcula manualmente a cada vez, desconfiança do cliente |
| Pagamento duplicado | Como impedir que o mesmo pedido seja cobrado duas vezes? | Reclamações do cliente com base na fatura do cartão, queda de confiança |
| Orientação sobre falha | Como orientar sobre limite excedido, saldo insuficiente e falha de autenticação? | Queda na taxa de conversão de nova tentativa, aumento de consultas desnecessárias |
| Histórico de pagamentos | Onde o cliente verifica o status de pagamento e reembolso? | Aumento de consultas ao atendimento, status pouco transparente |
| Aviso de reembolso | Onde posicionar a política de reembolso e o botão de cancelamento? | Controvérsia de dark patterns, risco regulatório |

## 1. Design do status do pedido: o status é a linguagem da operação

Ao criar uma função de pagamento, não se deve deixar o status do pedido apenas como “pedido concluído”. Um pedido real passa por várias etapas, como tentativa de pagamento, aprovação, cancelamento, reembolso, falha e expiração.

### Exemplos de status recomendados

| Exemplo de código de status | Status exibido ao cliente | Significado |
|---|---|---|
| `payment_pending` | Aguardando pagamento | O pedido foi criado, mas o pagamento ainda não foi concluído |
| `paid` | Pagamento concluído | A aprovação do pagamento foi concluída e o pedido é válido |
| `payment_failed` | Pagamento falhou | A tentativa de pagamento falhou e é preciso avaliar se uma nova tentativa é possível |
| `cancel_requested` | Cancelamento solicitado | O cliente solicitou o cancelamento e está aguardando processamento |
| `cancelled` | Cancelamento concluído | O cancelamento do pedido antes do pagamento ou o cancelamento da aprovação foi concluído |
| `refund_requested` | Reembolso solicitado | A solicitação de reembolso após o pagamento foi recebida |
| `refund_processing` | Reembolso em andamento | A aprovação do reembolso ou a devolução ao meio de pagamento está em processamento |
| `partially_refunded` | Reembolso parcial concluído | Apenas parte do valor do pedido foi reembolsada |
| `refunded` | Reembolso concluído | O processamento do reembolso foi concluído |
| `expired` | Pedido expirado | O tempo de espera pelo pagamento passou e o pedido foi invalidado |

### Princípios de design de status

- Não trate o status do pedido e o status do pagamento como exatamente a mesma coisa. O pedido pode existir, mas o pagamento pode falhar; e o pagamento pode ter sido aprovado, mas o armazenamento do pedido pode falhar.
- Toda alteração de status deve registrar horário de ocorrência, responsável pelo processamento, motivo, identificador da transação de pagamento e identificador da transação de reembolso.
- A tela do cliente, a tela do administrador e as frases de atendimento ao cliente devem usar a mesma definição de status.
- As transições de status devem ser desenhadas em sentido único, e a recuperação de exceções deve ser tratada com registro, por meio de permissão administrativa separada.

## 2. Arrependimento e prazo legal de reembolso: não é política, é exigência legal

Se você opera comércio eletrônico voltado a consumidores na Coreia, deve considerar a Lei sobre Proteção do Consumidor no Comércio Eletrônico etc. Em geral, o consumidor pode exercer o direito de arrependimento dentro de determinado período, e o fornecedor deve devolver o valor dentro do prazo definido após a solicitação de reembolso ou o procedimento de devolução.

Na prática, os critérios especialmente importantes são os seguintes.

- Em princípio, o consumidor pode exercer o direito de arrependimento em até 7 dias a partir da data definida pela lei, como o dia em que recebeu os bens.
- O fornecedor deve reembolsar o valor dentro do prazo legal após a ocorrência do motivo de reembolso; em caso de atraso, podem surgir problemas de compensação por atraso ou juros por atraso.
- Conteúdo digital, produtos feitos sob encomenda e produtos cujo valor diminui significativamente pelo uso podem ser exceções, mas, para aplicar uma exceção, é preciso verificar cuidadosamente requisitos como aviso prévio e consentimento.
- A aplicação real pode variar conforme o tipo de produto, a forma do contrato, os avisos fornecidos ao consumidor e se o uso foi iniciado, portanto é necessária revisão jurídica.

### Como transformar em requisitos de desenvolvimento

Não basta escrever os critérios legais apenas no texto dos termos. Eles também devem ser transformados em requisitos do sistema.

| Exigência legal/política | Requisito do sistema |
|---|---|
| Avaliação de possibilidade de arrependimento em até 7 dias | Cálculo automático do período de reembolso com base na data de recebimento do pedido ou na data de prestação do serviço |
| Necessidade de processar o reembolso em até 3 dias úteis | Exibir na tela do administrador a data de solicitação de reembolso e o prazo final de processamento |
| Risco de atraso no reembolso | Exibir alertas de prazo próximo e prazo excedido |
| Necessidade de aviso para produtos de exceção | Exibir claramente antes do pagamento que o produto tem restrição de reembolso e armazenar o log de consentimento |
| Necessidade de resposta a disputas | Manter versão dos termos, horário do aviso, horário do consentimento, IP do cliente ou logs da conta |

## 3. Regras de reembolso parcial: defina cupons, frete e impostos antecipadamente

O reembolso parcial é muito mais complexo do que o cancelamento total. Quando vários produtos são pedidos de uma vez e apenas alguns são devolvidos, é preciso decidir como dividir o desconto originalmente aplicado e o frete.

### Itens que devem ser definidos obrigatoriamente

- Como distribuir o valor pago por produto
- Se o cupom aplicado ao pedido inteiro será distribuído proporcionalmente por produto
- Se o cupom de um produto específico será aplicado apenas a esse produto
- Se o frete será descontado quando a condição de frete grátis deixar de ser atendida
- Como diferenciar o frete de devolução por simples arrependimento e o frete de devolução por defeito do produto
- Em que ordem reembolsar a parte paga com pontos, créditos e gift card
- Como alterar a nota fiscal, o recibo em dinheiro e a indicação no recibo após o reembolso parcial

### Exemplo de cálculo de reembolso parcial

| Item | Valor |
|---|---:|
| Produto A | 30,000 won |
| Produto B | 70,000 won |
| Cupom aplicado ao pedido inteiro | -10,000 won |
| Valor efetivamente pago | 90,000 won |

Se o cupom for distribuído conforme a proporção do valor dos produtos, o desconto alocado será de 3,000 won para o produto A e 7,000 won para o produto B. Nesse caso, se apenas o produto A for reembolsado, o valor-base do reembolso não é 30,000 won, mas 27,000 won. Se houver condição de frete grátis, frete de devolução e restrições de reembolso por meio de pagamento, o valor final do reembolso pode mudar ainda mais.

Não existe uma única resposta correta. O importante é definir previamente regras consistentes e avisar de forma que o cliente consiga compreendê-las antes do pagamento ou antes da solicitação de reembolso.

## 4. Prevenção de pagamento duplicado: desativar o botão não basta

Pagamento duplicado é o incidente de pagamento que o cliente percebe mais rapidamente. O cliente vê primeiro a mensagem de aprovação do cartão e a fatura do cartão, antes do status interno do pedido no serviço. Se o mesmo pedido for cobrado duas vezes, a confiança cai muito.

### Causas de ocorrência

- O cliente clica repetidamente no botão de pagamento
- O cliente atualiza a página logo após o pagamento ou clica em voltar
- A mesma solicitação é reenviada por atraso na rede móvel
- A resposta de aprovação do pagamento foi bem-sucedida, mas o armazenamento no servidor do serviço falhou
- O webhook e o redirecionamento do cliente alteram o status do pedido ao mesmo tempo

### Design de defesa

| Mecanismo de defesa | Descrição |
|---|---|
| Bloqueio do botão no cliente | Impede novo clique após o clique no botão de pagamento, mas deve ser usado apenas como recurso auxiliar |
| Bloqueio do pedido no servidor | Processa para que solicitações de aprovação de pagamento para o mesmo ID de pedido não sejam executadas simultaneamente |
| Chave de idempotência | Usa um identificador para que, mesmo enviando a mesma solicitação de pagamento várias vezes, o resultado seja criado apenas uma vez |
| Número de transação único | Impede armazenamento duplicado do número do pedido e do número da transação de pagamento por meio de restrições no banco de dados |
| Validação baseada em status | Bloqueia solicitação adicional de aprovação para pedidos que já estão `paid` |
| Tratamento de webhooks duplicados | Processa para que, mesmo que o mesmo evento de webhook chegue várias vezes, a alteração de status ocorra apenas uma vez |

Ao solicitar código de pagamento à AI, é melhor especificar “o processamento de aprovação e conclusão do pagamento para o mesmo pedido deve operar de forma idempotente” em vez de apenas “prevenção de clique duplicado”.

## 5. Mensagens de falha de pagamento: falha não é acidente, é fluxo normal

Falhas de pagamento são situações normais que acontecem todos os dias. Limite excedido, saldo insuficiente, falha de autenticação do cartão, erro de senha, falha de autenticação 3D Secure, ausência de resposta do app de pagamento simplificado e erro de rede são todos casos comuns.

Uma má orientação é uma mensagem que termina em “ocorreu um erro”. O cliente não sabe se o pagamento foi realizado, se pode clicar novamente ou se o pedido desaparecerá.

### Exemplos de mensagens recomendadas

| Situação | Orientação recomendada |
|---|---|
| Saldo insuficiente | O pagamento não foi concluído porque o saldo do meio de pagamento é insuficiente. Selecione outro meio de pagamento ou verifique o saldo e tente novamente. |
| Limite excedido | O pagamento falhou porque o limite do cartão ou o limite por transação foi excedido. Verifique o limite no app da administradora do cartão ou pague com outro cartão. |
| Falha de autenticação | Como a autenticação do pagamento não foi concluída, o pedido será mantido em status de aguardando pagamento. Você pode tentar pagar novamente dentro de 30 minutos. |
| Erro de rede | A confirmação do resultado do pagamento está atrasada. Para evitar pagamento duplicado, verifique o histórico de pagamentos daqui a pouco. |
| Pedido expirado | O tempo de espera pelo pagamento passou e o pedido expirou. Selecione os produtos novamente e faça o pedido. |

### Elementos essenciais da orientação de falha

- Diga claramente se o pagamento realmente não foi concluído.
- Informe por quanto tempo o pedido será mantido.
- Oriente se é possível tentar novamente ou se deve usar outro meio de pagamento.
- Mostre o número do pedido necessário ao entrar em contato com o atendimento ao cliente.
- Quando o resultado do pagamento for incerto, não incentive uma nova cobrança de forma automática; ofereça o status de verificação em andamento.

## 6. Página de histórico de pagamentos: a tela essencial para reduzir o atendimento ao cliente

Se não houver uma página de histórico de pagamentos, o cliente entra em contato com o atendimento para verificar o status de pagamento, cancelamento e reembolso. O histórico de pagamentos não é uma simples tela de recibo, mas um mecanismo de confiança pelo qual o cliente verifica o estado atual do próprio dinheiro.

### Informações a incluir na página de histórico de pagamentos

- Número do pedido
- Data e hora do pedido e data e hora do pagamento
- Nome do produto, quantidade, opções
- Meio de pagamento e número de aprovação ou identificador de transação
- Valor dos produtos, descontos, frete, valor usado em pontos, valor final pago
- Status atual do pedido e status do reembolso
- Data de solicitação de reembolso, data de aprovação do reembolso, data prevista de conclusão do reembolso
- Possibilidade de cancelamento ou reembolso
- Links para verificar recibo, demonstrativo da transação e recibo em dinheiro
- Informações necessárias ao consultar o atendimento ao cliente

### Conexão com a tela do operador

A tela do cliente e a tela do administrador devem ver os mesmos dados. Se para o cliente aparece “reembolso em andamento”, mas na tela do administrador aparece “processamento concluído”, o atendimento ao cliente fica confuso. Os nomes de status podem ser expressos de forma diferente, mas o código interno de status e as regras de transição devem ser únicos.

## 7. Local do aviso da política de reembolso: se esconder, deixa de ser política e vira risco

Não basta colocar a política de reembolso apenas em um canto da página de termos. Na tela em que o cliente toma a decisão de pagamento, deve ser fácil verificar o período de possibilidade de reembolso, as condições de restrição de reembolso e o método de cancelamento.

### Bons locais de aviso

- Próximo ao preço ou ao botão de compra na página de detalhes do produto
- Tela do carrinho ou do formulário de pedido
- Área de consentimento com os termos e a política de reembolso logo acima do botão de pagamento
- Página de conclusão do pagamento
- Tela de detalhes do pedido em Minha Página
- Tela de solicitação de reembolso

### Designs a evitar

- Design em que cadastro e pagamento são feitos de uma vez, mas cancelamento ou reembolso só são possíveis por telefone para o atendimento
- Design que esconde o botão de cancelamento dentro de várias etapas
- Design que mostra as condições de restrição de reembolso apenas depois do pagamento
- Design que posiciona cor, texto e ordem dos botões de forma a induzir o cliente ao erro
- Design que não informa claramente a cobrança automática após o fim do teste grátis

Esses designs não apenas prejudicam a experiência do cliente, como também podem ser avaliados como dark patterns. Em especial, é mais seguro projetar a dificuldade de cancelamento e encerramento de assinatura de modo que não seja muito diferente da dificuldade de cadastro e pagamento.

## Checklist para incluir no prompt a ser dado à AI

Ao solicitar a implementação de uma função de pagamento a uma ferramenta de desenvolvimento com AI, é preciso transmitir primeiro as políticas, como abaixo.

### Exemplo de prompt para função de pagamento

```text
Implemente a função de pagamento de um serviço de comércio eletrônico voltado a consumidores coreanos.
Reflita obrigatoriamente as seguintes políticas.

1. Os status do pedido usam payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired.
2. Pedidos aguardando pagamento devem ser alterados para expired após 30 minutos.
3. Para o mesmo pedido, permita apenas 1 aprovação de pagamento e use bloqueio do pedido no servidor e chave de idempotência.
4. Webhooks de pagamento podem ser recebidos de forma duplicada, portanto o mesmo ID de evento deve ser processado apenas uma vez.
5. Armazene a data da solicitação de reembolso, o prazo final de processamento do reembolso, o responsável pelo processamento, o motivo e o número da transação de reembolso.
6. O reembolso parcial deve ser calculado com base no valor efetivamente pago por produto, e o cupom aplicado ao pedido inteiro deve ser distribuído proporcionalmente ao valor dos produtos.
7. Em caso de falha no pagamento, retorne mensagens de orientação ao cliente por motivo de falha.
8. Permita que o cliente verifique o histórico de pagamentos e o status de reembolso em Minha Página.
9. Antes do pagamento, exiba o link da política de reembolso e a caixa de seleção de consentimento, e armazene o horário do consentimento e a versão dos termos.
10. Se houver alguma política não definida, faça perguntas antes de escrever o código.
```

A última frase, “se houver alguma política não definida, faça perguntas antes”, é importante. Ela pode fazer a AI perguntar novamente sobre políticas que pessoas tendem a deixar passar, como aprovação automática de reembolso, permissão administrativa de aprovação e forma de desconto do frete.

## Funções necessárias na tela do operador

A função de pagamento não fica completa apenas com a tela do cliente. Reembolsos e cancelamentos são tarefas operacionais processadas todos os dias, portanto uma tela administrativa é indispensável.

| Função administrativa | Motivo da necessidade |
|---|---|
| Lista de reembolsos pendentes | Necessária para não deixar passar reembolsos que precisam ser processados |
| Exibição do prazo legal de processamento | Necessária para reduzir o risco de atraso no reembolso |
| Alertas de prazo próximo/excedido | Necessários para que o operador perceba imediatamente critérios internos como 3 dias úteis |
| Seleção do motivo do reembolso | Necessária para estatísticas e alocação de custos, como simples arrependimento, defeito do produto e envio incorreto |
| Prévia do cálculo de reembolso parcial | Necessária para reduzir erros de cálculo manual do operador |
| Logs de processamento | Necessários para responder a disputas e auditorias |
| Gestão de permissões | Necessária para restringir aprovação de reembolso e alteração forçada de status |

## Configuração mínima do modelo de dados de pagamento

A estrutura de dados varia conforme o serviço, mas é recomendável separar, no mínimo, os dados no nível abaixo.

| Tabela ou objeto | Campos principais |
|---|---|
| Pedido | ID do pedido, ID do cliente, status do pedido, valor do pedido, valor do desconto, frete, data e hora de criação, data e hora de expiração |
| Produto do pedido | ID do produto, nome do produto, opções, quantidade, valor por produto, valor de desconto alocado por produto |
| Pagamento | ID do pagamento, ID do pedido, meio de pagamento, número de aprovação, valor aprovado, status do pagamento, data e hora da aprovação |
| Reembolso | ID do reembolso, ID do pedido, valor do reembolso, motivo do reembolso, status do reembolso, data e hora da solicitação, data e hora da conclusão |
| Histórico de status | ID do alvo, status anterior, status alterado, responsável pela alteração, motivo da alteração, data e hora da alteração |
| Consentimento com termos | Tipo de termos, versão dos termos, existência de consentimento, data e hora do consentimento, ID do cliente |

O ponto importante é não sobrescrever o valor aprovado do pagamento, o valor do reembolso e o valor total do pedido. Valores relacionados a dinheiro devem, sempre que possível, ser preservados em unidades de histórico e transação para que, posteriormente, a contabilidade e o atendimento ao cliente coincidam.

## Lista de verificação antes do lançamento

- Mesmo que o botão de pagamento seja pressionado 10 vezes para o mesmo pedido, o pagamento é aprovado apenas 1 vez?
- Se o armazenamento no servidor falhar após a aprovação do pagamento, é possível recuperar?
- Mesmo que o webhook de pagamento envie o mesmo evento várias vezes, ele não é processado de forma duplicada?
- O cliente consegue entender o motivo da falha de pagamento e o método de nova tentativa?
- Pedidos aguardando pagamento expiram automaticamente após determinado tempo?
- O valor do reembolso parcial está de acordo com as políticas de cupons, pontos e frete?
- Da data de solicitação de reembolso até o prazo final de processamento, essas informações são exibidas na tela do administrador?
- A política de reembolso pode ser verificada facilmente na tela antes do pagamento?
- Conteúdo digital ou produtos com restrição de reembolso têm aviso prévio e log de consentimento?
- O cliente consegue verificar diretamente o histórico de pagamentos e o status de reembolso em Minha Página?

## Conclusão

A AI consegue criar rapidamente o código de uma função de pagamento. Porém, um sistema de pagamento operado de forma segura e legal começa pela definição de políticas antes do código.

Se você organizar primeiro o status do pedido, o prazo legal de reembolso, a fórmula de cálculo de reembolso parcial, a prevenção de pagamento duplicado, a orientação sobre falha de pagamento, a página de histórico de pagamentos e o local do aviso da política de reembolso, e depois delegar a implementação à AI, poderá obter um resultado muito mais estável. Pagamento deve ser desenhado pela perspectiva de que não é uma “função que recebe dinheiro”, mas uma “função que se responsabiliza pelo dinheiro”.

## FAQ

### O que deve ser definido primeiro ao pedir para a IA criar uma funcionalidade de pagamento?
Antes de tudo, é preciso definir o fluxo dos status do pedido e do pagamento. Status como aguardando pagamento, pagamento concluído, pagamento falhou, solicitação de cancelamento, reembolso em andamento e reembolso concluído devem ser definidos para que a IA possa criar uma estrutura de dados e um fluxo de telas seguros.

### Por que é perigoso deixar o status do pedido apenas como pedido concluído?
Porque, em pagamentos reais, há muitos fluxos de exceção, como falha, cancelamento, reembolso e expiração. Se o status for simples demais, podem ocorrer problemas como o pagamento ter sido feito, mas não haver histórico do pedido, ou o reembolso ter sido concluído, mas a tela do cliente continuar mostrando pagamento concluído.

### A regra de 7 dias para desistência de compra no comércio eletrônico coreano sempre se aplica?
Em geral, o consumidor pode desistir da compra dentro de 7 dias a partir da data de referência definida por lei. No entanto, conteúdos digitais, produtos personalizados, produtos cujo valor diminui com o uso e outros itens podem ser exceções, por isso é necessária uma análise individual que inclua aviso prévio e requisitos de consentimento.

### Até quando o reembolso deve ser processado?
No comércio eletrônico coreano, a empresa deve reembolsar o valor dentro do prazo legal após surgir o motivo para o reembolso e, na prática, é mais seguro refletir o critério de 3 dias úteis na tela do administrador e nas notificações. Como atrasos podem gerar problemas de indenização por atraso, é recomendável ter uma função de alerta automático.

### Qual é o item que mais frequentemente causa problemas em reembolsos parciais?
Cupons aplicados ao pedido inteiro, condições de frete grátis, frete de devolução, valores usados em pontos e distribuição de descontos por produto costumam causar problemas. Para que o operador não precise decidir caso a caso após a solicitação de reembolso, é necessário definir previamente regras como o valor efetivamente pago por produto ou um método de distribuição proporcional.

### É possível impedir pagamentos duplicados apenas desativando o botão no frontend?
Desativar o botão ajuda, mas não é suficiente. Como podem ocorrer novas tentativas de rede, atualizações de página e recebimento duplicado de webhooks, também são necessários bloqueio de pedido no servidor, chave de idempotência, restrição de número de transação único e validação baseada em status.

### O que deve constar na mensagem de orientação sobre falha no pagamento?
Ela deve informar se o pagamento não foi concluído, qual foi o motivo da falha, se é possível tentar novamente, por quanto tempo o pedido será mantido e qual é o número do pedido necessário em caso de contato. Se apenas uma mensagem dizendo que ocorreu um erro for exibida, a evasão de clientes e as consultas aumentarão.

### Por que a página de histórico de pagamentos é indispensável?
Porque o cliente deve poder verificar diretamente quando e quanto pagou e até que etapa o reembolso avançou. Se não houver uma página de histórico de pagamentos, todas as solicitações de verificação se concentrarão no atendimento ao cliente, e o cliente poderá sentir que o serviço não gerencia adequadamente o fluxo do dinheiro.

### É suficiente que a política de reembolso esteja apenas na página de termos?
Não é suficiente. O cliente deve poder verificar facilmente o prazo em que o reembolso é possível e as condições de restrição na página de detalhes do produto, no formulário do pedido e perto do botão de pagamento, onde decide a compra. Se a política de reembolso for escondida ou se o botão de cancelamento for difícil de encontrar, pode surgir controvérsia sobre dark patterns.

### Qual frase deve obrigatoriamente ser incluída no prompt de IA?
É recomendável incluir uma frase pedindo que, se houver uma política não definida, a IA faça perguntas antes de escrever o código. Essa frase é uma medida de segurança que faz a IA voltar a perguntar sobre políticas que são fáceis de deixar passar, como o método de aprovação de reembolso, o critério de dedução do frete e exceções de transição de status.

### Quais funcionalidades de reembolso são necessárias na tela do administrador?
São necessários lista de reembolsos pendentes, data da solicitação, prazo final de processamento, alerta de prazo próximo, pré-visualização do cálculo de reembolso parcial, motivo do reembolso, log do responsável pelo processamento e gerenciamento de permissões. Como reembolso é uma tarefa operacional recorrente, se a tela do administrador for deficiente, será difícil cumprir os prazos legais e manter a qualidade do atendimento ao cliente.

### As mesmas regras de reembolso podem ser aplicadas também a pagamentos de conteúdo digital?
Em conteúdos digitais, a possibilidade de restrição da desistência de compra pode depender do início da disponibilização, do aviso prévio e do consentimento do cliente. Portanto, a implementação deve informar claramente as condições de restrição de reembolso na tela antes do pagamento e registrar o horário do consentimento e a versão dos termos.

## Sources

- [Centro Nacional de Informações Legislativas: Lei sobre a Proteção do Consumidor no Comércio Eletrônico etc.](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률)
- [Centro Nacional de Informações Legislativas: Decreto de Execução da Lei sobre a Proteção do Consumidor no Comércio Eletrônico etc.](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령)
- [Stripe Docs: Solicitações idempotentes](https://stripe.com/docs/idempotency)
- [Toss Payments Docs: Fluxo de integração de pagamentos](https://docs.tosspayments.com/guides/v2/get-started/payment-flow)
- [Comissão de Comércio Justo](https://www.ftc.go.kr/)

## Images

![Cérebro de IA central conectado a ícones de pagamento, compras, entrega, segurança e suporte](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp)
![Tela de checkout conectada a painéis de segurança, análise, assinatura, entrega e erros](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp)