Network/wallet/overview

= Introduction = The Wallet Service is a service that wraps the accounting module together with its database and provides a web service suited for service oriented architectures (SOA) or web oriented architectures (WOA).

The User Service uses a specified JSON format over HTTP. XML can also be used by specifying the correct HTTP headers. The Wallet Service manages its own database and it is not recommended to merge the tables with other tables in the same database since this would break the service isolation pattern.

For documentation of the generic communication scenarios and error handling please see the Cubeia Network Overview document.

Downloads and reference documentation can be found here.

Wallet Concepts
The accounting implementation uses a double-entry bookkeeping system. This means that every transaction within the system will be balanced over at least two accounts.

Below are some of the domain definitions for the wallet. These definitions are modeled and persisted to the database.

Entry
A single monetary transfer to or from one account. An entry will always be associated with a transaction.

Transaction
A transaction is a collection of entries. The sum of the amount over all entries within a transaction must always be zero. This ensures that every monetary transfer is always properly balanced by a debit or credit account.

Account
Account for a specific user. An account can be either session-specific or static. An account is a fairly light weight container for transaction and entry references.

Session
A Session is the same as a temporary account. When creating a session an account will be created with the type set to SessionAccount. Sessions are not modeled explicitly in the database but are contained in session accounts. Sessions and Session Accounts are typically used as place holders for transient events such as playing at a poker table.

= Use Cases = The main use cases for an end user (player) have been scoped out as below. The notes do not map to the available protocol but rather to the business logic inside the wallet to give a description of the actions that will be taken.

API Calls are calls done directly to the server using JSON. Firebase Service calls is when you are developing your game within Firebase and use the Wallet Service deployed in Firebase.

A detailed REST API documentation can be found here.

API Calls

 * Create Account Request, type = SESSION_ACCOUNT
 * Transfer Request, transfer type = CREDIT, operator id needs to be set.

Firebase Service calls

 * StartSession
 * Withdraw

API Calls
ReportTransaction

Firebase Service calls
RoundResult

API Calls
Transfer Request, transfer type = DEBIT, operator id needs to be set. Close Account

Firebase Service calls
Deposit EndSession

API Calls
Transfer Request, transfer type = CREDIT, operator id needs to be set.

Firebase Service calls
Withdraw

API Calls
TBD

Firebase Service calls
TBD

API Calls
TBD

Firebase Service calls
TBD

API Calls
TBD

Firebase Service calls
TBD

API Calls
TBD

Firebase Service calls
TBD

= Sequences = This section contains example sequences derived from the use cases above.

Example of table session (only one hand played)


The key aspect with the table session example is that distributed calls to the remote accounting service only occurs at the life boundaries of the session. Calling the remote accounting will in most cases be an expensive operation since the remote accounting service will most likely not be co-localed with the wallet service.