You save customers' cards and bank accounts for repeat purchases, subscriptions, or faster checkout. You might call the alternative to processor-held cards a portable vault, processor-agnostic tokenization, card on file, or "store once, charge anywhere". In Preczn, this is the token vault, part of Orchestrate.

If a processor holds your saved payment methods, adding or switching processors means a token export, if that processor allows one, or asking customers to re-enter their details.

Payment methods in the Preczn token vault aren't tied to a processor. The same Preczn token can be charged through any supported processor connection the merchant has, so adding or switching processors doesn't require new tokens. Tokens are bound to your platform. If you later want a processor to hold its own copy, token migration creates matching tokens at a supported destination processor. See Supported Connections.

Who this is for

---

• Platforms that save payment methods for recurring or repeat charges.
• Platforms that use, or expect to use, more than one processor.

You don't need this page in these cases:

• You only run one-time payments and never save a payment method. Use a single-use token from PaymentElements directly in a sale.
• You want to move cards from your current provider into Preczn. Start with Migrate merchants and stored payment methods from another processor.

When to use this

---

How it works

---

Preczn has two vaults. The token vault holds payment methods. The merchant vault holds business and onboarding data. This page concerns the token vault.

Payment methods enter the token vault in two ways: customers enter them through a Preczn SDK, or Preczn imports them from a previous provider. From the vault, a payment method can be used in two ways:

• Preczn runs the transaction. You send a Preczn token, and Preczn sends the transaction to a processor chosen by the merchant's plan or named on the request. You don't need a token from that processor to charge the payment method.
• The processor holds its own token. Preczn creates a matching token at a destination processor, and you transact with that processor directly. This is token migration, and some destinations, such as Nuvei, support only this.

The diagram shows payment methods entering the token vault and leaving it through either path.

flowchart LR
    SDK["PaymentElements<br/>or PaymentFields"] --> TV["Preczn token vault"]
    IMP["Token import"] --> TV
    TV -->|"Preczn token on a<br/>transaction request"| PLAN["Merchant's plan"]
    PLAN --> PA["Processor A"]
    PLAN --> PB["Processor B"]
    TV -->|"token migration"| PT["Token at a<br/>destination processor"]

Multi-use tokens don't expire, but they're still subject to the card's expiration date. The vault doesn't store CVV, so configure each processor's risk rules not to require CVV on later charges. See Tokenization.

🚧

Stripe needs raw card data access

Before Preczn can charge a vaulted card through a Stripe account, Stripe must enable raw card data APIs on that account. See Raw Card Data Access.

Prerequisites

---

• At least one connection that accepts transactions. See Supported Connections.
• Each merchant assigned to a plan, or your requests name a processor. See Assigning Merchants to Plans.
• A client-side capture integration. See Integrations to compare PaymentElements, PaymentFields, and the Direct API.

Outline

---

1. Choose a capture integration. PaymentElements is designed for the smallest PCI scope of the three options. Your processor or QSA determines your actual SAQ eligibility. See Integrations.
2. Capture the payment method. Exchange the customer's entry for a single-use token. See PaymentElements Integration.
3. Save it as a multi-use token. Send a sale, auth, or verify with ?tokenize=true. See Tokenization and Payment Transactions.
4. Store billing details with the token (optional). See Storing Billing Information.
5. Charge the token. Send the token in place of payment details, with the card-on-file context. See Card On File Flags.
6. Route the charge. Let the merchant's plan choose the processor, or name one. See Route Payments Across Providers.

Example

---

A membership platform for climbing gyms charges monthly dues to saved cards and wants to add a second processor next year without asking members to re-enter cards.

1. The platform renders PaymentElements on its signup page. When a member submits, it receives a single-use token.
2. It sends a verify with ?tokenize=true and stores the multi-use Preczn token against the member.
3. Each month, it sends a sale with the stored token and tokenUsage set to recurring. The gym's plan routes the sale to its current processor.
4. The next year, the platform boards the gym to the second processor and moves the gym to a plan that routes across both. Monthly dues now go to either processor, charged with the same stored tokens.

Related

---

How-to guides

• PaymentElements Integration
• Card On File Flags
• Storing Billing Information
• Assigning Merchants to Plans

Concepts and use cases

• Tokenization
• Integrations
• Payment Transactions
• Migrate merchants and stored payment methods from another processor
• Route Payments Across Providers

Reference

• Process Transaction
• Get Token
• Supported Connections