# Tokenization Overview

Tokenization is the foundation of secure payment processing in Nelnet Payment Services (NPS).
It ensures that **sensitive payment data is never exposed to merchant systems**, while still enabling flexible payment flows across cards, wallets, and ACH.

This page explains **how tokenization works**, **when it is required**, and **how it fits into the broader NPS architecture**.

## Core Concept

div
strong
Key idea:
br

  Sensitive payment data is collected securely in the browser and exchanged for a reusable NPS token.

Merchants never handle raw card numbers or bank account details directly.
Instead, they work with **NPS tokens**, which represent payment credentials safely and consistently.

## When Tokenization Is Required

### Credit Cards & Wallets (Required)

Tokenization is **required** for:

- Credit cards
- Apple Pay
- PayPal and Venmo


All of these payment methods must be tokenized using the **hosted payment iframe**.

There are no server-to-server alternatives for card or wallet token creation.

### ACH Payments (Recommended)

ACH is the one exception:

- Merchants may submit raw ACH account details directly to the Payments API
- NPS will **always tokenize the account internally**
- A token is returned in the payment response


div
strong
Recommendation:
br

  While not required, tokenizing ACH via the iframe is strongly recommended for consistency, reporting, and lifecycle updates.

Tokens created for ACH participate fully in:

- Reporting
- Payment Credential Lifecycle Management
- Returns and NOC handling


## Tokenization Flow (End-to-End)

The high-level tokenization flow looks like this:

div
ol
li
Your backend creates a JWT using API keys
li
Your backend exchanges the JWT for a 
strong
session token
li
The browser initializes a payment session using the session token
li
The hosted iframe collects sensitive payment data
li
NPS returns a token and token metadata to the browser
## Authentication & Sessions

div
strong
Key idea:
br

  JWTs authenticate servers. Session tokens authenticate the browser.

- **JWT**
  - Created server-to-server using API keys
  - Used to call NPS backend APIs
- **Session Token**
  - Derived from a JWT
  - Used only by the UI SDK and iframe
  - Short-lived and browser-scoped


Session tokens are never used for Payments API calls.

## The Hosted Payment Iframe

The hosted iframe is the **only supported way** to tokenize payment credentials.

### What the Iframe Does

Depending on the payment method, the iframe:

- Renders secure input fields for:
  - Credit card numbers
  - Bank account and routing numbers
- Embeds network SDKs and buttons for:
  - Apple Pay
  - PayPal and Venmo


In all cases:

- Sensitive data stays inside the iframe
- The browser receives an NPS token upon completion


## Returned Token & Metadata

At the end of tokenization, the browser receives:

- The **NPS token**
- Metadata describing the token, which may include:
  - Token type (PAN, network token, wallet token)
  - BIN information (cards)
  - Surcharge calculations (if configured)
  - Risk identifiers


This data can be passed from the browser to your backend using your own application logic.

## Fraud Controls & CAPTCHA

NPS applies fraud analytics during tokenization.

Depending on merchant configuration:

- Behavioral and device signals may be evaluated
- A CAPTCHA challenge may be presented inside the iframe


If enabled:

- The payer must complete the challenge before tokenization succeeds
- No additional integration work is required by the merchant


## Relationship to Payment Credential Lifecycle Management

div
strong
Note:
br

  Tokens created through this process automatically participate in Payment Credential Lifecycle Management.

This means:

- Card credentials may be transparently upgraded to network tokens
- Wallet and ACH credentials are kept current
- Tokens remain stable even as underlying credentials change


## Summary

- Tokenization protects sensitive payment data
- Credit cards and wallets must be tokenized using the iframe
- ACH tokenization is recommended and always performed internally
- JWTs authenticate servers; session tokens authenticate browsers
- Tokenization returns a token plus useful metadata
- Tokens participate in lifecycle management automatically