Project objectives
The objective of this project was to create a scratchcard management system for the statistical generation , distribution, sale and reporting of latex-covered scratchcards. This type of game is quite common in convenience stores around the world. To play, you buy a card, scratch off the latex coating to potentially reveal a prize which can be claimed in-store or, for big prizes, by contacting the game operator.
The cards and the distribution packs they belonged to needed to follow rules for access control, to protect against fraudulent claims. Therefore, packs of cards which had been distributed to a shop could no longer be viewed by the printer, claims could not be processed until sale of the card is confirmed and then all the details can be verified by the game operator using the card’s reference ID.
Web API Features
To understand where a card is and what state it is in, a Web API is used by points of sale, retailers and the game’s operator. Card sales can be tracked from the shop terminals to head office, where winners can be validated. Different users access different areas of the API through secure authentication.
Idempotency
Idempotency is an important aspect of transactional Web APIs. It means that if the same request is received twice, it only processes once.
All requests, such as sales and claims, may include an idempotency token, which not only stops the process from happening twice but also allows the same response to be returned. If the connection fails and a response is missed, the same response can be retrieved without the request completely reprocessing.
Documentation
Clear documentation is critical when developing an integration API. The point of sale in-shops needs to make requests for activating cards, claiming prizes and getting a daily financial readout. Communicating effectively the technical side of an API saves time and prevents bugs.
Management Portal
Using Angular, I developed a management portal which made easy the process of templating the distribution of prizes. It allows templates to be reused for multiple games which might be played between two dates.
Once a template is in use, it can no longer be edited but it may be reused. Games have a fixed number of scratchcards.
Game Templating
The scratchcard games need to be templated first, which means planning the costs and distribution of prizes. As cards are distributed to retailers in packs of a fixed size, the prize distribution could be configured for set numbers of packs. This allowed a single pack to be contain the top prize and retailer earnings to be predictable.
Distribution
The cards are distributed in packs, typically containing about 200 cards each. The options in the management portal allow packs to be assigned to retailers and/or voided if they go astray. Shops scan in the packs before they go on sale to confirm they have arrived and this activates the cards in the pack.
Reporting
Line graphs and pie charts were employed to present real-time tracking of scratchcard sale and claim data. Projection algorthms also allowed the user to see when new stock would be needed. Data can be downloaded as a CSV file for further analysis.