Gateway para Marketplace de Serviços: Como Dominar No-Show, Cancelamento e Split Dinâmico

Você opera um marketplace de serviços. Um cliente agenda uma faxina pesada pelo seu aplicativo, insere o cartão de crédito e, no dia marcado, simplesmente não aparece para abrir a porta. Ou pior: o profissional chega, mas o cliente pede para adicionar a limpeza de três janelas extras, dobrando o tempo e o valor previstos na plataforma.

Se você capturou o pagamento no exato momento do agendamento, tem agora um problema operacional gigantesco de estorno parcial ou uma cobrança adicional cheia de fricção. Se você não capturou nada e deixou para cobrar no final, o profissional tomou um calote do cliente ausente e a culpa, invariavelmente, vai cair no seu colo.

Nós cobrimos o mercado de pagamentos brasileiro há mais de 15 anos. Vimos o nascimento de gigantes como Nubank, Stone e PagSeguro. Acompanhamos a evolução regulatória do Banco Central de perto. E podemos afirmar com absoluta certeza: vender tempo e serviço é infinitamente mais complexo do que vender produtos físicos.

Se você opera um e-commerce tradicional, a equação é simples. Carrinho, checkout, aprovação do cartão, envio do produto. O valor é estático. Já nos marketplaces de serviços — de telemedicina a reparos domésticos, passando por beleza e bem-estar —, a transação é fluida. O tempo entre o agendamento e a execução é um buraco negro de incertezas.

Vamos destrinchar como a infraestrutura de pagamentos (seu gateway) deve ser arquitetada para resolver o caos do no-show, dos cancelamentos de última hora e do temido split de pagamento variável.

A diferença brutal entre vender produto e vender tempo

No varejo online tradicional, a captura do pagamento ocorre em milissegundos após a autorização. Você vendeu uma geladeira por R$ 3.000. O gateway consulta o emissor do cartão, verifica o limite, bloqueia o saldo e captura o dinheiro. Fim da história. O risco de mudança de escopo beira zero.

Agora, olhe para plataformas como GetNinjas, Singu, Zenklub ou Parafuzo. O cliente agenda um serviço para a próxima quinta-feira. O valor estimado é R$ 150. A taxa da plataforma (take rate) é de 20%, e os 80% restantes pertencem ao prestador de serviço.

O que acontece entre hoje e a próxima quinta-feira? Absolutamente tudo.

O cliente pode cancelar. O prestador pode adoecer. O serviço pode demorar mais ou menos tempo. O cliente pode querer incluir um adicional na hora. O mercado de serviços é probabilístico, não determinístico.

Dados da Abrasel e de associações do setor de beleza mostram que as taxas de cancelamento tardio e no-show (o não comparecimento) em serviços agendados variam entre 15% e 25% no Brasil. Se a sua plataforma não tem uma trava financeira de segurança, você está operando uma roleta russa financeira, assumindo o risco de crédito de milhares de transações diárias.

Pré-autorização: A sua apólice de seguro contra o No-Show

A arma mais letal contra o no-show não é o banimento do usuário. É a pré-autorização de cartão de crédito.

A mecânica é emprestada do setor de hotelaria e locação de veículos. Quando o cliente finaliza o agendamento no seu marketplace, seu gateway não faz uma transação de auth_and_capture (autorizar e capturar). Ele faz apenas um auth (autorização).

Neste momento, o emissor do cartão do cliente (Itaú, Nubank, Bradesco, etc.) verifica se há limite disponível. Se houver, ele aprova a transação e reserva aquele saldo. O limite do cliente é consumido, mas o dinheiro ainda não trocou de mãos. O lojista (seu marketplace) ainda não tem direito aos fundos.

Qual a vantagem técnica aqui?

Se o serviço ocorrer perfeitamente na quinta-feira pelo valor de R$ 150, seu sistema dispara um webhook para o gateway com o comando de capture. O dinheiro, então, inicia o fluxo de liquidação.

Se o cliente cancelar com 48 horas de antecedência (dentro da sua política de cancelamento grátis), seu sistema envia um comando de void (cancelamento da pré-autorização). O limite retorna para o cartão do cliente quase instantaneamente. Você não paga a taxa de MDR (Merchant Discount Rate) para a adquirente, apenas os centavos da chamada de API do gateway.

