It seems to me like this scheme is only a half-measure for protecting something, because if an attacker compromises your app and steals a token they can still use it like your app does, right?
Say you have wrapped a credit card number in a token. When a user buys something, you call the API to charge the CC token instead of a CC number. But if an attacker steals a token, they can make that same API call and charge a card to pay themselves.
I guess the mitigations tokens give you over bare CC numbers in that scenario are:
* The attacker probably needs your API key or similar to use along with the token, instead of having a bare CC they can easily use anywhere
* Better auditing of token use
* Tokens are revocable in case you discover a breach
Still, due to that risk I don't see how this "eliminates" compliance risk.
Say you have wrapped a credit card number in a token. When a user buys something, you call the API to charge the CC token instead of a CC number. But if an attacker steals a token, they can make that same API call and charge a card to pay themselves.
I guess the mitigations tokens give you over bare CC numbers in that scenario are:
* The attacker probably needs your API key or similar to use along with the token, instead of having a bare CC they can easily use anywhere
* Better auditing of token use
* Tokens are revocable in case you discover a breach
Still, due to that risk I don't see how this "eliminates" compliance risk.