Desenvolvedor WooCommerce em Lisboa

#Vender para fora de Portugal a partir de uma loja WooCommerce

A maioria das lojas de Lisboa que nos escrevem já não fala apenas com o mercado nacional. Um produtor de cortiça quer vender para lojas de decoração em França, uma conserveira descobre que os seus pacotes de latas voam em Londres e em Amesterdão, uma marca de calçado percebe que metade das encomendas do fim de semana vêm de Espanha. O WooCommerce é uma base excelente para esse salto, porque corre sobre WordPress, não cobra comissão por venda e deixa controlar cada regra de negócio até ao detalhe. Mas passar de uma loja que fatura em euros para clientes portugueses a uma loja que vende em três línguas, duas moedas e vários regimes de IVA é um trabalho de engenharia, não de instalar mais um plugin.

O nosso ponto de partida é quase sempre o mesmo: uma loja que cresceu de forma orgânica, com uma pilha de extensões acumuladas ao longo dos anos, e que agora precisa de servir mercados de exportação sem partir. O objetivo não é reconstruir tudo do zero, é dar-lhe a estrutura que faltava para escalar com segurança. Isso significa arrumar o catálogo, separar o que é código próprio do que é tema, e ligar a loja aos sistemas que uma operação de exportação portuguesa obriga a ter, começando pela faturação.

#Faturação certificada, IVA e SAF-T: o que uma loja portuguesa não pode ignorar

Este é o ponto onde as lojas WooCommerce montadas por quem não conhece o contexto português falham primeiro. Em Portugal, faturar acima do limiar definido por lei obriga a usar software de faturação certificado pela Autoridade Tributária, e o WooCommerce, por muito completo que seja, não emite faturas certificadas. Cada fatura tem de sair com ATCUD, o código único de documento, e com o QR code que a AT exige, e os documentos têm de ser comunicados através do SAF-T e da e-Fatura. Nada disto é opcional, e nada disto vem na instalação base da loja.

A abordagem correta não é tentar transformar o WooCommerce num emissor certificado, seria uma batalha perdida contra a própria lei. A abordagem correta é integrar a loja com um sistema de faturação já certificado, como o InvoiceXpress, o Moloni, o Vendus ou o Jasmin da Primavera, através de um conector que transfere cada encomenda paga para o emissor. Quando um cliente conclui a compra e o pagamento confirma, o conector cria a fatura no sistema certificado, devolve o número, o ATCUD e o link do PDF, e anexa o documento ao email de encomenda. A responsabilidade legal fica no software certificado, onde tem de estar, e o WooCommerce fica com o que faz bem: o catálogo, o carrinho e o checkout.

O IVA merece o mesmo cuidado. Para vendas B2C dentro da União Europeia, a loja tem de aplicar a taxa do país do comprador acima do limiar comunitário e alimentar o regime OSS. Para exportação para fora da UE, o Reino Unido é o caso mais frequente desde o Brexit, a venda sai sem IVA português e passa a exigir informação aduaneira. Escrevemos estas regras uma a uma, validamo-las com o contabilista da loja e deixamo-las documentadas, porque um pressuposto de IVA errado não aparece no dia da venda, aparece no fecho do trimestre, quando já custa muito mais corrigir.

#Pagamentos que os clientes portugueses esperam ver

Um checkout que só oferece cartão perde vendas em Portugal, e perde-as em silêncio. O comprador português espera MB Way para pagar com o telemóvel em segundos, espera a referência Multibanco para quem prefere pagar depois no homebanking, e só então espera o cartão. Uma loja de exportação precisa das duas realidades ao mesmo tempo: os métodos locais para o mercado interno e o cartão internacional com carteiras móveis para quem compra de fora.

Expomos os métodos portugueses através dos agregadores que ligam à rede SIBS, tipicamente o IfthenPay, o Easypay ou o Eupago, consoante as condições e as integrações que a loja já tem. Cada um traz uma particularidade que é preciso tratar bem no código: a referência Multibanco gera uma encomenda que fica pendente até o cliente pagar, às vezes horas ou dias depois, e a loja tem de lidar com esse estado intermédio sem libertar stock cedo demais nem cancelar cedo demais. Os webhooks de confirmação têm de ser idempotentes, porque chegam repetidos, e o email ao cliente tem de distinguir com clareza uma encomenda paga de uma encomenda à espera de pagamento. São detalhes que não aparecem numa demo e que decidem se a loja funciona sob carga real.

#Multi-moeda e multi-idioma para mercados de exportação