Se o cliente der um no-show na quinta-feira, você aciona a sua política de penalidade. A regra diz que no-shows pagam 50% do valor para compensar o profissional. Seu sistema envia um comando de captura parcial: capture(amount: 75.00). O gateway processa R$ 75 e automaticamente descarta os outros R$ 75 da reserva.

Você penaliza o mau comportamento, garante a remuneração do prestador e não gera o atrito de ter que cobrar o cliente ativamente depois do sumiço. O limite já estava garantido.

As regras das bandeiras (Visa, Mastercard) no Brasil geralmente permitem segurar uma pré-autorização padrão por 5 a 7 dias sem penalidades. Dependendo do seu MCC (Merchant Category Code), você pode negociar janelas maiores, chegando a 14 ou 30 dias. Converse com seu provedor (seja Pagar.me, Zoop, Iugu ou Stripe) sobre o tempo máximo de hold permitido para o seu modelo de negócio.

Split Variável: Matemática financeira em tempo real

Dominar a captura tardia resolve o no-show. Mas o que acontece quando o escopo do serviço muda? É aqui que o split de pagamento entra em cena e separa as plataformas amadoras das profissionais.

O split de pagamento é a tecnologia que divide uma única transação entre múltiplos recebedores. O cliente vê uma cobrança de R$ 200 na fatura. Por trás dos panos, o gateway manda R$ 40 para a conta do marketplace (take rate) e R$ 160 direto para a subconta do prestador de serviço.

Fazer isso de forma estática no momento do checkout é fácil. A verdadeira engenharia de software brilha no split dinâmico pós-autorização.

Imagine o cenário: o cliente reservou uma massagem de 1 hora por R$ 100. A pré-autorização segurou R$ 100. O split original cadastrado na API era 80/20.

Durante o atendimento, o cliente pede mais 30 minutos. O valor sobe para R$ 150. A pré-autorização inicial de R$ 100 já não cobre o valor total.

Aqui, o seu aplicativo precisa permitir que o prestador de serviço adicione o valor extra. O sistema fará uma segunda pré-autorização (ou uma cobrança direta) de R$ 50 no cartão tokenizado do cliente.

Agora, a mágica regulatória: de acordo com as regras do Banco Central (especialmente o arcabouço da Circular 3.952 sobre recebíveis de arranjo de pagamento), o marketplace não pode receber o valor total na sua conta para depois repassar ao profissional. Isso configuraria o marketplace como uma instituição financeira não autorizada, além de gerar bi-tributação absurda. Você precisa usar um gateway que atue como subcredenciador.

O seu gateway precisa permitir a atualização das regras de split via API minutos antes da captura final. A chamada RESTful se parece com algo como PUT /transactions/{id}/split_rules. Você injeta o novo arranjo matemático, garantindo que os R$ 150 totais sejam divididos corretamente (R$ 30 para a plataforma, R$ 120 para o profissional), já considerando as taxas de MDR proporcionais de cada parte.

Se o seu gateway atual exige que o split seja cravado em pedra no momento do token do cartão, você está usando a ferramenta errada para um marketplace de serviços. A flexibilidade da API de split é o coração da sua operação.

Políticas de Cancelamento Automatizadas e o Risco de Chargeback

Nós, da Ouro Capital, analisamos dezenas de RFPs (Request for Proposal) de plataformas buscando trocar de gateway. A maioria erra ao focar apenas na taxa de MDR. A verdadeira batalha financeira está no custo operacional de lidar com disputas.

Quando um cliente cancela um serviço de última hora e você aplica a multa de no-show via captura parcial, a chance de ele ligar para o banco e abrir um chargeback (alegando desacordo comercial ou fraude) dispara.

O chargeback é o pesadelo do marketplace. Você perde o dinheiro, paga uma taxa de disputa ao gateway (geralmente entre R$ 15 e R$ 40) e vê seu índice de chargeback subir. Se ultrapassar 1% do volume transacionado, as bandeiras aplicam multas severas e podem descredenciar sua operação.

