Transaction Tagging & Reporting Fields

Transaction tagging fields let you organize, search, and reconcile your payments in reporting. Consistent field population across your integration significantly reduces the time you spend on reconciliation and the number of support questions your team handles.

These fields are supported on every integration method — Direct with Embedded Tokenization, Customized Checkout, and Embedded Components — and work the same way across all three.

If you need to distribute funds across multiple merchants rather than categorize a single transaction, see Transfers and Splits.

Field Overview

SportsPay supports two kinds of tagging fields:

Searchable fields appear on every transaction record in PaymentsHQ. You can search, filter, and group by them.

  • INV — Invoice number. Groups related transactions.
  • REF — Reference number. Uniquely identifies a single transaction within a batch.
  • DESC — Description. Human-readable label.

Categorical fields power Deposit Report rollups, letting you split a single transaction into reconciliation categories.

  • PROGRAM — by program or fee type
  • PLAYER — by participant
  • ACCOUNT — by accounting category
FieldPurpose
INVGroups related transactions (sale + refund, declined + retry, installments)
REFUniquely identifies a single transaction
DESCHuman-readable label for reporting and receipts
PROGRAMCategorizes by program or fee type (Registration, Jersey, Tournament)
PLAYERCategorizes by participant
ACCOUNTCategorizes by accounting category (Operating, HST, Savings)

Searchable Fields

INV — Invoice Number

INV groups correlated transactions together. Multiple transactions can share the same INV — think of it as a tag, not an identifier.

Use the same INV across:

  • A sale and any refunds against it
  • A declined sale and its subsequent retries
  • All installment payments for a single registration (along with the SCHEDID)

Your platform controls the INV format. Consistency matters more than any specific scheme — pick an approach (registration ID, order number, membership ID) and stick with it.

REF — Reference Number

REF must be unique for every transaction request within a batch. Unlike INV, REF identifies a single transaction and is what you use to:

  • Look up a specific transaction in reporting
  • Reconcile a payment against your internal records
  • Reference the original transaction when issuing a Void, Refund, or Refund Void

DESC — Description

DESC is a free-text, searchable field that shows up in reporting and on the payment page for hosted methods. Use it to give human readers context:

  • "Fall Soccer Registration"
  • "U13 Boys — Jersey Fee"
  • "Installment 2 of 3"

Categorical Fields

PROGRAM, PLAYER, and ACCOUNT let you split a single transaction into multiple categories for reconciliation in the Deposit Report. All three:

  • Are optional — include any combination, or none.
  • Are independentPROGRAM rollups don't affect PLAYER rollups, and so on.
  • Accept multiple entries per transaction.
  • Handle partial totals by automatically assigning the remainder to a fallback category (see "Handling Partial Totals" below).

PROGRAM — by Program or Fee Type

Each PROGRAM entry includes a Name and an AMT.

JSON

{
  "PROGRAM": [
    { "Name": "Registration Fee", "AMT": "150.00" },
    { "Name": "Jersey Fee",       "AMT": "50.00"  }
  ]
}

Tag/value

PROGRAM=[Name=Registration Fee&AMT=150.00][Name=Jersey Fee&AMT=50.00]

PLAYER — by Participant

Each PLAYER entry includes an id (name or internal identifier) and an AMT.

JSON

{
  "PLAYER": [
    { "id": "Sarah Smith", "AMT": "100.00" },
    { "id": "Jake Smith",  "AMT": "100.00" }
  ]
}

Tag/value

PLAYER=[id=Sarah Smith&AMT=100.00][id=Jake Smith&AMT=100.00]

ACCOUNT — by Accounting Category

Each ACCOUNT entry includes a DESC and an AMT.

JSON

{
  "ACCOUNT": [
    { "DESC": "Operating Account", "AMT": "185.00" },
    { "DESC": "HST",               "AMT": "15.00"  }
  ]
}

Tag/value

ACCOUNT=[DESC=Operating Account&AMT=185.00][DESC=HST&AMT=15.00]

Handling Partial Totals

If the sum of entries doesn't match the transaction amount, the gateway automatically assigns the remainder to a fallback category:

  • PROGRAM and PLAYER remainder → "Uncategorized"
  • ACCOUNT remainder → "Unassigned"

Example: a $200.00 transaction with PROGRAM=[Name=Registration Fee&AMT=150.00] (only $150 categorized) appears in the Deposit Report as:

ProgramAmount
Registration Fee$150.00
Uncategorized$50.00

This lets you categorize the portions you know and leaves a trail for the rest — but for cleanest reporting, categorize the full transaction amount.

Recommended Usage

FieldBest populated with
INVRegistration ID, order number, or another identifier that stays stable across related transactions
REFUnique transaction identifier from your system — receipt number, internal transaction UUID, or a generated unique reference
DESCShort, human-readable label the merchant and customer will understand
PROGRAMFee categories (Registration, Jersey, Tournament, Membership)
PLAYERIndividual participants covered by the transaction, with names or participant IDs
ACCOUNTAccounting-side allocations (Operating, HST, Savings, Scholarship Fund)

For field formats (max length, allowed characters, decimal precision), see the API Reference.