O que vai vender na sua app: uma entrega ao domicílio, uma reserva ou acesso a conteúdos digitais? Antes de escolher os métodos de pagamento, responda a esta pergunta. As regras da App Store e do Google Play distinguem essas situações e condicionam os sistemas que pode utilizar. (developer.apple.com)

A nossa recomendação é começar pelo catálogo e pelo percurso da compra, não pelo logótipo que quer colocar no botão de pagamento. Peça à equipa de desenvolvimento que justifique a solução para cada tipo de venda.

Para uma empresa portuguesa a preparar uma app para iPhone e Android, a decisão deve ficar fechada antes de aprovar os ecrãs de compra. O objetivo é simples: saber como o cliente paga, quem confirma o pagamento e o que acontece quando a compra não corre como previsto.

Classifique a venda, não a empresa

Uma empresa pode vender produtos de naturezas diferentes na mesma app. Imagine uma escola de cerâmica que permite reservar workshops presenciais, encomendar materiais e comprar acesso a vídeos gravados. É um exemplo hipotético, mas útil: chamar a tudo «formação» não resolve a escolha do sistema de pagamento.

Nas regras da Apple, os bens físicos e serviços consumidos fora da app devem usar meios diferentes das compras integradas da App Store. No Google Play, o sistema de faturação da loja também não deve ser utilizado para bens físicos ou serviços físicos. Já o acesso pago a funcionalidades e conteúdos digitais dentro da app tem, como regra de partida, os sistemas de compra das lojas, com exceções e programas próprios. (developer.apple.com)

Use esta tabela para preparar a conversa com a equipa. É uma triagem, não uma autorização automática para cada modelo comercial.

| O que o cliente compra | Sistema a avaliar primeiro | Decisão a esclarecer |

|---|---|---|

| Materiais entregues em casa | Prestador de pagamentos externo | Como associar pagamento, encomenda e entrega? |

| Lugar num workshop presencial | Prestador de pagamentos externo | Quando fica a vaga confirmada? |

| Biblioteca de vídeos vista na app | Compras integradas das lojas | Que acesso é atribuído e durante quanto tempo? |

| Funcionalidade premium da app | Compras integradas das lojas | Como reconhecer uma compra anterior? |

| Pacote com workshop e vídeos | Análise separada das componentes | O pacote precisa de percursos de compra distintos? |

A classificação dos quatro primeiros casos segue a distinção das políticas das lojas; a separação do pacote é uma recomendação de análise para evitar pressupostos sobre uma oferta mista. (developer.apple.com)

Peça uma lista dos produtos efetivamente vendidos, com uma frase por produto: «o cliente paga para receber ou utilizar isto, neste local». Se a descrição continuar ambígua, ainda não há informação suficiente para fechar a integração.

Apple Pay não é o mesmo que uma compra da App Store

Os nomes podem confundir a discussão. A Apple menciona Apple Pay como uma opção para pagamentos de bens e serviços consumidos fora da app. Não é a mesma coisa que comprar uma funcionalidade digital através do sistema de compras integradas. A documentação do Google faz uma distinção equivalente entre Google Pay e a faturação do Google Play. (developer.apple.com)

Por isso, uma proposta que diga apenas «inclui Apple Pay e Google Pay» não responde à pergunta principal. Falta identificar o que será cobrado, por que sistema e com que confirmação.

Para vendas físicas ou reservas presenciais, peça ao prestador uma demonstração do percurso completo em iPhone e Android. Inclua os métodos relevantes para os seus clientes em Portugal, sem assumir que todos estão disponíveis no contrato ou na integração escolhida.

Na comparação, exija respostas para estas perguntas:

  • Que métodos estão efetivamente incluídos, em cada sistema operativo?
  • O cliente paga dentro da app ou passa para outro ambiente?
  • Como regressa à encomenda depois de autorizar o pagamento?
  • Quem recebe os fundos e quem consegue consultar a transação?
  • Como se inicia um reembolso e quem acompanha o resultado?

Não escolha apenas pela lista de métodos. Prefira uma proposta que consiga demonstrar a operação de cada um.

E os pagamentos alternativos para conteúdos digitais na Europa?

Existem opções e programas específicos. Isso não significa que uma empresa portuguesa possa substituir livremente as compras integradas por qualquer formulário de cartão. A Apple prevê condições próprias para opções de pagamento na União Europeia; a política do Google também contempla exceções e programas sujeitos a requisitos. (developer.apple.com)

Se uma proposta recomendar essa via, peça a identificação do programa, a elegibilidade da app, os territórios abrangidos e as obrigações contratuais e técnicas. Compare depois o custo total. «Pagamento externo» não deve ser tratado como sinónimo de ausência de encargos ou de responsabilidades adicionais. (developer.apple.com)

Defina quem pode dizer «está pago»

O ecrã de sucesso não deve ser a única prova usada para entregar uma compra. A Google recomenda verificar as compras no servidor antes de conceder o acesso. Na integração com um prestador externo, os avisos enviados ao servidor — normalmente chamados webhooks — permitem acompanhar eventos do pagamento sem depender apenas do que acontece no telemóvel. A Stripe documenta este mecanismo, incluindo a verificação da origem dos avisos e o tratamento de eventos repetidos. (developer.android.com)

