They dont answer to email and want add this.
I would like to add a further clarification to my complaint and also anticipate some of the possible responses from the operator, so that the dispute is not reduced simply to the words “if successful”.
My position is not that every single click on a Cash Out button must automatically constitute a completed settlement.
The issue is different: Rabona needs to explain which contractual rule governed the risk during the period after my click.
In my case the sequence was:
approximately €15,600 Cash Out available → I selected and confirmed it → request remained pending/processing → subsequent goal/market change → request rejected → later Cash Out of approximately €1,165 successfully settled.
I would therefore like to address in advance the main possible responses from Rabona.
1. “The Cash Out was not successful under Section 16.18.1.”
I do not dispute that Section 16.18.1 contains the words “if successful”.
What I dispute is that the provision does not explain what contractual condition may cause a request that has already been submitted while the Cash Out was available to become unsuccessful.
Simply stating that the request “was not successful” describes the final outcome but does not explain the contractual basis for the rejection.
The relevant question remains:
What specific Rabona provision states that an event occurring after my click may prevent an already pending Cash Out request from becoming successful?
2. “The only successful Cash Out was the later €1,165 Cash Out.”
This does not resolve the dispute.
I am not disputing the later approximately €1,165 Cash Out, which was successfully settled.
I am disputing the earlier approximately €15,600 request.
The fact that the second Cash Out was successful does not explain why the first one was rejected or which contractual provision allowed it to be rejected because of a later event.
3. “The market was suspended before the €15,600 Cash Out finished processing.”
If this is Rabona's technical explanation, I ask Rabona to expressly confirm it and provide the relevant timestamps.
However, such a response would make the contractual issue even more important.
Rabona's Section 16.18.1 does not expressly state that:
- acceptance is not guaranteed after the player clicks;
- the player continues to bear the market risk during processing;
- a market suspension occurring after submission may cause the request to fail.
LibraBet, which is within the same 7StarsPartners portfolio, expressly regulates this situation and clearly states that a Cash Out request may fail if the market suspends before the request has been processed.
I am not claiming that LibraBet's Terms apply to Rabona. The comparison simply demonstrates how easily such a limitation can be expressly disclosed when an operator intends to rely upon it.
4. “There was a technical or sportsbook provider issue.”
If so, I ask Rabona to provide the specific technical evidence.
I would like the rejection code, request status, timestamps and the precise technical event that caused this particular request to fail.
A generic reference to a “technical issue” should not replace the objective server records relating to my specific transaction.
5. “Clicking Cash Out does not mean that the request has been accepted.”
Even this response would not fully answer the dispute.
If there is a second approval stage after the player clicks, during which Rabona or its sportsbook provider may still reject the request based on subsequent events in the match, that stage is economically material to the player.
Rabona's Terms should therefore clearly explain:
- that such a stage exists;
- when that stage ends;
- which events may cause rejection;
- who bears the market risk during that period.
Section 16.18.1 does not do so.
6. “The processing delay was normal.”
Whether the processing lasted 10 seconds, 30 seconds or one minute does not resolve the contractual issue.
The issue is not only whether the delay was technically normal.
The issue is whether, after the player had already submitted the Cash Out, the risk of a future goal contractually remained with the player during that period.
The Rabona provision repeatedly cited to me does not expressly establish that rule.
For these reasons, I ask Rabona to provide LCB with the relevant server-side logs for bet ID 5359638430, including:
- the Cash Out amount recorded and available when my request was submitted;
- the exact timestamp when the approximately €15,600 request was received;
- the request status and duration of the processing period;
- the timestamp of the subsequent market suspension;
- the exact rejection reason/code;
- confirmation of whether the subsequent goal caused the request to be rejected.
I have requested this information directly from Rabona for several days through multiple emails. Rabona has not provided the timestamps or a specific technical explanation, and my subsequent emails have remained unanswered.
I find this lack of response particularly concerning because these server records should allow the sequence of events to be objectively established.
My position remains that, in the absence of an express Rabona provision placing the risk of events occurring after submission during processing on the player, the Cash Out should be recognised at the value displayed and selected when the request was made.
I therefore request payment of the difference between the approximately €15,600 Cash Out and the later approximately €1,165 Cash Out that was actually settled, i.e. approximately €14,435.
If Rabona agrees to resolve the complaint, I request that this amount be actually paid through the withdrawal method available on my account rather than merely credited as gaming balance.
I will consider the complaint resolved only once the funds have actually been received.
Ils ne répondent pas aux courriels et veulent ajouter ceci.
Je souhaite apporter une précision supplémentaire à ma réclamation et anticiper certaines des réponses possibles de l'opérateur, afin que le litige ne se réduise pas simplement aux mots « en cas de succès ».
Je ne prétends pas que chaque clic sur un bouton « Retrait d'espèces » doive automatiquement constituer un règlement définitif.
Le problème est différent : Rabona doit expliquer quelle règle contractuelle régissait le risque pendant la période suivant mon clic.
Dans mon cas, la séquence était la suivante :
Retrait d'environ 15 600 € disponible → Je l'ai sélectionné et confirmé → la demande est restée en attente/en cours de traitement → changement ultérieur d'objectif/de marché → demande rejetée → retrait ultérieur d'environ 1 165 € effectué avec succès.
Je voudrais donc aborder par avance les principales réponses possibles de Rabona.
1. « Le retrait d’argent n’a pas été possible en vertu de l’article 16.18.1. »
Je ne conteste pas que l’article 16.18.1 contienne les mots « en cas de succès ».
Ce que je conteste, c'est que la disposition n'explique pas quelle condition contractuelle peut entraîner l'échec d'une demande déjà soumise alors que l'option de retrait d'espèces était disponible.
Le simple fait d'affirmer que la demande « n'a pas abouti » décrit le résultat final, mais n'explique pas le fondement contractuel du rejet.
La question pertinente demeure :
Quelle disposition spécifique de Rabona stipule qu'un événement survenant après mon clic peut empêcher la réussite d'une demande de retrait d'espèces déjà en cours ?
2. « Le seul retrait réussi a été le retrait ultérieur de 1 165 €. »
Cela ne résout pas le différend.
Je ne conteste pas le retrait d'espèces d'environ 1 165 € effectué ultérieurement, qui a été réglé avec succès.
Je conteste la précédente demande d'environ 15 600 €.
Le fait que la deuxième tentative de retrait ait été couronnée de succès n'explique pas pourquoi la première a été rejetée ni quelle disposition contractuelle a permis son rejet en raison d'un événement ultérieur.
3. « Le marché a été suspendu avant que le retrait d’espèces de 15 600 € ne soit entièrement traité. »
S'il s'agit bien de l'explication technique de Rabona, je demande à Rabona de la confirmer expressément et de fournir les horodatages correspondants.
Toutefois, une telle réponse rendrait la question contractuelle encore plus importante.
L'article 16.18.1 de Rabona n'indique pas expressément que :
- l'acceptation n'est pas garantie après le clic du joueur ;
- le joueur continue de supporter le risque de marché pendant le traitement ;
- Une suspension du marché survenant après la soumission peut entraîner l'échec de la demande.
LibraBet, qui fait partie du même portefeuille 7StarsPartners, réglemente expressément cette situation et indique clairement qu'une demande de retrait peut échouer si le marché est suspendu avant que la demande n'ait été traitée.
Je ne prétends pas que les conditions d'utilisation de LibraBet s'appliquent à Rabona. Cette comparaison illustre simplement la facilité avec laquelle une telle limitation peut être expressément divulguée lorsqu'un opérateur entend s'en prévaloir.
4. « Il y a eu un problème technique ou un problème lié au fournisseur de paris sportifs. »
Dans ce cas, je demande à Rabona de fournir les preuves techniques précises.
Je souhaiterais obtenir le code de rejet, le statut de la requête, les horodatages et l'événement technique précis qui a provoqué l'échec de cette requête.
Une référence générique à un « problème technique » ne doit pas remplacer les enregistrements objectifs du serveur relatifs à ma transaction spécifique.
5. « Cliquer sur "Retirer l'argent" ne signifie pas que la demande a été acceptée. »
Même cette réponse ne permettrait pas de résoudre entièrement le différend.
Si une deuxième étape d'approbation intervient après le clic du joueur, au cours de laquelle Rabona ou son fournisseur de paris sportifs peuvent encore rejeter la demande en fonction d'événements ultérieurs survenus pendant le match, cette étape est économiquement importante pour le joueur.
Les conditions générales de Rabona devraient donc clairement expliquer :
- qu'un tel stade existe ;
- lorsque cette étape se termine ;
- quels événements peuvent entraîner un rejet ;
— qui supporte le risque de marché pendant cette période.
L’article 16.18.1 ne le fait pas.
6. « Le délai de traitement était normal. »
Que le traitement ait duré 10 secondes, 30 secondes ou une minute ne résout pas le problème contractuel.
La question n'est pas seulement de savoir si le retard était techniquement normal.
La question est de savoir si, après que le joueur a déjà effectué son retrait anticipé, le risque d'un objectif futur restait contractuellement à sa charge pendant cette période.
La disposition Rabona qui m'a été citée à maintes reprises n'établit pas expressément cette règle.
Pour ces raisons, je demande à Rabona de fournir à LCB les journaux serveur pertinents pour le pari ID 5359638430, notamment :
- le montant du retrait d'espèces enregistré et disponible au moment de la soumission de ma demande ;
- l'horodatage exact de la réception de la demande d'environ 15 600 € ;
- l'état de la demande et la durée de la période de traitement ;
- l'horodatage de la suspension de marché ultérieure ;
- le motif/code de rejet exact ;
- confirmation que l'objectif ultérieur a bien entraîné le rejet de la requête.
J'ai demandé ces informations directement à Rabona à plusieurs reprises par courriel, et ce depuis plusieurs jours. Rabona n'a fourni ni les dates et heures ni une explication technique précise, et mes courriels suivants sont restés sans réponse.
Je trouve ce manque de réponse particulièrement préoccupant car ces enregistrements du serveur devraient permettre d'établir objectivement la séquence des événements.
Je maintiens que, en l'absence d'une disposition Rabona expresse faisant peser sur le joueur le risque d'événements survenant après la soumission pendant le traitement, le retrait d'espèces doit être comptabilisé à la valeur affichée et sélectionnée lors de la demande.
Je demande donc le paiement de la différence entre le versement initial d'environ 15 600 € et le versement ultérieur d'environ 1 165 € qui a été effectivement réglé, soit environ 14 435 €.
Si Rabona accepte de régler le litige, je demande que ce montant soit effectivement versé via la méthode de retrait disponible sur mon compte plutôt que d'être simplement crédité sur mon solde de jeu.
Je ne considérerai la plainte comme résolue qu'une fois les fonds effectivement reçus.