Segurança e confiança
A Scorpaq está a ser desenvolvida para manter separados os dados do seu estabelecimento, atribuir à equipa acessos adequados ao trabalho e verificar os resultados dos pagamentos. O objetivo é gerir o serviço mantendo o controlo dos seus dados e pagamentos.
A segurança é um limite de todo o sistema, não apenas uma função da interface.
Esta página descreve princípios de conceção durante o desenvolvimento. Não afirma auditoria independente, certificação ou um serviço de produção totalmente ativo.
Os dados de negócios e espaços de trabalho são concebidos para permanecer separados. O acesso limita-se ao espaço e ao âmbito autorizados.
Cada pedido de dados precisa de um contexto de negócio autorizado; conhecer um identificador não deve bastar para ler um registo. O acesso entre negócios deve ser rejeitado no ponto de controlo, não apenas ocultado na interface.
O privilégio mínimo separa as responsabilidades do proprietário, gestor, equipa de sala e cozinha.
Os papéis devem seguir preparação, serviço, gestão e propriedade. Abrir um ecrã não deve dar ao pessoal acesso automático a definições sensíveis ou a todos os dados.
O servidor e o fornecedor verificam o pagamento. Uma página de sucesso ou de retorno no navegador não é prova de pagamento.
Uma interrupção no regresso ao navegador não deve determinar o estado real do pagamento. Resultados incertos ficam pendentes até aos controlos do servidor e do prestador.
São preferidos pagamentos alojados pelo fornecedor para que os dados brutos do cartão não tenham de entrar na lógica, registos ou análises da Scorpaq.
Os dados do cartão pertencem à página do prestador compatível, não às mensagens de contacto. O redirecionamento estabelece um limite de dados, não certifica todas as configurações.
A Scorpaq não guarda nem redistribui fundos dos hóspedes. O fluxo entre fornecedor e negócio permanece fora da plataforma.
A relação do negócio com o prestador determina o tratamento dos fundos dos clientes. É distinta da subscrição Scorpaq e não torna a Scorpaq o comerciante que guarda esses fundos.
Minimização de dados, ausência de conta obrigatória e ausência de identidade persistente ou impressão digital entre negócios são princípios de base.
O site informativo e a futura plataforma para clientes têm fluxos diferentes. Consulte o aviso do site para campos, proveniência e escolha comercial; não deduza dele uma política de produção.
A conceção inclui TLS, segredos geridos e verificação de identidade com OIDC/JWKS quando aplicável.
As credenciais devem ficar fora do código público e dos ficheiros do cliente. São princípios técnicos, não um inventário de regiões de alojamento ou uma garantia sobre cada configuração.
Idempotência, proteção contra repetição e estado duradouro das transações ajudam a recuperar com segurança resultados incertos.
Uma repetição técnica deve reutilizar a identidade da transação sem criar outra operação. A recuperação deve preservar o conhecido e indicar verificações pendentes, sem tratar incerteza como sucesso.
Os estados de transação e eventos operacionais necessários são concebidos para serem duradouros e auditáveis.
As alterações relevantes precisam de contexto de negócio e transação para investigar problemas. Isto não fixa um prazo público de conservação nem promete todos os eventos internos a cada utilizador.
As análises devem representar honestamente os dados observados. Dados frágeis não se tornam certezas; o texto livre dos hóspedes não é uma entrada publicitária ou de criação de perfis por defeito.
Os painéis de exemplo ilustram a abordagem, não medições de clientes. Custos incompletos não permitem medir toda a rentabilidade; os limites de qualidade devem acompanhar as análises.
Utilize a página de Contacto existente.
Escolha privacidade/dados para exercer direitos, ou descreva a página e o comportamento afetados numa questão de segurança. Não envie palavras-passe, dados completos de cartão ou documentos de identificação no primeiro contacto.