Understanding PCI Compliance

All merchants who process credit card payments are subject to the PCI compliance requirements as set out by the PCI Security Standards Counsel.

There are different levels of PCI compliance scope that a merchant integrating with Helcim could be subject to. This depends on what product they integrate with and whether they need to process with full credit card details.

Integrating with HelcimPay.js

Integrating with HelcimPay.js to process payments, or verify and tokenize card details, will provide the most reduced PCI compliance scope available.

Because we render the payment modal in an iFrame on your website, this means that sensitive credit card details never touch your website or server. Because of this, you would only need to complete the annual PCI compliance SAQ-A questionnaire that pops up on your Helcim dashboard.

Integrating with Helcim.js

Integrating with Helcim.js doesn't reduce PCI compliance scope as much as HelcimPay.js when used to process payments, or verify and tokenize card details.

Since this service uses HTML input fields, the customers credit card details technically touch your website even if the JavaScript doesn't allow them to be submitted to your server. Because of this, you need to complete the PCI compliance SAQ- A-EP questionnaire that can be downloaded from the PCI Security Standards Counsel website.

You would need to complete this annually and then upload your completed questionnaire into the Helcim system to remain PCI compliant. In your Helcim account you would select All Tools, My Business and then Security and Compliance in order to complete the upload for your PCI compliance process.

Integrating with Helcim API and full card numbers

The least reduction in scope comes when needing to process with full card details through the Helcim API, which requires a PCI compliance SAQ-D questionnaire to be completed by a third party auditor and approval by our CTO and cyber-security teams.

You would need to complete this annually and then upload your completed questionnaire into the Helcim system to remain PCI compliant. In your Helcim account you would select All Tools, My Business and then Security and Compliance in order to complete the upload for your PCI compliance process.

Reducing your PCI compliance scope

By default, Helcim merchants cannot send full card numbers, expiry dates, or CVV numbers to the Purchase, Preauth, or Verify endpoints in the Payment API. We strongly recommend that you do not store any sensitive cardholder information in your system, and instead use one of our payment solutions such as HelcimPay.js to process payments or verify and tokenize credit card details to be used through the Payment API.

Tokenizing credit card details

To process payments through the Payment API, you will first need to tokenize the customers credit card details and create a cardToken. The cardToken is a secure representation of your customers credit card information, that can be used to process future payments through the Payment API.

We recommend you use HelcimPay.js to tokenize and process initial payments for customers through your website or application. HelcimPay.js will return a cardToken value to you that can be stored in your system and used through the Process Purchase Transaction endpoint to process future payments without further action from the customer.

HelcimPay.js ensures sensitive credit card details are not passed to your website or server, reducing the security scope and PCI-DSS compliance requirements of your integration.

Processing with a cardToken

As part of the Helcim tokenization process, cards are stored under a customer profile and in your Helcim Card Vault, located in the Customer section of your Helcim account. Each customer also has their own card vault that can hold as many cards as needed.

Your system can store relevant cardToken information and use this when processing payments through the Payment API. The cardToken is not considered sensitive cardholder information and can only be used within the Helcim system, unless transferred to another PCI compliant payment processor through a secure data migration process.

When ready to process a new payment, the cardToken should be sent to the Payment API endpoint in the cardData object instead of the credit card number, expiry and CVV fields.

Field NameFormatDescription
cardTokenString (23)The 23-digit, alphanumeric card token representing the stored card information.