Tests to verify the API platform
Description
Tests are performed before connecting the client (partner) platform to FUNGAMESS.
These tests allow us to verify whether the platform meets the company's requirements.
A restriction on adding the platform may be applied if the tests are not passed successfully.
If the tests are successful, the platform can be connected to the product.
Tests for verifying API platforms can be found in the "Integration → Config" section of your FUNGAMESS back office.
Test 1 - sessionCheck User 1 Success
Method GET
Sending a request to sessionCheck for verification of the user.
A request is sent with the parameters of User1 and token for verification of the user.
Correct response: Status true.
If the token's validity period has expired, the response may contain status true and the token.
Additional request will be sent with a new token.
Expected result: Success.
Test 2 - sessionCheck User 1 wrong token
Method GET
Sending a request to sessionCheck with token substitution.
A request is sent with User1 parameters, but the token is replaced.
The platform must detect the substitution and prevent a user with the wrong token from connection to the system.
Correct response: Token not found.
Test 3 - sessionCheck signature verification
Method GET
Sending a request to sessionCheck for signature verification.
A request is sent with the User1 parameters and token, but a signature is substituted.
The system should detect invalid signature.
Correct response: Request not valid.
Test 4 - sessionCheck User 2 Success
Method GET
Sending a request to sessionCheck for verification of the second user.
The test is performed in the same way as the first test.
The parameters of User 2 were entered.
Correct response: true.
Test 5 - sessionCheck swap the users token
Method GET
Sending a request to sessionCheck after the swap of user tokens.
A request is sent to verify two users, when the user tokens were swapped.
The platform must detect token substitution and provide false responce to both requests.
Correct response: false.
Test 6 - getBalance User 1 Success
Method GET
Sending a request to getBalance to check the balance of first user.
A request is sent with the parameters of userID and token.
Correct response: true.
The amount of user's balance is displayed correctly.
Test 7 - getBalance User 1 wrong token
Method GET
Sending a request to getBalance with a token substitution.
A request is sent with a spoofed token.
The platform should detect the substitution and provide an error response: Token not found, status false.
A second request is sent to check the balance.
There should be no debit processing.
Response: The status and the amount of the user's balance were processed as true, before the initialization of verification.
Test 8 - getBalance signature verification
Method GET
Sending a request to getBalance to verify the signature.
A request is sent with a hash substitution.
The platform must detect the substitution and respond with: Invalid request.
Test 9 - playerDetails User 1 Success
Method GET
Sending a request to playerDetails to obtain information about the user.
A request is sent with the parameters of the first user.
The response displays all information about the player: status (existence), IP, Email, First name, Last name, userID, nickname, currency, language.
Test 10 - playerDetails User 1 Wrong token
Method GET
Sending a request to playerDetails with a token substitution.
A request is sent for playerDetails, an incorrect token is added to the request.
The platform should respond with: Error, code 417, Token not found.
Test 11 - playerDetails Check signature
Method GET
Sending a request to playerDetails for signature verification.
A request is sent with the new player's signature that was replaced.
The platform should respond: Error, Request not validate.
Test 12 - moveFunds default Success
Method POST
Sending a request to moveFunds to check the default movement of funds.
A request is sent with the User1 parameters and a token, a bet is made.
A debit transaction is processed with BetPlacing event type.
Correct response: Success, money has been debited from the balance sheet, direction Debit.
The second test is carried out with a credit transaction: enter a request to Win.
Correct response: status true, balance amount with winnings and direction Credit.
Both operations should be successful.
Test 13 - moveFunds wrong token check
Method POST
Sending a request to moveFunds with a fake token.
In the funds movement request, the token was replaced during a debit transaction.
The platform must detect the fake one and provide the correct response: Token not found.
Another request is made to check the balance.
The user's balance should not change after an unsuccessful transaction.
Response: true, the balance amount remains unchanged.
Test 14 - moveFunds check signature
Method POST
Sending a request to moveFunds for signature verification.
A request is sent with the parameters of User1 and token.
The signature in the request for the funds transfer is substituted.
The platform should detect the incorrect token and respond: Request not validate.
Test 15 - moveFunds rollback Success
Method POST
Sending a request to moveFunds to trace the movement and rollback of the funds.
A request is sent with two types of events – BetPlacing and BetPlacingAbort.
Successful transactions are carried out on debit.
While funds are credited to the balance along with the cancellation of the operation of debiting of funds from the balance.
Both transactions should be successful. The balance remains the same.
Test 16 - moveFunds debit 0 check
Method POST
Sending a request to moveFunds for verification of the funds movement at the rate of 0.
A request is sent to BetPlacing, a zero bet is made (amount 0) and the user’s balance is checked.
The debit transaction should be successful and the balance will remain unchanged.
Test 17 - moveFunds decimal check
Method POST
Sending a request to moveFunds for verification of the funds movement at a decimal rate.
A request is sent with the BetPlacing event type, which specifies the bet that is expressed as a floating point number.
For example, 94.5 amount.
The amount with cents should be debited from the balance.
Correct response: true, balance amount minus 94.5, direction debit. The platform worked correctly.
Test 18 - moveFunds negative balance check
Method POST
Sending a request to moveFunds to check the negative balance when funds are moved.
A request is sent with the BetPlacing event type, which specifies that a bet is greater than the amount of money in the player’s account.
The platform should not miss a payment.
Correct response: Error, code 402, the player’s balance has not changed, the amount remains the same as before the bet. The money were not debited.
Test 19 - moveFunds wrong event type
Method POST
Sending a request to moveFunds to check the movement of funds with the wrong event type.
A debit transaction request is sent for processing, but the parameter is replaced with Win(credit) instead of BetPlacing event type.
If the event type parameter is incorrect, the transaction should not go through.
Correct response with error: Errors, code 400, Unknown error occurred.
Once an error is detected, the balance is checked. The transaction failed.
Response: true, the balance has not changed.
Test 20 - moveFunds wrong event ID
Method POST
Sending a request to moveFunds to verify the movement of funds with the condition of incorrect eventID.
2 requests are sent, for debit and credit.
When a debit transaction is made, the eventID parameter is assigned with the correct value.
The platform should respond: true, direction – debit.
On a credit transaction, the event Id value is replaced with a false one.
The response should contain an error: Errors, code 406, Debit transaction not found in this event.
Result: No debit transaction was found in this event.
If the event ID does not match, there will be no movement of funds.
Test 21 - moveFunds duplicate bet
Method POST
Sending a request to moveFunds for verification of the funds movement in case of a duplicate bet.
2 debit transactions with identical data are performed one after another.
The first transaction should be successful, and the second should receive the response Errors, code 409, Duplicate bet.
Transaction already exists.
Result: rejection of the duplicate transation.
Test 22 - moveFunds duplicate result
Method POST
Sending a request to moveFunds for verification of the funds movement in case of a duplicate result.
3 requests are sent.
The first request is for bet placement.
A successful debit transaction is performed.
The second request is for a credit transaction, event type Win.
There must be a successful credit transaction.
A third request is sent to repeat transaction with Win parameter and data that is complete duplicate of the previous transaction.
The platform should detect duplicate and respond with: error 409, Duplicate.
Transaction already exists.
Test 23 - moveFunds duplicate rollback
Method POST
Sending a request to moveFunds to study the movement of funds whenever a duplicate is rollback. 3 requests are sent.
First, a successful debit transaction is performed in BetPlacing.
The data is duplicated for a credit with the BetPlacingAbort type.
The first rollback will be processed successfully, but not the second.
Due to the fact 2nd one is a request for repeatitive transaction, that has already been successfully completed, with identical data.
Response in the last request: error 409, Duplicate.
Transaction already exists, the balance amount is the same as at the beginning of the test.
Test 24 - moveFunds test if without betPlacing
Method POST
Sending a request to moveFunds to check the movement of funds without bet placement.
No debit transaction were made, but a credit request was sent.
For example, in a situation where the player didn't place a bet, but requests a win.
Event type – Win parameter.
The platform should provide negative response: Error, code 406, Debit transaction not found in this event.
Result: The system did not detect the debit transaction and rejected the request.
Test 25 - moveFunds Bet + Result + Rollback–
Method POST
Sending a request to moveFunds to verify the movement of funds during betting, winning and rollback attempts for a closed transaction.
3 requests are sent.
The player places a bet (BetPlacing event type), wins, receives a payout (successfully completed credit transaction), and requests a refund (BetPlacingAbort event type).
Rollback does not work because the debit transaction was already closed by the credit.
The correct response for the last request is: Error, code 406, Debit transaction not found in this event.
The balance does not change.
Test 26 - moveFunds Bet + Rollback + Result–
Method POST
Sending a request to moveFunds to check the movement of funds during betting, rollback and attempts of winnings claims.
3 requests are sent.
In the first request, the player places a bet (event type BetPlacing).
In the second request, the player requests a refund (event type BetPlacingAbort).
Funds are successfully debited from the player’s balance and returned.
Afterward the player requests a win (event type Win).
The money should not be credited to the player's account because the debit transaction was closed on a rollback.
As a result, the third request should receive a response: Error 406, Debit transaction not found in this event.
The rollback, does not change the balance.
Test 27 - moveFunds wrong user on credit and rollback
Method POST
Sending a request to moveFunds to verify the transfer of funds with data substitution for a random user during a rollback.
A bet is placed and funds are debited from the balance.
The debit transaction was completed successfully.
After that, two more requests are sent: one for winnings, and another for a rollback of funds, where the user being replaced with a random token and an incorrect user id.
The platform must detect the substitution and provide a negative response to both requests with a false data: Error, code 404, User not found.
The balance does not change.
Test 28 - moveFunds wrong (exist) user on credit and rollback
Method POST
Sending a request to moveFunds to verify the transfer of funds with data substitution for a real user during a rollback.
A bet is placed and funds are debited from the balance.
The debit transaction was completed successfully.
Two more requests are sent: one for winnings, and another for a rollback of funds with a substitution for token and userID of the real second user.
The platform must detect the substitution and provide a negative response to both requests with the false data.
Result: Error, code 404, User not found.
The balance does not change.
Test 29 - betFunds check
Method POST
Checking player balance changes (only for Sport 2 version).
The validity of credits to and debits from the account is verified.
A request for Bet Placing is sent indicating advanced parameters.
The debit transaction must be completed successfully.
Next, a series of loan transactions are performed.
A request is made with the event type BetSingle (single sports bet) and the half win parameter.
Requests are sent to BetFunds with the BetSingle event type and the results lose, win and return.
All credit transactions must be completed successfully with a true value.
The balance amount in the response should be changed with each transaction.
Test 30 - Change balance to 1
Method POST
Sending a request to moveFunds to change the balance to 1.
A request is made with the BetPlasing parameter to conduct a transaction with a bet of -1 to the user's current balance.
The bet size is calculated using a special formula written in the code.
Requirement: The balance in the response must be equal to 1.
Test 31 - Check Sport bet Cancel
Method POST
Transmitting a request to moveFunds to check the balance with a negative value.
Requests for bet, win, repeat bet and cancellation of the first win (bet failed) are executed.
In all responses to requests, the status parameter must be equal to true.
In a request with the SportBetCancel type, the balance must get a negative value.
The last action of the test is to return the user’s balance to its original state (pre testing).
Test 32 - Check getUserToken
Method GET
Sending a GetUserToken request to verify the token and user.
A request is sent to getUserToken with the userID.
The response must contain a set of parameters (true status, user id, token and balance).
The parameters received in the response are entered into check requestSession.
Correct response: true.
Result: the user is found in the database, the token is confirmed.
Test 33 - Check tournament
Method POST
Sending a moveFunds request to check the movement of funds with the PromoWin event type.
A request is sent to BetPlacing and a zero bet was placed (amount 0).
The debit transaction must be successful.
After that, a credit transaction is made with the player's winnings and the PromoWin event type.
Correct response: true.
Result: the player has received the designated amount of winnings to his account.