PSD3 e PSR: o que os comerciantes realmente têm de mudar

Ao abrigo da PSD2, as regras de conduta do dia a dia — prazos de reembolso, responsabilidade por fraude, tratamento de reclamações — eram definidas por uma diretiva. As diretivas não se aplicam diretamente. Cada um dos 27 Estados-Membros teve de transpor a PSD2 para o seu direito nacional, cada um com o seu próprio calendário, as suas próprias lacunas e a sua própria interpretação local. Um comerciante a operar em cinco países da UE estava, na prática, a operar segundo cinco regulamentos ligeiramente diferentes, ainda que todos afirmassem implementar "a mesma" diretiva.

O novo pacote divide o trabalho de forma diferente. A PSD3 continua a ser uma diretiva e abrange principalmente o licenciamento, a supervisão e o acesso ao mercado das instituições de pagamento — o tipo de matéria que afeta o estatuto regulatório do seu PSP, não o seu checkout. As regras de conduta que realmente afetam os comerciantes — responsabilidade por fraude, obrigações de reembolso, requisitos de autenticação, tratamento de reclamações — passam para o PSR, um regulamento. Os regulamentos aplicam-se diretamente e de forma idêntica em todos os Estados-Membros, sem etapa de transposição nacional e sem margem para peculiaridades de redação local.

Segundo análises jurídicas dos textos acordados, trata-se de uma resposta deliberada ao problema de fragmentação criado pela PSD2 — o PSR foi concebido para dar aos comerciantes e aos PSP um único regulamento uniforme, em vez de 27 variantes locais (a análise da Freshfields sobre os textos acordados). Para os comerciantes, isto significa que a revisão de conformidade que faz para a sua entidade alemã deverá, uma vez aplicado o PSR, produzir as mesmas respostas que a revisão para a sua entidade irlandesa ou portuguesa. É uma simplificação genuína, mas também significa que já não existe o argumento de recurso "o regulador local é mais permissivo quanto a isto".

As regras de responsabilidade da PSD2 foram construídas em torno de uma ideia bastante restrita de transação "não autorizada" — aquela que o cliente não aprovou. A fraude evoluiu desde então. Os esquemas de engenharia social, em que um fraudador se faz passar por um funcionário bancário ou convence um cliente a autorizar diretamente uma transferência, produzem tecnicamente uma transação "autorizada" segundo o quadro antigo, o que historicamente deixava o cliente (e, por extensão, o comerciante que dependia desse pagamento) com menos meios de recurso.

O PSR amplia a responsabilidade em algumas direções relevantes para os comerciantes:

• A fraude baseada em spoofing — em que um fraudador se faz passar pela equipa ou marca de um PSP — transfere mais responsabilidade para os prestadores de serviços de pagamento, em vez de deixar o cliente a absorver a perda.
• As falhas em oferecer ou aplicar corretamente a autenticação forte do cliente (SCA) atribuem a responsabilidade à parte da cadeia que não a aplicou devidamente, o que inclui os acquirers e, em alguns fluxos, os comerciantes que contornam a autenticação.
• O tratamento lento das denúncias de fraude por parte de um PSP pode, por si só, gerar responsabilidade, o que se destina a pressionar os bancos e os PSP a acelerar o tempo de resposta a denúncias de fraude, em vez de tratar cada reclamação como uma investigação prolongada.

Para um comerciante, o efeito prático é que as disputas de fraude vão depender cada vez mais das provas do que aconteceu durante a autenticação, e não apenas de o cliente alegar que não autorizou o pagamento. Isto torna os seus registos de autenticação e os dados de resultado da SCA parte das suas provas em disputas, e não apenas um registo de conformidade que guarda e esquece.

Uma das mudanças mais concretas para os fluxos de checkout envolve verificar se o nome associado a uma conta corresponde efetivamente a quem o pagador pensa que está a enviar o dinheiro. Isto baseia-se no mecanismo de Verificação do Beneficiário (VoP) já exigido para transferências instantâneas de crédito ao abrigo do Regulamento de Pagamentos Instantâneos da UE, e o novo pacote de pagamentos estende essa lógica a mais serviços de pagamento.

Na prática, a VoP significa que o banco do pagador verifica o nome do titular da conta em confronto com o IBAN antes de a transferência se concluir, assinalando uma discrepância — "sem correspondência" ou "correspondência aproximada" — ao pagador antes de este confirmar o pagamento. Isto visa diretamente a fraude por transferência autorizada indevidamente induzida, em que um cliente é enganado para transferir dinheiro para uma conta que não é quem pensa que é.

