Cashier Responsibilities: Platform Provider vs Crypto PSP

Nobody argues about the cashier during procurement. It's slide 31, four bullets, somebody says "standard integration," two people nod, and the deck rolls on to reporting.

The argument shows up about five months later. Saturday night, 11:40pm. A VIP's 5,000 USDT deposit has six confirmations sitting right there on the explorer, and his balance still reads zero.

Both vendors are on a bridge call being extremely polite to each other, and both are hinting that this smells like the other one's system. Your head of support keeps refreshing a dashboard that is not going to change. Meanwhile, the player is in live chat, in caps, asking whether he's just been robbed.

I've been on that call more times than I want to put in print. That's why this piece exists. Ownership is an abstract, mildly boring topic right up to the minute it costs you money and a player. Then it's the only thing anybody in the room wants to talk about.

Here's the split that holds up under a real incident. Your platform provider owns the cashier UI, the player session and the player ledger. Your crypto payment provider owns the rails, settlement and on-chain execution.

You own the reconciliation between them, and you own the promise you made the player. Stuck withdrawals almost never fail inside one of those three boxes. They fail in the seams.

What's coming: a function-by-function ownership table, four grey zones no table can hold, a 15-minute triage script for an uncredited deposit, and two full failure walkthroughs (a Lightning deposit that never credits, a stablecoin withdrawal broadcast on the wrong chain).

After that, contract language, the one-page RACI both vendors initial before go-live, and the UAT scenarios to run before a real player touches anything.

What "the cashier" actually consists of

The word "cashier" is carrying way too much weight. Operators use it to mean a screen. Vendors use it to mean whichever slice of the flow they happen to build. That mismatch is the crack accountability leaks out of.

Break it into four layers and most of the arguments die on the spot.

1. Front end

Deposit and withdrawal screens, method selection, minimums and maximums as displayed, the amount field, chain or network pickers, confirmation screens, every error string the player reads. Also the logic deciding whether a method is even visible: geo, currency, VIP tier, KYC status, device. Platform-owned, almost always, even when the widget is iframed in from the payment provider.

2. The ledger, and the session behind it

Balance. Real money kept apart from bonus money. Wagering contribution, pending withdrawal locks, transaction history, deposit and loss limits, cooling-off flags, self-exclusion state. Whatever the player has, this is the layer that says so. Which means a balance that jumps up and then quietly slides back down did not break on a chain somewhere. It broke in here.

3. Rails

Generating the address or the Lightning invoice. Watching the chain. Deciding how many confirmations count. Capturing the preimage. Signing the payout, broadcasting it, picking the fee. Checking that the address format and the destination chain actually agree with each other. Writing the settlement record afterwards. Execution, start to finish, and it belongs to the payment provider.

4. Back office

Treasury sweeps, hot and cold wallet balances, float management, settlement files, ledger exports, the reports your finance team reconciles and your auditor eventually asks for. Split three ways: the payment provider produces its half, the platform produces its half, and you match them. Nobody else is going to do it for you.

Now the problem. Bundle all four layers under one noun and an incident ticket that reads "cashier issue" becomes unassignable the second it lands in the queue.

A player sees "Withdrawal failed, please try again." That single string could have come from the front end (a validation rule), the ledger (a bonus lock), the rails (an unlisted chain rejected at the API boundary) or the back office (hot wallet empty). Four owners. One message. Zero routing information.

So write your ownership map at layer level, not vendor level. That's the difference between a four-minute triage and a three-hour call with eleven people on it, nine of whom are muted.

Casino platform provider vs payment provider: Where does the line actually sit?

The clean version is short. Your platform provider (the PAM) is a system of record for player state: identity, session, wallet balance, bonus liability, limits, transaction history. Your payment provider is a system of execution: it generates deposit addresses or invoices, watches chains, broadcasts payouts, and reports what happened.

The line sits at the callback.

Everything before the callback belongs to the payment provider. Invoice generation, chain monitoring, confirmation depth, broadcast, fee selection. Everything after the callback is consumed belongs to the platform. Ledger credit, bonus attribution, limit enforcement, cashier display.

That one sentence settles maybe 70% of disputes. The other 30% live in the grey zones below, and those are the ones that eat your Saturday.

Who owns each cashier function?

What the table cannot express: The four grey zones

Zone one: the callback retry window. The provider owns sending the callback. The platform owns receiving it. Nobody owns the gap between attempt three and attempt seven unless your contract spells out a retry schedule, a maximum backoff, and a dead-letter queue you can poll yourself. Miss that clause and a five-minute platform deploy turns a paid invoice into a permanently uncredited deposit.

