As per the technical guidelines for PCI data storage:
[1] These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other legislation (e.g., related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company’s practices if consumerrelated personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.
[2] Sensitive authentication data must not be stored after authorization (even if encrypted).
[3] Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere.[6]
iPayment does not store primary account number (PAN), Full Magnetic Stripte Data, CAV2/CVC2/CVV2/CID or PIN/PIN block. As we do not store the primary account number we are not we are not required to protect the cardholder name, service code or expiration date.
All interaction with the gateways are done using a Card store/Customer Information Manager system.
This means that only a token generated by the gateway is stored in the system but not the actual primary account number.
Authorize.NET |
http://developer.authorize.net/api/reference/features/customer_profiles.html |
Trust Payments (Secure Trading) |
http://www.securetrading.com/service/card-store-tokenisation/ |
CyberSource |
https://www.cybersource.com/products/payment_security/payment_tokenization/ |
Eway |
https://www.eway.com.au/developers/api/token-payments |
You can read more about data tokenization here: