This document defines the shared standards and conventions used across all Nelnet Payment Services (NPS) APIs.
It is intended for technical integrators and describes how NPS APIs behave consistently, regardless of the specific service (Payments, Tokenization, Risk, Notifications, etc.).
Key idea:
NPS APIs favor consistency and predictable behavior to make integrations easier to build and maintain.
NPS APIs favor consistency and predictable behavior to make integrations easier to build and maintain.
Across all services, you can expect:
- REST-oriented endpoints
- JSON request and response bodies
- Explicit, documented field names
- Stable response structures
- Clear separation between authentication, context, and behavior
All production API traffic is sent to:
https://api.nelnetpay.comA non-production environment is available for testing:
https://api.uat.nelnetpay.comAll API requests must include the following headers.
| Header | Description |
|---|---|
Content-Type: application/json | Required for all requests with a body |
Authorization: Bearer <JWT> | JWT created using API keys |
- NPS APIs use Bearer token authentication
- JWTs are created server-to-server using API keys
- JWTs are passed in the
Authorizationheader
Reminder:
Session tokens are used only by browser-based SDKs and must never be sent to backend APIs.
Session tokens are used only by browser-based SDKs and must never be sent to backend APIs.
| Method | Usage |
|---|---|
GET | Retrieve resources |
POST | Create resources or initiate actions |
PUT | Replace an existing resource |
PATCH | Partially update a resource |
DELETE | Remove a resource |
| Status Code | Meaning |
|---|---|
200 OK | Request succeeded |
201 Created | Resource created |
202 Accepted | Request accepted for processing |
400 Bad Request | Validation or request error |
401 Unauthorized | Authentication failed |
403 Forbidden | Insufficient permissions |
404 Not Found | Resource not found |
409 Conflict | State conflict |
500 Internal Server Error | Unexpected server error |
All NPS APIs return errors using a shared structure.
{
"result": {
"status": "ERROR"
},
"error": {
"code": 123,
"messages": [
{
"message": "A human-readable error message"
}
]
}
}| Type | Format |
|---|---|
| Date | YYYY-MM-DD |
| DateTime | ISO 8601 UTC |
| Type | Convention |
|---|---|
| Currency | Decimal (no floats) |
| Percentages | Decimal |
| IDs | Integer or string |
- Uppercase snake case
- Clients should tolerate new values
- API URLs do not include a version by default
- Versioning is explicit when required
- Strategy is evolving and will be communicated ahead of changes
- Consistent REST conventions across services
- Canonical error response structure
- Predictable field formats
- Explicit authentication model