Zone two: idempotency. The provider retries. The platform already credited. Congratulations, you've paid a player twice. Or the platform suppresses the duplicate correctly, except its dedupe key is player ID plus amount plus minute, so it also swallows a genuine second deposit of the same size from the same player thirty seconds later. Idempotency key format and collision behaviour is a joint spec. Put it in the integration document. Right now it probably lives in the head of one senior engineer who is six weeks away from a new job.

Zone three: the chain parameter on withdrawals. Stablecoins live on many networks. Somebody has to pick one. Depending on how your crypto cashier integration got built, that choice happens in a platform-rendered dropdown, inside a provider-hosted widget, or silently through a provider-side default network map. All three are defensible engineering. Only one of them is in your contract. Ask five operators which one they're running and four will have to go ask a developer.

Zone four: FX timing. The platform displays a rate. The provider executes against a quote with a validity window, usually 30 to 60 seconds. Your player spends 90 seconds hunting for their 2FA device. Now the executed rate isn't the displayed rate. Who absorbs the delta? At what threshold does it stop being noise and become a chargeable variance? That's a commercial term wearing a technical costume.

What should an online casino platform provider contractually own?

Start with a definition, because everything else hangs off it. "Credited" means a posted state in the player ledger with a timestamp. It does not mean "callback received." Two different events. The space between them is exactly where deposits go missing.

Then specify, in writing:

• Maximum elapsed time from callback receipt (HTTP 200 returned) to ledger credit. Put a number on it. Two seconds is reasonable. "Promptly" is not a number.

• Behaviour on malformed or partially valid payloads.

• The exact conditions under which the platform rejects a callback with a 4xx versus a 5xx. This matters far more than it sounds. A 4xx tells the provider "don't retry, this is wrong." A 5xx tells it "retry, I'm broken." Get those backwards and you either lose deposits or duplicate them.

• An operator-accessible log of every inbound payment callback: payload hash, response code, processing latency. No support ticket required to read it.

Two more items sit squarely in the platform column and get forgotten constantly, because they don't look like payments.

Bonus and wagering interaction. When a deposit credits, something decides whether it qualified for a promotion, how much wagering it carries, whether bonus balance spends before real balance, and whether a pending withdrawal breaks an active wagering requirement.

All of that is player-state logic. Platform-owned, full stop. It's also a top-three cause of "the deposit arrived and then the balance changed again," because a bonus-engine exception that rolls back a transaction takes the wallet write with it.

Method display logic. Which methods appear, for whom, in what order, with what minimum. The payment provider says what's technically available. The platform decides what a given player sees.

Offer a UK player a method your licence doesn't permit and that's a platform configuration failure. Your regulator will still file it under your name.

One more, and it isn't negotiable: limits, cooling-off periods and self-exclusion have to block the cashier at the platform layer, before any request reaches a payment rail. Responsible gaming enforcement that depends on your payment provider refusing a transaction isn't a control. It's a favour.

What should a crypto payment provider contractually own?

Everything from the moment a payment request is created to the moment a signed settlement record exists. Plus the record itself.

Detection. Confirmation policy. Broadcast. Fee strategy. Address-format and chain-compatibility validation. And the evidence proving what it did.

Four artefacts, written into the contract:

1. A per-transaction settlement record, cryptographically signed, timestamped from a stated source.

2. A contracted network whitelist with a hard obligation to reject rather than default on any unlisted chain. "Reject" is the operative word.

3. Address-format plus chain-compatibility validation as a provider-side check, not a front-end nicety.

4. Machine-readable settlement exports on a fixed cadence, in a fixed schema, retained for a stated period.

None of that should require a change request. Every incident triage you will ever run leans on those four artefacts, which is why they belong near the top of your shortlist criteria, well ahead of pricing. A payment provider built for casino cashier flows treats evidence generation as a product feature, not a support escalation you chase on a Sunday afternoon.

And add the clause almost everybody forgets: for any failing step the provider owns, a written RCA within a stated number of hours, whether or not the money came back.

What you can't hand to either vendor

Two things stay with you no matter what the contract says.

The player-facing SLA. "Withdrawals in under an hour" is your promise, on your site, under your licence. No clause transfers it. No regulator accepts a vendor's name in place of yours.

