La caja, y todo lo que hay detrás.
Configure los proveedores de pago por marca y siga cada paso del flujo de pago.
Esta página describe cómo funcionan los pagos en Callisto: cómo se determina el proveedor de pago para una marca y un método, qué ocurre entre el clic en «depositar» y el movimiento de un saldo, cómo se retienen y aprueban las retiradas, cómo se acredita la cripto por lo que realmente llegó y cómo se prueba todo el flujo antes de firmar con un solo proveedor.
De la solicitud de depósito al saldo del monedero.
Cuatro pasos, cada uno puede fallar y cada uno queda escrito. Nada del camino se le oculta al operador que después tendrá que explicarlo.
Se determina el proveedor de pago de la marca
Un depósito indica marca y método de pago, y la plataforma determina qué procesador atiende esa combinación para esa marca. Dos marcas del mismo despliegue pueden usar procesadores completamente distintos para el mismo método.
Se lleva al jugador al procesador
El proveedor devuelve una redirección que abre la caja: página alojada o marco, según lo que admita el procesador. Tarjetas, monederos, métodos locales, vales, pagos asistidos por agente y apuntes manuales siguen cada uno la forma que su método permite.
El veredicto llega por un webhook firmado
El procesador responde a un endpoint cuya frontera es una firma sobre el cuerpo en bruto y no una clave de plataforma: una empresa externa nunca tiene credenciales que abran servicios internos. Los reenvíos son lo normal, así que la entrega se reconoce por un índice y no por una lectura que dos llamadas simultáneas pasarían las dos.
El saldo se actualiza una sola vez
Un pago liquidado publica un evento de saldo y el monedero lo aplica con concurrencia optimista. La misma entrega dos veces no acredita dos veces; esa garantía está en la base de datos, no en un camino de código que alguien deba recordar.
Métodos, con la forma que realmente tienen.
Los tipos de método se numeran una vez para toda la plataforma, de modo que el mismo valor significa lo mismo en el backoffice, en la caja y en los informes. Cuáles ofrece una marca, y en qué orden, es configuración suya.
Páginas alojadas o sesión abierta en servidor, para mantener al jugador en su propia caja donde el procesador lo permita.
Facturada a una dirección con plazo y luego vigilada on-chain.
Los monederos que espera cada mercado, cada uno tras su propia integración.
Incluidos los rieles locales que una caja solo de tarjetas se pierde.
Para mercados donde una red de agentes financia al jugador, con su propio monedero y liquidación.
El apunte manual es solo administrativo, nunca visible para el jugador, y cada uno lleva a quien lo hizo.
Los métodos de una marca, su orden en la caja y sus límites se configuran por skin: añadir un método es configuración, y añadir un procesador es una clase detrás de una interfaz más una fila.
Cada retención de retiro muestra claramente su motivo.
Las retiradas son donde una plataforma o tiene política o la improvisa. Callisto tiene una: la retirada puede juzgarse en el momento en que el jugador la pide, y la respuesta se escribe en el propio pago.
Juzgada al solicitarla, no después de mover el dinero
Preguntar al motor de riesgo en la liquidación llega tarde: la retirada que debía frenar ya ocurrió. Por eso la solicitud se evalúa cuando el jugador la hace, y la retención queda anotada en el pago en vez de deducirse luego de un estado.
El motivo es una columna, no un estado
Una retirada retenida lleva consigo lo que la retiene. Quien abre la cola ve por qué espera esta, en lugar de deducirlo del orden de las filas.
Lo desconocido retiene, no libera
Si una comprobación no puede completarse —servicio inalcanzable, estado ilegible— la retirada espera a una persona. Tratar una pregunta sin respuesta como un visto bueno es justo el fallo que esta regla evita.
La aprobación es la decisión de alguien, y va firmada
Aprobaciones manuales, rechazos y ajustes registran quién los hizo y cuándo, en una pista inalterable. Una retirada que se movió sin nadie detrás es exactamente lo que pregunta una auditoría.
Se acredita lo que llegó, no lo que se pidió.
Un depósito cripto se factura a una dirección con plazo y luego se vigila. Al jugador se le acredita lo que realmente se liquidó on-chain, que es la única cifra verdadera: las facturas se pagan de menos, de más y tarde, y acreditar el importe facturado es acreditar un deseo. Por eso el pago de menos y el de más tienen resultados definidos en vez de convertirse en un ticket de soporte, y el depósito se concilia contra la cadena y no contra la intención.
Probar la caja sin firmar nada.
Con la plataforma viene un simulador de pagos, y no es un sustituto que devuelve «éxito»: recorre el mismo camino de webhook que un procesador real, así que lo que se le responde a su código es lo que habría respondido un proveedor.
Depósitos y retiradas de extremo a extremo
Un ciclo completo —solicitud, redirección, callback, movimiento de saldo— antes incluso de elegir un PSP, no digamos de integrarlo. Normalmente meses antes de que esas pruebas fueran posibles de otro modo.
Los fallos, no solo el camino feliz
Rechazos, tiempos agotados, callbacks malformados y firmas falsificadas son escenarios que puede pedir. Una firma falsificada se rechaza de verdad, porque el simulador pasa por la verificación real y no la esquiva.
Seguro junto a un proveedor real
Una marca solo tiene el simulador si está configurada para él, y el camino del webhook rechaza una entrega cuyo proveedor no sea el suyo. Una marca apuntada a un procesador real no puede manejarse desde el simulador.
Añada procesadores de pago sin rediseñar la plataforma.
Un procesador es una implementación detrás de una interfaz más su fila de configuración: credenciales por marca, cifradas y nunca devueltas por la API. Por encima de esa costura no cambia nada, y eso convierte «nuestro adquirente en este mercado» en una cuestión de configuración y no de hoja de ruta. Su equipo puede añadir uno sin nosotros: el código es suyo y las implementaciones existentes son los ejemplos ya resueltos.
No publicamos un muro de logotipos. Haber escrito una integración y haberla visto liquidar dinero real para su marca son afirmaciones distintas, y qué procesadores usa una marca es su propio contrato. Pregúntenos directamente y tendrá una respuesta clara sobre qué ha funcionado en real y qué no, incluido allí donde la respuesta es «todavía no».
Preguntas sobre los pagos.
Lo que sale cuando la caja deja de ser un diagrama.
En el código vienen integraciones para varios procesadores —tarjetas, cripto, monederos electrónicos y métodos locales— y añadir otro es una clase detrás de una interfaz más una fila de configuración, no un cambio de plataforma. No publicamos la lista como muro de insignias, porque «la integración existe» y «ha liquidado dinero para su marca» son enunciados distintos y a usted solo le importa el segundo. Díganos con qué adquirentes y PSP tiene contrato y le diremos con claridad qué está ya implementado, qué ha corrido en real y qué implica conectar el resto.
Sí, y es la configuración normal. El proveedor se resuelve por marca y por método de pago, de modo que un mismo despliegue puede atender a una marca europea con un adquirente y a una latinoamericana con otro, con métodos distintos en cada caja. Las credenciales son de la marca, se guardan cifradas y la API nunca las devuelve.
Una retirada se juzga cuando el jugador la solicita, no después de mover el dinero, y la retención se escribe en el pago junto con el motivo que la causó. Si una comprobación no puede completarse, la retirada espera a una persona en lugar de pasar por defecto. Las aprobaciones manuales y los ajustes registran quién los hizo, en una pista inalterable.
Se le acredita lo que realmente llegó on-chain, no lo que pedía la factura. El pago de menos y el de más tienen resultados definidos en vez de convertirse en un ticket de soporte, y el depósito se concilia contra la cadena, que es el único registro que no es una declaración de intenciones.
Sí, y es de lo más útil de la entrega. El simulador de pagos viene con la plataforma y recorre el mismo camino de webhook que un procesador real, incluidos rechazos, tiempos agotados, cuerpos malformados y firmas falsificadas. Su equipo puede completar un ciclo de depósito y retirada meses antes de que exista un contrato, y una marca apuntada a un procesador real no puede manejarse desde ahí.
No, y a propósito. Los monederos son multidivisa y cada importe permanece en la divisa en la que ocurrió; no hay fuente de tipos de cambio en la plataforma, porque convertir al cambio de hoy haría que el mismo importe se juzgara distinto en dos fechas. Donde un umbral o un informe necesita divisa, se define por divisa en lugar de convertirse a una.
Conserve los adquirentes y PSP con los que ya trabaja.
Cuéntenos con qué procesadores tiene contrato y qué mercados va a abrir. Le diremos qué está ya implementado, qué ha corrido en real y qué implica de verdad conectar el resto.
Respondemos en un día, normalmente el mismo.
Ver la plataforma