Transfers let funds move between SportsPay merchants. They cover two distinct use cases:

• Inter-Merchant Transfer — move funds from one merchant to another as an independent transaction (standalone operation).
• Splits — distribute a single payment across multiple merchants in one request, as part of a Sale or other charging transaction.

Both use cases share the same underlying transfer machinery. The difference is when the transfer happens: as its own call, or bundled into another transaction.

Common use cases include governing body fees, revenue sharing, multi-party registrations, and partner-fee collection.

Prerequisite: Merchants can only transfer to each other if they share a Transfer Group (TRANGP). Transfer Groups are configured on each terminal by SportsPay. To set up transfers between merchants, email [email protected].

Inter-Merchant Transfers

An Inter-Merchant Transfer moves funds from one merchant (the sender) to another (the receiver) as a standalone transaction. No Sale is involved — this is pure movement of funds between merchants that already share a Transfer Group.

For the full list of required and optional fields, see the Inter-Merchant Transfer API Reference.

Send a Transfer

Required parameters

• TERMID, PASS — credentials of the sending merchant
• TYPE=T — Transfer
• SUBTYPE=S — Send
• TRANGP — Transfer Group both merchants share
• RECV — Terminal ID of the receiving merchant
• AMT — transfer amount
• REF — unique reference number for this transfer
• MSG — short message shown on both merchants' reports

Example request

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID": "your_termid",
    "PASS":   "your_pass",
    "TYPE":   "T",
    "SUBTYPE":"S",
    "TRANGP": "BBALLCLUB",
    "RECV":   "NATLBODY",
    "AMT":    "200.00",
    "REF":    "xfer-20260412-001",
    "MSG":    "MEMBERSHIPFEE",
    "JSON":   "Y"
  }'

Reverse a Transfer

Use SUBTYPE=R to reverse a completed transfer. This credits the original sender and debits the original receiver.

Required parameters

• TERMID, PASS
• TYPE=T, SUBTYPE=R
• TRANGP
• ORIGREF — the REF of the original transfer being reversed
• MSG

Transfer Response

All transfer responses return the standard envelope:

• CODE — 0000 for approved, other codes for errors
• TEXT — APPROVED for success, or the error message
• DATE, TIME, DUR

Splits

Splits let you distribute a single payment across multiple merchants as part of a charging transaction. Each split within the request produces its own transfer record, but the entire set succeeds or fails together — if any split fails, the whole transaction is rejected.

The SPLIT field is a parameter on the transaction that carries it. For the full field reference, see the API Reference for the transaction type you're using — for example, the Sale API Reference if you're using Direct with Embedded Tokenization, or the StartSession API Reference if you're using Customized Checkout or Embedded Components.

Supported Transaction Types

Splits can be added to:

• Sale (TYPE=S)
• Refund (TYPE=R)
• Force Post (TYPE=F)
• Completion (TYPE=C)
• StartSession for both Customized Checkout and Embedded Components (TYPE=W, ACTION=StartSession)

Note: Splits cannot be added to payment Schedules.

The SPLIT Field

Include the SPLIT parameter on the transaction to trigger the distribution. Each split is wrapped in square brackets with ampersand-separated fields:

SPLIT=[TRANGP=...&RECV=...&AMT=...&REF=...&MSG=...][TRANGP=...&RECV=...&AMT=...&REF=...&MSG=...]

Important: When using JSON requests, the SPLIT field must be provided as a string using the bracket syntax above — not as a JSON array or object. The gateway parses the string directly.

Fields in each split entry

Reversing a Split

To reverse a split, send an Inter-Merchant Transfer Reversal (TYPE=T, SUBTYPE=R) using the split's original REF as the ORIGREF. Reverse each split independently if needed.

Response Behaviour

The response code describes the entire transaction, including all splits — it's all-or-nothing. If any split fails validation or processing, the entire Sale (or Refund, etc.) is rejected and no transfers are recorded.

Inter-Merchant Transfers vs Splits

Both approaches produce the same end result: funds distributed to multiple merchants. Pick based on timing and simplicity.

Worked Example

A parent registers their child with a local baseball club for $105.00. The fee is distributed like this:

Option 1 — Inter-Merchant Transfers (Four Calls)

Process the Sale to the Baseball Club, then send separate transfers to each recipient:

1. Sale of $105.00 to BASEBALLTID (TYPE=S)
2. Transfer $10.00 from BASEBALLTID to NATLBODY (TYPE=T&SUBTYPE=S, TRANGP=BBALLCLUB, MSG=MEMBERSHIPFEE)
3. Transfer $30.00 from BASEBALLTID to PROVBODY (MSG=UNIFORMFEE)
4. Transfer $5.00 from BASEBALLTID to REGPARTNER (MSG=WEBSITEFEE)

Option 2 — Splits (One Call)

A single Sale with three split entries handles the entire distribution:

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID": "BASEBALLTID",
    "PASS":   "your_pass",
    "TYPE":   "S",
    "AMT":    "105.00",
    "REF":    "reg-20260412-045",
    "TOKEN":  "4200HDETSHGT0042",
    "SPLIT":  "[TRANGP=BBALLCLUB&RECV=NATLBODY&AMT=10.00&REF=reg-045-nat&MSG=MEMBERSHIPFEE][TRANGP=BBALLCLUB&RECV=PROVBODY&AMT=30.00&REF=reg-045-prov&MSG=UNIFORMFEE][TRANGP=BBALLCLUB&RECV=REGPARTNER&AMT=5.00&REF=reg-045-reg&MSG=WEBSITEFEE]",
    "JSON":   "Y"
  }'

The Baseball Club sees a $105.00 Sale. Each receiving merchant sees a transfer credit on their report with the appropriate MSG. The entire transaction succeeds or fails atomically.