Transaction Types (API & HCO)

The specific action performed by the gateway is controlled by the transaction_type property in your API request.

Transactions fall into two categories:

Standard Transactions: Standalone actions requiring a full card number (PAN).
Tagged Transactions: Actions that reference a previous transaction ID (Tag) instead of a card number.

API - Standard Transactions

These are the most common transaction types used for one-time payments or processing a card for the first time.

Code	Type	Description	Compatible With
`00`	Purchase	Immediate sale. Charges the card and settles the funds at the end of the day.	API, HCO, POS
`01`	Pre-Authorization	Reserves funds on the cardholder’s account for 2-5 days without charging them. Must be completed later via a Completion (02).	API, HCO, POS
`02`	Pre-Auth Completion	Completes (captures) an existing pre-authorization. Requires the `authorization_num` from the original `01` transaction.	API, POS
`13`	Void	Cancels a Purchase or Completion that has not yet settled (usually same-day).	API, POS
`03`	Forced Post	Captures a transaction that was authorized outside the system (e.g., via voice auth). Requires an existing Auth Code.	API, POS

🚧
Void vs. Refund
Use a Void (13) if the transaction happened today (before the batch closes). Use a Tagged Refund (34) if the transaction settled yesterday or earlier.

Standard Transactions rely on the card_number value

API - Tagged Transactions (Tokenization)

Tagged transactions allow you to process payments without handling sensitive card data. Simply reference the transaction_tag returned from a previous valid transaction.

Code	Type	Description
`40`	Recurring Seed	A $0.00 verification transaction used solely to generate a Tag for future use. Does not charge the customer.
`41`	Recurring Seed Purchase	Processes a standard Purchase and generates a Tag for future recurring billing.
`30`	Tagged Purchase	Charges a customer using a stored card (Tag). Equivalent to a "Purchase" but uses a Tag instead of a PAN.
`31`	Tagged Pre-Auth	Reserves funds using a stored card (Tag). Useful for checking validity or holding funds on a returning customer.
`32`	Tagged Completion	Captures a Pre-Authorization. Only one completion is allowed per Pre-Auth.
`33`	Tagged Void	Voids a pending transaction using its Tag.
`34`	Tagged Refund	Returns funds to a customer. References the original Purchase/Completion Tag to ensure funds go back to the same card.

📘
How Tagged Transactions Work

Initial Step: Send a 00 (Purchase) or 40 (Seed) with the credit card number.

Response: The gateway returns a unique transaction_tag (e.g. "2151699105"), and authorization_num (e.g. "ET110589")

Future Steps: For all future billing, you send a 30 (Tagged Purchase) with just the transaction_tag,authorization_num and amount. No credit card data is required.

Tagged Transactions rely on the transaction_tag value

Hosted Checkout (HCO) - Transaction Types

When integrating with Hosted Checkout (HCO) Payment Pages, the transaction type is dictated by the x_type parameter.

The following transaction types are supported for HCO integrations:

`x_type` Value	Description
`AUTH_CAPTURE`	Sale / Purchase: Authorizes and immediately captures the transaction amount in a single step.
`AUTH_ONLY`	Pre-Authorization: Authorizes the card for a specified amount and places a hold on the funds, but does not capture them for settlement.
`AUTH_TOKEN`	Token Creation: Secures and stores a customer's payment information to generate a payment token for future use.
`PURCHASE_TOKEN`	Token Sale: Processes a Payment, and, secures and stores a customer's payment information to generate a payment token for future use.