Armadilhas da Store #3: Você não pode chamar de doação

2026-05-30

Tags: Windows · Microsoft Store · Armadilhas da Store

---

Mais uma armadilha da Store. Essa me pegou de surpresa.

O que aconteceu

Tenho um app de ferramenta gratuito para Windows. Eu queria adicionar uma forma de os usuários apoiarem o desenvolvimento, então criei um complemento in-app — uma simples compra "Support the Author". A listagem da Store chamava de opção de patrocínio, a interface in-app dizia "Consider buying the dev a coffee", e a compra era processada pelo próprio sistema de IAP da Microsoft Store.

Veio o resultado da certificação:

Status: Attention needed

10.8.2 Third-Party In-Product Purchases

Any developer donations must only be made through a secure third-party purchase processing API. Please use one of those methods or remove any donation options that use the Microsoft API.

Peraí — rejeitado por cobrar doações através da API de compra in-app?

A política

A política da Microsoft Store 10.8.2 diz:

You must use the Microsoft payment request API or a secure third-party purchase API to receive voluntary donations from users. However, if the user receives digital goods or services in return, including but not limited to additional features or removal of advertising, you must use the Microsoft Store in-product purchase API instead.

Tradução: Você deve usar a Microsoft payment request API ou uma API de compra segura de terceiros para receber doações voluntárias de usuários. Porém, se o usuário receber bens ou serviços digitais em troca, incluindo mas não se limitando a funcionalidades adicionais ou remoção de publicidade, você deve usar a Microsoft Store in-product purchase API.

Aqui é preciso distinguir entre duas APIs diferentes da Microsoft:

• Microsoft Payment Request API: usada para solicitações de pagamento gerais, pode receber doações
• Microsoft Store In-Product Purchase API: usada para compras in-app de bens e serviços digitais, não pode ser usada para receber doações

Quando usar cada API

Deve usar a API de compra in-app da Microsoft

Se o usuário pagar e receber qualquer benefício digital no app (incluindo, mas não se limitando aos casos abaixo), deve usar a API de compra in-app:

• Desbloqueio de funcionalidades: atualizar da versão gratuita para Pro, desbloquear ferramentas avançadas, ativar privilégios VIP
• Remoção de anúncios: pagar para remover anúncios permanentemente ou periodicamente
• Moeda/itens digitais: moedas, diamantes, skins em jogos, ou tokens/pontos em apps
• Serviços de assinatura: serviços de membros pagos mensais ou anuais

Atenção: mesmo que você disfarce esses comportamentos como "patrocínio", "gorjeta" ou "doação", desde que o pagamento do usuário acione qualquer mudança digital acima (por exemplo, conceder um distintivo VIP exclusivo, remover pop-ups), a Microsoft considerará isso como "compra de produto digital" e deverá usar a API de compra in-app.

Não deve usar a API de compra in-app da Microsoft

Nestes cenários, usar a API de compra in-app resultará em rejeição:

• Bens físicos: vender roupas, livros, equipamentos de hardware
• Serviços do mundo real: reservar ingressos de cinema, pedir delivery, chamar táxi, reservar hotel
• Doações puramente beneficentes/jogos de azar reais: arrecadar fundos para instituições de caridade legítimas, ou jogos com dinheiro real permitidos por lei
• Gorjetas puramente pessoais (sem retorno): o usuário simplesmente acha que programar é difícil e te dá algum dinheiro, mas não há nenhuma mudança de funcionalidade ou interface no app. Deve usar pagamento de terceiros ou Payment Request API

Um critério simples de julgamento

Após o usuário pagar, a lógica de código do app (ou campos do banco de dados) precisa mudar?

• Precisa (por exemplo isPro se torna true, ou adCount se torna 0) → Deve usar a API de compra in-app da Microsoft
• Não precisa (o código não muda em nada, o usuário está apenas demonstrando apoio, ou esperando a entrega de um produto físico) → Deve usar pagamento de terceiros ou Microsoft Payment Request API

Voltando ao meu caso

Meu complemento se chamava "Support the Author", com o slogan "Consider buying the dev a coffee" — pela linguagem, era puramente uma gorjeta. Mas estava usando a API de compra in-app da Store, e a política proíbe explicitamente o uso dessa API para gorjetas puras.

Na verdade, porém, o complemento em si daria ao usuário um distintivo de apoiador ou algo similar — em outras palavras, já era um produto digital. Pelo critério acima, se há mudança, é produto digital, e produto digital deve usar a API de compra in-app. Ou seja, esse pagamento teoricamente só podia passar pela API de compra in-app, não pela Payment Request API ou pagamento de terceiros.

Então o problema não era o método de pagamento, mas sim a descrição estava errada. Mudando "Support the Author" para "Upgrade to Pro", e "Consider buying the dev a coffee" para um texto descrevendo o retorno concreto, foi aprovado.

Em resumo

• A API de compra in-app da Microsoft só pode ser usada para transações de bens e serviços digitais — após o pagamento do usuário, deve haver uma mudança substantiva no app
• Gorjetas puras (sem nenhuma mudança no app) não podem usar a API de compra in-app, devem usar Payment Request API ou pagamento de terceiros
• Critério de julgamento: após o pagamento do usuário, o código/banco de dados precisa mudar? Muda → API de compra in-app; não muda → pagamento de terceiros
• Nomenclatura e descrição devem corresponder ao comportamento real: se houver mudança após o pagamento, use retornos concretos para descrever, evite linguagem de doação, patrocínio, gorjeta

---

Este artigo pertence à série Armadilhas da Store.