Como blindar a operação?

1. O contrato de prestação de serviço (Terms of Service) deve ser explícito no fluxo de checkout. O cliente precisa dar um opt-in claro na política de cancelamento.
2. Use a tokenização a seu favor. Nunca armazene o PAN (Primary Account Number) do cartão nos seus servidores. Deixe o gateway gerar um token seguro.
3. Integre a política de cancelamento diretamente no código. Crie gatilhos no seu backend.

Exemplo prático de automação:

• Cancelamento > 24h: O sistema baté na API do gateway com POST /transactions/{id}/void. O cliente recebe um e-mail confirmando o estorno imediato.
• Cancelamento entre 24h e 2h: O sistema envia POST /transactions/{id}/capture com 30% do valor, seguido do webhook de split para remunerar o profissional pelo tempo bloqueado na agenda.
• Cancelamento < 2h ou No-Show: O sistema captura 100% do valor.

Ter essa lógica rodando sem intervenção humana elimina o backoffice de atendimento ao cliente tentando calcular reembolsos em planilhas do Excel. A previsibilidade sistêmica reduz o atrito e, consequentemente, as disputas.

O que exigir do seu Gateway: O Checklist Técnico

Se você está construindo ou migrando a infraestrutura de pagamentos do seu marketplace, sente com seu CTO e exija que o provedor escolhido entregue os seguintes requisitos nativos:

• Suporte nativo a Auth / Capture Separados: Sem limite de tempo draconiano de 24 horas. Busque provedores que sustentem a pré-autorização por pelo menos 7 dias corridos.
• API de Split Dinâmico: Capacidade de alterar recebedores, percentuais e valores fixos no payload de captura, não apenas no payload de criação da transação.
• Multi-Party Routing: Se o serviço envolve o cliente, o prestador primário e um assistente, o gateway deve conseguir fazer o split para três contas distintas na mesma requisição.
• Webhooks de altíssima fidelidade: Você precisa saber em tempo real se um estorno parcial falhou ou se um cartão expirou entre a pré-autorização e a captura.
• Conformidade Regulatória (CERC/TAG/B3): O gateway deve lidar com o registro de recebíveis automaticamente, garantindo que o profissional possa antecipar os recebíveis da parte dele do split sem depender da sua plataforma.

O futuro imediato: Pix, Open Finance e Contratos Inteligentes

Você deve estar se perguntando: "E o Pix? O brasileiro ama o Pix".

O Pix revolucionou o fluxo de caixa, mas trouxe um retrocesso para os marketplaces de serviços: a perda da garantia de limite. O Pix padrão é um push payment imediato. O dinheiro sai da conta A e cai na conta B em 3 segundos. Não existe, até o momento, uma função nativa e amplamente adotada de "Pré-Autorização de Pix" no varejo comum.

Como as plataformas resolvem isso hoje? Através de contas de escrow (garantia). O cliente paga R$ 150 no Pix antecipadamente. O dinheiro cai em uma subconta gerida pela plataforma (uma conta de pagamento digital, protegida de falência). O valor fica travado lá. Após a execução do serviço, a plataforma aciona a API de split e distribui o dinheiro via transferência interna (book transfer) para a conta do prestador.

A desvantagem é que o cliente precisa desembolsar o dinheiro antes. A vantagem é que o no-show está 100% coberto.

A grande promessa para os próximos anos é a evolução do Pix Garantido e a Iniciação de Pagamento (ITP) via Open Finance. Veremos o surgimento de contratos inteligentes no sistema financeiro tradicional. O cliente aprovará uma regra no aplicativo do banco: "Autorizo o marketplace X a debitar até R$ 200 da minha conta na próxima quinta-feira, condicionado à confirmação de GPS do prestador de serviço na minha casa".

Até que essa utopia programável chegue às massas, a combinação clássica de tokenização de cartão, pré-autorização estendida e split dinâmico via API continua sendo a espinha dorsal de qualquer marketplace de serviços lucrativo no Brasil. Configure sua infraestrutura para prever o caos humano. O código não falha; as pessoas, sim.