Pagamentos e cobrança

O que é

Pagamentos e cobrança é tudo o que é preciso para receber dinheiro dentro do seu app: checkout avulso, assinaturas recorrentes, faturas e um registro de cada transação. Na ybuild, isso é integrado ao app e conectado a um processador de pagamento de verdade, para que os clientes paguem diretamente a você. Os planos, os preços e os recibos saem da sua descrição.

Por que importa

Um sistema de negócio que não consegue receber ainda não é um negócio: é uma ferramenta administrativa. Ter a cobrança vivendo dentro do mesmo app em funcionamento significa que os pagamentos estão ligados aos seus clientes e aos dados deles, e não acoplados por meio de uma ferramenta à parte que você concilia na mão. É isso que transforma o sistema em receita.

Como funciona no ybuild

Diga à ybuild o que você cobra e como, e ela conecta o checkout, as assinaturas e o faturamento dentro do app no ar. Tudo fica hospedado na ybuild e é servido no seu domínio, então os clientes pagam no seu site e o dinheiro cai na sua conta conectada. As transações ficam registradas no próprio banco de dados do seu app, bem ao lado do cliente a que pertencem.

O que realmente acontece quando um cliente paga você

Quando alguém toca em 'Pagar' no seu app, muita coisa acontece no segundo antes de o recibo aparecer, e a parte mais importante é justamente aquilo que o seu app, de propósito, nunca vê.

Os dados do cartão são capturados em um campo que pertence ao processador de pagamento, não ao código do seu app. No instante em que são digitados, vão direto para o processador e são trocados por um token: uma referência inofensiva, como a ficha de um guarda-volumes, que faz as vezes do cartão real. O seu app guarda e trabalha com esse token; o número bruto do cartão nunca toca o seu servidor nem o seu banco de dados. Essa única decisão de projeto é o que mantém você no caminho de conformidade mais curto que as bandeiras de cartão definem (o nível SAQ A), em vez do mundo cheio de auditorias de lidar com os dados do cartão você mesmo.

Com o token em mãos, o processador pede ao banco do cliente que autorize a cobrança —uma reserva que confere se o cartão é real e se há saldo— e depois a captura para de fato mover o dinheiro. Para clientes na Europa e no Reino Unido, o banco pode disparar uma etapa de Autenticação Forte do Cliente: um desafio 3D Secure, como um toque no app do banco ou um código de uso único, que a regulação exige em muitos pagamentos sem o cartão presente. Quando é aprovada, a cobrança passa e o cliente nunca sai do seu domínio.

Aqui está a parte que a maioria das montagens 'faça você mesmo' erra: o redirecionamento de volta para a sua página de sucesso não é prova de pagamento. A confirmação confiável é um webhook: uma mensagem assinada que o processador envia ao seu backend dizendo que a cobrança foi bem-sucedida. A ybuild conecta esse listener, verifica a assinatura e só então grava a transação no banco de dados do seu app, ao lado do cliente a que pertence. As entregas repetidas são tornadas idempotentes, de modo que um webhook que chega duas vezes não pode contar o pagamento duas vezes. O resultado é um único registro de verdade: o cliente, o plano e cada cobrança vivendo juntos no mesmo sistema em funcionamento, e não espalhados por um painel do processador que você concilia na mão.

Construir a cobrança você mesmo vs. tê-la na ybuild

Vale ser franco sobre o caminho de fazer você mesmo, porque cobrança é uma das tocas de coelho mais profundas do software.

Fazendo por conta própria, 'aceitar pagamentos' se expande num projeto à parte: integrar o SDK do processador, construir um checkout que lide com o fluxo do desafio 3D Secure, subir um endpoint de webhook com verificação de assinatura e idempotência, e depois conciliar o que o webhook diz com o que o seu banco de dados acha. As assinaturas transformam isso numa máquina de estados: testes que convertem, planos que sobem e descem no meio do ciclo, contas de rateio, pausas, cancelamentos e reativações, cada um com seus próprios casos extremos. Por cima disso está a metade sem glamour que ninguém mostra numa demo: repetir tentativas de cartões que falharam, e-mails de cobrança, reembolsos, créditos rateados, tratamento de chargebacks e disputas, faturas com numeração sequencial, e o cálculo de imposto sobre vendas ou IVA que muda conforme onde o cliente está. Cada uma dessas coisas é um ponto onde o dinheiro vaza ou onde um cliente é cobrado por engano.

Na ybuild, você descreve o que cobra e como —'um plano de US$ 29 por mês com um teste de 14 dias e uma opção anual', 'um checkout avulso para cada pedido', 'faturas com vencimento em 30 dias'— e ela conecta o checkout, as assinaturas, o faturamento e todo o encanamento do webhook dentro do app em funcionamento. É construído como um sistema full-stack hospedado: a lógica de cobrança, os registros de clientes e o banco de dados vivem juntos e vão ao ar no seu próprio domínio. Os clientes pagam no seu site, e o dinheiro cai na sua conta de processador conectada.

