Prinzipiell lassen sich zwei Arten unterscheiden, zum einen Verfahren bei denen die zu speichernden Daten selbst abgelegt werden, und solche bei denen die eigentlichen Daten serverseitig in einer Datenbank lagern und nur eine Kennung, die sogenannte Session-ID, auf dem Client gespeichert wird. Bei WAP kommt im Allgemeinen nur letzteres in Frage, da die Kapazitäten sinnvolle Datenmengen aufzunehmen auf den mobilen Endgeräten nicht gegeben sind.
Die erste Methode ist es, Daten in der URL zu kodieren. Hierbei wird die URL einer Seite mit Parametern angereichert, und diese auf der ja dynamisch erstellten Seite dann auch wieder an alle Verweise angehängt, wie WAP ist hier zu beachten dass dies ein Deck mit vielen Verweisen ziemlich aufblähen kann und man dann leicht an das Bytecodelimit stösst.
Einfacher für die Anwendungsprogrammierung sind Cookies, Informationsträger die z.B. im HTTP-Header übertragen, beim Client gespeichert und wieder abgerufen werden können. Während sich beim Web hier vor allem das Problem stellt, dass viele User die Cookies wegen Datenschutzbedenken vermeiden, sieht es bei WAP so aus, dass die wenigsten Endgeräte damit umgehen können. Dieses Problem umgehend gibt es jedoch WAP-Gateways, die das Speichern des Cookies für das mobile Endgerät übernehmen. Da die Verbindung zwischen Endgerät und WAP-Gateway statefull, also sitzungsbasiert ist, kann damit eine http-session in Cookies realisiert werden. Allerdings wird dies nicht von allen WAP-Gateways unterstützt, das von T-Mobil verwendet kann dies jedoch, so dass auch Anwendungen in JSP, die Sessiondaten benötigen, für die DeTeSystem kein Problem ergeben würden.
Als dritte Möglichkeit kommen im Web teilweise clientseitige Scripts zum Einsatz, die die Daten an geeigneten Stellen, z.B. einem immer sichtbaren Frame, ablegen. Dies lässt sich bei WAP, obwohl es mit WML-Script eine serverseitige Scriptsprache gibt, jedoch nicht sinnvoll realisieren und kommt daher nicht in Frage.