Software de aluguer com Stripe: cauções, pagamentos e reembolsos online

Cada aluguer tem três momentos distintos em que o dinheiro muda de mãos, e a maioria das empresas de aluguer trata cada um deles de forma diferente. Há a caução cobrada, ou retida, antes de o equipamento sair pela porta, o pagamento do próprio aluguer assim que o trabalho é confirmado ou concluído, e — muitas vezes — um reembolso ou uma recobrança parcial quando o artigo regressa, consoante o estado em que se encontra.

No papel, parece tudo bem organizado. Na prática, a caução é cobrada num terminal de pagamento ao balcão, a fatura é enviada por e-mail e cobrada separadamente, e se houver um reembolso em dívida, alguém entra dias depois num painel de pagamentos e processa-o manualmente, esperando que seja para o cliente e a encomenda certos. Nenhum destes três momentos comunica com os outros dois. O terminal de pagamento não sabe a que encomenda pertence a caução. O painel não sabe que a fatura já está liquidada. E o escritório só descobre quando alguém pergunta: «já devolvemos aquela caução?»

Isto não é propriamente um problema tecnológico, é um problema de rastreio da encomenda que, por acaso, envolve dinheiro. Uma encomenda de aluguer já contém um cliente, uma lista de artigos, datas de saída e regresso, e um valor. Se os pagamentos vivem num sistema separado dessa encomenda, alguém tem de conciliar os dois de memória ou numa folha de cálculo, sempre. É nessa conciliação que as cauções são esquecidas, os reembolsos ficam por fazer e as faturas são cobradas duas vezes.

Os três momentos de pagamento de um aluguer só são úteis se cada um estiver associado à encomenda a que pertence, em vez de flutuar como uma transação separada que alguém terá de fazer corresponder mais tarde.

Uma caução registada contra a encomenda significa que qualquer pessoa que consulte esse aluguer — não só quem recebeu o pagamento — consegue ver que foi cobrada, qual o seu valor, e se foi devolvida ou retida. Um pagamento do próprio aluguer, associado da mesma forma, evita que uma fatura fique como «não paga» na contabilidade quando o cliente, de facto, já pagou; a equipa financeira trabalha então sobre o estado real da encomenda em vez de um rolo de talões de um terminal de pagamento.

O reembolso ou a recobrança no final é o que mais conta, porque é o momento com maior probabilidade de correr mal quando é tratado separadamente. Se uma dedução por danos for feita a uma caução fora da encomenda, não fica qualquer registo no próprio aluguer sobre o que foi retido, o que foi devolvido, ou porquê — quando muito, uma nota na caixa de correio de alguém. Manter os três momentos ligados à encomenda tem menos a ver com organização e mais com a capacidade de responder, sem um telefonema, exatamente ao que aconteceu ao dinheiro de um cliente num determinado aluguer.

Nem todos os momentos de pagamento acontecem com o cliente à sua frente. Grande parte do negócio de aluguer é reservada por telefone, por e-mail, ou através de um pedido online, e a forma tradicional de cobrar nesse caso — um terminal de pagamento ao balcão — simplesmente não existe.

A alternativa geral, já comum nos pagamentos online, é um link de pagamento ou uma página de checkout alojada: em vez de ditar um número de cartão ao telefone ou esperar por uma transferência bancária, o cliente recebe um link seguro, introduz os seus próprios dados de cartão numa página gerida pelo prestador de pagamentos, e o pagamento é confirmado sem que o escritório veja alguma vez o número do cartão. O Renttix liga-se ao Stripe precisamente para isto, de modo que uma encomenda orçamentada ou confirmada possa ser levada ao pagamento de forma nativa, dentro da própria plataforma, em vez de através de um processo separado de fatura e painel acrescentado depois. É esse o propósito da integração com o Stripe — o pagamento é um passo no próprio fluxo da encomenda, não uma tarefa paralela que alguém tem de se lembrar de fazer.

Para uma empresa de aluguer, isto fecha uma lacuna que um terminal de pagamento não consegue fechar: permite cobrar uma caução ou um pagamento antes mesmo de o equipamento sair do armazém, junto de um cliente que não está por perto, sem lhe pedir para ditar um número de cartão em voz alta ou confiar que uma referência de transferência chega ao sítio certo.

Grande parte do aluguer é uma transação única: reservar, levantar, devolver, pagar. Mas uma parte crescente não é — equipamento de longa duração num aluguer sem prazo definido, unidades sanitárias num ciclo tipo subscrição, ou um cliente que aluga consigo todos os meses e não quer introduzir o cartão de cada vez.

Para este tipo de acordo, o Renttix suporta o registo de um cartão para que os alugueres sem prazo definido e as subscrições possam ser faturados num ciclo recorrente sem que alguém tenha de cobrar manualmente de cada vez. A mesma abordagem de cartão registado está na base da faturação por consumo medido, em que os valores dependem do uso real e não de um período fixo, e é o que permite cobrar as penalizações por atraso acumuladas sem um passo separado para as reclamar. O cliente autoriza o cartão uma vez, e a partir daí o ciclo de faturação trata de tudo.