A diferença não é só o esforço inicial. Uma pilha de cobrança feita à mão é superfície operacional permanente: alguém é dono do webhook que parou de disparar em silêncio, da renovação que cobrou em dobro, da regra de imposto que mudou da noite para o dia. Como a ybuild hospeda o app e mantém as peças conectadas umas às outras, mudar um preço ou adicionar um plano é uma frase, não uma migração. Você é dono da parte que gera dinheiro —os clientes, a receita, o domínio— e o encanamento embaixo é tarefa da plataforma.

As pegadinhas que mordem a cobrança no ar, e o que elas significam para o negócio

Um punhado de casos extremos pega quase todo time que opera cobrança, e vale nomeá-los porque um sistema no ar esbarra em todos eles.

As renovações que falham são a pegadinha silenciosa. Cartões vencem, batem no limite ou são recusados por engano, e negócios de assinatura perdem cerca de 9% da receita recorrente mensal para pagamentos que falham, com taxas de falha do setor entre 5% e 15%. A maior parte é recuperável, mas só se algo tentar de novo de forma inteligente e escrever ao cliente; sem cobrança de inadimplência, a receita simplesmente evapora. As recusas por SCA são o primo europeu: um pagamento que teria passado é bloqueado porque uma etapa 3D Secure nunca foi oferecida, então o fluxo do desafio precisa ser integrado, não acoplado. A idempotência importa mais do que parece: um soluço de rede pode fazer uma solicitação de cobrança chegar duas vezes e, sem uma proteção, o cliente é cobrado duas vezes e contesta. Os webhooks, e não o redirecionamento do navegador, são a fonte da verdade, então uma montagem que marca os pedidos como 'pagos' na página de agradecimento vai lançar receita fantasma no instante em que um cartão for recusado depois do redirecionamento. E o imposto segue a localização do cliente, não a sua, o que silenciosamente transforma um preço simples numa questão de conformidade no momento em que você vende através de fronteiras.

O que você ganha por tratar tudo isso corretamente é justamente o que faz de um sistema um negócio. Ter a cobrança vivendo dentro do mesmo app significa que cada cobrança está ligada ao cliente e aos dados dele: você consegue ver quem está em qual plano, de quem o cartão está falhando e quanto vale cada conta, sem exportar um CSV e cruzá-lo com um painel do processador. MRR, churn, recuperação de pagamentos falhos e valor no tempo de vida deixam de ser palpites de planilha e passam a ser propriedades do sistema em funcionamento.

Essa é a diferença entre uma ferramenta administrativa e uma empresa. Um app criado a partir de um prompt que recebe no seu próprio domínio, registra isso ao lado do cliente e mantém as assinaturas vivas durante o bagunçado trecho do meio é um motor de receita que você de fato consegue operar: hospedado na ybuild, no seu endereço, com o dinheiro caindo na sua conta desde o primeiro dia.

Perguntas frequentes

Preciso da minha própria conta na Stripe ou de pagamentos para receber?

Você conecta uma conta de processador de pagamento, e é lá que o seu dinheiro cai: ele continua sendo seu. A ybuild constrói o checkout, as assinaturas e o faturamento dentro do seu app e os conecta a essa conta, para que os clientes paguem diretamente a você no seu próprio domínio. Você não escreve a integração nem fica de babá dos webhooks; a plataforma os mantém rodando por trás do app no ar.

É seguro receber números de cartão em um app da ybuild?

Sim, porque o seu app nunca toca o número bruto do cartão. Os dados do cartão são capturados no campo seguro do próprio processador e trocados por um token antes de chegarem ao seu código, então os dados sensíveis ficam fora do seu servidor e fora do seu banco de dados. Isso mantém o seu app no caminho de conformidade mais curto das bandeiras de cartão (SAQ A), em vez do nível cheio de auditorias pensado para lojistas que armazenam dados de cartão eles mesmos.

Consigo rodar assinaturas com testes grátis, upgrades e cancelamentos?

Sim. Descreva os planos —mensal e anual, um teste grátis, faixas entre as quais os clientes podem transitar— e a ybuild constrói a cobrança recorrente, a conversão do teste, o rateio das mudanças no meio do ciclo e o cancelamento dentro do app no ar. O estado da assinatura vive no seu próprio banco de dados, ao lado do cliente, então você sempre sabe exatamente quem está em qual plano.

O que acontece quando o cartão de um cliente é recusado na renovação?

O app tenta de novo e faz o acompanhamento em vez de perder a receita em silêncio. Renovações que falham fazem negócios de assinatura perderem cerca de 9% da receita recorrente no setor todo, e a maior parte é recuperável com novas tentativas inteligentes e e-mails de cobrança, então a ybuild integra esse fluxo de recuperação. Como a cobrança fica dentro do seu app, você consegue ver exatamente quais contas estão falhando e agir sobre elas.

Ele consegue lidar com faturas e imposto sobre vendas?

Sim. A ybuild constrói o faturamento —números de fatura sequenciais, datas de vencimento, recibos— dentro do app, e pode aplicar imposto sobre vendas ou IVA conforme onde o cliente está, já que o imposto segue a localização dele, não a sua. Tudo fica registrado no banco de dados do seu app e é servido no seu próprio domínio, então os seus registros de cobrança e os seus registros de clientes são um sistema só, e não dois que você precisa conciliar.