Transaction Types

Direct with Embedded Tokenization supports a full set of transaction types for processing payments, authorizing funds, issuing refunds, and managing the daily batch. Each transaction is identified by a single-letter TYPE value.

For field formats, see the API Reference. For the full request/response field list, see Parameter Descriptions.

Quick Reference

TransactionTYPEDescription
SaleSStandard purchase — authorize and capture in one step
Auth OnlyAAuthorize funds without capturing (held for later)
Force PostFCapture funds for a previously approved Auth Only
Pre-AuthorizationPPlace a hold for an estimated amount
CompletionCSettle a Pre-Auth for the final amount
VoidVCancel an unsettled transaction
RefundRReturn funds to the cardholder
Refund VoidMCancel an unsettled refund
TokenizeKStore a card as a permanent token without charging it
SettlementDClose the batch and deposit funds

📘

Related transaction types

The following types exist but are documented separately:

  • Z — CheckUserFee queries the fee for a given amount before running the sale. See the CustomerPay / User Fee guide.
  • B — Batch List and L — Lookup are reporting operations covered under Transaction Query.

Standard Payment

Sale

TYPE=S — Authorize and capture a payment in one step. This is the most common transaction type.

Required fields

Optional fields

  • USERFEE — required if the merchant is CustomerPay-enabled
  • PLATFEE, PLATCHRG, PLATFORM
  • CUSTNAME, CUSTEMAIL, ZIP, CUSTID, INV, DESC

Example

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID": "your_termid",
    "PASS":   "your_pass",
    "TYPE":   "S",
    "AMT":    "125.00",
    "REF":    "102512003",
    "TOKEN":  "4200HDETSHGT0042",
    "JSON":   "Y"
  }'

The response returns a permanent TOKEN that can be stored and used for future charges.

Authorization and Capture

Authorization and capture is a two-step flow: the authorization places a hold on the card, and the capture claims the funds. SportsPay supports two variants: Auth Only / Force Post and Pre-Authorization / Completion.

Auth Only

TYPE=A — Authorize funds without capturing. The hold is placed on the card but no funds are moved until you issue a Force Post.

Use Auth Only when you know the exact amount up front but want to delay the capture — for example, confirming funds are available before fulfilling a registration.

Required fields

  • TERMID, PASS, TYPE=A
  • AMT
  • REF
  • TOKEN

The response includes an AUTH (authorization number) you'll need when posting the Force Post.

Force Post

TYPE=F — Complete an Auth Only by capturing the previously authorized amount.

Required fields

  • TERMID, PASS, TYPE=F
  • AMT
  • REF — the same reference you used on the Auth Only
  • AUTH — the authorization number returned by the Auth Only
  • TOKEN

Pre-Authorization

TYPE=P — Place a hold for an estimated amount that you'll finalize later with a Completion.

Use Pre-Authorization when the exact amount isn't known up front — for example, holding funds for a tournament entry that may incur additional fees.

Required fields

  • TERMID, PASS, TYPE=P
  • AMT — estimated amount
  • REF
  • TOKEN

Completion

TYPE=C — Settle a Pre-Authorization for the final amount, which may differ from the estimate.

Required fields

  • TERMID, PASS, TYPE=C
  • AMT — final amount
  • REF — the same reference you used on the Pre-Authorization
  • TOKEN

Reversing Transactions

Void

TYPE=V — Cancel an unsettled transaction (one that hasn't been included in a closed batch yet). Voids are the cleanest way to reverse a transaction because they don't produce a refund record.

If the transaction has already settled, use Refund instead.

Required fields

  • TERMID, PASS, TYPE=V
  • REF — the reference of the transaction to void

Refund

TYPE=R — Return funds to the cardholder for a previously settled transaction. Unlike a void, a refund produces a separate transaction record.

Required fields

  • TERMID, PASS, TYPE=R
  • AMT — amount to refund (can be partial)
  • REF — a new reference for this refund transaction
  • TOKEN — the permanent token of the card being refunded

Refund Void

TYPE=M — Cancel a refund that hasn't settled yet. Same idea as Void, but for a refund transaction.

Required fields

  • TERMID, PASS, TYPE=M
  • REF — the reference of the refund to cancel

Tokenization

Tokenize

TYPE=K — Convert a One-Time Token into a permanent token without charging the card. Use this when you want to save a card for future use without processing a transaction up front (for example, collecting a card during registration and charging it later when fees are assessed).

Required fields

The response returns a permanent TOKEN you can store and use for future Sale, Auth, Pre-Auth, or Refund transactions.

Batch Operations

Settlement

TYPE=D — Close the current batch and deposit the funds. Most terminals are configured to auto-settle at a scheduled time (see the AUTOSETTLE and MIDNIGHT BATCH settings in Production). Use this only when you need to force a manual settlement outside the scheduled window.

Required fields

  • TERMID, PASS, TYPE=D

The response includes batch totals and count.

Response Fields

All transaction responses include:

  • CODE — four-digit response code. 0000 = approved; anything else is a decline or error.
  • TEXT — human-readable message. For approvals, includes the authorization number and approved amount.
  • AUTH — authorization number from the card network (approved transactions only).
  • HASH — card data hash for deduplication (when card data is processed).
  • TOKEN — permanent token (when card data is processed).
  • GATEREF — globally unique gateway reference (approved financial transactions only).
  • DATE, TIME, DUR — standard envelope fields.

For the full response field catalog, see Parameter Descriptions.

CustomerPay and Platform Billing

Not all transaction types support every fee type:

USERFEEPLATFEEPLATCHRG
Sale
Auth Only
Force Post
Pre-Authorization
Completion
Void
Refund
Refund Void
Tokenize
Settlement

Fees only apply to transactions that actually charge or refund the card. See CustomerPay and Platform Billing for the fee contracts.


Did this page help you?