Skip to content
/
Credit Card Transactions
Last updated

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

Key idea:
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 TypeDescriptionNotes
VERIFYPerforms a zero‑amount transaction to validate card details.No funds are authorized or captured.
AUTH_ONLYAuthorizes funds without capturing for settlement.Requires a subsequent CAPTURE.
CAPTURESubmits a previously authorized transaction for settlement.References the original AUTH_ONLY.
SALEAuthorizes and captures funds in a single step.Most common card transaction type.
VOIDCancels an unsettled transaction.Must occur before settlement.
REFUNDReturns funds to the cardholder after settlement.Reference refunds are recommended.

Card Verification (AVS & CVV)

Key idea:
AVS and CVV checks can be performed during VERIFY, AUTH_ONLY, and 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.

Common reasons:
  • Service fee models
  • Manual review or fraud screening
  • Shipping‑based workflows
  • 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
{
  "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
{
  "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.

  • References the original transaction
  • Ensures processor compatibility
  • Maintains transaction lineage
{
  "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
Important:
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.

Examples:
  • VERIFY → SALE
  • AUTH_ONLY → CAPTURE
  • SALE → VOID
  • SALE → REFUND

Storing transaction IDs is critical for refunds, voids, reporting, and reconciliation.

Best Practices

  • Prefer SALE unless delayed settlement is required
  • Always store paymentTransactionId
  • Void transactions whenever possible instead of refunding
  • Use reference refunds whenever available
  • 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
Previous page
Next page