AML sign-off. Your payment provider screens addresses and flags sanctions and risk exposure. Your platform fires threshold events and freezes the cashier. Neither one makes the decision.

A human on your team, named in your policy, reviews the case and signs it. Source-of-funds judgement, SAR filing, enhanced due diligence, the call to release or hold a payout: all yours.

Vendors supply inputs. You own the decision, and you own the file when an auditor asks to see it.

The 15-minute triage: uncredited deposit

Run this in order, on a timer, before anybody opens a bridge call. Can't finish it in fifteen minutes? Congratulations, that's your gap analysis.

Minutes 0–2. Confirm the money exists. Pull the settlement record. Lightning: is there a preimage? On-chain: is there a tx hash at the required confirmation depth, to a known-good address? No proof of settlement, no incident. What you have instead is a player who thinks he paid, and support can close it with evidence attached.

Minutes 2–5. Pull the callback log. Every attempt against that payment reference: target URL, timestamp, payload hash, HTTP status returned. Highest-value lookup in the entire process. Which is exactly why operator-accessible callback logs belong in the contract, not in a vendor's support queue.

Minutes 5–7. Route on the response code. Zero attempts logged: payment provider owns it, detection or dispatch fault. 5xx or timeout: platform owns it, and the provider still owes you the contracted retry schedule plus a dead-letter entry. 200 returned: platform owns it, no argument available. They accepted the credit and then lost it inside their own system.

Minutes 7–10. Hunt for a ghost in the platform. Look for a matching transaction that got created and then reversed, or a dedupe suppression against the payment reference. Idempotency collisions and bonus-engine rollbacks are the two usual suspects. Both leave a trace.

Minutes 10–13. Pay the player. Manual credit from a suspense account against the provider's settlement record. Reference the payment reference and the platform transaction ID in the adjustment note. Never make a player wait on vendor consensus. That's your reputation funding somebody else's RCA.

Minutes 13–15. Log it and assign it. One ticket, one named owner from step three, one RCA deadline pulled straight from the contract. Then it goes into the weekly count, because one uncredited deposit is bad luck and eleven in a month is a broken integration.

Notice that every single step is a lookup, not a conversation. That's the whole design goal.

Failure-mode walkthrough: two incidents, step by step

Incident one: a Lightning deposit that never credits

Player has a paid invoice. Balance unchanged. Support has escalated. Here's how ownership moves.

1. Payment provider confirms invoice state: settled, in-flight, expired or failed. Settlement is proven by the preimage. No preimage, no settlement. That closes roughly a third of these tickets in a single step.

2. Payment provider produces the callback log for that invoice: every attempt, target URL, timestamp, payload hash, HTTP status returned.

3. No callback ever attempted? Ownership stays with the payment provider. Detection or dispatch fault on their side, their RCA.

4. Callbacks attempted, 5xx or timeouts returned? Ownership moves to the platform provider. The provider's remaining obligation is to honour the contracted retry schedule and expose the dead-letter entry.

5. Callback returned 200 and the ledger shows nothing? That one is the platform provider's, and there's no argument to be had. The credit was accepted and lost internally. Usual causes: idempotency key collision with an earlier transaction, or a bonus-engine exception rolling back the wallet write.

6. Operator works in parallel from step 2 onward. Credit the player manually from a suspense account against the provider's settlement record, referencing the invoice ID and the platform transaction ID.

7. Operator closes the loop by reconciling that manual adjustment against the next settlement file, so the suspense account nets to zero and the audit trail shows one payment and one credit.

Incident two: a stablecoin withdrawal sent on the wrong chain

1. Operator freezes the affected payout method. Immediately. Only you can make a commercial stop decision, and the job in the first two minutes is stopping incident two from becoming incident twenty.

2. Payment provider supplies the signed payout request exactly as received, showing the chain parameter as submitted, plus the broadcast transaction hash.

3. Parameter names the wrong chain? Ownership is the platform provider's. Or yours, if the chain was hardcoded in a config you supplied. The provider executed a valid instruction faithfully, which is its job.

4. Parameter absent, or naming a chain outside the contracted whitelist, and the provider defaulted instead of rejecting? Ownership is the payment provider's, recovery cost included.

