# Credit Card Payment Lifecycle & Transaction Types

This document describes **credit card–specific transaction types** in Nelnet Payment Services (NPS) and how they fit into the full payment lifecycle.

It covers:

- Authorization and settlement flows
- Verification behavior (AVS / CVV)
- Refunds and voids
- How transactions relate to one another over time


## The Credit Card Payment Lifecycle

div
strong
Key idea:
br

  Credit card transactions may authorize and settle in one step or across multiple steps.

At a high level, credit card payments move through these phases:

1. **Verification** – Optional validation of card details (AVS / CVV)
2. **Authorization** – Confirm funds are available
3. **Settlement** – Capture and move funds
4. **Post‑processing** – Voids and refunds


Not every transaction type uses every phase.

## Supported Credit Card Transaction Types

The following transaction types apply to **credit card payments**.

| Transaction Type | Description | Notes |
|  --- | --- | --- |
| **VERIFY** | Performs a zero‑amount transaction to validate card details. | No funds are authorized or captured. |
| **AUTH_ONLY** | Authorizes funds without capturing for settlement. | Requires a subsequent `CAPTURE`. |
| **CAPTURE** | Submits a previously authorized transaction for settlement. | References the original `AUTH_ONLY`. |
| **SALE** | Authorizes and captures funds in a single step. | Most common card transaction type. |
| **VOID** | Cancels an unsettled transaction. | Must occur before settlement. |
| **REFUND** | Returns funds to the cardholder after settlement. | Reference refunds are recommended. |


## Card Verification (AVS & CVV)

div
strong
Key idea:
br

  AVS and CVV checks can be performed during 
code
VERIFY
, 
code
AUTH_ONLY
, and 
code
SALE
 transactions.

### Address Verification Service (AVS)

- Validates the cardholder’s billing address
- Include:
  - `addressLine1`
  - `postalCode`
- Result returned in:
  - `processorResponse.avsResultCode`


### Card Verification Value (CVV2)

- Validates the card’s CVV value
- Include:
  - `paymentType.cardVerificationValue`
- Result returned in:
  - `processorResponse.cvvResultCode`


> **Important:** CVV values are PCI‑sensitive and must never be stored.


AVS and CVV checks may influence:

- Authorization approval
- Fraud scoring
- Merchant‑defined rules


## VERIFY: Zero‑Amount Card Validation

`VERIFY` performs a zero‑amount transaction to validate card details.

**When to use:**

- Card‑on‑file setup
- Account validation
- Fraud prevention prior to charging


Characteristics:

- No funds are authorized
- No settlement occurs
- AVS and CVV results are returned


## SALE: One‑Step Authorization and Capture

`SALE` authorizes and captures funds in a single request.

**When to use:**

- Standard e‑commerce payments
- Immediate fulfillment
- Most one‑time card charges


Characteristics:

- Authorization and settlement occur together
- AVS and CVV may be evaluated
- Returns a `paymentTransactionId` for future actions


## AUTH_ONLY and CAPTURE: Two‑Step Card Payments

Use `AUTH_ONLY` and `CAPTURE` together when authorization and settlement must be separated.

div
strong
Common reasons:
ul
li
Service fee models
li
Manual review or fraud screening
li
Shipping‑based workflows
li
Service or usage‑based billing
### AUTH_ONLY

- Confirms funds are available
- Does not move money
- AVS and CVV may be evaluated
- Returns a `paymentTransactionId`


### CAPTURE

- Completes settlement for a prior authorization
- Requires the original `paymentTransactionId`
- May be for the full or partial authorized amount



```json
{
  "transactionType": "CAPTURE",
  "paymentTransactionId": "80503dc9-15f8-430a-8622-3cff38124bbd",
  "amount": 123.65
}
```

## VOID: Canceling an Unsettled Card Transaction

A **void** cancels a transaction that has been authorized but not yet settled.

**When to use a void:**

- The transaction was approved recently
- Settlement has not yet occurred
- The charge should be fully canceled


Characteristics:

- References the original `paymentTransactionId`
- Amount is not required
- Partial voids are not supported



```json
{
  "transactionType": "VOID",
  "paymentTransactionId": "80503dc9-15f8-430a-8622-3cff38124bbd"
}
```

Once voided, the transaction cannot be captured or refunded.

## REFUND: Returning Funds to the Cardholder

A **refund** returns funds after a transaction has settled.

### Refund with Reference (Recommended)

- References the original transaction
- Ensures processor compatibility
- Maintains transaction lineage



```json
{
  "transactionType": "REFUND",
  "paymentTransactionId": "80503dc9-15f8-430a-8622-3cff38124bbd",
  "amount": 50.00
}
```

### Refund without Reference

- Used only when the original transaction ID is unavailable
- Not supported by all processors


div
strong
Important:
br

  Always use reference refunds when possible.

### Partial vs Full Refunds

- Full refund: equals original settled amount
- Partial refund: less than original amount
- Refund amounts must not exceed the settled total


## Transaction Relationships

Credit card transactions are linked using `paymentTransactionId`.

div
strong
Examples:
ul
li
code
VERIFY
 → 
code
SALE
li
code
AUTH_ONLY
 → 
code
CAPTURE
li
code
SALE
 → 
code
VOID
li
code
SALE
 → 
code
REFUND
Storing transaction IDs is critical for refunds, voids, reporting, and reconciliation.

## Best Practices

div
ul
li
Prefer 
code
SALE
 unless delayed settlement is required
li
Always store 
code
paymentTransactionId
li
Void transactions whenever possible instead of refunding
li
Use reference refunds whenever available
li
Test all transaction types in UAT
## Summary

- This document applies to **credit card payments only**
- AVS and CVV checks apply to VERIFY, AUTH_ONLY, and SALE
- SALE is the most common card transaction type
- AUTH_ONLY and CAPTURE support delayed settlement
- Voids cancel unsettled transactions
- Refunds return funds after settlement
- Adjustments are not supported