Integrations

Preczn offers flexible integration options to suit a variety of business needs, enabling Merchants to seamlessly incorporate our payment solutions into their systems. These options range from fully isolated, iframe-based card capture to direct API access, and differ significantly in the PCI DSS validation effort they impose on the Platform.

1. PaymentElements Integration (recommended): Preczn's most isolated card-entry integration. Each input (card number, expiration, CVV) is rendered inside a separate iframe served from Preczn's own origin, and the fields communicate with a Preczn-hosted controller document over origin-pinned postMessage. Cardholder data is entered into, and never leaves, the Preczn-origin frames; it is tokenized directly against Preczn's API and is never present in the Platform's page DOM, in Platform JavaScript, or on Platform servers. The Preczn documents are protected by a per-request Content-Security-Policy with a script nonce and frame-ancestors pinning, and the parent-page SDK is delivered with a Subresource Integrity digest. Field styling is configurable through a sanitized style API, so the fields can be matched to the Platform's design without granting script access to them.

2. PaymentFields Integration: A lightweight JavaScript library for Platforms that want to own their checkout markup. The Platform renders its own form inputs and tags them with data-preczn attributes; the Preczn library reads those values on submit and tokenizes them directly against Preczn's API. Cardholder data therefore travels from the consumer's browser to Preczn without passing through Platform servers — but it is present in the Platform's own page and DOM, and the security of the Platform's checkout page directly affects the security of that data. PaymentFields offers the greatest markup flexibility of the browser-side integrations, at the cost of a larger PCI validation scope than PaymentElements.

3. Direct API Integration: For Platforms seeking maximum control, Preczn offers direct server-to-server API access. This method allows Platforms to build fully custom payment experiences and handle complex transactions, with a robust set of tools for processing payments, managing accounts, and retrieving transaction data. Because the Platform receives and transmits raw cardholder data on its own systems, this option carries the most extensive PCI DSS obligations.

Comparison

PCI DSS SAQ implications

The three integrations differ in where cardholder data exists, and that placement is what drives which Self-Assessment Questionnaire a Platform completes.

PaymentElements is designed for the narrowest scope. Because every element of the card-entry interface is delivered to the consumer's browser from Preczn's origin and the PAN never enters the Platform's page, this integration is intended to support the shortest SAQ available to an e-commerce merchant that does not touch cardholder data. Note that the platform still hosts the parent page that embeds the Preczn frames, so controls over that page remain relevant to the Platform's assessment.

PaymentFields does not offer the same scope reduction. Although cardholder data bypasses Platform servers, it is entered into inputs the Platform renders and is read by script executing in the Platform's page. The Platform's checkout page can therefore affect the security of the payment transaction, which places it in a materially different category than PaymentElements.

Direct API places cardholder data on Platform systems and carries the most extensive validation obligations of the three.

A Platform's actual SAQ eligibility is determined by its processors or QSA against its full environment, not by its Preczn integration alone. Platforms should confirm their SAQ type with their processors before relying on any scope reduction described here.