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 typePLAYER— by participantACCOUNT— by accounting category
| Field | Purpose |
|---|---|
INV | Groups related transactions (sale + refund, declined + retry, installments) |
REF | Uniquely identifies a single transaction |
DESC | Human-readable label for reporting and receipts |
PROGRAM | Categorizes by program or fee type (Registration, Jersey, Tournament) |
PLAYER | Categorizes by participant |
ACCOUNT | Categorizes 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 independent —
PROGRAMrollups don't affectPLAYERrollups, 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:
PROGRAMandPLAYERremainder →"Uncategorized"ACCOUNTremainder →"Unassigned"
Example: a $200.00 transaction with PROGRAM=[Name=Registration Fee&AMT=150.00] (only $150 categorized) appears in the Deposit Report as:
| Program | Amount |
|---|---|
| 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
| Field | Best populated with |
|---|---|
INV | Registration ID, order number, or another identifier that stays stable across related transactions |
REF | Unique transaction identifier from your system — receipt number, internal transaction UUID, or a generated unique reference |
DESC | Short, human-readable label the merchant and customer will understand |
PROGRAM | Fee categories (Registration, Jersey, Tournament, Membership) |
PLAYER | Individual participants covered by the transaction, with names or participant IDs |
ACCOUNT | Accounting-side allocations (Operating, HST, Savings, Scholarship Fund) |
For field formats (max length, allowed characters, decimal precision), see the API Reference.
Updated 12 days ago
