Most teams approach STS certification as a final step. Our experience was different. A client request led us deep into the security layer of the STS ecosystem long before certification began. Although we ultimately built and certified a Vending System and Token Server, that early work gave us a deeper understanding of token generation, encryption, and system behavior. The result was a first-attempt certification pass and several lessons on preparation, scope, and system design.
Key engineering takeaway
Certification should validate the engineering decisions already made, not guide the development process. We treated STS that way from the start.
Most teams treat STS certification as a final checkpoint. They complete the application, validate a subset of scenarios, and proceed to certification with the expectation that any remaining issues can be addressed during the process. In practice, this is where most problems emerge.
Our path was different. At the start of the project, at the client’s request, we began by attempting to build the security module itself. This required going beyond the application layer into encryption algorithms, token structure, and low-level system behaviour. Only later did we learn that building a security module was not required for our scope. Instead, our objective was to develop and certify two components: an STS Vending System and a Token Server capable of securely generating STS tokens through an approved security module. What initially looked like unnecessary effort became the foundation that enabled us to pass certification on the first attempt.
What STS Certification Actually Requires
The Standard Transfer Specification (STS) was initiated in 1993 to formalise the need to develop compatibility between meters and vending systems from different suppliers. Also paramount was the need to ensure sufficient system security to prevent fraud. The STS venture resulted in the formation of the STS Association and has enabled vending systems from different manufacturers to provide compatible tokens or credit transfers to any STS-compliant meters. STS is an international industry standard described in IEC62055-41, -51 and -52.
STS certification is a strict and deterministic validation of system behaviour. The process is based on a large set of predefined scenarios, in which each case specifies input parameters and an exact expected token output. In our case, this meant working through approximately 400 test cases.
The evaluation is performed in real time. Test cases are executed one by one while the system’s behaviour is observed. Additional scenarios can be introduced that are not shared in advance, specifically to confirm that the system is not hardcoded and can handle variations correctly. A single incorrect result is enough to terminate the process.
Based on evaluators' feedback, it is common for teams to require several attempts to pass. Multiple certification cycles are not unusual.
Why Teams Fail
The primary challenge is not the volume of test cases, but the way teams approach the problem.
Many teams treat STS as a simple integration. They send requests to a security module and expect consistent results without fully understanding the underlying logic. This often leads to systems that perform well in basic scenarios but fail under less predictable conditions.
Another common issue is the mixing of business logic with STS logic. STS is strictly defined and independent of domain-specific concerns such as tariffs, customer debt, or transaction history. When these concerns are intertwined, the system becomes more difficult to reason about and harder to validate during certification.
Teams also tend to unnecessarily expand the scope. STS allows certification to be limited to specific meter types and token categories. Attempting to cover all possible combinations increases complexity without a clear benefit.
A frequent technical failure point is the handling of automatic key change. This mechanism requires the system to detect outdated keys, generate multiple tokens, and apply them in the correct sequence. Without a precise understanding of this process, implementations tend to break during validation.
What We Did Differently
We did not approach certification as a deadline. Instead, we treated it as a validation that should only be attempted once the system behaviour was fully understood and predictable. We delayed the certification until we were confident that all scenarios were covered.
This approach was made possible by the work we had done earlier in the project.
The Work That Changed Everything
Our initial assumption that we needed to build a security module forced us to engage with the most complex parts of the system. We worked with limited documentation and relied on simulation to validate our understanding. At times, this meant analysing binary representations to understand how tokens were constructed and how algorithms behaved.
Although we later pivoted away from building the module itself and focused on the application layer, the knowledge gained during that phase remained critical. From a delivery perspective, that effort was not required. From an engineering perspective, it proved decisive.
The Advantage of Understanding the System
Because we had already explored the underlying mechanics, we did not treat STS as a black box. We understood how tokens are constructed, what each parameter represents, and how the algorithms behave under different conditions. This allowed us to design the system with fewer assumptions, implement edge cases correctly, and resolve issues more efficiently.
Rather than relying on trial and error, we had a clear model of expected behaviour.
The Certification Process
When we entered certification, the process matched our expectations. The evaluation was conducted through a live session where each test case was executed and verified. The evaluators monitored both the inputs and the system responses and introduced additional parameters to confirm correctness beyond predefined scenarios.
The requirement was consistent throughout: every result had to be correct.
The Outcome
We passed certification on the first attempt for both components we built, the Vending System and the Token Server. The validation was conducted in a single live session, covering the full test suite and additional unannounced scenarios introduced by the evaluators.
According to the evaluators, most teams require several attempts before achieving the same result, often across multiple certification cycles. In our case, there were no failed test cases and no need for a second session.
Two factors made the difference. First, we delayed certification until the system behaviour was predictable across all scenarios, including edge cases. Second, we had a working understanding of the underlying token generation logic, which reduced reliance on trial and error during implementation and validation.
The immediate outcome was that the system was approved for operation without iteration. More importantly, it established a foundation for extending the platform beyond certification scope without reworking core STS functionality.
Lessons for Teams Preparing for STS Certification
The experience highlights several practical lessons.
First, certification should not be rushed. Attempting it prematurely often leads to repeated failures and longer overall timelines.
Second, STS should not be treated as a simple integration. A working system requires a clear understanding of how tokens are generated and how the underlying logic operates.
Third, STS logic and business logic should be separated. Keeping these concerns distinct simplifies both development and validation.
Fourth, the scope of certification should be limited to what is actually required. Expanding scope unnecessarily increases complexity without adding value.
Finally, special attention should be given to key change mechanisms, as they represent a common point of failure.
Final Thought
In many software projects, speed is seen as a primary advantage. In this case, it was not. What mattered was the depth of understanding behind the implementation.
The initial decision to explore the most complex part of the system was not efficient in the short term. However, it provided the clarity needed to build a reliable solution and to approach certification with confidence. That is what ultimately made the difference.