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.
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.
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 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
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
The high-level tokenization flow looks like this:
- Your backend creates a JWT using API keys
- Your backend exchanges the JWT for a session token
- The browser initializes a payment session using the session token
- The hosted iframe collects sensitive payment data
- NPS returns a token and token metadata to the browser
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 iframe is the only supported way to tokenize payment credentials.
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
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.
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
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
- 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