Withdrawal Protocol — lets a player move their shadow-ledger balance out of the game to their own bank via Stripe Connect.
The GM never talks to Stripe; it only produces the atomic ledger moves as MoM
ledger/batch effects (so they run under the game's GM authority, never a
direct ledger HTTP call). The actual Stripe Transfer is performed by the game's
HTTP layer (game.payments) between the reserve and settle steps:
request -> ledger/batch player -> @withdrawals-pending (game.payments calls Stripe create-transfer) settle -> ledger/batch @withdrawals-pending -> @withdrawals-paid (success) reverse -> ledger/batch @withdrawals-pending -> player (failure)
A single withdrawal-id (minted by game.payments) keys the reserve ledger
move and the Stripe Idempotency-Key; settle/reverse derive :settle/:reverse
suffixed keys so replays are exactly-once. Records live in game-state under
:withdrawal :records and are advanced by MoM's on-success callbacks.
Withdrawal Protocol — lets a player move their shadow-ledger balance out of the game to their own bank via Stripe Connect. The GM never talks to Stripe; it only produces the atomic ledger moves as MoM `ledger/batch` effects (so they run under the game's GM authority, never a direct ledger HTTP call). The actual Stripe Transfer is performed by the game's HTTP layer (game.payments) between the reserve and settle steps: request -> ledger/batch player -> @withdrawals-pending (game.payments calls Stripe create-transfer) settle -> ledger/batch @withdrawals-pending -> @withdrawals-paid (success) reverse -> ledger/batch @withdrawals-pending -> player (failure) A single `withdrawal-id` (minted by game.payments) keys the reserve ledger move and the Stripe Idempotency-Key; settle/reverse derive `:settle`/`:reverse` suffixed keys so replays are exactly-once. Records live in game-state under `:withdrawal :records` and are advanced by MoM's on-success callbacks.
(handle-query payload)List a player's own withdrawal records (most recent first).
List a player's own withdrawal records (most recent first).
(handle-request payload)Reserve step: records the withdrawal and returns the ledger/batch effect that debits the player into @withdrawals-pending. game.payments calls Stripe after this succeeds.
Reserve step: records the withdrawal and returns the ledger/batch effect that debits the player into @withdrawals-pending. game.payments calls Stripe after this succeeds.
(handle-reserve-failed payload)(handle-reserve-succeeded payload)(handle-reverse payload)Failure step: return the amount holding the funds back to the source account. Pre-settle (funds in @withdrawals-pending) is the normal async-failure path. But a transfer can also be reversed AFTER settle (dispute, manual clawback), in which case the funds already sit in @withdrawals-paid; source from there so the return batch has balance to debit and the account (house or player) is made whole.
Failure step: return the amount holding the funds back to the source account. Pre-settle (funds in @withdrawals-pending) is the normal async-failure path. But a transfer can also be reversed AFTER settle (dispute, manual clawback), in which case the funds already sit in @withdrawals-paid; source from there so the return batch has balance to debit and the account (house or player) is made whole.
(handle-reverse-failed payload)(handle-reverse-succeeded payload)(handle-settle payload)Success step: move the reserved amount @withdrawals-pending -> @withdrawals-paid.
Success step: move the reserved amount @withdrawals-pending -> @withdrawals-paid.
(handle-settle-failed payload)(handle-settle-succeeded payload)(validate-payload event-key payload)cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |