Transaction Lifecycle

Standard and Tokenized Transactions

Understanding the transaction lifecycle is critical to building a robust payment integration. Depending on your business model, you may need to capture funds immediately, place holds on customer cards, or save payment methods for future billing.

This guide explains the flow of both Standard (One-Off) transactions and Tokenized transactions.


Part 1: Standard (One-Off) Transactions

Standard transactions involve passing raw cardholder data to the gateway to perform a single, immediate action. These are typically divided into Standalone flows and Two-Pass flows.

Standalone Transactions

These are single-step API calls that complete a full action on their own.

  • Purchase / Sale (Type 00): The most common transaction type. It authorizes the card and flags the transaction for immediate capture in the next settlement batch.
  • Void (Type 13): Cancels a transaction before it settles (usually the same day). Requires the Authorization_Num from the original Sale.
  • Refund (Type 04): Returns funds to a customer after the original transaction has settled.

Two-Pass Transactions (Auth & Capture)

If you need to verify funds before fulfilling an order (like a hotel hold or a delayed shipment), you will use a two-pass flow.

  1. Pre-Authorization (Type 01): Contacts the issuing bank to verify the card is valid and places a hold on the specified funds. This does not move any money.
  2. Pre-Auth Completion (Type 02): Once the service is rendered or the physical good is shipped, this second API call flags the original pre-authorization to be captured and settled in the next batch.

Part 2: Tokenized Transactions

If you process recurring billing, subscriptions, or offer a "card on file" experience, you must use tokens to keep your application out of PCI scope.

The tokenized lifecycle separates the storage of the card from the processing of the card.

1. Token Creation (Types 40,41,60)

Recurring Seed (Type 40) A pre-authorization transaction that creates a token for later use.

  • Validates the data format locally at the gateway, securely stores the card, and returns a Gateway Token.
  • Validates the card and confirms there are sufficient funds with the card issuer.

Recurring Seed Purchase (Type 41) A purchase transaction that simultaneously creates a token for later use.

  • Validates the data format locally at the gateway, securely stores the card, and returns a Gateway Token.
  • Validates the card and confirms there are sufficient funds with the card issuer.
  • Processes a Payment

Secure Storage Tokenization (Type 60) functions similarly to a seed pre-auth, but with one major difference: it does not send a request to the issuer for authorization. * It is purely a vaulting transaction.

  • Validates the data format locally at the gateway, securely stores the card, and returns a Gateway Token.
  • Note: Because it does not contact the issuing bank, it does not check for sufficient funds or active card status.

2. Processing with Tokens (30,31,32,33,34)

Once a token has been generated, execute a follow-on transactions using the 30,31, or 32 transaction types. Instead of passing a Card_Number and Expiry_Date, you pass the Transaction_Tag and the original Authorization_Num.

The 3X Series: Token Purchases & Adjustments

Use the 3X series for immediate capture and standard adjustments using a saved token.

  • Tagged Purchase (Type 30): Authorizes and immediately captures funds using the vaulted token. Multiple tagged purchases can be made from one existing seed transaction.
  • Tagged Pre-Auth (Type 31): Authorizes and places a hold on the card using the vaulted token.
  • Tagged Pre-Auth Completion (Type 32): Sends a request for held funds from a Tagged Pre-Auth 31 to be charged as a sale. Only one Tagged Completion is permitted per Recurring Seed or Pre-Authorization.
  • Tagged Void (Type 33): Cancels an unsettled Token Sale (30) or Token Refund (34).
  • Tagged Refund (Type 34): Refunds a settled Tagged Purchase .

What's Next?

Now that you understand the lifecycle, check out our Recipes to see the exact JSON payloads and code snippets required to execute these transactions:

  • [Recipe: Process a Standard Sale]
  • [Recipe: Issue a Refund or Void]
  • [Recipe: Generate a Secure Token (Type 60)]