What is Preczn?

Preczn is a fintech operating system for vertical SaaS platforms. One integration connects your software to the payment processors, payment facilitators, and lenders your merchants use — and Preczn holds the merchant data, the stored payment methods, and the routing logic in between.

That middle layer is the point. Because merchant records and payment tokens live in your Preczn vault rather than inside any one processor, adding a provider, changing providers, or running several at once is a configuration change instead of a re-integration.

Each provider still underwrites the merchants it takes on — that decision stays theirs, and it applies whether you're moving to a new processor or adding a new fintech service such as lending. What changes is the work in front of it: the merchant's data is already in your Preczn vault, so the new application is largely prefilled rather than filled out again, and their customers are never asked to re-enter their cards.

Preczn does three things, and most platforms use all three in sequence:

flowchart LR
    L["Legacy provider<br/>merchants, tokens,<br/>transaction history"] -->|migrate| PZ
    P["Your platform"] --> PZ

    subgraph PZ["Preczn control layer"]
        direction TB
        MV["Merchant vault<br/>business data, credentials,<br/>connection status"]
        TV["Token vault<br/>PCI DSS Level 1"]
        RT["Routing<br/>plans and rules"]
    end

    PZ --> C1["Platform processors<br/>Payrix, Stripe Connect,<br/>Adyen for Platforms, Frame…"]
    PZ --> C2["Direct processors<br/>Stripe, Adyen, Braintree,<br/>CardPointe, Checkout…"]
    PZ --> C3["Lenders and issuers<br/>GreenSky, Nelnet,<br/>Jaris, Ramp"]

What can you do with Preczn?

---

Migrate onto Preczn

Most platforms arrive with merchants already processing somewhere. You don't have to start over.

Bring your existing merchant book

Import merchant records in bulk from a CSV, or pull them directly from a processor you already use. Supported connections can also import historical transactions, so reporting doesn't restart at zero.

Bring your stored payment methods

Existing tokens can be imported into the Preczn token vault from a prior provider or vault, and supported connections can be re-tokenized during a processor change. Cards that already work keep working.

Keep merchants that are already boarded

A merchant already boarded to a provider outside Preczn doesn't need to be boarded to it again. Link the existing credentials to the merchant record and start routing through Preczn immediately.

Onboard and activate merchants

---

One merchant record, many providers

Every processor asks for the same business, ownership, and banking data in a different shape. Preczn normalizes those requirements into a single merchant record, tracks what has been collected against what is still outstanding for each connection, submits the merchant for underwriting, and reports status back until the connection reaches Active.

Boarding the same merchant to a second provider means a second underwriting review, but not a second data collection — Preczn supplies what it already holds and asks the merchant only for what that provider additionally requires. See Merchant Onboarding.

Collect sensitive data without touching it

Boarding forms are Preczn-hosted, served on your domain in your branding. Bank account details, ownership information, tax identifiers, and signed agreements are collected and stored by Preczn — they never pass through your infrastructure. Merchants can save progress and finish across sessions, and each form renders only the fields the target connection actually requires.

A single form can be scoped to several connections at once, so one merchant application boards to more than one provider.

Run it from the Dashboard or the API

Create merchants through the Dashboard for manual and one-off work, or through the API for automated signup flows. Both write to the same merchant record.

Orchestrate payments, lending, and fintech services

---

Accept payments

Process card and ACH payments, plus Apple Pay and Google Pay, through one transaction API. The full set of transaction types — sale, verify, auth, capture, void, and refund — behaves the same way regardless of which processor executes it, and so do AVS, CVV, Level II and Level III data, dynamic statement descriptors, and metadata.

Store payment methods once, use them anywhere

Preczn tokenizes cards and bank accounts into a PCI DSS Level 1 token vault. That decouples where a payment method is stored from who processes it: Preczn can run the transaction to a processor on your behalf, or push the card to a third-party processor that tokenizes it so your platform transacts directly.

The vault is yours, not a processor's — which is what makes changing providers a routing decision rather than a re-tokenization project.

Route transactions across providers

A Plan decides which connection a merchant's transactions go to, using Rules you configure: by BIN, card brand, currency, volume distribution, priority order, or reject salvage — re-running a declined transaction against the merchant's other connections. Routing is configuration, not code: adjust cost, authorization rates, processor volume thresholds, or redundancy without a deploy.

If you'd rather own the decision, name a processor on the transaction request and Preczn routes it there directly. See Transaction Routing.

Offer financing alongside payments

Payments aren't the only thing Preczn orchestrates. B2B2C lending is embedded in your software the same way payments are, and behaves the same way a card token does: a loan originated for a merchant's customer — a homeowner financing a renovation, say — is tokenized, drawn down to pay the merchant, and tracked for status and balance over the life of the loan.

Stay compliant as you scale

---

PaymentElements renders each card input inside an iframe served from Preczn's origin, so cardholder data never enters your page, your JavaScript, or your servers — the narrowest PCI scope of the three integration options below.

On the merchant side, SAQ management lets you create, sign, and track PCI DSS Self-Assessment Questionnaires across your portfolio, and transmit signed documents to supported processors.

How can you integrate?

---

Preczn offers three ways to capture payments. They differ mainly in where cardholder data lives, which is what drives your PCI DSS validation effort.

PaymentElements

Each card field is rendered by Preczn inside its own iframe and styled to match your design through a sanitized style API. The PAN is never present in your page's DOM or on your servers. Narrowest PCI scope. See PaymentElements Integration.

PaymentFields

You render your own checkout markup and tag the inputs with data-preczn attributes; a lightweight Preczn library reads them on submit and tokenizes directly against Preczn's API. Card data bypasses your servers but is present in your page. Maximum markup control, larger PCI scope. See PaymentFields Integration.

Direct API

Server-to-server integration for platforms that need complete control of the payment experience. Your systems receive and transmit raw cardholder data, which carries the most extensive PCI obligations. See Direct API Integration.

ℹ️ Not every workflow needs code

Boarding merchants, configuring connections, building plans and rules, and reviewing transactions can all be done entirely from the Dashboard. Many platforms start there and add the API as they automate.

Your platform's actual SAQ eligibility is determined by your processors or QSA against your full environment, not by your Preczn integration alone. See Integrations for the complete comparison.

Terms to know

---

Four terms carry most of this documentation. The rest are in the Glossary.

Every Preczn object ID carries a prefix identifying its type — mid_ for a merchant, tkn_ for a token, txn_ for a transaction. The full list is in Object ID Prefixes.

Live mode and test mode

---

Preczn has no separate sandbox. Every platform has a test mode and a live mode, toggled in the Dashboard, and they are fully isolated from one another — merchants, connections, plans, rules, transactions, and API keys are all mode-specific. Test transactions route to the sandbox environments of the connections you configure, using the sandbox credentials your processors issue.

Build and validate your entire configuration in test mode, then reproduce it in live mode. See Live vs Test Mode.

Where to start

---

🚀 Building with an AI coding assistant?

The Preczn MCP Server gives Claude Code, Cursor, Copilot, and other MCP-aware tools direct access to this documentation and the API reference.