A caixa, e tudo o que está por trás dela.
Configure os fornecedores de pagamento por marca e acompanhe cada passo do fluxo de pagamento.
Esta página descreve como funcionam os pagamentos na Callisto: como é determinado o fornecedor de pagamento para uma marca e um método, o que acontece entre o clique em «depositar» e o movimento de um saldo, como os levantamentos são retidos e aprovados, como a cripto é creditada pelo que realmente chegou, e como todo o fluxo se testa antes de assinar um único contrato com fornecedor.
Do pedido de depósito ao saldo da carteira.
Quatro passos, cada um pode falhar e cada um fica escrito. Nada do caminho está escondido do operador que depois terá de o explicar.
É selecionado o fornecedor de pagamento da marca
Um depósito indica marca e método de pagamento, e a plataforma determina que processador trata essa combinação para essa marca. Duas marcas na mesma instalação podem usar processadores completamente diferentes para o mesmo método.
O jogador é levado ao processador
O fornecedor devolve um redirecionamento que a caixa abre — página alojada ou frame, consoante o que o processador suporta. Cartões, carteiras, métodos locais, vouchers, pagamentos assistidos por agente e lançamentos manuais seguem cada um a forma que o seu método permite.
O veredicto chega por um webhook assinado
O processador responde a um endpoint cuja fronteira é uma assinatura sobre o corpo em bruto e não uma chave da plataforma: uma empresa externa nunca detém credenciais que abram serviços internos. As repetições são normais, por isso a entrega é reconhecida por um índice e não por uma leitura que duas chamadas em corrida passariam ambas.
O saldo é atualizado uma única vez
Um pagamento liquidado publica um evento de saldo e a carteira aplica-o com concorrência otimista. A mesma entrega duas vezes não credita duas vezes; essa garantia está na base de dados e não num caminho de código de que alguém tenha de se lembrar.
Métodos, na forma que realmente têm.
Os tipos de método são numerados uma vez para toda a plataforma, para que o mesmo valor signifique o mesmo no backoffice, na caixa e nos relatórios. Quais deles uma marca oferece, e por que ordem, é configuração dela.
Páginas alojadas ou sessão aberta do lado do servidor, para manter o jogador na sua própria caixa onde o processador o permitir.
Faturada para um endereço com prazo e depois vigiada on-chain.
As carteiras que cada mercado espera, cada uma atrás da sua integração.
Incluindo os canais locais que uma caixa só de cartões deixa de fora.
Para mercados onde uma rede de agentes financia o jogador, com carteira e acerto próprios.
O lançamento manual é só administrativo, nunca visível ao jogador, e cada um traz quem o fez.
Os métodos de uma marca, a sua ordem na caixa e os seus limites configuram-se por skin: acrescentar um método é configuração, e acrescentar um processador é uma classe atrás de uma interface mais uma linha.
Cada retenção de levantamento apresenta claramente o motivo.
Os levantamentos são onde uma plataforma ou tem política ou improvisa uma. A Callisto tem: um levantamento pode ser avaliado no momento em que o jogador o pede, e a resposta fica escrita no próprio pagamento.
Avaliado no pedido, não depois de o dinheiro se mover
Perguntar ao motor de risco na liquidação é tarde — o levantamento que devia travar já aconteceu. Por isso o pedido é avaliado quando o jogador o faz, e a retenção é anotada no pagamento em vez de ser deduzida depois de um estado.
O motivo é uma coluna, não um estado
Um levantamento retido transporta o que o retém. Quem abre a fila vê porque este está à espera, em vez de o deduzir da ordem das linhas.
O desconhecido retém em vez de libertar
Se uma verificação não puder concluir-se — serviço inacessível, estado ilegível — o levantamento espera por uma pessoa. Tratar uma pergunta sem resposta como aprovação é exatamente a falha que esta regra evita.
A aprovação é decisão de alguém, e vai assinada
Aprovações manuais, recusas e ajustes registam quem os fez e quando, num trilho inalterável. Um levantamento que se moveu sem ninguém por trás é precisamente aquilo por que uma auditoria pergunta.
Credita-se o que chegou, não o que foi pedido.
Um depósito cripto é faturado para um endereço com prazo e depois vigiado. O jogador é creditado com o que realmente liquidou on-chain, o único número verdadeiro: as faturas são pagas a menos, a mais e fora de prazo, e creditar o valor faturado é creditar um desejo. Por isso o pagamento a menos e a mais têm resultados definidos em vez de virarem um ticket de suporte, e o depósito é conciliado contra a cadeia e não contra a intenção.
Testar a caixa sem assinar nada.
Um simulador de pagamentos vem com a plataforma, e não é um stub que devolve «sucesso»: percorre o mesmo caminho de webhook que um processador real, por isso o que o seu código recebe é o que um fornecedor teria respondido.
Depósitos e levantamentos de ponta a ponta
Um ciclo completo — pedido, redirecionamento, callback, movimento de saldo — antes ainda de um PSP estar escolhido, quanto mais integrado. Normalmente meses antes de esses testes serem possíveis de outra forma.
As falhas, e não só o caminho feliz
Recusas, timeouts, callbacks malformados e assinaturas forjadas são cenários que pode pedir. Uma assinatura forjada é mesmo recusada, porque o simulador passa pela verificação real e não ao lado dela.
Seguro ao lado de um fornecedor real
Uma marca só tem o simulador se estiver configurada para ele, e o caminho do webhook recusa uma entrega cujo fornecedor não seja o dela. Uma marca apontada a um processador real não pode ser conduzida a partir dali.
Adicione processadores de pagamento sem redesenhar a plataforma.
Um processador é uma implementação atrás de uma interface mais a sua linha de configuração: credenciais por marca, cifradas, nunca devolvidas pela API. Acima dessa costura nada muda — é isso que torna «o nosso adquirente neste mercado» uma questão de configuração e não de roadmap. A sua equipa pode acrescentar um sem nós: o código é seu e as implementações existentes são os exemplos já resolvidos.
Não publicamos uma parede de logótipos. Ter escrito uma integração e tê-la visto liquidar dinheiro real para a sua marca são afirmações diferentes, e que processadores uma marca usa é contrato dela. Pergunte-nos diretamente e terá uma resposta clara sobre o que correu em real e o que não correu — incluindo onde a resposta é «ainda não».
Perguntas sobre pagamentos.
O que aparece assim que a caixa deixa de ser um diagrama.
No código vêm integrações para vários processadores — cartões, cripto, carteiras eletrónicas e métodos locais — e acrescentar outro é uma classe atrás de uma interface mais uma linha de configuração, não uma alteração de plataforma. Não publicamos a lista como parede de emblemas, porque «a integração existe» e «liquidou dinheiro para a sua marca» são afirmações diferentes e só a segunda lhe interessa. Diga-nos com que adquirentes e PSP tem contrato e dizemos-lhe com clareza o que já está implementado, o que correu em real e o que envolve ligar o resto.
Sim, e é a configuração normal. O fornecedor é resolvido por marca e por método de pagamento, por isso a mesma instalação pode servir uma marca europeia num adquirente e uma latino-americana noutro, com métodos diferentes em cada caixa. As credenciais pertencem à marca, são guardadas cifradas e a API nunca as devolve.
Um levantamento é avaliado quando o jogador o pede, e não depois de o dinheiro se mover; a retenção é escrita no pagamento com o motivo que a causou. Se uma verificação não puder concluir-se, o levantamento espera por uma pessoa em vez de passar por omissão. Aprovações manuais e ajustes registam quem os fez, num trilho inalterável.
É creditado com o que realmente chegou on-chain, e não com o que a fatura pedia. Pagamento a menos e a mais têm resultados definidos em vez de virarem um ticket de suporte, e o depósito é conciliado contra a cadeia — o único registo que não é uma declaração de intenção.
Sim, e é das coisas mais úteis da entrega. O simulador de pagamentos vem com a plataforma e percorre o mesmo caminho de webhook que um processador real, incluindo recusas, timeouts, corpos malformados e assinaturas forjadas. A sua equipa pode completar um ciclo de depósito e levantamento meses antes de existir contrato, e uma marca apontada a um processador real não pode ser conduzida a partir dali.
Não, e deliberadamente não. As carteiras são multimoeda e cada valor fica na moeda em que aconteceu; não há fonte de taxas de câmbio na plataforma, porque converter à taxa de hoje faria o mesmo valor ser julgado de forma diferente em dois dias. Onde um limiar ou um relatório precisa de moeda, é definido por moeda em vez de convertido numa só.
Mantenha os adquirentes e PSP com quem já trabalha.
Diga-nos com que processadores tem contrato e que mercados vai abrir. Dizemos-lhe o que já está implementado, o que correu em real e o que envolve mesmo ligar o resto.
Respondemos dentro de um dia, normalmente no próprio.
Ver a plataforma