How iGaming Platform Modules Work Together: Follow the Player and the Money

A player experiences the platform through an account and a joined view of funds. Behind that view, several modules answer different questions: may this player act, has a payment succeeded, is money available, which promotion applies, and has a game result been recorded? The difficult part is making those answers agree when responses are delayed or work stops halfway through.

This article is for product owners, architects and operations leads reviewing an integrated platform. It follows an illustrative journey from registration to withdrawal and gives each transition a decision owner, durable record and recovery path. The sequence and promotional rules are examples to adapt to the operator’s approved requirements; they are not a universal legal sequence or a description of a deployed client system.

Assign authority before drawing the player journey

Start with the capabilities described by the modular iGaming platform and platform capabilities, then ask which component is allowed to change each fact. These responsibilities can live in a modular monolith or separate services. A deployment boundary alone does not establish ownership.

• Player accounts: own account identity, lifecycle and the current restrictions relevant to an action. Verification evidence comes from a verification process; a provider’s result does not itself decide every platform permission.
• Payments: own the platform payment record, provider references and the interpretation of external payment status.
• Wallet: owns monetary postings, available funds and holds. A payment status, game result or support dashboard cannot independently rewrite the balance.
• Bonuses: own the promotion instance, applicable terms, eligibility and progress. Any bonus-funded money movement must use the agreed wallet contract.
• Games: own the platform’s interpretation of provider rounds, acceptance, settlement and reversals. They reference wallet operations instead of making a competing balance.
• Workflow coordination: owns unfinished steps, deadlines and recovery. Reporting, support and the frontend show joined views; they request changes through the responsible module.

“Source of truth” therefore applies to a specific fact, not to one database for everything. The provider has external evidence; payments have a canonical interpretation; the wallet has the financial posting. Reconciliation checks the relationship between these records rather than pretending they are interchangeable.

Keep account creation, verification and action permission separate

In this example, registration creates an account, identity verification is completed, and only then is a deposit permitted. Actual requirements differ by market, product and action. The operator and qualified advisers must specify when checks, restrictions and limits apply; engineering must make those decisions enforceable.

Registration should return a stable player identifier and an explicit account state. The verification process stores a case reference and result; the account module applies the approved policy to decide which actions are now allowed. Avoid a single “verified” flag that also means unrestricted, allowed to deposit and allowed to withdraw. A completed identity check does not remove a separate account restriction.

Permissions must be evaluated when a consequential action is accepted, not just when the player logs in. Consider a restriction arriving while a deposit or stake request is in flight. Specify which module makes the final acceptance decision, how it uses current policy and restriction state, and how concurrent changes are ordered. A version check, lock or coordinated acceptance protocol must actually enforce that contract; reading several services and then acting later leaves a race.

Recovery also needs a distinction between new activity and an earlier accepted obligation. A restriction may prevent a new stake while a result for an already accepted round still needs to be accounted for under the approved rules. Blocking every callback can leave money unexplained. The player account architecture develops these state and permission boundaries.

A deposit can succeed before the wallet or bonus catches up

Suppose the player requests a EUR 100 deposit. Payments creates a stable operation reference before contacting the provider. The browser returning to a “success” page is not authority to credit funds. The adapter must authenticate external evidence and check its association with the correct provider account, payment, player, currency and amount before payments accepts a state transition.

As one provider-specific example, Stripe’s webhook documentation warns that deliveries can be duplicated and arrive out of order, and requires origin verification. This illustrates an integration risk, not a recommendation of that provider for iGaming or a contract shared by every processor.

Once the agreed payment evidence supports crediting, payments asks the wallet to post the deposit under one stable posting identifier. The wallet durably records the operation and credit together. If the response is lost, payments queries or retries that same operation according to the contract; it does not request another credit with a new identifier. Payments can show “provider confirmed; wallet credit pending” until the posting is verified. The player should see that useful intermediate state instead of a balance that the platform cannot substantiate.

A confirmed wallet posting can then trigger bonus evaluation. In this example, a player who explicitly activates an eligible offer receives EUR 20 in a separately tracked bonus balance; its terms allow cash withdrawals independently and exclude that bonus balance from withdrawal. These are illustrative terms, not a default rule. Bonuses stores the activation and terms version, then uses a distinct stable wallet operation for the grant. A delayed bonus must not repeat the EUR 100 deposit or make that deposit disappear.

