O cliente recebeu a referência Multibanco. A sua loja já está a tratar a encomenda como paga?

O cliente escolhe Multibanco, recebe uma entidade e uma referência e fecha o navegador. A loja mostra a página de agradecimento. No armazém, uma automação começa a preparar a encomenda porque interpretou essa página como prova de pagamento. O problema não está no método escolhido; está no significado que o site atribuiu ao fim do checkout.

Para uma loja portuguesa, integrar MB WAY e Multibanco implica desenhar estados e recuperação. O botão é a parte visível. A decisão de reservar material, confirmar uma compra ou iniciar expedição precisa de informação fiável do prestador de pagamentos e das regras comerciais da empresa.

Cada método tem o seu percurso

A apresentação oficial da SIBS Gateway distingue a geração de referências Multibanco do pedido de pagamento MB WAY. Neste último, a resposta ao envio da notificação não substitui a aceitação pelo utilizador. A documentação do prestador escolhido deve definir a interpretação concreta dos estados.

A documentação da Stripe sobre Multibanco descreve o pagamento fora do fluxo do checkout, através dos dados fornecidos, e a possibilidade de confirmação diferida. Isto mostra por que razão o regresso a uma página do site não deve ser a única condição para marcar a encomenda como paga.

Não copie limites, prazos ou possibilidades de um prestador para outro. A mesma marca de método de pagamento pode estar disponível através de produtos e contratos diferentes. Confirme as condições da conta e da integração que vai utilizar, sem prometer funcionalidades apenas porque aparecem numa demonstração.

Dê uma identidade à encomenda e outra à tentativa de pagamento

O comprador pode mudar de método, repetir uma tentativa ou abandonar uma autorização. A encomenda deve continuar identificável sem confundir todas essas ações com uma única transação. Guarde as referências necessárias para relacionar cada tentativa com a compra.

Se uma confirmação chegar depois de o cliente ter iniciado outra tentativa, o sistema precisa de reconhecer o contexto. Uma mensagem atrasada não deve criar uma segunda encomenda. Também não deve ser descartada sem análise quando representa um pagamento efetivamente concluído.

O apoio ao cliente precisa de uma vista simples: montante esperado, tentativas, estado conhecido e próxima ação. Mostrar apenas um código técnico transfere a interpretação para alguém que pode não ter acesso à documentação do prestador.

A reserva de stock exige uma política comercial

Quanto tempo deve a loja guardar uma unidade para uma referência ainda não paga? A resposta depende do produto, da procura e das capacidades do prestador. Deve ser definida pelo negócio e implementada de forma consistente no site, no ERP e nas mensagens enviadas ao cliente.

Num exemplo ilustrativo, a reserva de uma unidade termina antes de a confirmação chegar. A integração deve reconhecer a situação e encaminhá-la para a resolução acordada. Não pode prometer expedição de stock inexistente só porque recebeu um evento de pagamento válido.

O artigo sobre integração CRM–ERP e stock detalha esta responsabilidade. Quando existem vários canais de venda, o sistema que controla a disponibilidade deve participar na decisão, evitando que cada canal mantenha a sua própria versão da última unidade.

As notificações do servidor precisam de validação e repetição segura

O estado comercial deve ser atualizado através dos mecanismos suportados pelo prestador, com validação de autenticidade e controlo de acesso. Os detalhes variam entre integrações. Peça ao fornecedor que documente como verifica uma notificação e como consulta o estado quando há incerteza.

Uma notificação pode repetir-se ou chegar depois de outra mais recente. O processamento deve reconhecer operações já aplicadas e impedir regressões indevidas. Se uma encomenda está confirmada, uma mensagem antiga não deve fazê-la voltar automaticamente a aguardar pagamento.

Os erros precisam de uma fila de reconciliação. Uma indisponibilidade temporária do ERP pode impedir a atualização da encomenda mesmo depois de o pagamento estar confirmado. O cliente não deve ser convidado a pagar outra vez para resolver uma falha interna de sincronização.

Explique ao comprador o que falta fazer

Uma página com referência emitida deve mostrar os dados necessários e indicar que a confirmação será acompanhada pelo sistema. Uma tentativa MB WAY precisa de instruções adequadas ao passo em curso. Em ambos os casos, permita voltar à encomenda sem exigir que o cliente repita o formulário inteiro.

As mensagens de correio eletrónico devem usar o mesmo estado da aplicação. Evite enviar «pagamento recebido» a partir de um modelo que é acionado apenas pela criação da encomenda. A confirmação de pedido e a confirmação de pagamento podem ser mensagens diferentes.

No telemóvel, teste o regresso depois de mudar de aplicação. O visitante pode interromper a sessão do navegador para concluir o pagamento. A experiência deve recuperar a encomenda e consultar o estado atual, em vez de apresentar um erro porque perdeu um dado temporário da página.

Devoluções e apoio fazem parte da entrega

Defina quem pode iniciar uma devolução, o que precisa de aprovar e como a loja acompanha o resultado. A ação deve ter uma referência e um histórico. Uma devolução pedida não é necessariamente uma devolução concluída.

Inclua no teste uma tentativa falhada, uma notificação duplicada, uma confirmação tardia e uma indisponibilidade do sistema de encomendas. Utilize o ambiente de testes do prestador e dados próprios para esse fim. O objetivo é provar o percurso sem criar transações reais desnecessárias.

Uma loja também precisa de recuperar de falhas mais amplas; veja o guia de alojamento e recuperação de encomendas. A Innovation T pode integrar checkout e operação através dos seus serviços de desenvolvimento. Indique a plataforma, o prestador de pagamentos e o problema que quer resolver para definir uma implementação verificável.

Perguntas frequentes

Emitir uma referência Multibanco significa receber o pagamento?

Não. A referência permite ao cliente iniciar o pagamento. A loja deve aguardar a confirmação apropriada do prestador antes de executar ações que dependem de pagamento recebido.

Um pedido MB WAY aceite pela API já está pago?

Não deve assumir isso. A SIBS distingue o envio da notificação da aceitação pelo utilizador. A integração tem de interpretar o estado efetivo do pagamento segundo a documentação do prestador.

Como tratar uma confirmação que chega depois de libertar o stock?

Encaminhe o caso para uma regra explícita de reconciliação e resolução comercial. Não confirme uma expedição impossível nem repita cobranças para tentar corrigir a situação.