Card not present transactions are no different from users entering sensitive data into any web-application– whether it is social security numbers, bank account numbers, passport numbers, etc., calling the foundation services of the SAKA requires the same design considerations as discussed in the preceding section.
The flexibility of the SAKA allows for many different use-cases:
- Making tokens smaller or larger than 16-digits. Tokens may be as small as 7-digits or as large as 64, allowing for a wide variety of use-cases for tokenizing vast quantities of data;
- Encrypting objects larger than credit-card numbers. The SAKA allows for encrypting up to 10,000 characters of text. This has allowed customers to encrypt objects such as Base64-encoded asymmetric key-pairs with digital certificates, bar-codes, images, XML objects, JSON objects, etc.
- StrongAuth's free and open-source CryptoEngine library is capable of escrowing symmetric cryptographic keys – such as the Triple Data Encryption Standard (3DES) or the Advanced Encryption Standard (AES) keys – on the SAKA, while the symmetric key itself is used to encrypt files of any-type and any-size. This allows for the encryption of objects significantly larger than the 10,000 characters of text that the SAKA allows, while still using the SAKA as a vault for storing keys centrally and securely;
- Similarly, StrongAuth's free and open-source CryptoDriver software is capable of escrowing symmetric cryptographic keys on the SAKA, while the symmetric key itself is used to encrypt disk drives and volumes to protect data-at-rest. This has the benefit of mitigating losses for a stolen machine/disk since the decryption keys are not resident on the device.
StrongAuth is constantly adding value to the SAKA based on customer feedback and requirements. If there is a use-case you believe has not been addressed by StrongAuth, do let us know; we'll review it for potential inclusion into the SAKA “ecosystem”.
Application Design for “Card Present” transactions
In the credit-card industry, card present transactions represent transactions where the customer is buying products and services at a physical location where the merchant has the credit-card physically “present” in front of the merchant. The merchant, typically, swipes the credit-card in a reader – also called Magnetic Stripe Readers (MSR) because of the device's ability to read a magnetic stripe on the back of the credit-card containing sensitive CHD – attached to a “ point-of-sale” (POS) device as part of the transaction.
|
|
NOTE: In today's retail environment, POS devices may be a smartphone or tablet computer with a physically connected card-reader. Alternatively, they may be “ wireless” readers using one of many wireless protocols such as Near Field Communications (NFC), Bluetooth, etc. However, the principal concept is the same: the card is present in front of the merchant, adding a level of verification not found in “card not present” transactions.
Newer card-readers have the ability to encrypt the PAN and other sensitive data from the magnetic stripe as the card is swiped through the reader. Such encrypting readers use an encryption standard called the Derived Unique Key Per Transaction (DUKPT) algorithm conforming to the American National Standards Institute (ANSI) X9.24-1 – 2009 standard.
When StrongAuth's Card Crypto Service (CCS) module is deployed on the SAKA, it has the ability to decrypt the encrypted swipe, parse the content, re-encrypt the decrypted PAN using the SAKA's Foundation cryptographic services thus creating a token for the PAN, and returning the transaction to the calling application as a Javascript Object Notation (JSON) string. The JSON has all the information the merchant application needs to fulfill the purchase transaction while only getting the token instead of the original PAN. This has the benefit of providing end-to-end encryption between the MSR and the SAKA, shielding sensitive CHD from the POS application, networks, back-end merchant applications and anyone attempting to snoop for CHD.
|
|
Design Consideration #5
|
When using the SAKA to process DUKPT-encrypted transactions, additional time may be needed for StrongAuth to integrate your choice of MSRs (if the current list of supported MSRs will not work for you). The MSR vendor-documentation and a sample reader with configurable Initial PIN Encryption Key (IPEK) or Initial Key (IK) tools will be necessary to add supported MSRs to the CCS module. |
Design Consideration #5
|
The CCS module only returns JSON (www.json.org) strings embedded with transaction details with the token for the credit card used in the transaction. Your application must be capable of parsing this JSON string in the SOAP response of the webservice call, to get the transaction data. |
Summary on “Card Present” transactions
Card present transactions are very specific in the format of the data-structure returned by the card-reader. StrongAuth's list of supported card-readers is currently limited; consequently, this may require planning for a little extra time to have your preferred card-reader integrated into the CCS module. Additionally, the application must be prepared to parse a JSON object in the response from the SAKA. Finally, since the CCS module uses the Foundation cryptographic services of the SAKA, all design considerations listed in the “Card Not Present” section still apply.
If you have any questions, please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.. Thank you.