{"content_id":"dtvo1yuy0p","slug":"ai-payment-feature-7-core-decisions","locale":"pt","schema_type":"TechArticle","category":"how_to","category_name":"Como Fazer","title":"7 coisas a definir antes de criar pagamentos com IA","summary":"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.","author":{"name":"injoys","url":"https://injoys.com/ko/about"},"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."],"content_markdown":"## Resumo essencial\n\nO 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.\n\nTecnicamente, 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.\n\n| Área de decisão | Pergunta a definir antecipadamente | Risco em caso de falha |\n|---|---|---|\n| 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 |\n| Prazo de reembolso | Como refletir o prazo de arrependimento e processamento de reembolso? | Violação de prazo legal, juros por atraso, risco de disputa |\n| Reembolso parcial | Como calcular devolução de alguns produtos, cupons e frete? | O operador calcula manualmente a cada vez, desconfiança do cliente |\n| 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 |\n| 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 |\n| Histórico de pagamentos | Onde o cliente verifica o status de pagamento e reembolso? | Aumento de consultas ao atendimento, status pouco transparente |\n| Aviso de reembolso | Onde posicionar a política de reembolso e o botão de cancelamento? | Controvérsia de dark patterns, risco regulatório |\n\n## 1. Design do status do pedido: o status é a linguagem da operação\n\nAo 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.\n\n### Exemplos de status recomendados\n\n| Exemplo de código de status | Status exibido ao cliente | Significado |\n|---|---|---|\n| `payment_pending` | Aguardando pagamento | O pedido foi criado, mas o pagamento ainda não foi concluído |\n| `paid` | Pagamento concluído | A aprovação do pagamento foi concluída e o pedido é válido |\n| `payment_failed` | Pagamento falhou | A tentativa de pagamento falhou e é preciso avaliar se uma nova tentativa é possível |\n| `cancel_requested` | Cancelamento solicitado | O cliente solicitou o cancelamento e está aguardando processamento |\n| `cancelled` | Cancelamento concluído | O cancelamento do pedido antes do pagamento ou o cancelamento da aprovação foi concluído |\n| `refund_requested` | Reembolso solicitado | A solicitação de reembolso após o pagamento foi recebida |\n| `refund_processing` | Reembolso em andamento | A aprovação do reembolso ou a devolução ao meio de pagamento está em processamento |\n| `partially_refunded` | Reembolso parcial concluído | Apenas parte do valor do pedido foi reembolsada |\n| `refunded` | Reembolso concluído | O processamento do reembolso foi concluído |\n| `expired` | Pedido expirado | O tempo de espera pelo pagamento passou e o pedido foi invalidado |\n\n### Princípios de design de status\n\n- 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.\n- 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.\n- A tela do cliente, a tela do administrador e as frases de atendimento ao cliente devem usar a mesma definição de status.\n- 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.\n\n## 2. Arrependimento e prazo legal de reembolso: não é política, é exigência legal\n\nSe 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.\n\nNa prática, os critérios especialmente importantes são os seguintes.\n\n- 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.\n- 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.\n- 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.\n- 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.\n\n### Como transformar em requisitos de desenvolvimento\n\nNão basta escrever os critérios legais apenas no texto dos termos. Eles também devem ser transformados em requisitos do sistema.\n\n| Exigência legal/política | Requisito do sistema |\n|---|---|\n| 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 |\n| 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 |\n| Risco de atraso no reembolso | Exibir alertas de prazo próximo e prazo excedido |\n| 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 |\n| 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 |\n\n## 3. Regras de reembolso parcial: defina cupons, frete e impostos antecipadamente\n\nO 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.\n\n### Itens que devem ser definidos obrigatoriamente\n\n- Como distribuir o valor pago por produto\n- Se o cupom aplicado ao pedido inteiro será distribuído proporcionalmente por produto\n- Se o cupom de um produto específico será aplicado apenas a esse produto\n- Se o frete será descontado quando a condição de frete grátis deixar de ser atendida\n- Como diferenciar o frete de devolução por simples arrependimento e o frete de devolução por defeito do produto\n- Em que ordem reembolsar a parte paga com pontos, créditos e gift card\n- Como alterar a nota fiscal, o recibo em dinheiro e a indicação no recibo após o reembolso parcial\n\n### Exemplo de cálculo de reembolso parcial\n\n| Item | Valor |\n|---|---:|\n| Produto A | 30,000 won |\n| Produto B | 70,000 won |\n| Cupom aplicado ao pedido inteiro | -10,000 won |\n| Valor efetivamente pago | 90,000 won |\n\nSe 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\nNã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.\n\n## 4. Prevenção de pagamento duplicado: desativar o botão não basta\n\nPagamento 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.\n\n### Causas de ocorrência\n\n- O cliente clica repetidamente no botão de pagamento\n- O cliente atualiza a página logo após o pagamento ou clica em voltar\n- A mesma solicitação é reenviada por atraso na rede móvel\n- A resposta de aprovação do pagamento foi bem-sucedida, mas o armazenamento no servidor do serviço falhou\n- O webhook e o redirecionamento do cliente alteram o status do pedido ao mesmo tempo\n\n### Design de defesa\n\n| Mecanismo de defesa | Descrição |\n|---|---|\n| 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 |\n| 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 |\n| 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| 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 |\n| Validação baseada em status | Bloqueia solicitação adicional de aprovação para pedidos que já estão `paid` |\n| 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 |\n\nAo 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”.\n\n## 5. Mensagens de falha de pagamento: falha não é acidente, é fluxo normal\n\nFalhas 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.\n\nUma 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á.\n\n### Exemplos de mensagens recomendadas\n\n| Situação | Orientação recomendada |\n|---|---|\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| Pedido expirado | O tempo de espera pelo pagamento passou e o pedido expirou. Selecione os produtos novamente e faça o pedido. |\n\n### Elementos essenciais da orientação de falha\n\n- Diga claramente se o pagamento realmente não foi concluído.\n- Informe por quanto tempo o pedido será mantido.\n- Oriente se é possível tentar novamente ou se deve usar outro meio de pagamento.\n- Mostre o número do pedido necessário ao entrar em contato com o atendimento ao cliente.\n- 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.\n\n## 6. Página de histórico de pagamentos: a tela essencial para reduzir o atendimento ao cliente\n\nSe 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.\n\n### Informações a incluir na página de histórico de pagamentos\n\n- Número do pedido\n- Data e hora do pedido e data e hora do pagamento\n- Nome do produto, quantidade, opções\n- Meio de pagamento e número de aprovação ou identificador de transação\n- Valor dos produtos, descontos, frete, valor usado em pontos, valor final pago\n- Status atual do pedido e status do reembolso\n- Data de solicitação de reembolso, data de aprovação do reembolso, data prevista de conclusão do reembolso\n- Possibilidade de cancelamento ou reembolso\n- Links para verificar recibo, demonstrativo da transação e recibo em dinheiro\n- Informações necessárias ao consultar o atendimento ao cliente\n\n### Conexão com a tela do operador\n\nA 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.\n\n## 7. Local do aviso da política de reembolso: se esconder, deixa de ser política e vira risco\n\nNã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.\n\n### Bons locais de aviso\n\n- Próximo ao preço ou ao botão de compra na página de detalhes do produto\n- Tela do carrinho ou do formulário de pedido\n- Área de consentimento com os termos e a política de reembolso logo acima do botão de pagamento\n- Página de conclusão do pagamento\n- Tela de detalhes do pedido em Minha Página\n- Tela de solicitação de reembolso\n\n### Designs a evitar\n\n- 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\n- Design que esconde o botão de cancelamento dentro de várias etapas\n- Design que mostra as condições de restrição de reembolso apenas depois do pagamento\n- Design que posiciona cor, texto e ordem dos botões de forma a induzir o cliente ao erro\n- Design que não informa claramente a cobrança automática após o fim do teste grátis\n\nEsses 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.\n\n## Checklist para incluir no prompt a ser dado à AI\n\nAo 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.\n\n### Exemplo de prompt para função de pagamento\n\n```text\nImplemente a função de pagamento de um serviço de comércio eletrônico voltado a consumidores coreanos.\nReflita obrigatoriamente as seguintes políticas.\n\n1. Os status do pedido usam payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired.\n2. Pedidos aguardando pagamento devem ser alterados para expired após 30 minutos.\n3. Para o mesmo pedido, permita apenas 1 aprovação de pagamento e use bloqueio do pedido no servidor e chave de idempotência.\n4. Webhooks de pagamento podem ser recebidos de forma duplicada, portanto o mesmo ID de evento deve ser processado apenas uma vez.\n5. 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.\n6. 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.\n7. Em caso de falha no pagamento, retorne mensagens de orientação ao cliente por motivo de falha.\n8. Permita que o cliente verifique o histórico de pagamentos e o status de reembolso em Minha Página.\n9. 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.\n10. Se houver alguma política não definida, faça perguntas antes de escrever o código.\n```\n\nA ú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.\n\n## Funções necessárias na tela do operador\n\nA 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.\n\n| Função administrativa | Motivo da necessidade |\n|---|---|\n| Lista de reembolsos pendentes | Necessária para não deixar passar reembolsos que precisam ser processados |\n| Exibição do prazo legal de processamento | Necessária para reduzir o risco de atraso no reembolso |\n| Alertas de prazo próximo/excedido | Necessários para que o operador perceba imediatamente critérios internos como 3 dias úteis |\n| 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 |\n| Prévia do cálculo de reembolso parcial | Necessária para reduzir erros de cálculo manual do operador |\n| Logs de processamento | Necessários para responder a disputas e auditorias |\n| Gestão de permissões | Necessária para restringir aprovação de reembolso e alteração forçada de status |\n\n## Configuração mínima do modelo de dados de pagamento\n\nA estrutura de dados varia conforme o serviço, mas é recomendável separar, no mínimo, os dados no nível abaixo.\n\n| Tabela ou objeto | Campos principais |\n|---|---|\n| 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 |\n| Produto do pedido | ID do produto, nome do produto, opções, quantidade, valor por produto, valor de desconto alocado por produto |\n| 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 |\n| 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 |\n| 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 |\n| Consentimento com termos | Tipo de termos, versão dos termos, existência de consentimento, data e hora do consentimento, ID do cliente |\n\nO 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.\n\n## Lista de verificação antes do lançamento\n\n- Mesmo que o botão de pagamento seja pressionado 10 vezes para o mesmo pedido, o pagamento é aprovado apenas 1 vez?\n- Se o armazenamento no servidor falhar após a aprovação do pagamento, é possível recuperar?\n- Mesmo que o webhook de pagamento envie o mesmo evento várias vezes, ele não é processado de forma duplicada?\n- O cliente consegue entender o motivo da falha de pagamento e o método de nova tentativa?\n- Pedidos aguardando pagamento expiram automaticamente após determinado tempo?\n- O valor do reembolso parcial está de acordo com as políticas de cupons, pontos e frete?\n- Da data de solicitação de reembolso até o prazo final de processamento, essas informações são exibidas na tela do administrador?\n- A política de reembolso pode ser verificada facilmente na tela antes do pagamento?\n- Conteúdo digital ou produtos com restrição de reembolso têm aviso prévio e log de consentimento?\n- O cliente consegue verificar diretamente o histórico de pagamentos e o status de reembolso em Minha Página?\n\n## Conclusão\n\nA 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.\n\nSe 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”.","content_html":"\u003ch2\u003e\n\u003ca href=\"#resumo-essencial\" class=\"anchor\" id=\"resumo-essencial\"\u003e\u003c/a\u003eResumo essencial\u003c/h2\u003e\n\u003cp\u003eO 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.\u003c/p\u003e\n\u003cp\u003eTecnicamente, 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eÁrea de decisão\u003c/th\u003e\n\u003cth\u003ePergunta a definir antecipadamente\u003c/th\u003e\n\u003cth\u003eRisco em caso de falha\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisão\"\u003eStatus do pedido\u003c/td\u003e\n\u003ctd data-label=\"Pergunta a definir antecipadamente\"\u003ePor quais status o pedido passa, e em que ordem?\u003c/td\u003e\n\u003ctd data-label=\"Risco em caso de falha\"\u003eOcorrência de pedidos fantasma: o pagamento foi feito, mas o pedido não existe\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisão\"\u003ePrazo de reembolso\u003c/td\u003e\n\u003ctd data-label=\"Pergunta a definir antecipadamente\"\u003eComo refletir o prazo de arrependimento e processamento de reembolso?\u003c/td\u003e\n\u003ctd data-label=\"Risco em caso de falha\"\u003eViolação de prazo legal, juros por atraso, risco de disputa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisão\"\u003eReembolso parcial\u003c/td\u003e\n\u003ctd data-label=\"Pergunta a definir antecipadamente\"\u003eComo calcular devolução de alguns produtos, cupons e frete?\u003c/td\u003e\n\u003ctd data-label=\"Risco em caso de falha\"\u003eO operador calcula manualmente a cada vez, desconfiança do cliente\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisão\"\u003ePagamento duplicado\u003c/td\u003e\n\u003ctd data-label=\"Pergunta a definir antecipadamente\"\u003eComo impedir que o mesmo pedido seja cobrado duas vezes?\u003c/td\u003e\n\u003ctd data-label=\"Risco em caso de falha\"\u003eReclamações do cliente com base na fatura do cartão, queda de confiança\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisão\"\u003eOrientação sobre falha\u003c/td\u003e\n\u003ctd data-label=\"Pergunta a definir antecipadamente\"\u003eComo orientar sobre limite excedido, saldo insuficiente e falha de autenticação?\u003c/td\u003e\n\u003ctd data-label=\"Risco em caso de falha\"\u003eQueda na taxa de conversão de nova tentativa, aumento de consultas desnecessárias\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisão\"\u003eHistórico de pagamentos\u003c/td\u003e\n\u003ctd data-label=\"Pergunta a definir antecipadamente\"\u003eOnde o cliente verifica o status de pagamento e reembolso?\u003c/td\u003e\n\u003ctd data-label=\"Risco em caso de falha\"\u003eAumento de consultas ao atendimento, status pouco transparente\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área de decisão\"\u003eAviso de reembolso\u003c/td\u003e\n\u003ctd data-label=\"Pergunta a definir antecipadamente\"\u003eOnde posicionar a política de reembolso e o botão de cancelamento?\u003c/td\u003e\n\u003ctd data-label=\"Risco em caso de falha\"\u003eControvérsia de dark patterns, risco regulatório\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-design-do-status-do-pedido-o-status-%C3%A9-a-linguagem-da-opera%C3%A7%C3%A3o\" class=\"anchor\" id=\"1-design-do-status-do-pedido-o-status-é-a-linguagem-da-operação\"\u003e\u003c/a\u003e1. Design do status do pedido: o status é a linguagem da operação\u003c/h2\u003e\n\u003cp\u003eAo 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#exemplos-de-status-recomendados\" class=\"anchor\" id=\"exemplos-de-status-recomendados\"\u003e\u003c/a\u003eExemplos de status recomendados\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eExemplo de código de status\u003c/th\u003e\n\u003cth\u003eStatus exibido ao 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=\"Exemplo de código de status\"\u003e\u003ccode\u003epayment_pending\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003eAguardando pagamento\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eO pedido foi criado, mas o pagamento ainda não foi concluído\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003epaid\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003ePagamento concluído\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eA aprovação do pagamento foi concluída e o pedido é válido\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003epayment_failed\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003ePagamento falhou\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eA tentativa de pagamento falhou e é preciso avaliar se uma nova tentativa é possível\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003ecancel_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003eCancelamento solicitado\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eO cliente solicitou o cancelamento e está aguardando processamento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003ecancelled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003eCancelamento concluído\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eO cancelamento do pedido antes do pagamento ou o cancelamento da aprovação foi concluído\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003erefund_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003eReembolso solicitado\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eA solicitação de reembolso após o pagamento foi recebida\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003erefund_processing\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003eReembolso em andamento\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eA aprovação do reembolso ou a devolução ao meio de pagamento está em processamento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003epartially_refunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003eReembolso parcial concluído\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eApenas parte do valor do pedido foi reembolsada\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003erefunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003eReembolso concluído\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eO processamento do reembolso foi concluído\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exemplo de código de status\"\u003e\u003ccode\u003eexpired\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status exibido ao cliente\"\u003ePedido expirado\u003c/td\u003e\n\u003ctd data-label=\"Significado\"\u003eO tempo de espera pelo pagamento passou e o pedido foi invalidado\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#princ%C3%ADpios-de-design-de-status\" class=\"anchor\" id=\"princípios-de-design-de-status\"\u003e\u003c/a\u003ePrincípios de design de status\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eNã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.\u003c/li\u003e\n\u003cli\u003eToda 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.\u003c/li\u003e\n\u003cli\u003eA tela do cliente, a tela do administrador e as frases de atendimento ao cliente devem usar a mesma definição de status.\u003c/li\u003e\n\u003cli\u003eAs 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.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-arrependimento-e-prazo-legal-de-reembolso-n%C3%A3o-%C3%A9-pol%C3%ADtica-%C3%A9-exig%C3%AAncia-legal\" class=\"anchor\" id=\"2-arrependimento-e-prazo-legal-de-reembolso-não-é-política-é-exigência-legal\"\u003e\u003c/a\u003e2. Arrependimento e prazo legal de reembolso: não é política, é exigência legal\u003c/h2\u003e\n\u003cp\u003eSe 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.\u003c/p\u003e\n\u003cp\u003eNa prática, os critérios especialmente importantes são os seguintes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEm 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.\u003c/li\u003e\n\u003cli\u003eO 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.\u003c/li\u003e\n\u003cli\u003eConteú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.\u003c/li\u003e\n\u003cli\u003eA 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.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#como-transformar-em-requisitos-de-desenvolvimento\" class=\"anchor\" id=\"como-transformar-em-requisitos-de-desenvolvimento\"\u003e\u003c/a\u003eComo transformar em requisitos de desenvolvimento\u003c/h3\u003e\n\u003cp\u003eNão basta escrever os critérios legais apenas no texto dos termos. Eles também devem ser transformados em requisitos do sistema.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eExigência legal/política\u003c/th\u003e\n\u003cth\u003eRequisito do sistema\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exigência legal/política\"\u003eAvaliação de possibilidade de arrependimento em até 7 dias\u003c/td\u003e\n\u003ctd data-label=\"Requisito do sistema\"\u003eCá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\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exigência legal/política\"\u003eNecessidade de processar o reembolso em até 3 dias úteis\u003c/td\u003e\n\u003ctd data-label=\"Requisito do sistema\"\u003eExibir na tela do administrador a data de solicitação de reembolso e o prazo final de processamento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exigência legal/política\"\u003eRisco de atraso no reembolso\u003c/td\u003e\n\u003ctd data-label=\"Requisito do sistema\"\u003eExibir alertas de prazo próximo e prazo excedido\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exigência legal/política\"\u003eNecessidade de aviso para produtos de exceção\u003c/td\u003e\n\u003ctd data-label=\"Requisito do sistema\"\u003eExibir claramente antes do pagamento que o produto tem restrição de reembolso e armazenar o log de consentimento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Exigência legal/política\"\u003eNecessidade de resposta a disputas\u003c/td\u003e\n\u003ctd data-label=\"Requisito do sistema\"\u003eManter versão dos termos, horário do aviso, horário do consentimento, IP do cliente ou logs da conta\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-regras-de-reembolso-parcial-defina-cupons-frete-e-impostos-antecipadamente\" class=\"anchor\" id=\"3-regras-de-reembolso-parcial-defina-cupons-frete-e-impostos-antecipadamente\"\u003e\u003c/a\u003e3. Regras de reembolso parcial: defina cupons, frete e impostos antecipadamente\u003c/h2\u003e\n\u003cp\u003eO 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#itens-que-devem-ser-definidos-obrigatoriamente\" class=\"anchor\" id=\"itens-que-devem-ser-definidos-obrigatoriamente\"\u003e\u003c/a\u003eItens que devem ser definidos obrigatoriamente\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eComo distribuir o valor pago por produto\u003c/li\u003e\n\u003cli\u003eSe o cupom aplicado ao pedido inteiro será distribuído proporcionalmente por produto\u003c/li\u003e\n\u003cli\u003eSe o cupom de um produto específico será aplicado apenas a esse produto\u003c/li\u003e\n\u003cli\u003eSe o frete será descontado quando a condição de frete grátis deixar de ser atendida\u003c/li\u003e\n\u003cli\u003eComo diferenciar o frete de devolução por simples arrependimento e o frete de devolução por defeito do produto\u003c/li\u003e\n\u003cli\u003eEm que ordem reembolsar a parte paga com pontos, créditos e gift card\u003c/li\u003e\n\u003cli\u003eComo alterar a nota fiscal, o recibo em dinheiro e a indicação no recibo após o reembolso parcial\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#exemplo-de-c%C3%A1lculo-de-reembolso-parcial\" class=\"anchor\" id=\"exemplo-de-cálculo-de-reembolso-parcial\"\u003e\u003c/a\u003eExemplo de cálculo de reembolso parcial\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eItem\u003c/th\u003e\n\u003cth\u003eValor\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eProduto A\u003c/td\u003e\n\u003ctd data-label=\"Valor\"\u003e30,000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eProduto B\u003c/td\u003e\n\u003ctd data-label=\"Valor\"\u003e70,000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eCupom aplicado ao pedido inteiro\u003c/td\u003e\n\u003ctd data-label=\"Valor\"\u003e-10,000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eValor efetivamente pago\u003c/td\u003e\n\u003ctd data-label=\"Valor\"\u003e90,000 won\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eSe 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.\u003c/p\u003e\n\u003cp\u003eNã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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-preven%C3%A7%C3%A3o-de-pagamento-duplicado-desativar-o-bot%C3%A3o-n%C3%A3o-basta\" class=\"anchor\" id=\"4-prevenção-de-pagamento-duplicado-desativar-o-botão-não-basta\"\u003e\u003c/a\u003e4. Prevenção de pagamento duplicado: desativar o botão não basta\u003c/h2\u003e\n\u003cp\u003ePagamento 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#causas-de-ocorr%C3%AAncia\" class=\"anchor\" id=\"causas-de-ocorrência\"\u003e\u003c/a\u003eCausas de ocorrência\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eO cliente clica repetidamente no botão de pagamento\u003c/li\u003e\n\u003cli\u003eO cliente atualiza a página logo após o pagamento ou clica em voltar\u003c/li\u003e\n\u003cli\u003eA mesma solicitação é reenviada por atraso na rede móvel\u003c/li\u003e\n\u003cli\u003eA resposta de aprovação do pagamento foi bem-sucedida, mas o armazenamento no servidor do serviço falhou\u003c/li\u003e\n\u003cli\u003eO webhook e o redirecionamento do cliente alteram o status do pedido ao mesmo tempo\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#design-de-defesa\" class=\"anchor\" id=\"design-de-defesa\"\u003e\u003c/a\u003eDesign de defesa\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMecanismo de defesa\u003c/th\u003e\n\u003cth\u003eDescrição\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de defesa\"\u003eBloqueio do botão no cliente\u003c/td\u003e\n\u003ctd data-label=\"Descrição\"\u003eImpede novo clique após o clique no botão de pagamento, mas deve ser usado apenas como recurso auxiliar\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de defesa\"\u003eBloqueio do pedido no servidor\u003c/td\u003e\n\u003ctd data-label=\"Descrição\"\u003eProcessa para que solicitações de aprovação de pagamento para o mesmo ID de pedido não sejam executadas simultaneamente\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de defesa\"\u003eChave de idempotência\u003c/td\u003e\n\u003ctd data-label=\"Descrição\"\u003eUsa um identificador para que, mesmo enviando a mesma solicitação de pagamento várias vezes, o resultado seja criado apenas uma vez\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de defesa\"\u003eNúmero de transação único\u003c/td\u003e\n\u003ctd data-label=\"Descrição\"\u003eImpede 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\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de defesa\"\u003eValidação baseada em status\u003c/td\u003e\n\u003ctd data-label=\"Descrição\"\u003eBloqueia solicitação adicional de aprovação para pedidos que já estão \u003ccode\u003epaid\u003c/code\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mecanismo de defesa\"\u003eTratamento de webhooks duplicados\u003c/td\u003e\n\u003ctd data-label=\"Descrição\"\u003eProcessa para que, mesmo que o mesmo evento de webhook chegue várias vezes, a alteração de status ocorra apenas uma vez\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAo 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”.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-mensagens-de-falha-de-pagamento-falha-n%C3%A3o-%C3%A9-acidente-%C3%A9-fluxo-normal\" class=\"anchor\" id=\"5-mensagens-de-falha-de-pagamento-falha-não-é-acidente-é-fluxo-normal\"\u003e\u003c/a\u003e5. Mensagens de falha de pagamento: falha não é acidente, é fluxo normal\u003c/h2\u003e\n\u003cp\u003eFalhas 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.\u003c/p\u003e\n\u003cp\u003eUma 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á.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#exemplos-de-mensagens-recomendadas\" class=\"anchor\" id=\"exemplos-de-mensagens-recomendadas\"\u003e\u003c/a\u003eExemplos de mensagens recomendadas\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituação\u003c/th\u003e\n\u003cth\u003eOrientação recomendada\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação\"\u003eSaldo insuficiente\u003c/td\u003e\n\u003ctd data-label=\"Orientação recomendada\"\u003eO 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.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação\"\u003eLimite excedido\u003c/td\u003e\n\u003ctd data-label=\"Orientação recomendada\"\u003eO 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.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação\"\u003eFalha de autenticação\u003c/td\u003e\n\u003ctd data-label=\"Orientação recomendada\"\u003eComo 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.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação\"\u003eErro de rede\u003c/td\u003e\n\u003ctd data-label=\"Orientação recomendada\"\u003eA confirmação do resultado do pagamento está atrasada. Para evitar pagamento duplicado, verifique o histórico de pagamentos daqui a pouco.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação\"\u003ePedido expirado\u003c/td\u003e\n\u003ctd data-label=\"Orientação recomendada\"\u003eO tempo de espera pelo pagamento passou e o pedido expirou. Selecione os produtos novamente e faça o pedido.\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-essenciais-da-orienta%C3%A7%C3%A3o-de-falha\" class=\"anchor\" id=\"elementos-essenciais-da-orientação-de-falha\"\u003e\u003c/a\u003eElementos essenciais da orientação de falha\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDiga claramente se o pagamento realmente não foi concluído.\u003c/li\u003e\n\u003cli\u003eInforme por quanto tempo o pedido será mantido.\u003c/li\u003e\n\u003cli\u003eOriente se é possível tentar novamente ou se deve usar outro meio de pagamento.\u003c/li\u003e\n\u003cli\u003eMostre o número do pedido necessário ao entrar em contato com o atendimento ao cliente.\u003c/li\u003e\n\u003cli\u003eQuando 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.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-p%C3%A1gina-de-hist%C3%B3rico-de-pagamentos-a-tela-essencial-para-reduzir-o-atendimento-ao-cliente\" class=\"anchor\" id=\"6-página-de-histórico-de-pagamentos-a-tela-essencial-para-reduzir-o-atendimento-ao-cliente\"\u003e\u003c/a\u003e6. Página de histórico de pagamentos: a tela essencial para reduzir o atendimento ao cliente\u003c/h2\u003e\n\u003cp\u003eSe 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#informa%C3%A7%C3%B5es-a-incluir-na-p%C3%A1gina-de-hist%C3%B3rico-de-pagamentos\" class=\"anchor\" id=\"informações-a-incluir-na-página-de-histórico-de-pagamentos\"\u003e\u003c/a\u003eInformações a incluir na página de histórico de pagamentos\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eNúmero do pedido\u003c/li\u003e\n\u003cli\u003eData e hora do pedido e data e hora do pagamento\u003c/li\u003e\n\u003cli\u003eNome do produto, quantidade, opções\u003c/li\u003e\n\u003cli\u003eMeio de pagamento e número de aprovação ou identificador de transação\u003c/li\u003e\n\u003cli\u003eValor dos produtos, descontos, frete, valor usado em pontos, valor final pago\u003c/li\u003e\n\u003cli\u003eStatus atual do pedido e status do reembolso\u003c/li\u003e\n\u003cli\u003eData de solicitação de reembolso, data de aprovação do reembolso, data prevista de conclusão do reembolso\u003c/li\u003e\n\u003cli\u003ePossibilidade de cancelamento ou reembolso\u003c/li\u003e\n\u003cli\u003eLinks para verificar recibo, demonstrativo da transação e recibo em dinheiro\u003c/li\u003e\n\u003cli\u003eInformações necessárias ao consultar o atendimento ao cliente\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#conex%C3%A3o-com-a-tela-do-operador\" class=\"anchor\" id=\"conexão-com-a-tela-do-operador\"\u003e\u003c/a\u003eConexão com a tela do operador\u003c/h3\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-local-do-aviso-da-pol%C3%ADtica-de-reembolso-se-esconder-deixa-de-ser-pol%C3%ADtica-e-vira-risco\" class=\"anchor\" id=\"7-local-do-aviso-da-política-de-reembolso-se-esconder-deixa-de-ser-política-e-vira-risco\"\u003e\u003c/a\u003e7. Local do aviso da política de reembolso: se esconder, deixa de ser política e vira risco\u003c/h2\u003e\n\u003cp\u003eNã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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#bons-locais-de-aviso\" class=\"anchor\" id=\"bons-locais-de-aviso\"\u003e\u003c/a\u003eBons locais de aviso\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003ePróximo ao preço ou ao botão de compra na página de detalhes do produto\u003c/li\u003e\n\u003cli\u003eTela do carrinho ou do formulário de pedido\u003c/li\u003e\n\u003cli\u003eÁrea de consentimento com os termos e a política de reembolso logo acima do botão de pagamento\u003c/li\u003e\n\u003cli\u003ePágina de conclusão do pagamento\u003c/li\u003e\n\u003cli\u003eTela de detalhes do pedido em Minha Página\u003c/li\u003e\n\u003cli\u003eTela de solicitação de reembolso\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#designs-a-evitar\" class=\"anchor\" id=\"designs-a-evitar\"\u003e\u003c/a\u003eDesigns a evitar\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDesign 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\u003c/li\u003e\n\u003cli\u003eDesign que esconde o botão de cancelamento dentro de várias etapas\u003c/li\u003e\n\u003cli\u003eDesign que mostra as condições de restrição de reembolso apenas depois do pagamento\u003c/li\u003e\n\u003cli\u003eDesign que posiciona cor, texto e ordem dos botões de forma a induzir o cliente ao erro\u003c/li\u003e\n\u003cli\u003eDesign que não informa claramente a cobrança automática após o fim do teste grátis\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEsses 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#checklist-para-incluir-no-prompt-a-ser-dado-%C3%A0-ai\" class=\"anchor\" id=\"checklist-para-incluir-no-prompt-a-ser-dado-à-ai\"\u003e\u003c/a\u003eChecklist para incluir no prompt a ser dado à AI\u003c/h2\u003e\n\u003cp\u003eAo 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#exemplo-de-prompt-para-fun%C3%A7%C3%A3o-de-pagamento\" class=\"anchor\" id=\"exemplo-de-prompt-para-função-de-pagamento\"\u003e\u003c/a\u003eExemplo de prompt para função de pagamento\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eImplemente a função de pagamento de um serviço de comércio eletrônico voltado a consumidores coreanos.\n\u003c/span\u003e\u003cspan\u003eReflita obrigatoriamente as seguintes políticas.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Os status do pedido usam payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired.\n\u003c/span\u003e\u003cspan\u003e2. Pedidos aguardando pagamento devem ser alterados para expired após 30 minutos.\n\u003c/span\u003e\u003cspan\u003e3. Para o mesmo pedido, permita apenas 1 aprovação de pagamento e use bloqueio do pedido no servidor e chave de idempotência.\n\u003c/span\u003e\u003cspan\u003e4. Webhooks de pagamento podem ser recebidos de forma duplicada, portanto o mesmo ID de evento deve ser processado apenas uma vez.\n\u003c/span\u003e\u003cspan\u003e5. 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.\n\u003c/span\u003e\u003cspan\u003e6. 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.\n\u003c/span\u003e\u003cspan\u003e7. Em caso de falha no pagamento, retorne mensagens de orientação ao cliente por motivo de falha.\n\u003c/span\u003e\u003cspan\u003e8. Permita que o cliente verifique o histórico de pagamentos e o status de reembolso em Minha Página.\n\u003c/span\u003e\u003cspan\u003e9. 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.\n\u003c/span\u003e\u003cspan\u003e10. Se houver alguma política não definida, faça perguntas antes de escrever o código.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eA ú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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#fun%C3%A7%C3%B5es-necess%C3%A1rias-na-tela-do-operador\" class=\"anchor\" id=\"funções-necessárias-na-tela-do-operador\"\u003e\u003c/a\u003eFunções necessárias na tela do operador\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eFunção administrativa\u003c/th\u003e\n\u003cth\u003eMotivo da necessidade\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Função administrativa\"\u003eLista de reembolsos pendentes\u003c/td\u003e\n\u003ctd data-label=\"Motivo da necessidade\"\u003eNecessária para não deixar passar reembolsos que precisam ser processados\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Função administrativa\"\u003eExibição do prazo legal de processamento\u003c/td\u003e\n\u003ctd data-label=\"Motivo da necessidade\"\u003eNecessária para reduzir o risco de atraso no reembolso\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Função administrativa\"\u003eAlertas de prazo próximo/excedido\u003c/td\u003e\n\u003ctd data-label=\"Motivo da necessidade\"\u003eNecessários para que o operador perceba imediatamente critérios internos como 3 dias úteis\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Função administrativa\"\u003eSeleção do motivo do reembolso\u003c/td\u003e\n\u003ctd data-label=\"Motivo da necessidade\"\u003eNecessária para estatísticas e alocação de custos, como simples arrependimento, defeito do produto e envio incorreto\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Função administrativa\"\u003ePrévia do cálculo de reembolso parcial\u003c/td\u003e\n\u003ctd data-label=\"Motivo da necessidade\"\u003eNecessária para reduzir erros de cálculo manual do operador\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Função administrativa\"\u003eLogs de processamento\u003c/td\u003e\n\u003ctd data-label=\"Motivo da necessidade\"\u003eNecessários para responder a disputas e auditorias\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Função administrativa\"\u003eGestão de permissões\u003c/td\u003e\n\u003ctd data-label=\"Motivo da necessidade\"\u003eNecessária para restringir aprovação de reembolso e alteração forçada de status\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#configura%C3%A7%C3%A3o-m%C3%ADnima-do-modelo-de-dados-de-pagamento\" class=\"anchor\" id=\"configuração-mínima-do-modelo-de-dados-de-pagamento\"\u003e\u003c/a\u003eConfiguração mínima do modelo de dados de pagamento\u003c/h2\u003e\n\u003cp\u003eA estrutura de dados varia conforme o serviço, mas é recomendável separar, no mínimo, os dados no nível abaixo.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTabela ou objeto\u003c/th\u003e\n\u003cth\u003eCampos principais\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabela ou objeto\"\u003ePedido\u003c/td\u003e\n\u003ctd data-label=\"Campos principais\"\u003eID 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\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabela ou objeto\"\u003eProduto do pedido\u003c/td\u003e\n\u003ctd data-label=\"Campos principais\"\u003eID do produto, nome do produto, opções, quantidade, valor por produto, valor de desconto alocado por produto\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabela ou objeto\"\u003ePagamento\u003c/td\u003e\n\u003ctd data-label=\"Campos principais\"\u003eID do pagamento, ID do pedido, meio de pagamento, número de aprovação, valor aprovado, status do pagamento, data e hora da aprovação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabela ou objeto\"\u003eReembolso\u003c/td\u003e\n\u003ctd data-label=\"Campos principais\"\u003eID 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\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabela ou objeto\"\u003eHistórico de status\u003c/td\u003e\n\u003ctd data-label=\"Campos principais\"\u003eID do alvo, status anterior, status alterado, responsável pela alteração, motivo da alteração, data e hora da alteração\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabela ou objeto\"\u003eConsentimento com termos\u003c/td\u003e\n\u003ctd data-label=\"Campos principais\"\u003eTipo de termos, versão dos termos, existência de consentimento, data e hora do consentimento, ID do cliente\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eO 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#lista-de-verifica%C3%A7%C3%A3o-antes-do-lan%C3%A7amento\" class=\"anchor\" id=\"lista-de-verificação-antes-do-lançamento\"\u003e\u003c/a\u003eLista de verificação antes do lançamento\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMesmo que o botão de pagamento seja pressionado 10 vezes para o mesmo pedido, o pagamento é aprovado apenas 1 vez?\u003c/li\u003e\n\u003cli\u003eSe o armazenamento no servidor falhar após a aprovação do pagamento, é possível recuperar?\u003c/li\u003e\n\u003cli\u003eMesmo que o webhook de pagamento envie o mesmo evento várias vezes, ele não é processado de forma duplicada?\u003c/li\u003e\n\u003cli\u003eO cliente consegue entender o motivo da falha de pagamento e o método de nova tentativa?\u003c/li\u003e\n\u003cli\u003ePedidos aguardando pagamento expiram automaticamente após determinado tempo?\u003c/li\u003e\n\u003cli\u003eO valor do reembolso parcial está de acordo com as políticas de cupons, pontos e frete?\u003c/li\u003e\n\u003cli\u003eDa data de solicitação de reembolso até o prazo final de processamento, essas informações são exibidas na tela do administrador?\u003c/li\u003e\n\u003cli\u003eA política de reembolso pode ser verificada facilmente na tela antes do pagamento?\u003c/li\u003e\n\u003cli\u003eConteúdo digital ou produtos com restrição de reembolso têm aviso prévio e log de consentimento?\u003c/li\u003e\n\u003cli\u003eO cliente consegue verificar diretamente o histórico de pagamentos e o status de reembolso em Minha Página?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclus%C3%A3o\" class=\"anchor\" id=\"conclusão\"\u003e\u003c/a\u003eConclusão\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003cp\u003eSe 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”.\u003c/p\u003e\n","tags":["Desenvolvimento de IA","Sistema de pagamento","Política de reembolso","Lei de comércio eletrônico","Padrões obscuros"],"faqs":[{"question":"O que deve ser definido primeiro ao pedir para a IA criar uma funcionalidade de pagamento?","answer":"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."},{"question":"Por que é perigoso deixar o status do pedido apenas como pedido concluído?","answer":"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."},{"question":"A regra de 7 dias para desistência de compra no comércio eletrônico coreano sempre se aplica?","answer":"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."},{"question":"Até quando o reembolso deve ser processado?","answer":"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."},{"question":"Qual é o item que mais frequentemente causa problemas em reembolsos parciais?","answer":"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."},{"question":"É possível impedir pagamentos duplicados apenas desativando o botão no frontend?","answer":"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."},{"question":"O que deve constar na mensagem de orientação sobre falha no pagamento?","answer":"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."},{"question":"Por que a página de histórico de pagamentos é indispensável?","answer":"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."},{"question":"É suficiente que a política de reembolso esteja apenas na página de termos?","answer":"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."},{"question":"Qual frase deve obrigatoriamente ser incluída no prompt de IA?","answer":"É 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."},{"question":"Quais funcionalidades de reembolso são necessárias na tela do administrador?","answer":"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."},{"question":"As mesmas regras de reembolso podem ser aplicadas também a pagamentos de conteúdo digital?","answer":"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":[{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"Centro Nacional de Informações Legislativas: Lei sobre a Proteção do Consumidor no Comércio Eletrônico etc.","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령","title":"Centro Nacional de Informações Legislativas: Decreto de Execução da Lei sobre a Proteção do Consumidor no Comércio Eletrônico etc.","type":"source"},{"url":"https://stripe.com/docs/idempotency","title":"Stripe Docs: Solicitações idempotentes","type":"source"},{"url":"https://docs.tosspayments.com/guides/v2/get-started/payment-flow","title":"Toss Payments Docs: Fluxo de integração de pagamentos","type":"source"},{"url":"https://www.ftc.go.kr/","title":"Comissão de Comércio 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/en/articles/ai-payment-feature-7-core-decisions"}