Best practices CDB

Een wijziging in een spelnaam moet real-time gerapporteerd worden volgens trigger 4 (en niet trigger 3).

U bepaalt hoe de naam van een spel gewijzigd wordt in het systeem. U hoeft het spel niet te deactiveren als dit niet nodig is. In de rapportages richting CDB willen wij echter zeker weten dat er geen twee actieve spelnamen bestaan voor hetzelfde spel. Daarom verwachten wij bij een naamswijziging, een record met de oude naam en de datum en tijd van het inactiveren. Daaropvolgend verwachten wij een tweede record met daarin dezelfde Game ID maar met de nieuwe naam en de datum en tijd van de activatie. De verwachting is dat in de meeste gevallen de datum en tijd van de-activatie van het oude spel en activatie van het nieuwe spel gelijk zullen zijn.

Trigger 3 moet gebruikt worden wanneer een spel volledig teruggetrokken wordt uit het systeem hetzij voorgoed, het zij voor een lange periode.

Een eerder aangegane weddenschap is bijgewerkt door bijvoorbeeld het verwijderen van een deel van de bet parts of door een gedeeltelijke uitbetaling.

BET_UPDATED is een status voor dergelijke gevallen. Zonder de nieuwe trigger wordt de update niet aangeleverd, waardoor de bijbehorende transactie geen link krijgt met de betreffende bet.

De triggers bij het aanleveren van WOK_BET zijn:

1. Een Bet is geplaatst en geaccepteerd.
2. Een bet is settled of gecanceld
3. Een bet is bijgewerkt door bijvoorbeeld een gedeeltelijke cancellation of uitbetaling

De spelers met status Trial mogen enkel transacties uitvoeren in het kader van de verificatie procedure van hun spelersaccount.

Het datamodel 1.1 bevat updates en aanscherpingen, waaronder de introductie van vijf nieuwe velden en drie nieuw toegestane enumeraties.

De vijf nieuwe velden:

De gebruikte id’s hieronder zijn geen geldige id’s en zijn enkel ter illustratie.

Een weddenschap wordt gerapporteerd door WOK_BET bestand met daarin:

In het WOK_BET bestand zijn de transacties door middel van de transactie ID gelinkt aan zowel de wok_Player_account_transaction als wwft_player_account_transaction.

Als er fouten ontdekt zijn, nadat deze bestanden verzonden zijn, moet een resettlement gedaan worden. Bijvoorbeeld als de odds 3.5 keer de stake hadden moeten zijn. In zo’n geval wordt er een nieuw wok_bet bestand aangeleverd met een nieuwe record id, maar met dezelfde bet_id en dezelfde player_id. Dit moet via de Replacement of de Cancellation methode van het initiële WOK_BET bestand, omdat de odds gewijzigd zijn.

2.1 Replacement methode

De nieuwe resettlement transactie TRANS000-0000-0000-0000-000000000003 moet ook aangeleverd worden in zowel wok_player_account_transaction als in wwft_player_account_transaction. De twee initiële transacties worden dus niet opnieuw aangeleverd omdat ze onveranderd zijn.

2.2 Cancellation methode

De replaced_record_ID blijft leeg en we verwachten een cancellation bestand dat de originele work_bet record cancelt. Wok_bet en cancelled_record_id = REC00000-0000-0000-0000-000000000001. De rest is identiek aan de Replacement methode.

2.3 Resettlement zonder replacement of cancellation

Het is mogelijk dat door een error de resettlement is uitgevoerd op data die niet aan Ksa is geleverd:

• Delta methode: als alle overige data in WOK_BET ongewijzigd blijft, moet alleen een nieuwe transactie van type resettlement toegevoegd worden aan WOK_BET (nieuw record id en nieuwe transactie in de transactie sectie van WOK_BET, de rest blijft ongewijzigd)
• Replacement of Cancellation methode: procedure is gelijk aan de Delta methode met het verschil dat er een replaced_record_id toegevoegd moet worden of een record in het cancellation bestand. De initiële odds blijven uiteraard ongewijzigd.

Zoals te zien, kunnen de replacement en cancellation methode gebruikt worden in gevallen waarbij WOK_BET gewijzigd is nadat een bet settled is door een error.

Gebruik van resettlement transactie type bij andere situaties is niet mogelijk.

