Glossary

Terms are grouped by the area of Preczn they belong to, and alphabetical within each group. Each definition links to the page that covers the concept in full — this page is the index, not the explanation.

Who's who


Customer	Your merchant's customer — the person or business paying the merchant. Preczn never holds a direct relationship with them.
Merchant	Your customer: the business that processes payments through your platform. Also the name of the record Preczn keeps for that business. See Merchants Overview.
Platform	You — the vertical SaaS software that integrates Preczn. ID prefix `pfm_`.
Portfolio	A parent organization that can own more than one platform, used where a single company runs several products or brands. ID prefix `port_`, live mode only. Most platforms have exactly one and never interact with it.
Preczn user	A person with Dashboard login credentials for your platform. Users are shared across live and test mode. ID prefix `user_`. See User Management.
Provider	Any fintech company Preczn connects to — a payment processor, payment facilitator, lender, or service provider. Used interchangeably with connection when talking about the company rather than the configuration.

Connections


Billing group	A fee group a merchant is assigned to at a connection, determining the fees the processor charges. The fee definitions live at the processor; Preczn assigns and moves merchants between groups. Supported on Payrix and Rainforest. See Billing Group Management.
Connection	The link between your platform and one fintech provider. A merchant can hold every connection your platform supports, but only one of each. See Connections Overview.
Connection status	The state of one merchant's relationship with one connection, from `Unconfigured` through `Active`. Each connection on a merchant tracks its own status independently. Full list in Merchant Lifecycle.
Direct processor	A connection where each merchant holds their own agreement, pricing, and account with the processor. See Connections Overview.
Issuing processor	A connection that provides cards or financing to the merchant itself rather than processing the merchant's sales. Merchants board to it, but transactions don't route through it.
Lending processor	A connection that originates and services loans, and handles loan disbursement and repayment. See B2B2C Loans.
Merchant connection	One merchant's entry for one connection — its credentials, its MID at that provider, and its status. ID prefix `midCon_`.
MID	Merchant identifier. Depending on context, either the merchant's ID at a provider, or the Preczn merchant record ID (prefix `mid_`). A business with two MIDs at the same provider needs two Preczn merchant records. See Merchants and Connections.
PayFac	Payment facilitator. See platform processor.
Platform connection	Your platform's configuration of a connection — the credentials and settings that make it available to your merchants. ID prefix `pfmCon_`. See Connection Configuration.
Platform processor	A connection, also called a payment facilitator or PayFac, where merchants board as sub-accounts under your platform's master account and your platform owns the processor relationship.
Service processor	A connection providing payment-adjacent services such as loan servicing or fraud detection.

Merchants and onboarding


Attachment	A document stored against a merchant, an owner, or a bank account — a voided check, a business license, an ID. ID prefixes `midDoc_`, `midOwn_`, `midBank_` respectively for the records they attach to.
Boarding domain	Your own subdomain serving Preczn-hosted boarding forms, so form URLs carry your brand. ID prefix `brd_`. See Configuring Domain Names.
Boarding form	A Preczn-hosted form that collects a merchant's onboarding data, served on your domain in your branding. Renders only the fields the target connections require. ID prefix `form_`. See Boarding Forms.
Boarding form template	A reusable configuration that boarding forms are created from — sections, copy, terms, and settings. ID prefix `formTemp_`. See Boarding Form Templates.
Contact	A named person on a merchant, assignable to per-connection roles such as signer or support contact. ID prefix `cnt_`.
External ID	Your own identifier for a merchant, stored on the Preczn merchant record so you can reconcile against your system.
KYC / KYB	Know Your Customer and Know Your Business — the identity and business verification data a provider requires before it will underwrite a merchant.
Label	A tag you attach to merchants to build and filter cohorts, such as a migration batch. See Labeling Merchants.
Merchant record	The single record holding a merchant's business data, owners, banking, connections, plan assignment, and status. One record per account at a provider. ID prefix `mid_`.
Merchant vault	Preczn's store for merchant business data and processor credentials, and the Dashboard view onto it. Distinct from the token vault, which holds payment data.
Owner	A beneficial owner of the merchant business, with the ownership percentage and identity data providers require for underwriting. ID prefix `midOwn_`.
Requirements	The fields one connection needs before a merchant can be submitted to it. Preczn maintains the requirements for every supported processor and reports what is still outstanding. See Onboarding Data Requirements.
Requirement template	The set of requirements applied to a merchant at a connection. Every connection gets a default template; platforms can add custom templates for different merchant types. ID prefix `reqTemp_`.
RFI	Request for Information. A connection status meaning the processor needs more information before it can finish underwriting. See Onboarding Troubleshooting.
Underwriting	The provider's review of a merchant application. Each provider underwrites independently, so boarding one merchant to a second provider means a second review — but not a second data collection. See Merchant Onboarding.

Payments and transactions


ACH	Automated Clearing House — bank-to-bank transfers, also called direct debit. See ACH (Direct Debit).
Auth	A transaction that authorizes and holds funds without capturing them. See Auth.
Capture	A transaction that captures previously authorized funds and settles them for funding. See Capture.
Refund	A transaction returning funds to the customer after settlement. See Refund.
Sale	A transaction that authorizes and captures in one step. See Sale.
Settlement	The movement of captured funds from the processor to the merchant's bank account. A transaction can be voided before settlement and only refunded after it.
Transaction	A single payment operation run against a connection. ID prefix `txn_`. See Process Transaction.
Verify	A transaction confirming a payment method is valid without moving funds. See Verify.
Void	A transaction cancelling a sale, auth, or drawdown that has not yet settled. See Void.

Payment methods and stored data


Card on file (COF)	The context in which a stored token is being charged, sent as `tokenUsage` and passed to the processor as network COF flags. Values are `customer`, `merchant`, `recurring`, and `installment`. See Card On File Flags.
Multi-use token	A permanent token, returned on an approved sale or auth when requested, reusable for future transactions. Never expires, though the underlying card still does.
PAN	Primary Account Number — the card number itself. Where the PAN exists in your systems is what drives your PCI scope.
Single-use token	A token obtained before authorizing, typically from a customer-facing form via PaymentFields, so card details never reach your servers.
Token	A stored card or bank account in the Preczn token vault, usable across connections. ID prefix `tkn_`. See Tokenization.
Token scope	Whether tokens are owned at the merchant level (specific to one merchant) or the platform level (shared across all your merchants).
Token vault	Preczn's PCI DSS Level 1 store for tokenized payment data. Because the vault is yours rather than a processor's, changing processors is a routing change instead of a re-tokenization project.
Tokenization	Replacing payment account data with a non-reversible token that can stand in for it in transactions. Reduces your PCI scope. See Tokenization.

Payment data on a transaction


AVS	Address Verification Service — checks the billing address supplied against the one the card issuer holds. See AVS.
BIN	Bank Identification Number — the first 4 to 11 digits of a card number, identifying the brand, type, and issuing bank. See BIN Rule.
CVV	Card Verification Value — the security code on the card. Never stored in a multi-use token, per PCI rules. See CVV.
Level II / Level III data	Additional purchase detail (tax amounts, line items, and more) sent with commercial-card transactions to qualify for lower interchange. See Level II Data.
Metadata	Your own flat key/value data attached to a transaction — order references, internal IDs. Stored by Preczn, returned to you, and forwarded where the processor supports it. See Metadata.
Statement descriptor	The text a cardholder sees for the charge on their statement. Sending it per transaction requires the processor to support and enable dynamic descriptors. See Dynamic Statement Descriptors.

Routing


BIN rule	Routes a transaction based on the card's BIN. See BIN Rule.
Card brand rule	Routes a transaction based on the card brand. See Card Brand Rule.
Currency rule	Routes a transaction based on its currency. See Currency Rule.
Distribution rule	Splits transactions across connections by percentage, measured by currency volume or transaction count. Applied to every new plan by default. See Distribution Rule.
Order rule	Routes to connections in a priority order you set. See Order Rule.
Plan	The routing configuration assigned to a merchant, made up of one or more rules. Assigning a plan lets Preczn pick the connection; without one, name the connection on each request. ID prefix `plan_`. See Plans Overview.
Reject salvage rule	Re-runs a declined transaction against the merchant's other connections. See Reject Salvage Rule.
Rule	One routing decision within a plan. Multiple rules run in priority order. See Routing Rules.
`processor` field	Names a connection directly on a transaction request, bypassing the plan's rules. The connection must still be part of the merchant's assigned plan. See Transaction Routing.