Servir Espanha, França e o Reino Unido a partir de Lisboa é mais do que traduzir o menu. Uma loja de exportação bem construída mostra a cada visitante a moeda que ele usa, o preço já com o IVA correto do seu mercado, a língua em que se sente à vontade e as opções de envio que fazem sentido para o destino dele. Configuramos multi-moeda com EUR e GBP, e por vezes mais, com taxas de câmbio geridas em vez de deixadas ao acaso, para que o preço em libras de uma peça de cerâmica não oscile a cada atualização.

No multilingue, o par WooCommerce e WPML continua a ser a combinação mais sólida para catálogos que precisam de traduzir produtos, categorias, atributos e páginas de checkout, com o hreflang correto para que o Google mostre a versão certa a cada país. Traduzir o conteúdo de marketing é a parte fácil; a difícil é garantir que uma variação de produto, uma regra de envio ou uma mensagem de erro no pagamento também aparecem traduzidas, porque é aí que a experiência quebra para o cliente estrangeiro. Testamos o percurso completo em cada língua, do produto ao email de confirmação, não apenas a página inicial.

#Envios e transportadoras: da encomenda nacional à exportação

Os portes de envio são onde muitas lojas de exportação perdem margem sem dar por isso. Uma tabela de portes montada à pressa cobra a menos para França e a mais para o Algarve, e ninguém repara até os números do mês não fecharem. Desenhamos zonas de envio por mercado, com regras que refletem o peso real dos produtos e os escalões das transportadoras, e ligamos a loja aos serviços que os comerciantes portugueses usam de facto, a começar pela CTT e pela CTT Expresso, e conforme o caso a DPD, a GLS ou a Nacex para a exportação.

Para um produtor que envia caixas de vinho ou latas de conserva, o cálculo de portes tem de considerar o peso volumétrico e os limites por caixa, não apenas o valor da encomenda. Para uma marca de moda que expede peças leves, o critério é outro. Quando o volume justifica, integramos a geração de etiquetas e o rastreio diretamente no painel de encomendas, para que a equipa de armazém não ande a copiar moradas à mão entre o WooCommerce e o site da transportadora. O objetivo é sempre o mesmo: que o custo de envio cobrado ao cliente e o custo real pago à transportadora fiquem alinhados, encomenda a encomenda.

#Escalar para a época alta sem reescrever a loja

Muitas lojas de Lisboa concentram uma fatia grande do ano em poucas semanas, seja a campanha de Natal de uma marca D2C, seja a procura de verão por experiências e produtos regionais. O erro clássico é dimensionar o alojamento para essa ponta e pagar servidor a mais durante os outros dez meses. A alternativa é fazer com que a loja aguente a ponta sem sobredimensionar a base, e isso resolve-se com arquitetura, não com força bruta.

O princípio é separar o que pode ser servido em cache do que não pode. As páginas de produto e de categoria, iguais para todos os visitantes anónimos, podem ser entregues a partir de cache e da borda da rede a uma velocidade que o servidor de origem nunca alcançaria por pedido. O carrinho, o checkout e a área de cliente, únicos por sessão, chegam sempre ao origin, mas passam a ser uma fração do tráfego. Quem quiser levar esta camada mais longe, empurrando o cache e os redirecionamentos para a borda, encontra o padrão descrito na página de desenvolvimento Cloudflare Workers em Lisboa e no serviço de edge da Cloudflare. No lado do WooCommerce, garantimos que os fragmentos de carrinho não destroem o cache das páginas, que o Action Scheduler processa tarefas em segundo plano sem bloquear o checkout e que as queries mais pesadas do catálogo estão indexadas e medidas.

#Como estendemos o WooCommerce sem tocar no core

Uma loja de exportação acumula lógica própria: uma regra que oferece portes acima de um valor por mercado, um campo de checkout que recolhe o NIF para a fatura, um cálculo de IVA que muda com o país, uma integração que sincroniza stock com o ERP. A tentação de resolver tudo editando ficheiros do core do WooCommerce ou colando código no functions.php do tema é real, e é sempre a decisão errada. Uma loja assim deixa de poder ser atualizada em segurança, e cada atualização do Woo passa a ser uma aposta.

Trabalhamos sempre pela via oposta. As personalizações vivem num plugin próprio, separado do tema, e ligam-se ao WooCommerce através dos hooks action e filter que a plataforma expõe precisamente para isto. O tema trata da aparência, o plugin trata do comportamento, e o core fica intacto e atualizável. Onde a storefront precisa de dados que o WooCommerce não serve de forma nativa, estendemos a REST API em vez de contornar a base de dados diretamente. Onde um bloco server-side ajuda a manter uma secção de produtos consistente, usamo-lo. Cada escolha não óbvia fica registada num Architecture Decision Record, para que daqui a dois anos, com outra pessoa na sala, a razão da decisão continue legível.

#Três lojas de Lisboa, três desafios de comércio

