For decrypting ciphertext, the web service call requires four parameters:

When SAKA receives the request, it first verifies the credentials presented against its internal database or an optional LDAP directory server and then determines their authorization to request the decryption service by determining if they are a member of a DecryptionAuthorized group. Note that if using LDAP, this group and its members must be created in the LDAP directory as a distinct task of the SAKA installation and configuration process; when using the SAKA internal database, this is performed automatically.

If the requester is authorized, SAKA searches its RDBMS for the token, determines the identifier of the key that was used to encrypt it originally and uses that key to decrypt the ciphertext. If the key was rotated at some point due to PCI DSS or other security requirements, SAKA uses the rotated key to decrypt the ciphertext—applications are neither aware nor concerned about cryptographic key management operations when requesting encryption and/or tokenization services from SAKA.

After the decryption process, SAKA retrieves the identifier of the HMAC key originally used by the application and, with the HMAC key, recalculates a new HMAC with the just-decrypted plaintext. It then compares the original HMAC (stored after the successful encryption operation) with the just-calculated HMAC; if the two HMACs are identical, SAKA knows the decryption process was successful.

SAKA logs the decryption request—without storing or logging the sensitive plaintext—replicates the transaction object to all other SAKA nodes within the same cluster and returns the plaintext to the requester.