The cashier, and everything behind it.
Configure payment providers per brand and trace every step of the payment flow.
This page describes how payments work in Callisto: how a provider is resolved for a brand and a method, what happens between a player pressing deposit and a balance moving, how withdrawals are held and approved, how crypto is credited by what actually arrived, and how the whole flow is tested before a single provider contract is signed.
From deposit request to wallet balance.
Four steps, each of which can fail, and each of which is written down. Nothing about the path is hidden from the operator who has to explain it afterwards.
The brand’s provider is resolved
A deposit names a brand and a payment method, and the platform resolves which processor handles that combination for that brand. Two brands on one deployment can use entirely different processors for the same method.
The player is taken to the processor
The provider returns a redirect the cashier opens — a hosted page or a frame, depending on what the processor supports. Cards, wallets, local methods, vouchers, agent-assisted payments and manual entries each follow the shape their method allows.
The verdict arrives on a signed webhook
The processor reports back to an endpoint whose border is a signature over the raw body rather than a platform key — an outside company never holds a credential that opens internal services. Retries are ordinary, so deliveries are recognised by an index rather than by a read two racing callbacks would both pass.
The balance moves once
A settled payment publishes a balance event, and the wallet applies it under optimistic concurrency. The same delivery arriving twice does not credit twice; that guarantee is in the database, not in a code path somebody has to remember.
Methods, in the shapes they actually take.
Method types are platform-wide and numbered once, so the same value means the same thing in the backoffice, the cashier and the reports. Which of them a brand offers, and in which order, is that brand’s configuration.
Hosted pages or a server-opened session, so a brand can keep the player inside its own cashier where the processor allows it.
Invoiced to an address with a deadline and then watched on-chain.
The wallets a market expects, each behind its own processor integration.
Including the local rails a card-only cashier misses.
For markets where an agent network funds the player, with its own wallet and settlement.
Manual entry is admin-only, never player-facing, and every one carries the person who made it.
A brand’s methods, their order in the cashier and their limits are configured per skin — adding a method is configuration, and adding a processor is a class behind one interface plus a row.
Withdrawal holds with a clear reason.
Withdrawals are where a platform either has a policy or improvises one. Callisto has a policy: a payout can be judged the moment a player asks for it, and what the answer was is written onto the payment itself.
Judged at request, not after the money moved
Asking the risk engine at settlement is late — the payout it was meant to stop has already happened. So the request is evaluated when the player makes it, and the hold is recorded on the payment rather than inferred later from a status.
The reason is a column, not a status
A held payout carries what held it. An operator opening the queue sees why this one is waiting rather than deducing it from the order of the rows.
Unknown holds rather than releases
If a check cannot be completed — a service unreachable, a status unreadable — the payout waits for a person. Treating an unanswered question as a pass is the failure mode this rule exists to prevent.
Approval is somebody’s decision, and it is signed
Manual approvals, rejections and adjustments record who made them and when, in an append-only trail. A payout that moved with nobody attached to it is exactly what an audit asks about.
Credited by what arrived, not by what was asked for.
A crypto deposit is invoiced to an address with a deadline and then watched. The player is credited with what actually settled on-chain, which is the only number that is true: invoices are underpaid, overpaid and paid late, and a platform that credits the invoice amount is crediting a wish. Under- and overpayment therefore have defined outcomes rather than becoming a support ticket, and the deposit is reconciled against the chain rather than against the intention.
Test the cashier with nothing signed.
A payment simulator ships with the platform, and it is not a stub that returns success: it drives the same webhook path a real processor uses, so what your code is answered with is what a provider would have answered.
Deposits and withdrawals end to end
A full cycle — request, redirect, callback, balance movement — before a PSP has been chosen, let alone integrated. Typically months before that testing would otherwise be possible.
The failures, not just the happy path
Declines, timeouts, malformed callbacks and forged signatures are scenarios you can ask for. A forged signature really is refused, because the simulator goes through the real verification rather than around it.
Safe next to a real provider
A brand gets the simulator only by being configured for it, and the webhook path refuses a delivery whose provider is not that brand’s. A brand pointed at a real processor cannot be driven from the simulator.
Add payment processors without redesigning the platform.
A processor is an implementation behind one interface plus its configuration row: credentials per brand, encrypted, never returned by the API. Nothing above that seam changes, which is what makes "our acquirer in this market" a configuration question rather than a roadmap question. Your team can add one without us — the source is yours, and the existing implementations are the worked examples.
We do not publish a logo wall. Writing an integration and having it settle real money for your brand are different claims, and which processors a brand uses is its own contract. Ask us directly and you will get a straight answer about what has run live and what has not — including where the answer is "not yet".
Payment questions.
What comes up once the cashier stops being a diagram.
Integrations for a number of processors ship in the code — cards, crypto, e-wallets and local methods — and adding another is a class behind one interface plus a configuration row rather than a platform change. We do not publish the list as a badge wall, because "the integration exists" and "it has settled money for your brand" are different statements and only the second one matters to you. Tell us which acquirers and PSPs you hold contracts with, and we will tell you plainly which are already implemented, which have run live, and what connecting the rest involves.
Yes, and that is the normal configuration. A provider is resolved per brand and per payment method, so one deployment can serve a European brand on one acquirer and a Latin American brand on another, with different methods in each cashier. Credentials belong to the brand, are stored encrypted and are never returned by the API.
A payout is judged when the player requests it rather than after the money has moved, and the hold is written onto the payment with the reason that caused it. If a check cannot be completed, the payout waits for a person rather than passing by default. Manual approvals and adjustments record who made them, in an append-only trail.
They are credited with what actually arrived on-chain, not with what the invoice asked for. Under- and overpayment are defined outcomes rather than a support ticket, and the deposit reconciles against the chain — which is the only record that is not a statement of intent.
Yes, and this is one of the more useful things in the delivery. A payment simulator ships with the platform and drives the same webhook path a real processor uses, including declines, timeouts, malformed bodies and forged signatures. Your team can run a full deposit and withdrawal cycle months before a provider contract exists, and a brand pointed at a real processor cannot be driven from it.
No, and deliberately not. Wallets are multi-currency and every amount stays in the currency it happened in; there is no exchange-rate source on the platform, because converting on today’s rate would let the same amount be judged differently on two days. Where a threshold or a report needs a currency, it is set per currency rather than converted into one.
Keep the acquirers and PSPs you already work with.
Tell us which processors you have contracts with and which markets you are opening. We will say what is already implemented, what has run live, and what connecting the rest actually involves.
We reply within a day, usually the same one.
See the platform