5. Payment provider determines destination type and gives you a realistic recovery picture rather than a hopeful one:

   • Self-custody wallet where the player controls the same key across EVM networks: funds are accessible. Expect near-100% recovery, same day. Deliverable is proof plus plain-English instructions.

   • Custodial exchange or another casino, unsupported network: this is now a support ticket at a third party. Call it a coin flip and you won't be far off. Roughly half come back, timelines run two to eight weeks, and most venues charge a flat fee (commonly $100 to $1,000) or a percentage. Plenty of Tier-2 exchanges decline outright and point at their terms.

   • Token contract address, a burn address, or a chain where nobody holds the key: zero. Not "difficult." Zero. Write it off and move on.

   • Blended across a year of these, plan for under half the value coming back and budget the rest as a loss. Anyone promising better is selling you optimism.

6. Platform provider moves the withdrawal out of "pending" into a terminal or explicitly flagged state. A payout parked in pending distorts liability reporting and generates a fresh player contact every day it sits there.

7. Operator sets a decision clock. Usually 24 hours. After that, reissue the withdrawal on the correct chain and pursue recovery as a separate commercial matter between vendors. The player is not your collections department.

8. Both vendors, jointly: chain becomes a strict enum, unsupported values get rejected at the API boundary with a specific error code, and the platform surfaces that error to the player instead of retrying blindly.

If your current setup can't run those steps without a bridge call, you don't have a technical gap. You have a contract gap in a technical costume. See how LightningPay defines its side of the cashier before you write the next integration spec.

Instant Lightning settlement with a signed settlement record per transaction

Most cashier incidents stall on one unfalsifiable sentence: "it hasn't settled on our side yet."

While settlement stays probabilistic and time-dependent, that sentence remains true for as long as the vendor finds it convenient. Triage just sits there, waiting.

Lightning settlement is atomic. A payment either produces a preimage, which is cryptographic proof that the receiving node released the payment hash, or the payment doesn't exist. No confirmation-depth judgement call. No mempool ambiguity. No "pending" state roomy enough to hide an hour of investigation inside.

The operational value comes from binding that proof to a record. Per transaction: a signed, timestamped artefact carrying amount, payment hash, preimage, node identity and settlement time. Signed, so you can verify it without trusting anybody's dashboard. Timestamped at settlement rather than at reporting, so callback latency and ledger-credit latency become two separate numbers pointing at two separate owners.

The effect on incident handling is structural, not cosmetic. Step one of the deposit walkthrough stops being a debate and becomes a lookup. The ownership question (provider dispatch, network transport, or platform ingestion) resolves inside the first minute instead of the third hour.

The contract language that makes the ownership map enforceable

A map is only as good as its clauses. Five provisions do most of the work.

Definitions. Define "settled," "credited," "confirmed" and "completed" as four distinct states with four named owners. Vague definitions here have caused more stand-offs than bad code ever has.

Callback SLA. Retry count, backoff schedule, dead-letter access, maximum acceptable time from settlement to callback dispatch, and a measurable breach threshold. Numbers. Not adjectives.

Joint incident protocol. A severity scale, response times per severity, and a rule that every step names the owner of the next action. No incident should ever reach a state where both vendors are politely waiting on each other.

Data rights. Machine-readable exports from both sides, fixed schema, stated retention, accessible without raising a ticket. Reconciliation you can't automate is reconciliation you won't do.

Liability for misdirected funds. Tie liability to the ownership map, not to goodwill. Defaulted outside the whitelist? Provider owns recovery. Sent a bad parameter? Platform owns it. Write it down while everyone still likes each other.

How to phrase the withdrawal remediation clause

Operators ask me for actual wording more than anything else, so here's a workable starting point. Adapt it to your jurisdiction and let counsel read it before it goes anywhere near a vendor.

Misdirected Payout Remediation. Where a payout is executed to a network other than the network specified in the Approved Network Whitelist (Schedule X), the Party whose system originated the incorrect or absent network parameter, as evidenced by the signed payout request logged by the Provider, shall be the Responsible Party.

The Responsible Party shall, at its own cost:

• (a) within four (4) business hours of notification, deliver written confirmation of the transaction hash, asset contract address, destination address, amount and destination classification

• (b) within two (2) business days, initiate and fund any recovery process available at the destination venue, including any recovery fees; and

• (c) within five (5) business days, deliver a written root cause analysis and remediation plan.

Where the Provider executed a payout to a network absent from Schedule X, or applied a default network in the absence of an explicit network parameter, the Provider is the Responsible Party irrespective of the instruction received.

The Operator may reissue the payout on the correct network at any time after twenty-four (24) hours from notification. The Responsible Party shall reimburse the Operator the full reissued amount plus network fees within thirty (30) days, and such reimbursement is not contingent on the success of any recovery attempt.

