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

📘

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

• TERMID, PASS, TYPE=S
• AMT
• REF
• TOKEN — an OTT from Embedded Tokenization or a stored permanent token

Optional fields

• USERFEE — required if the merchant is CustomerPay-enabled
• PLATFEE, PLATCHRG, PLATFORM
• CUSTNAME, CUSTEMAIL, 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

• TERMID, PASS, TYPE=K
• TOKEN — an OTT from Embedded Tokenization

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:

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