Tokenization

Tokenization (also known as Card On File) is a secure way to store payment account information (credit card numbers, or bank account and routing numbers) with Preczn.
The resulting token can be used in future transactions instead of sensitive payment account information.

Tokenization Use Cases

Tokenization's primary purpose is securely encoding cardholder payment data, while also making that data available for use in transactions in the form of a non-relational token.

Unlike encryption, tokenization is irreversible.

Tokenization protects cardholder information such as credit card numbers, bank account numbers, and PINs from being compromised during transactions. Implementing tokenization results in drastically reduced risks in handling payment account data, and a reduction in your platform's PCI scope.

Tokenization uses include:

• Secure payment processing: By replacing sensitive data with a unique token, tokenization can prevent fraud and unauthorized access to payment information during the transaction process. This helps to ensure that customers' payment information is kept safe and secure.
• Recurring payments: Tokenization can be used to streamline recurring payments. The token can be used to securely store payment information, so that future transactions can be processed without the need for the customer to re-enter payment details.
• Faster checkout: Tokenization can speed the checkout process by allowing customers to save their payment information securely, enabling them to complete transactions more quickly, and reducing abandoned carts.

The Preczn Token Vault: Your Payment Data, Any Processor

Preczn tokenizes payment data into a PCI-DSS Level 1 compliant token vault. Payment data enters the token vault from multiple sources, and from there it can be transacted in two ways: Preczn runs the transaction to a processor on your behalf, or Preczn pushes the card to a third-party processor that tokenizes it so you can transact directly.

This decouples where a card is stored from who processes it. You store once with Preczn, then choose the model that fits each processor, geography, or integration.

---
title: Preczn Token Vault
---
flowchart TB
    subgraph sources["Payment Data In"]
        direction LR
        import["Import from prior<br/>provider or vault<br/>(bulk migration)"]
        sdk["Cardholder entry via<br/>Preczn SDKs<br/>(PaymentFields)"]
    end

    vault[("Preczn Token Vault<br/>PCI-DSS Level 1")]

    tokenAtPsp["Token created<br/>at the PSP"]
    psp["Payment processors<br/>Stripe · Adyen · Fiserv · …"]

    import ==> vault
    sdk ==> vault

    vault ==>|"Method 1<br/>Preczn runs the transaction"| psp
    vault ==>|"Method 2<br/>Third-party tokenization"| tokenAtPsp
    tokenAtPsp ==>|"SaaS transacts directly"| psp

    classDef vaultStyle fill:#5128D1,stroke:#3A1C9E,color:#fff,font-weight:bold
    classDef ioStyle fill:#EEF2FF,stroke:#5128D1,color:#1E1B4B
    class vault vaultStyle
    class import,sdk,tokenAtPsp,psp ioStyle

How payment data enters the token vault

• Migration / import — Card data exported from a prior service provider or vault is imported directly into the Preczn token vault via Token Import. Preczn becomes the system of record for that payment data.
• SDK capture — Cardholders enter card details through Preczn's SDKs (PaymentFields), which land the data straight in the token vault so your systems never touch raw PAN.

Two ways to transact from the token vault

Method 1 — Preczn-initiated transactions. Payment data stays in the Preczn token vault, and Preczn initiates transactions to your configured processor(s) on demand. The processor receives a transaction request backed by vaulted payment data — it does not store or tokenize the card on its side. This is the model to use when you want a single token vault serving one or many supported processors.

Method 2 — Third-party tokenization. Preczn pushes the card to the destination processor, which creates a token at the PSP. The vertical SaaS company then runs transactions directly with the PSP rather than through Preczn. Use this when the SaaS wants to own the processing relationship and transact against a processor-native token.

Token Scope

Preczn supports token ownership at both the merchant and platform levels.

Merchant-level ownership means that the individual merchant has their own set of tokens that are specific to their business. Merchant scoped tokens also ensure that any issues or errors with tokenization are contained within that specific merchant rather than affecting an entire platform.

Platform-level ownership, on the other hand, means that the tokens are owned and managed by the platform, with tokens shared among all merchants. This model offers simplicity and ease of use.

Multi-Use Tokens

The Preczn API returns multi-use tokens, when requested, along with the response of a successfully approved transaction.

• A credit card token represents a card number and expiration date
• A token will only be generated upon an approved Sale or Auth transaction. A declined transaction will never generate a token
• Multi-use tokens are permanent and never expire, although a token's lifespan is still subject to its card's expiration date
• Tokens are platform-bound. The same payment account details used for transactions on different platforms will generate different tokens. The same payment account details for different merchants belonging to the same platform will return the same token.

Multi-Use Token Request via API Integration

To request a multi-use token to be returned, append the URL query parameter ?tokenize=true to either an Auth or Sale transaction request.
If the transaction is approved, a token will be returned with the transaction response in the payment.token response field.

Use a token to process a transaction:

All tokens are used in place of payment account details when making an API request to process a transaction.

Simply set the payment.token property of the request to the token you wish to use in the transaction:

"payment": {
  "token": "tkn_5ptw6a9dd8brzz5qw2b7xqkt1"
}

See the Process Transaction endpoint for more details

Single-Use Tokens

Single use tokens typically originate from a customer-facing user interface where the goal is to tokenize account information prior to authorizing a transaction. This prevents sensitive payment account information from being transmitted or stored by your software and servers.

The Preczn API provides single-use tokens which can be securely obtained using PaymentFields, helping to reduce the PCI scope of your software!