Use the qualifying deposit reference and promotion instance to prevent a replay from creating a second grant. Define what happens if eligibility changes before activation, or the deposit is later reversed: review the affected promotion and any spent funds under the agreed rules. Automatically deleting old credits cannot reconstruct what the player has already done.

Game acceptance, wallet movements and bonus progress must agree

The player now stakes EUR 10 from the cash balance. The game integration resolves the account, brand, currency, game session and provider round to a stable platform operation. It checks current action permissions and the applicable limit controls, then coordinates funding and game acceptance through the documented contract.

One possible design reserves funds first, sends the game command and converts the reservation to a stake posting when acceptance is established. This is one option, not a universal provider protocol: some integrations use provider-initiated debit callbacks or other arrangements. Specify the actual acceptance evidence, the funding commit point and the recovery path. A game launch is not evidence that a stake exists.

Two tabs can place different stakes at the same time. The wallet must enforce available funds atomically across both; each request may be individually valid while their combined amount is not. Shared limit controls need equivalent concurrency protection for the quantity they govern. Duplicate suppression alone does not prevent overspending by distinct operations.

For a simple accounting example, assume this accepted stake consumes EUR 10 cash, then the provider reports a total cash return of EUR 15, including the returned stake. Available cash moves from EUR 100 to EUR 90 and then EUR 105. The unused EUR 20 bonus remains separate. The adapter must define whether a provider amount is total return or net win: crediting both the return and an additional returned stake would overpay.

Settlement refers to the accepted round and uses a stable financial operation. Bonus progress follows the actual funding allocation and the recorded promotion terms; a cash stake does not automatically count towards every offer. A result arriving before the required round record should wait for resolution or enter a controlled exception path, not be silently discarded. A later void or correction is a linked new operation, not an edit that erases the original settlement.

A withdrawal needs a hold and a recoverable payout decision

The player requests EUR 40 from the EUR 105 cash balance. Under this example’s terms, and assuming the action passes current account, risk and withdrawal checks, the wallet reserves EUR 40 against that withdrawal. Available cash is now EUR 65 and held cash is EUR 40; total cash has not yet been paid out. The bonus balance remains outside this calculation.

The payout workflow stores its operation, destination reference, checks and any required review. Payments submits the provider request with the stable external identity supported by that integration. Staff approval authorises the proposal; it does not prove that the provider paid it. Prevent concurrent workers or repeated approvals from submitting a second payout.

If the provider definitively rejects the payout before paying, release the hold through a linked wallet operation. If the agreed evidence confirms the completed payout, consume the hold and record that outcome. If the response times out after submission, keep an explicit unknown outcome and investigate using the original reference. Do not release the hold and simultaneously try another provider: both payouts may later succeed.

Cancellation needs an equally precise boundary. A player can request cancellation, but the platform must establish whether the external payout can still be stopped before making the reserved funds available again. A worker’s expired lease is not proof that its external command failed. If the provider has no reliable lookup or duplicate protection, the recovery path may require manual provider confirmation rather than an automatic retry.

Show the player and support staff the same operational meaning: under review, awaiting provider outcome, paid, rejected or cancellation under investigation. Reveal appropriate detail without exposing sensitive documents or payment credentials. “Completed” should reflect the chosen financial completion evidence, not the fact that a queue job ran.

Coordinate incomplete work without taking over every module

Use synchronous decisions where an action needs an immediate authoritative answer, and durable asynchronous work where completion may outlive a request. A stored workflow can coordinate a withdrawal’s hold, review, submission and result. It should ask domain modules to act; it should not bypass their controls or become a second wallet.

Microsoft’s saga guidance describes coordinated local transactions and compensating actions, while warning about failed compensation and the lack of built-in isolation across services. A workflow engine therefore does not supply a global financial rollback or solve concurrent balance updates.

For the proposed design, persist the workflow’s current step, accepted decision references, pending command, deadline, version and responsible recovery queue. Recover after a worker crash by inspecting this durable state and the participant’s recorded operation. Conditional step transitions prevent competing workers from completing incompatible paths; stable participant operation identifiers protect against repeated external work only where the receiving boundary enforces duplicate protection. Neither mechanism alone protects everything.

AWS’s transactional outbox guidance couples a local state update and its outgoing event record in one database transaction. A separate publisher sends committed events. It also highlights duplicate delivery and ordering; the pattern does not make a remote financial effect atomic with that local transaction.

