Account System Integration
Some studios have a common Account system that spans across multiple games. It is often desirable in these situations to integrate an age gate and to handle Verifiable Parental Consent (VPC) directly in the Account creation flow so that players are asked for their age only once for all games from the same publisher.
When doing this type of integration, there are a few important considerations:
Product Context for VPC
If the games all require an Account to play, then VPC can be triggered from the Account creation process. However, the request for consent must be specific to a game so that a parent knows what they are consenting to. The k-ID API determines what Product should be presented to the parent during the consent process based on what API key is used when triggering VPC.
In practice, the integration of k-ID into an Account system must be able to determine at the time of Account setup what game triggered the Account creation process, and map that to a k-ID API key.
Using kuid to Access k-ID Sessions
k-ID exposes a global identifier for all players that have had some form of parental consent called kuid or k-ID User ID. The kuid is returned as a property of the Session object. When integrating with an Account system across multiple games, the kuid should be associated with the player's identity in the Account system when present in a Session. This will allow retrieval of a k-ID Session, if it exists, for any k-ID Product by calling /session/get providing only the kuid as a parameter and using the appropriate API key for the correct Product.
When a parent gives consent for a child to play one or more Products, the registered web-hook endpoint for each approved Product will be invoked with eventType set to Challenge.StateChange. Each of the Session objects will have the same kuid for the player. More information about k-ID web-hooks can be found in the Webhooks page.
Caching Sessions for Multiple Products
Caching of Sessions is discussed in Architecture Considerations.
When integrating with an Account system, Sessions from multiple Products will be cached. Session objects can all be cached as a map in the Account system using the k-ID Product ID as a key. When a player attempts to play a new game, the map containing Session objects can be queried by Product ID, and if a Session is already present, the player can then be allowed to continue without further parental consent.
Account-Level Product
When configuring an Account System integration of k-ID, it is typical to create one k-ID Product for each game, and then a separate k-ID Product for the Account System itself. This is useful to represent any permissions and disclosures that are common or global for all games, or the Account itself.
When a Product is mapped to the Account system, this means that for each game, there will be two Session objects retrieved, one for the k-ID Product mapped to the game, and one for the k-ID Product mapped to the Account system. The k-ID API is scoped to the a Product by the API key. The correct API key must be used depending on whether you are trying to access the k-ID Product mapped to the Account system or the game.