O que é um gateway de pagamento em criptomoedas autoalojado
Um gateway de pagamento em criptomoedas autoalojado é um software de pagamentos que executa na sua própria infraestrutura ou numa infraestrutura que controla diretamente. Parece simples — e, por vezes, é mesmo. O gateway pode aceitar faturas, detetar pagamentos na blockchain, associá-los a encomendas e enviar atualizações de estado à sua loja ou ao seu sistema de faturação.
O essencial é o controlo. Se a sua equipa gere o servidor, decide que registos são guardados e escolhe onde ficam as cópias de segurança, também define o rasto de dados. Um fornecedor de alojamento pode continuar a tratar dados em seu nome, mas, em geral, uma configuração autoalojada significa que assume mais responsabilidades operacionais. Isto torna-se importante quando os períodos de retenção são analisados ao pormenor.
Os dados de pagamento podem abranger mais informação do que muitos comerciantes imaginam. Um endereço de carteira, um carimbo temporal, um endereço IP, um número de fatura, o e-mail de um cliente e uma nota de envio podem constar todos do mesmo registo de transação. Para compreender que dados pessoais são tratados em pagamentos cripto, examine cada campo recolhido no checkout e nos sistemas associados. Se está a planear integrar uma loja, o guia sobre gateways de pagamento em criptomoedas para comércio eletrónico é um bom ponto de partida, porque a forma como os dados são recolhidos no checkout influencia o que terá de ser eliminado mais tarde.
Há um pormenor que costuma causar confusão: «autoalojado» não significa «fora do âmbito das regras». Significa apenas que a responsabilidade operacional mudou de mãos. Os registos continuam a existir. As obrigações também.
Quando é que o RGPD se aplica ao tratamento de pagamentos em criptomoedas
O RGPD aplica-se quando são tratados dados pessoais, e este critério costuma ser mais abrangente do que os comerciantes pensam à partida. Se um gateway de pagamento em criptomoedas trata dados relativos a uma pessoa identificada ou identificável, pode estar sujeito ao RGPD, mesmo que o pagamento seja feito na blockchain. Em determinado contexto, um endereço de carteira pode ser suficiente para identificar alguém; noutro, pode não ser. O contexto é importante.
A localização do utilizador também conta. Se o pagador estiver na UE ou no EEE, ou se a sua empresa visar esses mercados, o RGPD pode aplicar-se mesmo que o servidor esteja noutro local. Uma empresa em Toronto que execute um nó em Frankfurt não fica isenta só porque a máquina está no estrangeiro. A localização do servidor é apenas uma parte da questão.
As funções das partes também são importantes. Por vezes, o comerciante é o responsável pelo tratamento. Noutras situações, o operador do gateway é o subcontratante. Há ainda configurações em que ambas as partes tomam decisões autónomas sobre retenção, verificações antifraude ou registos contabilísticos. Nesse caso, a análise pode envolver as duas partes, em vez de ter uma resposta simples e única. Esta divisão deve ficar documentada antes da emissão da primeira fatura.
Então, um gateway de pagamento em criptomoedas autoalojado está sujeito às regras de retenção de dados do RGPD? Em muitos casos comuns, sim. A designação da implementação não altera o facto de os dados pessoais poderem ser armazenados, copiados, incluídos em cópias de segurança, registados ou exportados. A questão da conformidade começa pelos dados, não pela arquitetura.
Que registos são considerados dados pessoais ao abrigo do RGPD
Ao abrigo do RGPD, os dados pessoais incluem qualquer informação relativa a uma pessoa identificada ou identificável. Num gateway de pagamento em criptomoedas, podem ir muito além de um campo com o nome. Um endereço de carteira associado à conta de um cliente, um registo de IP ligado a uma sessão de checkout ou uma nota de reembolso que mencione um cliente pelo nome podem ser considerados dados pessoais.
Os registos de faturas são outra fonte frequente de risco. Um número de fatura, por si só, pode não identificar ninguém. Mas, se for associado a um e-mail profissional, a uma morada de envio e a um carimbo temporal, a situação muda rapidamente. O mesmo se aplica aos pedidos de assistência associados a pagamentos falhados. Uma única linha num pedido pode transformar um registo técnico em dados pessoais.
Os metadados das transações são muitas vezes ignorados. Montantes, carimbos temporais, IDs de encomendas, impressões digitais do navegador e identificadores de dispositivos podem tornar-se dados pessoais se for possível associá-los a alguém, direta ou indiretamente. Essa associação pode ser feita através do CRM, do sistema de e-mail ou até de uma folha de cálculo exportada por alguém numa sexta-feira à tarde particularmente atarefada.
Os registos de atividade merecem atenção especial. Os registos de acesso, os registos de erros, os webhooks e os alertas de fraude podem conter identificadores que não são óbvios à primeira vista. Um endereço de carteira num ficheiro de depuração continua a ser um registo. Um e-mail parcialmente visível num registo de assistência também. Os pequenos detalhes importam.
Princípios do RGPD sobre retenção de dados mais relevantes
Há três princípios do RGPD que são fundamentais neste caso: limitação da conservação, limitação das finalidades e minimização dos dados. A limitação da conservação determina que não se devem guardar dados pessoais durante mais tempo do que o necessário. A limitação das finalidades exige que haja um motivo definido para os conservar. A minimização dos dados significa que só se deve guardar aquilo de que realmente se precisa.
Estes princípios parecem abstratos até alguém perguntar porque é que um registo de pagamentos de 2021 ainda está numa base de dados ativa. Se a única justificação for «talvez venha a ser preciso um dia», não é suficiente. O período de retenção tem de corresponder a uma finalidade concreta, como a gestão de estornos, a contabilidade, a análise de fraude ou as investigações de segurança. «Por precaução» não é um plano.
Os períodos de retenção têm de ser justificados. Um registo de assistência pode ser conservado durante 30 dias. Um documento fiscal pode ter de ser guardado durante anos, consoante o regime legal aplicável. Um sinal de fraude pode ser retido por menos tempo se deixar de ajudar a proteger a empresa. O mais importante não é o prazo em si, mas a razão que o justifica.
Há também uma questão prática. Se disser que os dados são conservados durante 90 dias, mas as cópias de segurança os mantiverem por 2 anos, a sua política não passa de ficção. Esta discrepância é comum. Torna as auditorias dispendiosas e as reclamações dos clientes incómodas.
Como funcionam as regras de retenção em sistemas autoalojados
O autoalojamento transfere o controlo, mas não elimina a responsabilidade. A pessoa ou a equipa que define o calendário de retenção tem de o conseguir explicar, aplicar e provar que foi cumprido. Se o comerciante gerir o gateway, é normalmente o primeiro a quem os reguladores recorrem. Se um programador gerir a infraestrutura ao abrigo de um contrato, este deve indicar quem decide sobre a retenção e a eliminação.
Esta pergunta surge em muitas análises jurídicas: quem decide durante quanto tempo os dados são conservados? Numa configuração autoalojada, a resposta é muitas vezes o comerciante, o operador ou ambos. Um fornecedor que disponibiliza o código, mas não o alojamento, pode ainda tratar dados durante a assistência ou a monitorização. Uma empresa de alojamento pode guardar cópias instantâneas por motivos operacionais próprios. Cada interveniente precisa de uma política de retenção distinta.
O autoalojamento também gera cópias. Bases de dados, cópias de segurança, armazenamento de objetos, mensagens em filas e ficheiros de registo podem conter a mesma informação de pagamento. Se um sistema eliminar os dados e outro conservar uma réplica, a retenção não foi realmente cumprida. A limpeza tem de abranger toda a cadeia, incluindo exportações automáticas e armazenamento de recuperação de desastres.
É por isso que «autoalojado» não é um atalho para contornar as obrigações do RGPD. Pode tornar as responsabilidades mais claras, mas também pode facilitar a propagação de erros. Um único script pode copiar dados pessoais para 4 locais antes da hora de almoço.
Políticas práticas de retenção para gateways de pagamento em criptomoedas
Uma boa política de retenção começa pela categorização. Os registos de atividade, as faturas, os registos de reembolsos, as verificações antifraude, as notas de assistência ao cliente e os alertas de segurança não devem ter todos o mesmo período de retenção. Um gateway que guarda tudo durante o mesmo prazo, regra geral, está a conservar dados em excesso.
Quanto aos registos de atividade, muitas equipas conservam apenas o mínimo necessário para resolver problemas e, depois, rodam e eliminam os registos de acordo com um calendário. Na prática, é comum usar períodos de 7 ou 30 dias, mas o prazo adequado depende do sistema e das necessidades da empresa. Se precisar dos registos para responder a incidentes, conserve apenas os campos necessários e remova os identificadores diretos sempre que possível. Não há motivo para manter um endereço de carteira para sempre só porque um servidor teve uma noite complicada.
As faturas e os registos contabilísticos são diferentes. Poderá ser necessário conservá-los durante mais tempo devido a obrigações fiscais e comerciais. Isso não significa que todos os campos da fatura devam continuar visíveis para toda a gente. O acesso pode ser limitado. A equipa de faturação pode precisar da fatura, mas a equipa de assistência não.
Os dados relativos a reembolsos devem ser conservados durante tempo suficiente para demonstrar quem foi pago, porquê e quando. Os registos de prevenção de fraude podem justificar um período mais longo se ajudarem a analisar padrões ou a responder a litígios. Mesmo assim, os dados devem ser revistos regularmente. Um registo que ajudou a bloquear um pagamento suspeito em março pode já não ser útil em dezembro.
Os registos de segurança têm muitas vezes o seu próprio prazo. Os registos de autenticação, de acesso administrativo e de entrega de webhooks podem ter de ser conservados durante tempo suficiente para diagnosticar ataques ou verificar o comportamento do sistema. Se utilizar o processo de verificação de webhooks, as suas notas operacionais devem refletir essa lógica. O artigo como verificar webhooks assinados do Payora é relevante, porque o tratamento de webhooks pode gerar registos que não devem ficar guardados sem uma justificação.
Alguns registos podem estar sujeitos a exceções de conservação por motivos legais. A contabilidade, os impostos, a prevenção de fraude e a resolução de litígios podem justificar a conservação de dados específicos por mais tempo do que o prazo padrão. O erro não está na exceção, mas em deixar que ela se torne a regra para tudo.
Riscos e erros comuns de conformidade
O maior erro é conservar dados durante demasiado tempo. As equipas guardam registos em bruto «por segurança», arquivam faturas antigas em três locais e esquecem-se de bases de dados de teste que ainda contêm dados reais de clientes. Passa um ano. Depois, outro. Quando alguém pergunta que dados estão armazenados, ninguém consegue dar uma resposta clara.
Outro problema frequente é não haver uma base jurídica adequada. Uma empresa pode saber que quer conservar dados, mas não saber porquê. O RGPD exige uma justificação para o tratamento, não uma vaga esperança de que os registos possam ser úteis mais tarde. Se o motivo for a prevenção de fraude, indique-o. Se for a contabilidade, indique-o. Se for a assistência, indique-o também.
O registo excessivo de dados cria riscos silenciosos. Por vezes, os programadores registam cargas úteis completas, incluindo e-mails, moradas e notas internas, porque isso facilita a depuração. E facilita mesmo. Esse é também o problema. Um único registo de erro pode armazenar mais dados pessoais do que a própria página de pagamento.
As falhas de eliminação são outro problema clássico. A política diz «eliminar após 30 dias», mas a tarefa cron falha, o restauro da cópia de segurança nunca foi testado ou uma exportação CSV fica guardada na caixa de entrada de um funcionário. O resultado é uma política de retenção que só existe no papel. As políticas em papel não garantem a conformidade com o RGPD.
Há também o problema da revisão. Um sistema que estava em conformidade no ano passado pode já não estar. São acrescentados novos campos. São integradas novas ferramentas antifraude. Surgem novas regiões de alojamento. Se ninguém rever o calendário de retenção depois de uma alteração, a política afasta-se da realidade. É nesse desfasamento que começam muitas das conclusões de não conformidade.
Como criar um processo de retenção compatível com o RGPD
Comece por mapear os dados. Enumere todos os locais onde podem surgir dados de pagamento: tabelas de bases de dados, mensagens em filas, registos de atividade, cópias de segurança, exportações para análise, pedidos de assistência e ambientes de teste dos programadores. Inclua qualquer registo que possa conter dados pessoais. Um mapa de uma página é melhor do que um palpite.
Em seguida, atribua um período de retenção a cada categoria. Registe por escrito o prazo e a respetiva justificação. Basta uma linha por categoria, desde que seja específica. Por exemplo, «registos de pagamentos: 30 dias para análise de incidentes» é muito melhor do que «conservados conforme necessário». A segunda opção não diz a ninguém o que fazer.
Depois, restrinja o acesso. Se só 2 pessoas precisam de consultar faturas, só 2 pessoas devem poder vê-las. Se os programadores precisarem de dados para testes, anonimize-os primeiro. Se a equipa de assistência precisar do histórico de transações, dê-lhe apenas o estritamente necessário. O controlo de acesso não é um pormenor: faz parte da retenção, porque os dados que não são utilizados continuam a representar um risco enquanto estiverem visíveis para demasiadas pessoas.
Sempre que possível, automatize as rotinas de eliminação. Isso implica purgas programadas, regras de expiração para cópias de segurança e um método para confirmar que a eliminação foi realmente executada. A eliminação manual pode funcionar para alguns registos, mas falha rapidamente à medida que o volume aumenta. Um mês em falta transforma-se em 12 meses antes que alguém dê conta.
Reveja também os acordos com fornecedores e de alojamento. Um gateway autoalojado pode continuar a depender de fornecedores de e-mail, armazenamento de objetos, ferramentas de monitorização ou serviços de cópias de segurança geridos. Todos eles podem armazenar dados de pagamento. Os contratos devem indicar o que é armazenado, durante quanto tempo e quem o elimina. Se estiver a mudar de plataforma, um plano de migração pode ajudar. O artigo como migrar do Stripe é relevante, porque as migrações muitas vezes copiam registos antigos de clientes para o novo sistema sem uma nova verificação do prazo de retenção.
Por fim, teste o processo. Restaure uma cópia de segurança. Verifique se os registos eliminados reaparecem. Confirme se os registos de atividade são rodados. Verifique se as faturas arquivadas só são conservadas nos locais necessários. Um processo de retenção só é real quando alguém o testa de ponta a ponta. Basta um teste falhado para revelar uma lacuna na política.
Lista prática para os próximos 30 dias
Nos próximos 7 dias, identifique os campos de dados pessoais do seu gateway de pagamento em criptomoedas e assinale quais aparecem nos registos de atividade. Nos próximos 14 dias, atribua uma justificação de retenção a cada categoria de registos. Nos próximos 30 dias, confirme separadamente se a eliminação funciona na base de dados, nos registos de atividade e nas cópias de segurança. Estes três passos cobrem muito mais do que um documento genérico de políticas.
Designe uma pessoa responsável pelo calendário de retenção. Não um comité: uma pessoa, uma pessoa suplente e uma data para a revisão. Isso facilita a próxima auditoria e evita a conversa habitual de «pensava que outra pessoa tratava disso».
Se precisar de uma referência sobre o tratamento de dados de pagamento num modelo de negócio específico, o artigo gateway de pagamento em criptomoedas para profissionais independentes pode ser útil, porque a faturação de profissionais independentes gera um conjunto limitado, mas muito comum, de registos a conservar: fatura, comprovativo de pagamento e dados de contacto.
O último passo é documentar o processo de exceção. Uma ordem de conservação legal, uma obrigação fiscal ou um caso de fraude podem justificar a retenção de dados por mais tempo. Indique quem pode aprovar essa exceção, que provas são necessárias e quando termina. Se a exceção não tiver uma data de fim, não é uma exceção: é simplesmente retenção por hábito. Uma política clara de RGPD para gateways de pagamento em criptomoedas deve definir essas regras, os responsáveis pela sua aplicação e a forma de verificar que a eliminação ocorre em todos os sistemas.
Comments