Als er geen sprake is van resettlement, maar het spelersaccount moet gedebiteerd/gecrediteerd worden door een andere reden, dan valt dit NIET onder resettlement transactie type.

Resettlement mag allen gebruikt worden wanneer een transactie gelinkt is aan een BET (zoals CASH_OUT en VOID_BET).

Voor elk specifiek geval, gebruik bijbehorend type zoals beschreven in het datamodel. Gevallen die niet door het datamodel gedekt worden, kunnen met OTHER aangeduid worden.

Hieronder worden 3 scenario’s beschreven:

1. Een poker toernooi met inschrijving waaraan de speler deelneemt

Voorbeeld: inschrijven en spelen

• Speler schrijft zich in op 1 maart 2022 in op een toernooi met €500 (€480 chips, €20 entry fee)
• In totaal schrijven zich 16 spelers zich in
• Het toernooi start op 1 mei 2022
• Er worden verschillende ronden gespeeld. Bij iedere ronde vallen er spelers af.

Uitwerking:

• Inkopen (buy-in) op toernooi hoeft niet apart gerapporteerd te worden.
• Bij start toernooi start de game_session.
• Iedere speler heeft zijn eigen game_session. De session stopt op het moment dat de speler uit het toernooi ligt.
• De buy-in kan volledig omgezet worden in chips waarmee gespeeld kan worden. Er kan echter ook een commissie (entry fee) ingehouden worden.
• De buy-in (in voorbeeld €500,-) moet conform de regels van het toernooi gerapporteerd worden. Een evt. entry fee (bijv. €20,-) als commissie en het totale bedrag (€500,-) als de stake van de game.
• Bijkopen van fiches (rebuy) is een additionele stake en dient gesommeerd te worden met het inkopen tot 1 transactie.
• Spelers die winnen krijgen een WINNING transactie bij de game_session, gelijk aan reguliere games
• Game_session kan in dit geval lang duren, bijvoorbeeld een aantal dagen tot een week.
• In de lijst met spelletjes moet onderscheid gemaakt kunnen worden tussen enkele poker spellen en een toernooi.

2. Een poker toernooi met inschrijving waarbij de speler niet deelneemt en annuleert

• Speler schrijft zich in op 1 maart 2022 in op een toernooi met €500
• Het toernooi start op 1 mei 2022
• Speler annuleert op 1 april

Uitwerking

• Op 1 april een game_session
• En daaraan gekoppeld:
  • STAKE transactie van 500
  • VOID_STAKE transactie van 500 of zoveel als overblijft na aftrek eventuele commissie.

3. Een (willekeurig) spel waarbij de speler na starten van het spel niet actief speelt

Voorbeeld scenario:

• Speler start Black Jack en zet €50,-
• Speler krijgt slechte kaarten. Om het geld niet kwijt te raken sluit de speler de browser/app af.
• Na 30 minuten stop de spel sessie.
• Speler heeft tot 30 dagen de tijd om het spel alsnog weer op te starten en af te maken
• Na 30 dagen wordt het spel afgebroken en krijgt de speler zijn geld terug.

Uitwerking:

• Game_session loopt van start spel tot 30 minuten na (onverwachte) sluiten browser/app
• Game_session heeft 2 transacties: STAKE van €50 euro en een VOID_STAKE van €50 Mocht speler al reeds wat gewonnen hebben (voorbeeld €5) dan zal de VOID_STAKE €50 blijven en is er een WINNING transactie van €5.
• Wordt het spel toch voortgezet binnen 30 dagen is dit een nieuwe game session waarbij automatisch ook een STAKE wordt uitgevoerd die gelijk is aan de VOID_STAKE + WINNING van de vorige game_session. In dit voorbeeld €50,- zonder winst en €55 met winst.

De void_stake is altijd gelijk aan hetgeen er ingezet is tijdens het spel. Het idee is dat als een speler het spel niet voorzet (dus niet 3e bullit doet) er geen additionele registraties in CDB terecht komen. Vanuit ons gezien zijn het als het ware 2 verschillende spellen die gespeeld worden. Bij winst in het ‘eerste’ spel wordt dat meegenomen als stake in het tweede spel.

UTC is de enige gebruikte tijdzone. Eventueel voorkomende CET tijdzones in de documentatie is het gevolg van een tikfout.