Developer Portal
Register
Handling sensitive financial information is a significant responsibility for any modern business. For developers, the technical burden of securing credit card numbers, CVVs, and bank account details is often the most complex part of building a checkout experience. Every piece of raw data that touches your server increases your liability and complicates your security posture.
When a merchant's server "sees" or "touches" raw primary account numbers (PAN), the requirements for PCI DSS compliance skyrocket. This is known as being in scope. Staying in scope means adhering to rigorous, multi-layered security standards that require constant auditing, expensive security software, and specialized infrastructure.
For many, the risk of a data breach is a constant concern. If sensitive data is intercepted on its way to your server or stolen from your local database, the fallout can be catastrophic for both the merchant and the developer. This is why the industry has shifted toward tokenization as the gold standard for secure payment gateway integration.
The Payment Card Industry Data Security Standard (PCI DSS) requires merchants to complete a Self-Assessment Questionnaire (SAQ). The complexity of this questionnaire depends entirely on how you handle cardholder data. If your server processes raw data, you are often relegated to the most difficult version, SAQ D, which involves over 300 security controls.
By using modern tools to offload data handling, merchants can qualify for a simplified pci compliance saq. Specifically, methods that prevent raw data from ever reaching the merchant's server allow for the use of SAQ A or SAQ A-EP. These shortened versions focus on front-end security rather than the entire server environment.
Integrate Payments provides the tools necessary to shift the heavy lifting of security to our hardened infrastructure. This allows developers to focus on the user experience while the merchant benefits from a drastically reduced compliance burden and lower operational risk.
Collect.js is a powerful JavaScript library designed to act as a secure bridge between your online payment forms and the payment gateway. It provides a way for developers to build fully customized checkout pages without the security risks associated with handling raw payment data.
The primary function of Collect.js is tokenization. This is the process of replacing sensitive data with a non-sensitive equivalent, known as a token. Because the library handles the communication with the payment gateway directly from the customer’s browser, the raw card information never touches the merchant's web server.
This "hands-off" approach is the preferred method for high-growth companies. It allows for a seamless, white-labeled experience where the customer never feels like they are leaving your site, yet the security remains as robust as a third-party hosted payment page.
The architecture of a Collect.js integration follows a specific flow designed to isolate sensitive data. It starts the moment a customer lands on the checkout page and ends with a successful transaction response from the payment gateway.
First, the library is initialized on the client side using a public key. This key identifies the merchant account but does not have the permissions required to actually process a transaction or move money. Its only job is to facilitate the creation of a secure environment for data entry.
The library then creates secure, isolated input fields, often referred to as iframes, within your payment form. These fields are technically hosted on the secure payment gateway servers but appear visually as part of your website. When the customer enters their card details and clicks "pay," the data is sent directly from their browser to the gateway.
Once the customer initiates the payment, Collect.js captures the information from the secure fields and transmits it to the tokenization server. This happens in the background, invisible to the user. The gateway validates the card information to ensure it is formatted correctly and is a valid account.
If the data is valid, the gateway generates a unique, temporary string of characters called a payment token. This token acts as a placeholder for the actual credit card or bank account information. It has no value to hackers because it cannot be used to recreate the original card number.
The gateway sends this token back to the customer's browser. At this point, the raw card data is discarded by the browser, and only the token remains. This entire process happens in milliseconds, ensuring that the checkout flow remains fast and responsive.
After the token is received, it is automatically injected into the merchant’s payment form. The form is then submitted to the merchant's server. Because the form now contains a token instead of a credit card number, the merchant’s server can safely receive, process, and even log the submission without falling into a high-risk PCI category.
The merchant’s server then takes this token and prepares a server-to-server request to the payment gateway. This is where the actual financial transaction occurs. This step requires a private security key, which is kept strictly on the server and is never exposed to the public or the customer’s browser.
The gateway receives the token and the security key, looks up the original payment data associated with that token, and submits the transaction to the banking network. The result, either an approval or a decline, is sent back to the merchant's server to complete the order.
Understanding the specific variables used in this process is essential for a successful integration. There are three primary components that manage the security and data flow between the client, the server, and the gateway.
The Tokenization Key: This is a public-facing identifier. It is used in the front-end code to tell the library which merchant account should receive the tokenized data. Since it can only be used to create tokens and not to process charges, it is safe to include in your client-side JavaScript.
The Payment Token (payment_token): This is the temporary variable generated after successful tokenization. It is short-lived and usually valid for only one transaction. It represents the customer's intent to pay and acts as a secure proxy for their financial details during the transition from the front-end to the back-end.
The Security Key: This is the most sensitive variable in the integration. It is used on the server side to authenticate the final payment request. It grants the authority to capture funds, issue refunds, and manage the customer vault secure credit card info. This key must never be shared or exposed in client-side code.
For SaaS providers, Collect.js is often the preferred method for building custom billing portals. These platforms require high levels of customization to match their brand identity but cannot afford the massive overhead of managing high-level PCI compliance across thousands of sub-accounts.
By using Collect.js, a SaaS developer can build a single, secure integration that scales. They can offer their users a professional payment gateway integration while ensuring that the platform itself remains insulated from the risks of data theft.
Furthermore, the tokens generated can often be used to store information in a secure vault. This allows for recurring billing and "one-click" checkout experiences without the platform ever having to store a card number in its own database.
Custom e-commerce platforms also benefit significantly from this architectural approach. Unlike standard plug-and-play shopping carts, custom builds often require unique logic for split payments, complex shipping calculations, or multi-vendor payouts.
Collect.js provides the flexibility to handle these complex scenarios. Because the developer has full control over the online payment forms, they can design a user interface that perfectly fits the niche of the marketplace.
Whether it is a specialized restaurant management software or a complex B2B portal, the ability to tokenize at the edge and process on the backend provides the perfect balance of security and creative freedom.
Beyond the initial setup, using a tokenization library simplifies long-term maintenance. When security standards evolve or browser requirements change, the library is updated at the source. This means developers spend less time patching security vulnerabilities in their custom forms and more time building features.
This architecture also makes it easier to test your integration. Developers can use a developer sandbox payment gateway to simulate the entire tokenization and transaction process without using real money or risking real data.
As your business grows and your transaction volume increases, the infrastructure scales with you. Because the heavy processing occurs on the gateway side, your server's resource usage remains low, and your security profile remains clean, regardless of how many customers are checking out at once.
In the current landscape of fintech and web development, security is not a feature, it is a foundation. Collect.js provides a clear path for developers to implement world-class security without sacrificing the user experience.
By moving away from raw data and toward a tokenized architecture, you protect your customers, your business, and your reputation. The shift from manual data handling to an automated, token-based system is the smartest move any merchant can make in their journey toward better pci compliance saq and long-term stability.
Integrate Payments is committed to providing the documentation and support necessary to help you succeed. By focusing on high-level architectural standards and robust security parameters, we ensure that your payment integration is a competitive advantage rather than a technical liability.
Compliance Disclosure: Integrate Payments provides payment processing services and tools designed to assist merchants in achieving PCI DSS compliance. Use of Collect.js and other tokenization methods can significantly reduce the scope of your PCI SAQ, but it does not exempt a merchant from the requirement to complete an annual assessment. Merchants are responsible for ensuring their overall business practices meet all current PCI standards and local financial regulations. Please consult with a qualified security assessor for specific compliance guidance.