With any modern¹ encryption mechanism, it's safe to send the plaintext and the ciphertext together, but that doesn't help you. Encryption mechanisms have the property that if someone has a series of plaintexts and their corresponding ciphertexts, and they have one more ciphertext for which they don't have the corresponding plaintext, and they don't have the key, then knowing all of these plaintext-ciphertext pairs doesn't help them decrypt that mysterious ciphertext. This says nothing about being able to build a ciphertext from a plaintext. Depending on the encryption mechanis, this may be completely trivial or possible only with certain specific arrangements of data, but it's not a goal of encryption mechanisms.
What you need is an authentication mechanism. The client has some data in cleartext, and an extra blob which they don't need to be able to decode. Given the cleartext and the extra blob, you want to guarantee that the extra blob was generated by your server for that particular cleartext. The blob is called a signature if using asymmetric cryptography, and a MAC if using symmetric cryptography. Authentication mechanisms have the property that without the key, it's impossible to generate the signature/MAC of a piece of data. This property is exactly what you need.
In plain English: encryption lets you keep the data secret. You have no interest in keeping the data secret, so encryption is not useful here. Authentication lets you check that the data has not been modified, which is what you want.
Since your server is both creating the authentication blob and verifying it later, you can symmetric cryptography, i.e. use a MAC. The most popular family of MACs is HMAC, which doesn't use AES inside. HMAC is available in virtually every cryptographic library.
Note that a MAC (or signature) only guarantees the authenticity of the data, i.e. it guarantees that your server signed it at some point in the past. It doesn't say anything about why your server signed it, so as always, use the key only for the purpose of validating IDs, don't use the same key for different purposes.
The MAC (or signature) also doesn't say anything about when your server signed it, so just because the client can show an ID with a correct MAC doesn't mean that this ID is valid: it only means that the ID was valid in the past. How to deal with that depends on how your IDs become invalid. For example, if IDs remain valid until the server reboots, then you could generate a new key at boot time; IDs from before the reboot would not be signed with the new key and so would be invalid. If it's possible for some IDs to become invalid while other IDs are still valid, then you need a more complex mechanism, perhaps separate keys for each client.
¹ “Modern” meaning anything from the computer era. Obviously this applies only to mechanisms that are widely approved by the cryptographer community, not to homemade or discredited mechanisms.