Para os comerciantes, isto afeta qualquer fluxo em que um cliente inicia uma transferência bancária para lhe pagar — métodos de pagamento de conta para conta, pagamentos iniciados por open banking, ou qualquer etapa do checkout em que apresente os dados do beneficiário para o cliente concluir uma transferência:

• O nome legal registado na sua conta bancária comercial tem de corresponder exatamente ao nome comercial que os clientes veem na sua página de checkout, ou os clientes começarão a ver avisos de discrepância que parecem sinais de fraude, mesmo quando nada está errado.
• Se opera sob um nome comercial diferente do nome da sua entidade legal, este é o momento de os alinhar ou de garantir que o seu checkout explica claramente a discrepância antes de o cliente se confrontar com um aviso de VoP a meio do pagamento.
• Qualquer documentação interna que liste os dados da sua conta de liquidação para fins de reconciliação deve ser verificada em confronto com o que está efetivamente registado no seu banco, uma vez que um registo desatualizado surgirá como uma discrepância para todos os clientes que utilizem um método baseado em transferência.

Este é um caso em que uma verificação administrativa de cinco minutos — confirmar que o nome registado na conta bancária corresponde à marca da sua loja — evita uma onda de confusão junto dos clientes quando as verificações do tipo VoP estiverem plenamente em vigor.

A PSD2 deu aos bancos gestores de contas duas opções para expor dados de conta a terceiros: uma API dedicada, ou uma interface de recurso construída sobre os seus ecrãs de banca online já existentes, orientados ao cliente. Na prática, as interfaces de recurso eram frequentemente mais lentas, menos fiáveis e mantidas de forma inconsistente, o que tornava os fluxos de checkout baseados em open banking — opções de pagamento direto por banco, informação de conta para avaliação de risco e funcionalidades semelhantes — menos fiáveis do que os pagamentos por cartão.

O novo quadro reforça isto. Os bancos enfrentarão obrigações mais claras e mais aplicáveis quanto ao desempenho da interface dedicada — mais próximas da paridade com a fiabilidade dos seus próprios canais orientados ao cliente, com expectativas definidas quanto a tempo de atividade e tempos de resposta, em vez do padrão pouco exigente de "esforço razoável" que caracterizou partes da implementação da PSD2 (a análise da MoFo sobre os desenvolvimentos da PSD3/PSR).

Para os comerciantes que oferecem ou estão a considerar opções de checkout de pagamento direto por banco ou outras opções de conta para conta, isto é relevante de duas formas:

• Menos tentativas de autorização falhadas ou com tempo esgotado deverão significar menos carrinhos abandonados em métodos de pagamento baseados em transferência, que historicamente tinham um desempenho inferior ao dos cartões na taxa de conclusão, em parte devido à fiabilidade da interface.
• Se depende de serviços de informação de conta para decisões de risco — verificar a titularidade da conta ou consultar saldos antes de expedir encomendas de elevado valor — esses fluxos de dados deverão tornar-se mais consistentes para construir fluxos de trabalho em torno deles, em vez de exigirem lógica de repetição e tratamento de contingência.

Nada disto elimina a necessidade de testar a sua integração face ao comportamento real dos bancos, uma vez as regras em vigor. Significa, sim, que a fiabilidade de base que está a testar deverá melhorar.

Esta é a parte que fica de fora da maioria dos resumos jurídicos. Eis o que se altera do seu lado.

Os seus contratos com o PSP e o acquirer. Reveja as cláusulas de alocação de responsabilidade nos seus acordos de serviços de pagamento em vigor. Nos contratos da era PSD2, a linguagem sobre responsabilidade assumia frequentemente a definição antiga, mais restrita, de "transação não autorizada" e as antigas regras de isenção da SCA. Uma vez aplicadas as disposições de responsabilidade do PSR, os contratos que não tenham sido atualizados poderão remeter para normas que já não correspondem à lei, criando ambiguidade precisamente quando precisa de clareza — a meio de uma disputa. Pergunte diretamente ao seu PSP se as suas condições padrão para comerciantes serão atualizadas para refletir a alocação de responsabilidade do PSR, e obtenha a resposta por escrito, em vez de assumir que está tratado.

• O seu fluxo de checkout. Três alterações concretas a verificar:
• Confirme que o nome legal associado à sua conta de liquidação corresponde à marca da sua loja, para evitar avisos de discrepância de VoP desnecessários em métodos de pagamento baseados em transferência.
• Garanta que o seu fluxo de desafio de SCA (3DS ou equivalente) degrada de forma controlada — um cliente que abandona uma compra porque uma etapa de autenticação falhou tecnicamente, e não porque a recusou, é exatamente o cenário que as novas regras de responsabilidade foram concebidas para detetar, e não quer estar do lado errado disso quando uma disputa for revista.
• Se oferece pagamento direto por banco ou outras opções de conta para conta, planeie voltar a testar as taxas de conclusão uma vez em vigor as novas obrigações de desempenho das API — os pressupostos de fiabilidade em torno dos quais construiu a sua lógica de contingência podem deixar de ser a restrição vinculativa.