Traduza isto numa pergunta de negócio: que confirmação autoriza a entrega, a reserva ou o acesso?

No exemplo do workshop, recomendamos distinguir a vaga temporariamente reservada da inscrição paga. Defina durante quanto tempo aceita manter a vaga e o procedimento quando chega uma confirmação depois de esse prazo terminar. A equipa deve validar se o método escolhido permite executar essa regra.

Para os vídeos, exija que uma compra confirmada fique associada à conta certa. Inclua também uma regra para recuperar o acesso quando o cliente volta a entrar na app. Não deixe estas decisões escondidas numa tarefa chamada «integrar pagamentos».

Proponha estados compreensíveis para quem gere o negócio:

  • A aguardar pagamento: o pedido existe, mas ainda não autoriza a entrega.
  • Confirmado: existe confirmação válida e o pedido pode avançar.
  • Falhado ou expirado: o cliente precisa de uma indicação clara sobre o próximo passo.
  • Reembolso em curso ou concluído: o apoio ao cliente consegue distinguir as duas situações.

Adapte os estados ao serviço contratado. O essencial é evitar que a equipa comercial tenha de interpretar códigos técnicos para perceber se pode confirmar uma inscrição.

Compare o custo de operar, não apenas a comissão

Peça uma simulação baseada no seu negócio, com pressupostos escritos. Não use uma percentagem isolada para escolher entre propostas que incluem tarefas diferentes.

Forneça o valor típico de uma compra, o volume esperado e os mercados onde pretende vender. Se esses dados ainda não existirem, trabalhe com cenários identificados como hipóteses. Não os apresente como previsões de receita.

Solicite que cada proposta separe:

| Parcela | O que deve ficar explícito |

|---|---|

| Integração inicial | Plataformas, métodos e percursos incluídos |

| Encargos de utilização | Tabela contratual aplicável e pressupostos da simulação |

| Operação | Trabalho necessário para conferir pagamentos e resolver exceções |

| Reembolsos e contestações | Procedimentos, responsáveis e eventuais encargos |

| Alterações futuras | O que acontece quando muda o catálogo ou o modelo de venda |

Peça ainda que a proposta mostre onde termina o pagamento e onde começa o processo de faturação. A sua equipa financeira deve validar os dados de que precisa e o sistema onde os vai receber. Não aceite uma linha genérica de «integração administrativa» sem uma demonstração do resultado esperado.

A nossa preferência é por uma solução que permita seguir uma compra do pedido ao respetivo movimento, mesmo que não seja a que apresenta a menor comissão no primeiro quadro comercial.

Faça uma prova de compra antes de aprovar a entrega

Uma demonstração em que tudo corre bem é insuficiente para aceitar esta parte da app. Peça uma sessão de testes com a equipa de desenvolvimento e uma pessoa que vá prestar apoio aos clientes.

Use o seguinte guião como prova de aceitação. São resultados a exigir e a adaptar ao produto, não uma lista de funcionalidades garantidas por qualquer prestador.

| Situação a simular | Resultado a exigir |

|---|---|

| O cliente toca duas vezes em pagar | Não surgem duas entregas ou inscrições para o mesmo pedido |

| A app fecha depois da autorização | Ao regressar, o cliente consegue consultar o resultado correto |

| A confirmação demora | A app mostra um estado pendente, sem incentivar uma nova cobrança às cegas |

| O servidor recebe o mesmo aviso duas vezes | O pedido só é processado uma vez |

| O pagamento é recusado | O cliente percebe se pode tentar novamente e não recebe acesso indevido |

| É iniciado um reembolso | A operação fica identificada e pode ser acompanhada pelo apoio |

| Uma compra digital válida é recuperada | O acesso é atribuído à conta correta, sem exigir nova compra |

O teste de avisos repetidos responde a um comportamento documentado dos webhooks; a verificação antes de conceder acesso segue a recomendação de segurança do Google Play. (docs.stripe.com)

Registe o resultado de cada teste nos dois sistemas operativos. Para qualquer falha, peça uma correção e uma nova demonstração, em vez de aceitar a promessa de que será resolvida depois.

A decisão que deve levar para o orçamento

Antes de contratar o desenvolvimento dos pagamentos, procure fechar quatro pontos: a classificação de cada venda, o sistema que a vai cobrar, a confirmação que autoriza a entrega e quem resolve uma exceção.

Se vende apenas produtos físicos, concentre a comparação no percurso de pagamento e na operação. Se vende acesso digital, esclareça primeiro o enquadramento nas lojas. Se combina ambos, peça que a proposta os trate separadamente antes de decidir se devem partilhar o mesmo percurso.

Leve o catálogo e o guião de testes à reunião com a equipa responsável pela sua app para iPhone e Android. Assim, o orçamento deixa de prometer apenas um botão para pagar: passa a descrever uma compra que o seu negócio consegue confirmar, entregar e, quando necessário, corrigir.