Encryption transforms plain text into encoded information. In payments, it is the process of taking sensitive information and converting it into code. Credit, debit, and ACH numbers become ciphertext that requires a specific corresponding decryption key to convert back into usable payment information. There are two main types of encryption.

• Symmetric in which both encryption and decryption use the same key. It’s the faster of the two methods but is more prone to risk.
• Asymmetric uses two different keys: A public key that can be shared for encryption; and a private key that is held by authorized parties for decryption.

Encryption occurs when a customer initiates a transaction. The encoded information is protected as it travels from the owner to a payment server. Encrypted data can also be stored on ecommerce sites for recurring payments. If a fraudster gets ahold of this information, it’s unusable to them — unless they obtain the key.

Encryption is a compliance requirement that is part of the Payment Card Industry Data Security Standard (PCI DSS) to protect customer information. While compliance with this standard is not law, most payment partners take on this burden to help merchants maintain business as usual and avoid sanctions.

Most North Developer integrations are PCI Level-3-certified right off the shelf and reduce PCI scope for ISVs For example, our North SI Cloud API encrypts cardholder data and prevents sensitive cardholder information from ever reaching ISV or merchant servers. Only API integrations that allow sensitive data into your server environment are within PCI scope. We also offer available Point-to-Point Encryption that eliminates clear-text cardholder data from the payment transmission process.

Tokens are randomly generated strings of characters or symbols that take the place of sensitive data like card or account information. They can’t be reconverted or reverse engineered. And if they’re lost or stolen, the value and information they represent is not lost.

Custom tokens also allow you to securely link to transactions for additional functionality, including reporting, chargebacks, recurring sales, and even to create other transactions. Risk is minimized because credit, debit, and ACH account numbers are not being stored by the merchant or ISV — tokens are. Tokens can be used for recurring purchases, acting upon a previous transaction such as capturing an authorization by using the authorization token in the capture request. They can also be used to refund a sale by using the sale token in the refund request.

Payments Hub custom BRIC tokens allow you to link transactions for reporting, chargebacks, and recurring sales (you can also find API solutions for reporting and recurring billing on our portal). BRIC tokens can also be used to create other transactions without the risk and expense of storing card and ACH account data. BRICs are commonly used to act upon a previous transaction. An existing authorization can be captured or an existing transaction can be refunded. BRICs can also be used to create recurring payments.

• Sensitive data can only be retrieved with the correct token when an authorized request is made. This process is often used alongside encryption, protecting sensitive transaction information from any unauthorized eyes during the transfer.
• Tokens can minimize the risk of data loss for merchants and ISVs since the data is not stored in a database maintained by the merchants or software providers — only the tokens are. This protects the information from falling into criminal hands, unlike stolen encrypted data, which can be obtained (though not necessarily decrypted).
• Tokens aid in compliance with PCI DSS, an industry obligation for businesses with whom you implement payment processing.
• Tokens are not-so-scalable. If you’re dealing with large volumes of data, a great number of tokens are needed, which can make the process cumbersome.

Choosing to use encryption, tokenization, or a mix of the two depends on the nature of the business you’re working with, as well as the specific information requirements of your payment application.

Here are some additional considerations:

• Tokenization offers robust security with fewer vulnerabilities. If you’re working with large data sets — more than just account numbers or shorter form information — encryption may be the better option.
• Consider how long the sensitive data will be stored. If you’re building payments for recurring purchases, to be kept in online store accounts, or subscription-based sales, tokenization will offer enhanced security in the long run.
• Encryption keys are a strong tool for protecting information, but if management of said key is a concern, if there’s any chance its ownership could be compromised, tokenization's keyless qualities may be the better — less burdensome — choice.
• It may come down to cost effectiveness: Consider how data is transmitted, the way service providers may prefer to receive sensitive data. Many offer lower fees depending on whether encryption or network tokens are used.