• O seu processo de disputas. As provas que decidem uma disputa de fraude ou um chargeback estão a mudar. Enquanto as disputas da era PSD2 dependiam frequentemente de saber se a SCA foi ou não aplicada, as disputas da era PSR dependerão mais frequentemente de como foi aplicada, de se foi realizada uma verificação VoP e qual o resultado devolvido, e da rapidez com que uma denúncia de fraude foi escalada. Isto significa que:
• A sua equipa de suporte precisa de acesso aos registos de resultado da autenticação, e não apenas ao estado da transação, ao responder a uma disputa.
• A sua documentação para submissão de provas deve ser atualizada para incluir os resultados de correspondência/sem correspondência do VoP como campo padrão, uma vez que esses dados existam nos seus registos de transação.
• Os SLA internos para escalar denúncias de suspeita de fraude ao seu PSP devem tornar-se mais exigentes, já que o atraso está a tornar-se, por si só, um fator de responsabilidade e não uma etapa administrativa neutra.

A mudança da PSD2 para o PSR tem menos a ver com o aparecimento de novas obrigações do nada e mais com o encerramento de lacunas já existentes.

Os comerciantes que trataram a responsabilidade por fraude, a SCA e as provas em disputas como "aquilo que o banco local disser" vão descobrir que essa resposta deixa de valer quando o mesmo texto regulatório se aplica em todos os Estados-Membros. O trabalho é administrativo — atualizar contratos, textos de checkout e modelos de provas — mas tem de acontecer antes da aplicação geral, não depois de a primeira disputa ao abrigo das novas regras expor a lacuna.

Nada disto exige reconstruir o seu checkout do zero. Exige tratar o seu contrato com o PSP, os dados registados da sua conta e os seus modelos de provas em disputas como documentos vivos que precisam de uma revisão num calendário específico — que é precisamente o propósito da checklist abaixo.

A data exata de aplicação geral depende de quando o Jornal Oficial publicar o texto final, mas a sequência está fixada. Use isto como um calendário de trabalho, e não como um prazo fixo, e confirme as datas assim que a publicação no Jornal Oficial for confirmada.

• Até ao 4.º trimestre de 2026 — Prevê-se a publicação no Jornal Oficial (junho–julho de 2026). Uma vez publicada, calcule a sua data firme de aplicação geral a 21 meses e coloque-a no seu calendário de conformidade. Comece já a revisão do contrato com o PSP, em vez de esperar pelo prazo.
• Ao longo de 2027 — Confirme o plano do seu PSP para atualizar as condições para comerciantes de forma a refletir a alocação de responsabilidade do PSR. Auditar o nome legal registado da sua conta de liquidação em confronto com a marca do seu checkout. Mapeie quais dos seus fluxos de checkout utilizam SCA e documente a lógica de isenção atual, para poder compará-la com os requisitos finais do PSR.
• Início de 2028 — Teste o seu processo de provas em disputas de ponta a ponta: a sua equipa de suporte consegue efetivamente obter, a pedido, os dados de resultado da SCA e de correspondência do VoP para uma transação, ou isso exige um pedido à equipa de engenharia? Corrija essa lacuna antes de ser testada por uma disputa real.
• Na aplicação geral (estimada para março–abril de 2028) — Confirme que os contratos atualizados com o PSP estão assinados, que o texto do checkout reflete quaisquer requisitos relativos ao nome do beneficiário, e que a sua documentação de disputas inclui os novos campos de prova. Trate a data de aplicação geral como o momento em que tudo o que foi referido já deveria estar em funcionamento, e não como o ponto de partida.

A Cost+ funciona com o modelo de preços IC++ (Interchange Plus Plus) precisamente porque acreditamos que os comerciantes tomam melhores decisões quando os componentes de um pagamento — interchange, scheme fee e a nossa margem — são visíveis em vez de estarem agregados. O mesmo princípio aplica-se à mudança regulatória: quanto mais cedo conseguir ver o que está realmente a alterar-se nos requisitos de responsabilidade e de prova, menos disruptiva será a transição. Se quiser falar sobre como a sua configuração atual de checkout e de disputas se enquadra no calendário do PSR, contacte a nossa equipa ou compare a sua estrutura de custos atual com os preços low-risk publicados no nosso site, enquanto revê os contratos.