Isto conta tanto para a tesouraria como para a comodidade. Uma empresa que tem de andar ativamente atrás de um pagamento por cartão todos os meses, num aluguer de longa duração, acabará, mais cedo ou mais tarde, por falhar um ciclo — porque um colaborador está de folga, um cliente é difícil de contactar, ou a fatura simplesmente desce na lista de tarefas. A faturação por cartão registado elimina essa dependência de alguém se lembrar de pedir.

O final de um aluguer é o momento em que sistemas separados causam mais estragos, porque é o ponto com mais exceções: o artigo regressa com um dia de atraso, falta alguma coisa, um risco precisa de ser recobrado, ou está tudo bem e a caução só precisa de ser devolvida.

O Renttix permite emitir uma nota de crédito sobre a fatura original e, a partir daí, fazer um reembolso total ou parcial, sincronizado com a sua contabilidade em vez de processado como uma transação isolada que a equipa financeira tem de detetar e fazer corresponder separadamente. Essa distinção — total ou parcial — é o que torna as recobranças geríveis na prática. Um artigo danificado não tem de significar reembolsar toda a caução e assumir a reparação como perda, ou ficar com tudo e discutir por causa disso; um reembolso parcial permite devolver o que é devido e justificar o que é retido, na mesma fatura em que a caução foi cobrada.

Como a nota de crédito e o reembolso fazem ambos referência à encomenda original, quem quer que reveja esse aluguer mais tarde — um gestor a verificar um litígio, um contabilista a fechar o mês — consegue ver a sequência completa: caução cobrada, aluguer faturado, dedução feita, restante reembolsado. É uma situação bem diferente de uma nota numa caixa de correio a dizer «resolvido, devolvemos-lhe quase tudo».

Cada um dos momentos de pagamento acima ainda pressupõe que alguém no seu escritório os inicia. O portal do cliente elimina esse pressuposto para as transações que não precisam de nenhuma pessoa do seu lado.

Através do portal, os clientes podem gerir os seus próprios cartões registados, pagar uma fatura pendente, assinar um contrato de aluguer e pedir a devolução do equipamento quando terminam — sem terem de telefonar ao escritório para nada disto. Para um pagamento simples numa fatura que já está correta, não há razão para que isso exija uma conversa; o cliente pode liquidá-la sozinho, à hora que lhe convier, e uma chamada às 19h a perguntar se um pagamento por cartão «passou» é uma chamada que o seu escritório não precisa de atender.

Isto não substitui os fluxos de caução, pagamento e reembolso descritos acima — apenas muda quem carrega no botão. A encomenda, a fatura e o registo do pagamento ficam exatamente onde estavam; o portal é outra porta de entrada, não um destino diferente.

Para tornar isto concreto: imagine uma empresa de aluguer para festas que aceita reservas de tendas, mesas e cadeiras — uma ilustração útil, não uma afirmação sobre como toda a empresa de aluguer deve funcionar.

Um cliente pergunta sobre uma tenda para um evento de fim de semana, com seis semanas de antecedência. Na reserva, a empresa cobra uma caução online através de um link de pagamento, em vez de pedir uma transferência bancária e esperar para ver se chega. Essa caução fica associada à encomenda a partir do momento em que é paga. Na semana anterior ao evento, o saldo do aluguer é faturado e pago da mesma forma — um link, não um terminal de pagamento, já que ninguém da empresa está diante do cliente até ao próprio dia da entrega.

Depois do evento, a tenda regressa com um painel rasgado. Em vez de reter toda a caução ou reembolsá-la na totalidade e absorver o custo, a empresa faz um reembolso parcial: o custo da reparação é deduzido, e o resto volta para o cartão do cliente como uma nota de crédito na mesma fatura em que a caução foi cobrada. O cliente vê uma razão clara para o que foi retido, a empresa tem um registo associado à encomenda em vez de uma conversa que ninguém anotou, e nada teve de ser conciliado manualmente entre um terminal de pagamento, um extrato bancário e uma fatura.

Nada disto obriga a escolher um único método de pagamento para cada cliente. O Stripe é um dos vários prestadores de pagamento a que o Renttix se liga, juntamente com opções como PayPal, Square, Razorpay, Xendit, Mercado Pago, Alipay+ e Airwallex, e os pagamentos feitos através de qualquer um deles podem incluir um imposto calculado por classes, zonas e isenções quando aplicável — um tema à parte, tratado na página de pagamentos e impostos globais, e não algo que este artigo pretenda explicar por completo.

O que importa especificamente para o ciclo caução-pagamento-reembolso é que cada um dos três momentos fique associado à encomenda de onde provém, seja qual for o prestador que cobra o dinheiro. Bem configurada, uma integração com o Stripe faz com que uma caução, um pagamento de fatura e um reembolso sejam três entradas no mesmo registo de aluguer, e não três histórias separadas que só se encaixam se alguém se lembrar de as relacionar.

Se a sua configuração atual envolve um terminal de pagamento que não sabe nada das suas reservas e um painel de pagamentos que ninguém verifica até ao final do mês, vale a pena fechar essa lacuna antes que lhe custe um reembolso esquecido ou uma caução contestada. Entre em contacto para ver como isto se adapta à sua própria operação de aluguer.