Integration methods


Direct API	Server-to-server integration. Your systems receive and transmit raw cardholder data, which carries the most extensive PCI obligations of the three options. See Direct API Integration.
PaymentElements	Each card input rendered by Preczn inside its own iframe from Preczn's origin, styled through a sanitized style API. The PAN never enters your page or servers — the narrowest PCI scope. See PaymentElements Integration.
PaymentFields	You render your own checkout markup and tag inputs with `data-preczn` attributes; a Preczn library reads and tokenizes them on submit. Card data bypasses your servers but is present in your page. See PaymentFields Integration.

Developer platform


API key	Credentials authenticating every API request. Each key has a type (public for client-side tokenization, private for server-side calls) and a mode. Prefixes `pub_`, `priv_`, `pub_test_`, `priv_test_`. See API Keys.
Event type	The string naming what happened, such as `transaction.approved`, used in a subscription's `events` list. Full catalog in Webhooks.
Idempotency key	A value sent in the `Idempotency-Key` header so a retried request cannot create a duplicate. Strongly recommended on all transaction requests. See Idempotency Key Support.
Live mode	Your production environment. See test mode.
Object ID prefix	The short prefix at the start of every Preczn ID identifying the object's type, with a `_test_` variant in test mode. Full list in Object ID Prefixes.
Test mode	A fully isolated environment alongside live mode, toggled in the Dashboard. Merchants, connections, plans, rules, transactions, and API keys are all mode-specific; there is no separate sandbox. See Live vs Test Mode.
Webhook	A signed `POST` Preczn sends to your endpoint when a subscribed event occurs, so you don't have to poll. See Webhooks.
Webhook attempt	One delivery try against your endpoint, recorded and retained for 15 days. ID prefix `what_`. See Delivery, Retries, and Failures.
Webhook subscription	Your registered endpoint URL plus the events it should receive. Scoped to one platform and one mode. ID prefix `wh_`. See Subscribing to Webhooks.

Lending


B2B2C loan	A loan originated for a merchant's customer and drawn down to pay the merchant — for example, a homeowner financing a renovation. See B2B2C Loans.
Drawdown	A transaction type that uses funds made available by a loan agreement, drawn in stages rather than disbursed upfront. See Loan Transactions.
Loan	A loan record held by Preczn for status and balance over the life of the loan. ID prefix `loan_`. See Loan Updates.
Loan token	A token representing a loan, used the way a card token is used — to run drawdown transactions against it. Created at origination, or by tokenizing an existing loan. See Tokenizing Loans.

Compliance


PCI DSS	Payment Card Industry Data Security Standard — the card networks' security requirements for handling cardholder data.
PCI DSS Level 1	The highest PCI DSS validation tier, requiring annual assessment by a QSA. Preczn's token vault is validated at Level 1. See Preczn Data Security.
PCI scope	The parts of your environment that fall under PCI DSS assessment. Driven by where cardholder data exists, which is what separates the three integration options. See Integrations.
QSA	Qualified Security Assessor — an assessor certified to validate PCI DSS compliance. Your SAQ eligibility is determined by your processors or QSA against your full environment, not by your Preczn integration alone.
SAQ	Self-Assessment Questionnaire — the PCI DSS validation document a merchant completes. Preczn supports creating, signing, tracking, and transmitting them. ID prefix `saq_`. See SAQ Management Overview.
SAQ Type A	The SAQ for e-commerce merchants with card-not-present processing, and the type Preczn currently supports (PCI DSS 4.0.1).

ℹ️ Missing a term?

If something in the documentation isn't defined here, it belongs here. Let us know and we'll add it.