Conecte somente a receita que pertence a você

Separe as duas finalidades do Stripe

A cobrança da própria assinatura do Reylin não é a conexão de análise de clientes. Uma conta comercial compartilhada pode conter serviços sem relação entre si. Escolha um escopo de produtos selecionados ou escolha explicitamente a análise da conta inteira somente quando toda a conta pertencer ao projeto. Nenhum metadado do cliente pode determinar a elegibilidade do produto.

A política de lançamento exclusiva para o proprietário não é cobrável e atualmente permite apenas análises de clientes em modo de teste. A coleta em produção continua sujeita a uma etapa separada de aceitação e autorização.

Lista de verificação da conexão

• Use um espaço de trabalho de proprietário verificado e uma origem de site aprovada, não a demonstração sintética compartilhada.
• Confirme a conta do provedor e o modo de teste ou produção com credenciais oficiais antes de salvar uma conexão.
• Escolha o escopo imutável de produtos do projeto antes de ingerir pagamentos. Alterar o escopo exige um projeto separado, não a reescrita de recebimentos antigos.
• Configure o endpoint exato do webhook e o segredo de assinatura por um fluxo seguro e aprovado de credenciais. Nunca cole chaves em um guia, artigo, console do navegador ou conversa.
• Confirme a verificação da assinatura do corpo bruto e a entrega; depois, examine separadamente o sucesso do pagamento e da atribuição.

Decisões sobre produtos selecionados

Itens de linha do Checkout ou alocação canônica de pagamentos de faturas fornecem evidência oficial do produto. Toda linha incluída deve poder ser resolvida e estar no conjunto de produtos escolhido. Um pagamento inteiramente alheio é excluído; evidências mistas, ambíguas, ausentes ou não suportadas ficam em quarentena. Nenhuma alocação proporcional de receita é presumida.

O valor do recebimento continua sendo o valor oficial pago, incluindo pagamentos de faturas com desconto ou parciais suportados. Ele não é substituído por uma soma de itens de linha. A evidência verifica conta, modo, identidade e moeda.

Reembolsos e receita recorrente

A elegibilidade de um pagamento aceito fica congelada. Uma exclusão posterior de produto não invalida um reembolso parcial válido. Um reembolso anterior ao pagamento pode manter a decisão verificada do pagamento original sem subtrair recebimentos líquidos até a chegada desse pagamento. Somente o estado succeeded de reembolso subtrai dinheiro.

A descoberta e a atualização de assinaturas aplicam a mesma política de produtos. O MRR contratual é bruto, antes de descontos e impostos, e separado por moeda; não é uma previsão de caixa nem um modelo completo de cobrança por faixas ou consumo. Estados não suportados ou desatualizados não são contados como receita saudável.

Limites históricos e aceitação em produção

A importação histórica limitada de eventos do provedor não recria visitantes que nunca foram rastreados, e a disponibilidade do histórico do provedor é finita. Eventos excluídos avançam a cobertura da importação sem contar como pagamentos importados. Evidências não resolvidas continuam pendentes.

Testes sintéticos locais cobrem eventos duplicados, exclusões de escopo, produtos mistos, reembolsos parciais, renovações por fatura e isolamento de moedas. Eles não comprovam permissões reais de chaves restritas, aceitação da versão da API, entrega de webhooks ou recuperação operacional. Conclua essas verificações antes de conectar dados de produção.