Documentation Game API pour l’intégration AG GAME Slots

Sérialisez le corps final de la requête comme body, puis concaténez merchantCode + timestamp + nonce + signType + body dans cet ordre et sans séparateurs. signType est fixé à HmacSHA256. Calculez HMAC-SHA256 avec la clé de signature et placez le résultat dans X-SIGN. Le body utilisé pour la signature doit être exactement identique au corps envoyé.

C10004 indique un échec de vérification de signature. Vérifiez d’abord le code marchand, timestamp, nonce, clé de signature et le type fixe HmacSHA256. Vérifiez ensuite que le middleware n’a pas sérialisé de nouveau la chaîne JSON signée, modifié l’ordre des champs ou les espaces. Conservez reqTraceId et l’heure de requête pour le diagnostic, mais n’enregistrez jamais la clé de signature.

En mode portefeuille unique, le marchand conserve le solde du joueur et la plateforme coopère avec le portefeuille marchand par les callbacks de solde, de mise et de règlement. En mode portefeuille de transfert, le marchand appelle des points de terminaison tels que /game/v5/cash/deposit et /game/v5/cash/withdraw pour déplacer des fonds entre son système et le portefeuille de jeu du joueur. Le modèle utilisé dépend de la configuration d’intégration du marchand et ne doit pas être mélangé dans le même flux de transaction.

Le marchand doit utiliser transactionId comme base d’idempotence des transactions de callback. Lorsque la même transaction arrive à nouveau, renvoyez le résultat de traitement et le solde déjà confirmés ; ne la débitez ni ne la créditez une seconde fois. Conservez la requête, le résultat métier et le solde final pour le rapprochement. La nécessité de /wallet/bet et /wallet/cancel reste soumise à la liste finale des callbacks du marchand.

Ne créez pas une nouvelle transaction et ne répétez pas le transfert tant que le résultat est inconnu. Utilisez d’abord le merchantTransactionId d’origine pour appeler /game/v5/cash/transaction et consulter le résultat, puis décidez d’un nouvel envoi selon l’accord technique final. Cela évite une comptabilisation en double lorsque la première requête a réussi mais que sa réponse a été perdue sur le réseau.

reqTraceId est l’identifiant de suivi unique de chaque requête. Il permet d’associer les journaux d’appel et de diagnostiquer une requête ; il doit être généré et enregistré pour chaque requête, y compris lors d’une nouvelle tentative. merchantTransactionId est l’identifiant unique de transaction côté marchand, utilisé pour le rapprochement des transferts, les consultations de résultat et la prévention du traitement répété d’une même transaction métier. Ils ont des objectifs différents et ne se remplacent pas.

Obtenez un gameCode disponible dans le catalogue de jeux, préparez l’identifiant joueur, la devise, la langue et l’adresse IP, puis appelez /game/v5/game/url avec les en-têtes communs de requête. Une réponse réussie renvoie gameUrl et peut renvoyer expireTime ; le client doit ouvrir l’URL tant que la session est valide.

Appelez /game/v5/game/record avec pageNum, pageSize et la plage reqData.startTime et reqData.endTime ; sort peut être fourni si nécessaire. Lisez les enregistrements de commande, joueur, montant de mise, gain, code jeu et tour dans gameRecordList de la réponse, puis poursuivez la consultation page par page.