Apply that idea to wallet credit and its notification. A publisher failure leaves committed work waiting to be delivered, rather than a permanently missing bonus trigger. Consumers must durably coordinate their processed-message record with their own local change; downstream side effects need their own operation contract. An event identifier deduplicates delivery, an operation identifier identifies the business effect, and a correlation identifier joins the journey. Substituting the last for the first two is unsafe.

The Amazon Builders’ Library explains caller-provided request identifiers, atomic recording of identifiers with mutations, rejection of changed parameters and service-specific retention. Those properties must be established at the boundary where a repeated request could repeat an effect; an identifier in a log is insufficient.

Agree a bounded retry policy for each boundary and retain duplicate-protection evidence for the supported replay and recovery window. After that window, reconcile old requests rather than treating them as new. Ordering needs a scope: a provider round, payment or promotion may have its own sequence. Wall-clock timestamps do not create a reliable global order. Validate permitted transitions and versions; queue genuine missing prerequisites, reject contradictory changes and investigate unresolved gaps.

A failing email or reporting consumer can lag without undoing a valid wallet posting. A missing mandatory permission decision may instead require holding or rejecting a new action. Make those choices explicit per dependency. This allows useful degradation without pretending that every component is equally safe to bypass.

Review the journey as a sequence of enforceable contracts

Use the following sequence as a review worksheet. Replace every example state and owner with the real module and provider contract; add a responsible team, expected completion time and escalation threshold to each item.

1. Account created → permitted action. Which account state exists, which checks apply to this action, and where is permission accepted? Evidence: player reference, policy version and decision. Recovery: verification or restriction ambiguity goes to a named case; it does not become permission by timeout.
2. Deposit requested → wallet credited. Which evidence qualifies the payment, who records its canonical status, and which operation posts the credit? Evidence: provider reference, accepted payment transition and wallet posting. Recovery: reconcile a confirmed payment without a posting; never credit from the browser redirect.
3. Qualifying deposit → bonus activated. Which offer and terms version applies, and must the player opt in? Evidence: promotion instance, deposit reference and grant posting. Recovery: finish or reject that activation without repeating the deposit; handle later reversal through explicit policy.
4. Stake requested → round settled. Which module accepts the round, how is funding committed, and what does the reported amount mean? Evidence: acceptance, funding allocation and linked postings. Recovery: resolve an uncertain acceptance before releasing its funds; process a correction against the original round.
5. Withdrawal requested → payout resolved. When are funds held, when is external submission allowed, and which evidence releases or consumes the hold? Evidence: proposal, review where required, provider reference and wallet operations. Recovery: retain the hold for an unknown payout and investigate the original submission.
6. Recorded outcome → visible outcome. Which views can lag and which must be current for a decision? Evidence: source reference, projection version and last processed position. Recovery: replay or rebuild a view without replaying the underlying financial commands.

Give operations a searchable path through those references and the age of pending steps. Distinguish a delayed event, an absent wallet posting and an unknown external payout: they need different owners and responses. Set alert thresholds from the agreed workflow deadlines and provider contracts, not from invented industry numbers. Track unresolved items until their records reconcile; a green HTTP dashboard cannot prove a completed journey.

For deeper reviews, use module boundaries and decision ownership, wallet and ledger design, payment orchestration and reconciliation, and technical due diligence. The integration review below should demonstrate recorded effects and recovery, not just a successful walkthrough of the interface.

• Confirmed deposit, interrupted credit. Stop processing after the provider outcome is recorded and again after the wallet credit commits but before its response arrives. Recover both cases: one cash credit, one activation of the eligible, opted-in bonus, and consistent player and support statuses. Also prove that an ineligible offer produces no grant.
• Concurrent stakes, repeated result. Submit distinct stakes that together exceed available funds; acceptance must respect the balance and applicable limits. Repeat one settlement and deliver it before its prerequisite round record. Recover to one posting for that settlement, with the correct total-return interpretation.
• Unknown payout, attempted cancellation. Let the provider accept a payout and lose the response. Attempt retry, cancellation and submission through another worker. Prove that funds remain protected until the original outcome is established and that recovery cannot create a second payout.
• Restriction change and interrupted event delivery. Race a restriction with action acceptance and verify the documented ordering rule. Crash the publisher after a wallet commit, then replay deliveries. New actions remain subject to restrictions, earlier accepted obligations remain recoverable, and views and bonus processing catch up without repeating money movements.