Authorize.Net prides itself on our flexible APIs and the many ways in which they can be used to create your own payment system. From time to time, we like to invite guest bloggers to talk about their real-world solutions. This way, you can see just one example of the many ways that Authorize.Net can be implemented. We hope these perspectives will help you as you determine how best to approach designing your own solutions and applications.
Today’s post is by CRESECURE. CRE Secure is a hosted payment acceptance service for online retailers. Created before Authorize.Net launched our hosted CIM solution, CRE Secure’s solution uses a combination of Authorize.Net’s AIM and CIM integration methods to provide a fully hosted payment form that uses tokenization to store sensitive data. Whether you decide to create your own solution using Authorize.Net’s hosted CIM, to code your own payment form using CRE Secure’s example as a guideline, or to simply use a ready-to-go offering like CRE Secure’s, we hope this post will provide some good information and stimulate some ideas.
If you’re interested in blogging about your solution, please email Michelle at michelle@authorize.net.
Tokenization is used in payment systems and payment integrations to replace sensitive credit card data in a business system so the system no longer has to be subject to PCI Compliance regulations.
- How does Tokenization work?
- Who can use Tokenization?
- How does Tokenization compare to encryption?
- How does CRE Secure work with Authorize.Net to provide complete tokenization?
How does tokenization work?
Tokenization works by storing the credit card in a third party system that is PCI Compliant. The third party returns a token to the merchant system upon receipt of the credit card data. The merchant stores the token in their database instead of the card data. The only part of the credit card data that needs to be kept out of the merchant system via tokenization is the 15-16 digit Payment Account Number, or PAN, the credit card number. The other elements of the card are considered non-sensitive.
The merchant will also want to store the non-sensitive card data to identify the token—name on the card, card brand, expiration date and the last four digits of the credit card number. The CVV (or CVC) cannot be permanently stored by the merchant or the provider.
In the case where a payment gateway is the token provider, the merchant sends the token to the payment gateway in transactions for new authorizations. Just like they would send the credit card to the gateway’s API, they send the token to the API along with the order number, amount of the transaction and any other details about the new transaction that is required. The key here is that instead of the sensitive card data, the merchant can use the token to make new authorizations.
Tokens can come in many different formats. Make sure your system can account for them. Some are long Generated Unique Identifiers (GUIDs), some are serialized IDs, others can be generated to match the same data storage requirements as a credit card number, 16 digits numeric. The latter is referred to as a legacy or format preserving token and should preserve the last four and in some cases the first 2 - 4 digits of the originating card number. This can reduce the alteration of complex systems that are coded to display the last 4 digits of the actual card data.
Who can use tokenization?
Any merchant that wants to charge a card more than once without having to create PCI Compliant data storage. Typically merchants used to store the entire credit card number so they could resubmit it for new authorizations. With tokenization you replace all of the credit card PAN (payment account numbers) with tokens. Then you submit the tokens to your payment provider for new authorizations.
At this point, card data should not be stored by merchants without serious security in place that are up to or exceed PCI Compliance standards.
- 81% of private data is stolen via malware on merchant’s servers – 2011 Verizon Study
How does Tokenization compare to encryption?
Another option for securing card data is encryption. Tokenization is different from encryption. With encryption you take the card data and convert it into an encrypted string which is stored. Encryption requires key management and logic/code to perform the encryption and decryption. With encryption the security surface moves to the keys. It is the responsibility of the company that has access to the keys now has to secure them.
Traditionally merchants have used encryption in their database, but kept the keys and logic on the same server or servers with direct access to the database. This makes it easy for an attacker to get access to the keys and the data and the logic to de-crypt and thus stealing the card data. Merchants who secure the keys or use third party decryption / storage can gain a lot of flexibility with encryption. However, any systems handling the card data once it is decrypted need to be secured since they are back in scope of PCI Compliance.
In summary, some things about tokens:
- Tokenization replaces the card data in a way that the card data cannot be retrieved, ever
- The tokens are bound to a specific gateway account, or third party provider
- A token represents a single credit card or account number
- If tokens are stolen they cannot be used at any other merchant or gateway
- There are no additional security requirements needed to store and transmit tokens
- Tokens come in different forms:
- GUIDs (generated unique ids)
- 16 digit legacy format
- Custom patterns
How does CRE Secure work with Authorize.Net to provide complete tokenization?
Authorize.Net provide a secure data storage that provides a type of flexible tokenization. Authorize.Net Customer Information Manager or CIM stores card data and addresses. The tokens it provides are mutli-part as multiple profile ids and is available as a separate API from their popular Advanced Integration Method or AIM.
Two challenges exist for merchants integrating to CIM:
- Securing the card data as it is collected before it is passed to CIM
- Connecting to AIM and CIM apis to for single use and multiple use transactions
CRE Secure has partnered with authorize.Net to solve the above challenges and also solve additional challenges that emerge around secure collection.
CRE Secure provides a revolutionary method for securing a merchant payment or collection page in a PCI Compliant environment that has certified connections to major gateways featuring Authorize.Net AIM and CIM. The revolutionary part comes in providing a hosted payment page for ultimate security, which is actually the merchant's page moved into CRE's secure datacenter in real time each time the merchant sends a customer to the hosted page. This provides merchants with absolute control over the content and templating of the page without ever having to manage it outside their environment.
CRE Secure collects the card data and interacts with Authorize.Net gateway to store, authorize or store and authorize the card and return to the merchant system CRE tokens and CIM profile ids along with transaction and AVS results in the case of a transaction.
Merchants can then send the CRE tokens which can be legacy or format preserving, back to a CRE API end point which translates the tokens back into the CIM profiles and communicates with Authorize.Net for authorizations. For merchants that have existing CIM integration, they can use the CIM profile ids returns and use them directly with the CIM api.
While Authorize.Net provides several methods to either secure card data or give merchant control over the collection of card data. CRE Secure provides both security and control for Authorize.Net merchants.
Tokenization is an important part of securing card data and by using best of class technology and payment providers merchants can completely remove their systems from PCI scope while continuing to work with their preferred gateway and business systems.
Learn more about securing your card data before sending it to Authorize.Net CIM at www.cresecure.com .
