Reclamação sobre *****: Limitações de Split, Burocracia Excessiva e Falta de Transparência

Resolvido
Salvador - BA
12/05/2026 às 09:55
ID: 248390291
Um dos maiores erros que cometi como gestor de tecnologia este ano foi contratar a *****. E faço este relato não mais na expectativa de resolver os inúmeros problemas que enfrentamos, mas como um alerta para empresas que estejam considerando contratar os serviços da plataforma.
A ***** se apresenta em suas redes sociais, landing pages e materiais comerciais como uma solução whitelabel completa, moderna e preparada para operações com split de pagamentos. Esse, inclusive, foi o principal motivo pelo qual escolhemos a empresa. Porém, na prática, o que encontramos foi um cenário repleto de limitações ocultas, burocracia excessiva, instabilidade e decisões arbitrárias.
O maior problema está justamente no recurso que mais divulgam: o split de pagamentos. A ***** impõe uma regra interna chamada *****, que impede que o split seja realizado caso os repasses não respeitem a proporção mínima de ***** e máxima de ***** do valor da transação. Em outras palavras: você simplesmente não tem liberdade para definir o modelo de divisão financeira do seu próprio negócio.
E o mais absurdo é que essa limitação não existe nas principais soluções do mercado. Plataformas como *****, *****, ***** e ***** operam com split de forma muito mais flexível e aderente à realidade de marketplaces e plataformas digitais.
Outro ponto extremamente grave é a discrepância entre o ambiente Sandbox e o ambiente de produção. Durante a homologação, tudo parece relativamente simples. Porém, ao entrar em produção, o processo muda completamente. A ativação de estabelecimentos comerciais (ECs), permissões de split e liberações operacionais passam a depender exclusivamente do time de prevenção a risco da *****.
E aqui está, talvez, o maior gargalo da empresa.
Tudo depende desse setor. Absolutamente tudo. Solicitações simples se transformam em processos demorados, burocráticos e imprevisíveis. Pedimos, por exemplo, a remoção da regra ***** da nossa conta. O pedido foi negado. Nossa gerente de contas tentou recorrer. Depois de insistência, o próprio CEO autorizou uma flexibilização para ***** o que por si só já demonstra que a regra não possui qualquer fundamento técnico consistente, apenas uma política arbitrária.
Mesmo assim, cada novo EC criado entra sem permissão para operar com split. E toda vez é necessário abrir solicitação manual para o time de prevenção a risco liberar a funcionalidade. O prazo? Imprevisível. Às vezes 1 dia. Às vezes 3. Tudo isso para habilitar uma funcionalidade básica que deveria ser automática em uma plataforma que se vende justamente como solução de split.
Sem falar dos incontáveis bugs de erro que ocorrem no ambiente de produção, posso listar:
- Não conclui a transação online em nenhum cartão de crédito porque dá erro no antifraude 3DS.
- O Webhook de mudança de status do estabelecimento não dispara depois que o time de prevenção a risco aprova o cadastro
- O segundo EC cadastrado em produção veio sem o nome da mãe e deu erro e não existe na documentação nada a ser feito.
É surreal.
E existe um detalhe ainda mais grave: para ter acesso à API e integrar sua plataforma à *****, fomos obrigados a contratar um plano superior no valor de R$ 50.000,00.
Mesmo com um investimento desse porte nenhuma dessas limitações foi apresentada de forma transparente durante a negociação, nenhuma dessas regras está claramente descrita no contrato, nenhuma dessas burocracias operacionais foi mencionada pelo time comercial.
O discurso comercial vende facilidade, autonomia e escalabilidade. A realidade entrega dependência, lentidão operacional e insegurança.
Hoje, relendo o contrato, percebemos que o cancelamento praticamente nos inviabiliza juridicamente neste momento. Então seguimos operando não por satisfação, mas porque já estamos presos a uma decisão extremamente cara e desgastante.
Compartilhe
Resposta da empresa
18/05/2026 às 15:18
Oi, Yargo. Boa tarde!
Meu nome é Karol A. e faço parte do time de atendimento do Reclame Aqui da Paytime.
Antes de qualquer ponto, quero agradecer pelo nível de detalhe da sua manifestação. Li atentamente todo o relato e entendo o desgaste gerado pela experiência que você descreveu, principalmente considerando o investimento realizado, a expectativa criada durante a negociação comercial e o impacto operacional enfrentado no ambiente de produção.
Após análise interna do seu histórico, identifiquei que boa parte dos pontos mencionados em sua manifestação já vinha sendo tratada diretamente entre você, sua gerente de contas e nossos times internos antes mesmo da abertura deste registro no Reclame Aqui, inclusive com ajustes e liberações já concluídos ao longo das tratativas operacionais.
Em relação à regra de split, houve a flexibilização do modelo inicialmente aplicado (80/20) para o formato 90/10, considerando que a configuração padrão realmente não atendia parte relevante da estrutura operacional da sua carteira.
Também validamos o contexto informado sobre o modelo de negócio utilizado, no qual a principal receita da operação não está necessariamente vinculada ao percentual transacionado, mas sim às mensalidades e ao módulo de split contratado.
É importante contextualizar também que a limitação de split segue parâmetros operacionais e de segurança previstos nos fluxos transacionais da plataforma e nas diretrizes aplicáveis ao modelo de intermediação financeira utilizado pela Paytime.
Conforme previsto em nossos Termos de Uso, a Paytime atua como plataforma de processamento e gerenciamento de pagamentos, realizando análises de risco, monitoramento transacional e validações operacionais junto aos parceiros adquirentes e instituições envolvidas no fluxo financeiro. Por esse motivo, determinadas regras de distribuição financeira e composição de repasses fazem parte das políticas internas de prevenção e conformidade da operação.
Dentro desse cenário, o modelo de split integral em 100% não é disponibilizado operacionalmente na estrutura atual da plataforma. Ainda assim, entendendo a particularidade da sua operação, foi realizada uma flexibilização excepcional para o formato 90/10, buscando atender da forma mais aderente possível a necessidade apresentada por você.
Além disso, sua gerente de contas realizou contato direto com você para entender de forma mais aprofundada a necessidade operacional apresentada e, a partir desse alinhamento, foi possível chegar a um entendimento em comum acordo referente aos ajustes aplicados na operação.
Nas permissões operacionais, também foi realizada a configuração do modelo guarda-chuva, permitindo que novos Estabelecimentos cadastrados via integração já sejam criados com habilitação D+1 para venda online.
Reforço ainda que a permissão de split já permanece habilitada por padrão nos Estabelecimentos. O comportamento mencionado no seu relato indica um cenário pontual relacionado à configuração operacional aplicada na estrutura da conta, e esse fluxo já foi direcionado para validação e ajuste técnico interno.
Em relação ao webhook de alteração de status do estabelecimento, identificamos que o cenário estava relacionado à inconsistência no preenchimento do campo nome da mãe durante o processo de validação cadastral.
Atualmente já estamos atuando na correção desse comportamento junto às bases de consulta utilizadas no fluxo de habilitação dos Estabelecimentos.
Como medida adicional para evitar novas inconsistências, também orientamos que o campo nome da mãe seja enviado no payload de cadastro via API sempre que possível. Dessa forma, caso a consulta automática não retorne a informação corretamente, o sistema consegue utilizar o dado enviado diretamente pela integração.
O cenário mencionado referente ao segundo Estabelecimento criado em produção também foi identificado dentro desse mesmo contexto cadastral.
Já os apontamentos envolvendo autenticação 3DS e transações online foram direcionados internamente para acompanhamento técnico e tratativa junto aos times responsáveis.
Entendemos também o ponto trazido sobre a percepção entre Sandbox e produção. Seu relato foi importante para reforçarmos internamente oportunidades de melhoria na transparência técnica e operacional durante os processos de implantação e acompanhamento das integrações.
Seguimos à disposição para acompanhar qualquer necessidade adicional e prestar o suporte necessário sempre que precisar.
Karol A.
Reclame Aqui | Paytime
Consideração final do consumidor
26/05/2026 às 16:37
Olá, Karol! Boa tarde.
Obrigado pelo retorno e pelo esforço do time em tratar os pontos levantados. Vou aproveitar para atualizar o status de cada item:
**Regra de Split (80/20 90/10)**
A flexibilização para 90/10 foi um avanço significativo e ajudou bastante na nossa operação fico feliz em reconhecer isso. No entanto, ainda não resolve completamente a nossa necessidade. Gostaria de levantar formalmente a possibilidade de ampliar para 95/5 ou, idealmente, remover essa restrição por completo. E aqui fica também uma pergunta genuína: qual é a origem técnica ou regulatória dessa regra? Se há um fundamento claro seja de compliance, de parceiros adquirentes ou de qualquer outra natureza gostaríamos de entendê-lo. Isso nos ajudaria muito a planejar nossa operação com mais previsibilidade.
**Permissão de Split nos novos ECs**
Acreditamos que o problema foi resolvido, mas como nosso cliente piloto ainda não iniciou o cadastro dos estabelecimentos comerciais, ainda não tivemos como validar na prática. Seguiremos monitorando e retornamos com um feedback assim que os próximos ECs forem criados.
**Campo "nome da mãe" na API**
Entendo a orientação de enviar o campo no payload de cadastro, e estamos tentando fazer isso. O problema é que esse atributo não está documentado na API técnica não encontramos o nome do parâmetro para incluir no request. Acreditamos que a API simplesmente não está preparada para receber esse dado ainda. Seria possível o time técnico confirmar se o campo está disponível na integração e, se sim, incluir a documentação correspondente?
**Problema 3DS (resolvido)**
Esse ponto foi resolvido. Identificamos que a causa era uma inconsistência entre o valor enviado à API (bruto) e o valor enviado ao SDK 3DS (líquido): quando as taxas são repassadas ao cliente, o valor dessas taxas precisa ser somado ao amount enviado no SDK 3DS. Era um comportamento não documentado que gerou bastante confusão.
**Webhook (novo problema identificado)**
Identifiquei uma nova inconsistência no comportamento do webhook e já reportei ao time responsável. Aguardo a conclusão da análise.
**Status geral**
No geral, estamos operando com o cliente piloto e, até o momento, o ambiente está estável. Seguimos atentos e continuaremos reportando qualquer novo comportamento.
Agradeço pela atenção contínua do time e fico no aguardo dos próximos retornos.
Atenciosamente,
Yargo
O problema foi resolvido?

Resolvido
Voltaria a fazer negócio
Sim
Nota do atendimento
10