Overview

SafeToken supports three authentication methods: service-issued OTPs delivered by SMS or email, authenticator-app TOTP credentials provisioned through QR codes, and counter-based OTPs generated by physical hard-token devices.

Core workflow

• A token requestor or aggregator calls the API using an API key
• SafeToken identifies the customer token and permitted authentication methods
• It generates, sends, or validates the OTP locally or through an external provider
• Successful authentication returns transaction status, ECI, and a CAVV-style authentication token
• Each attempt is logged for auditing, reporting, and billing

Main capabilities

• Token registration, activation, update, and retrieval
• OTP generation, validation, and authentication
• Authenticator-app provisioning through QR codes
• Requestor and aggregator authorization
• SMS and email OTP delivery
• Configurable external OTP providers including GTB, ZIB, Rolez, and generic third parties
• Multiple regional SMS providers plus delivery reports and callbacks
• Validation history, correlation IDs, Wibmo reporting, and legacy token compatibility

Architecture and technology

• Java 25 and Spring Boot 4 REST application
• Controllers for external APIs and services for token and authentication rules
• Provider abstractions for external OTP, SMS, and email systems
• JDBC DAOs backed by Microsoft SQL Server
• Redis for temporary OTP and request-session data
• Kafka for asynchronous validation reports
• Flyway and an internal migrator for database changes
• HSM integration for cryptographic authentication-token generation
• OpenAPI/Swagger, Actuator, structured logging, and Docker deployment

Why it matters

The platform sits in a security-sensitive part of the payments stack, so correctness, traceability, delivery reliability, and partner integration behavior all matter at the same time.