That last sentence gets negotiated hardest.

Don't drop it. Recovery success and liability are separate questions, and any vendor tying reimbursement to recovery has just parked the risk of a burn address on your balance sheet.

Want to pressure-test your split before go-live? Book a walkthrough with LightningPay and bring your current integration spec.

The pre-go-live deliverable: A one-page RACI both vendors initial

Everything above compresses into one document. One page. Not a policy. Not a 40-page MSA annex nobody opens after signature. One page your platform provider and your payment provider both initial and date before launch.

Rows and four columns.

Three rules make it work.

Exactly one name in the Accountable column. Two names means nobody.

Row eight, the chain parameter, is where most maps quietly collapse. If you can't fill it in today, that's your first action item, not something to tidy up after launch.

Attach the two failure-mode sequences as an annex so the escalation path is pre-agreed. Nobody should be negotiating process at midnight during an incident.

Then get wet-ink initials or a signed PDF from both vendors. A shared spreadsheet nobody signed is a suggestion. The signature is the entire point. It's what turns a conversation into evidence when you're trying to recover money six months later.

UAT scenarios to run before you launch

Read the map, agree the map, then break it on purpose. Every scenario below has settled a real dispute I've watched play out after go-live, which is a stupid time to be finding any of this out.

Simulated callback failure. Take your callback endpoint down for eight minutes while three deposits settle. Confirm the provider retries on the contracted schedule. Confirm all three land once the endpoint returns. Confirm each one shows up in the dead-letter queue while it's failing. Then confirm you can see that queue yourself, without emailing a single person.

Idempotent retry. Replay the same callback five times, two of them inside the same second. Expect exactly one credit. Then run the nastier version: same player, same amount, two genuine deposits ninety seconds apart. Expect exactly two credits. Plenty of integrations sail through the first test and fail the second.

Unlisted chain rejection. Submit a payout on a network that isn't whitelisted. Correct outcome is a rejection at the API boundary with a specific error code. Silent success is a failed test. A default substitution is a failed test and a contract renegotiation.

Absent chain parameter. Same idea, harder. Omit the network field entirely. Anything other than a hard rejection means somebody's code is guessing with your money.

FX quote expiry. Open the confirmation screen, let the quote expire, then confirm. The player should get a re-quote, not a silent execution at a stale or repriced rate. Note who eats the delta and check it matches the contract.

Bonus rollback under load. Deposit into an active promotion, then force a bonus-engine error. Confirm the wallet credit survives independently of the bonus write. At absolute minimum, confirm the failure gets logged and alerted rather than swallowed.

Limit and self-exclusion block. Self-exclude a test account, then try to deposit. The block must fire at the platform, before any request reaches the payment provider. If the rejection comes back from the rail, your primary responsible gaming control lives in somebody else's system.

Withdrawal in pending, force-terminated. Push a payout into pending, then kill it. Confirm the platform can move it to a terminal state and that liability reporting updates. Zombie pending payouts poison finance numbers for weeks.

Reconciliation break, injected. Have someone quietly credit a manual adjustment that doesn't exist in the settlement file. Your daily match should catch it by tomorrow morning. If it takes a month, your reconciliation is decorative.

Run all of it in one shared session with engineers from both vendors on the call. Screenshot the results. Staple them to the RACI. That package is what you hand a regulator, an auditor, or an angry lawyer, and putting it together takes about a day and a half.

Final thoughts

After enough incidents, one pattern gets hard to unsee: the technology worked exactly as specified, and the specification said nothing at all about the thing that broke.

Cashier failures are overwhelmingly contract gaps in technical costume. An undefined retry. An unowned parameter. A settlement state two vendors define differently and neither defines in writing. That's most of them. Genuinely.

What never moves is the player-facing SLA. It's yours. No clause transfers it, no licensing regulator will accept a vendor's name where yours should be, and no player in the history of online gambling has felt better about a three-day withdrawal because the delay was technically someone else's fault.

Which is why the remedy is so unglamorous and so cheap. One page covering every row in that table, countersigned by both vendors before go-live, failure-mode sequences attached as an annex, UAT evidence stapled to the back.

Operators who do that resolve incidents in minutes and negotiate from evidence. Operators who don't spend their escalations arguing about whose problem it is while the withdrawal queue grows and the reviews get worse.

Nobody wants to talk about online casino platform provider cashier responsibilities during procurement. Do it anyway. Cheapest hour you'll spend all quarter.