Estes três arranques descrevem o que costuma estar em cima da mesa quando uma loja da cidade nos contacta.

O produtor a exportar cortiça e vinho: uma empresa da região vendia bem em Portugal a partir de uma loja WooCommerce simples, mas a entrada em França e no Reino Unido travou no checkout. Faltava GBP, faltava a distinção de IVA entre venda intra-UE e exportação, e a faturação era feita à mão fora da loja. Ligámos a loja ao Moloni para faturação certificada com ATCUD, configurámos multi-moeda EUR e GBP, o regime OSS para a UE e a saída sem IVA para o Reino Unido, e desenhámos zonas de envio CTT por peso volumétrico para as caixas de garrafas. A operação passou de encomendas tratadas uma a uma para um fluxo em que a fatura sai sozinha no momento do pagamento.

A loja de experiências e produtos regionais para turismo: um negócio que vende passeios, provas e caixas de produtos locais em três línguas via a procura disparar no verão e o site arrastar-se justamente quando mais interessava. O problema não era a plataforma, era a arquitetura: fragmentos de carrinho a impedir o cache, imagens de produto sem otimização e queries de catálogo lentas. Separámos a camada que podia ser servida em cache das páginas por sessão, otimizámos o pipeline de imagens e indexámos as queries pesadas. O checkout passou a oferecer MB Way e referência Multibanco além do cartão internacional, e a loja aguentou a época seguinte sem cair.

A marca D2C com assinaturas: uma marca de Lisboa vendia diretamente ao consumidor e queria acrescentar entregas recorrentes sem perder os clientes existentes. Implementámos as subscrições com faturação recorrente ligada ao emissor certificado, para que cada renovação gerasse a fatura correta, e simplificámos o checkout com MB Way expresso para reduzir o abandono. O trabalho passou por reforçar os webhooks de pagamento, de modo que uma renovação falhada seguisse um fluxo de recuperação em vez de cancelar a assinatura em silêncio.

#Quando não precisam de um programador WooCommerce dedicado

Vale a pena dizer isto com clareza, porque é a parte que quem vende desenvolvimento costuma calar. Nem toda a loja precisa de código à medida. Uma loja com poucas dezenas de produtos, um único mercado, pagamentos padrão e sem integrações especiais fica servida com um bom tema, um punhado de extensões bem escolhidas e alguém interno que saiba geri-la. Nesse cenário, contratar desenvolvimento dedicado é gastar em complexidade que ninguém vai conseguir manter, e uma loja simples e saudável vale mais do que uma arquitetura sofisticada e órfã.

Há até casos em que outra plataforma serve melhor, e digo-o por escrito quando é verdade. Um negócio de puro dropshipping sem faturação própria, ou uma loja que só quer um catálogo estático com um botão de contacto, não tira partido do que o WooCommerce oferece. O desenvolvimento WooCommerce dedicado compensa quando há razões concretas: exportação para vários mercados com moedas e IVA diferentes, integração com faturação certificada e ERP, lógica de checkout própria, subscrições, ou volume de tráfego que exige otimização a sério. Se o vosso caso não cai em nenhuma destas, dizemo-lo na primeira conversa em vez de vos vender um projeto.

#Como trabalhamos com lojas de Lisboa

Trabalhamos em modelo remote-first a partir da UE, em português ou inglês conforme a equipa, com apenas uma hora de diferença horária, o que significa reuniões dentro do horário normal dos dois lados e respostas no mesmo dia. Os contratos ficam no quadro jurídico europeu, com um interlocutor fixo e etapas aceites uma a uma, e a pessoa com quem falam é a pessoa que escreve o código, sem gestores a transmitir mensagens nem juniores a aprender no vosso projeto.

O ponto de partida é uma auditoria de catálogo e checkout: onde está o desempenho hoje, que gateways e integrações a loja tem, como está a faturação, quantos mercados e línguas serve e onde estão os riscos. A partir daí o trabalho avança em ramos de funcionalidade, com QA end-to-end nos caminhos de encomenda antes de qualquer implantação, do carrinho ao email de fatura, passando por cada gateway com os seus cartões e referências de teste. Cada etapa termina com um resultado que se sustenta sozinho, para que não fiquem presos a um megaprojeto de fim incerto.

A loja que exporta a partir de Lisboa vive de duas coisas ao mesmo tempo: cumprir a lei portuguesa de faturação e falar a língua comercial de cada mercado onde vende. É essa combinação que construímos. Para quem chega a este trabalho vindo de uma mudança de arquitetura maior, a migração para Astro e Next.js em Lisboa e o desenvolvimento WordPress em Lisboa encaixam no mesmo interlocutor, para que backend, frontend e loja não andem em três conversas separadas.

Última atualização: 10 de julho de 2026