Wallet Service is a web service implemented in Customer system (only) by Customers leveraging Seamless Wallet mode. It provides payment operations for players during a game play.
Integration casino system allows accessing Wallet Service over the following protocols:
- SOAP
- REST JSON
The options are functionally equal, Customers choose whichever suits their technological stack better.
For convenience, we also provide a suite of tests, to help verify validity of Wallet Service implementation from the functional and performance points of view. The tests are available in the Staging environment, directly on the Management Console and accessible by both Managers and Operators.
SOAP Wallet Service
Wallet Service is implemented on the customer's side. The service must be published as SOAP 1.1 service with literal encoding and namespace http://GMS.Integration.Plugin/WalletService.
WSDL definition of Wallet Service will be delivered with the staging/production account. We also provide sample implementations of service in some major programming languages.
REST JSON Wallet Service
REST JSON Wallet Service is a web service to be implemented by the Customer system. It is accessed over HTTP with JSON data content.
All resources only support HTTP POST verbs. Data is supposed to be stored in request payload, parameters directly in the URI query string are not supported.
Paths to individual Service resources listed below are relative to the base path where the Service is hosted. For example, if the base path is https://casino.com/THE/WalletService and the resource to be accessed is GetBalance, then the request has to be made to https://casino.com/THE/WalletService/GetBalance.
HATEOAS is not required, however, Customers are encouraged to base their implementation on the WADL definition. For convenience, we also provide an XML schema representing fictional XML responses (at the time of writing, there’s no standard way of describing JSON responses).
As for authentication, each request contains a cryptographic hash (parameter sign) calculated from the data to be transmitted.
The only expected HTTP Status Code is 200 (OK). Business logic related errors are communicated directly in response JSON data content.
Note: For the sake of brevity, HTTP response headers in the following examples have been omitted.
The service provides the following resources:
Comments
0 comments
Article is closed for comments.