Transaction Tagging & Reporting Fields

SportsPay provides several fields that can be used to tag transactions for reporting and reconciliation. Using these fields consistently makes it significantly easier for merchants to match transactions in PaymentsHQ and for your platform to reconcile records.

Field Overview

Invoice Number (INV)

INV groups related transactions together. Merchants use this field in PaymentsHQ to find and match transactions to a registration or order.

Key rules:

• A sale and its refund should share the same INV
• A declined transaction and the subsequent approved retry should share the same INV
• All installment payments for the same registration should share the same INV

How you structure INV values is up to your platform. The important thing is that related transactions are grouped consistently so merchants can view the full payment history for a registration in one place.

Reference Number (REF)

REF uniquely identifies a single transaction. Unlike INV, which groups transactions, REF must be different for every request.

Use REF when you need to look up or reconcile a specific transaction.

Description (DESC)

DESC is a free-text, searchable label that appears alongside the transaction in reporting. It gives merchants context at a glance.

Examples: "Fall Soccer Registration", "Jersey Fee", "Instalment 2 of 3"

Program, Player & Account

PROGRAM, PLAYER, and ACCOUNT are optional structured fields that appear in the Deposit Report, allowing merchants to reconcile deposits with greater granularity. A single transaction can include multiple entries for each field.

They are independent of one another — you can use any combination, or none at all.

PROGRAM

Breaks down a transaction by program or fee type.

Each entry includes:

• Name – Program or fee description
• AMT – Dollar amount for that program

Example: A $200 registration broken down by fee type:

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

If the total of all PROGRAM AMT values is less than the transaction amount, the remainder is automatically assigned to an Uncategorized entry.

PLAYER

Breaks down a transaction by player or participant.

Each entry includes:

• id – Player identifier (name or internal ID)
• AMT – Dollar amount attributed to that player

Example: A $200 transaction covering two players:

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

If the total of all PLAYER AMT values is less than the transaction amount, the remainder is automatically assigned to an Uncategorized entry.

ACCOUNT

Breaks down a transaction by internal accounting category, such as tax allocations or bank account destinations.

Each entry includes:

• DESC – Description of the account category
• AMT – Dollar amount attributed to that category

Example: A $200 transaction split across accounting categories:

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

If the total of all ACCOUNT AMT values is less than the transaction amount, the remainder is automatically assigned to an Unassigned entry.

Recommended Usage

Populating these fields consistently on every transaction gives merchants the best possible reporting experience and reduces reconciliation support requests.

For full parameter details and constraints, see Parameter Descriptions.