Payment Schedules let you set up a series of future payments against a single card. The gateway processes due payments automatically each night and notifies your platform when each payment completes — approved or declined.

Use schedules for installment plans, recurring registration fees, multi-month billing, or any case where you want SportsPay to handle ongoing card billing on a fixed schedule.

Components of a Schedule

Every schedule has three pieces. All three must be in place before the gateway can process payments:

1. Schedule — the container, identified by SCHEDID. Created with TYPE=L, SUBTYPE=CS.
2. Payments — a list of dated amounts. Can be added during schedule creation or later.
3. Card data — a stored card the gateway charges. Can be attached during creation, attached later via Direct (TYPE=L, SUBTYPE=AC), or collected through Customized Checkout or Embedded Components.

Once all three are present, the schedule moves to Ready and the gateway processes payments automatically on their due dates.

Schedule Lifecycle

flowchart LR
    A[New] -->|All components added| B[Ready]
    B -->|Payment fails| C[Card Error]
    C -->|New card attached| B
    B -->|Suspended| D[Suspended]
    D -->|Restored| B
    B -->|All payments processed| E[Completed]
    E -->|Payment added| B
    B -->|Cancelled| F[Cancelled]

Payments within a schedule have their own status:

All schedule operations use TYPE=L (Schedule). The SUBTYPE determines the action.

For field formats and full per-action parameter reference, see the API Reference.

Creating a Schedule

SUBTYPE=CS — Create a new schedule. You can create it empty and add payments and card data later, or include everything in one call.

Required parameters

• TERMID, PASS
• TYPE=L, SUBTYPE=CS
• SCHEDID — your schedule identifier (must be unique per terminal)
• INVOICE — invoice number for reporting

Optional parameters

• DESC — schedule description
• PYMTS — list of payments to add immediately (see Adding Payments)
• Card fields — CARD, EXP, CUSTNAME, CUSTEMAIL to attach a card on creation

Example: empty schedule

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":  "your_termid",
    "PASS":    "your_pass",
    "TYPE":    "L",
    "SUBTYPE": "CS",
    "SCHEDID": "U13-Boys-2026-001",
    "INVOICE":     "REG-12345",
    "DESC":    "U13 Boys Fall Season",
    "JSON":    "Y"
  }'

Example: schedule with payments

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":  "your_termid",
    "PASS":    "your_pass",
    "TYPE":    "L",
    "SUBTYPE": "CS",
    "SCHEDID": "U13-Boys-2026-001",
    "INVOICE":     "REG-12345",
    "DESC":    "U13 Boys Fall Season",
    "PYMTS":   "[DATE=20260901&AMT=125.00&REF=u13-001-pmt1][DATE=20261001&AMT=125.00&REF=u13-001-pmt2][DATE=20261101&AMT=125.00&REF=u13-001-pmt3]",
    "JSON":    "Y"
  }'

Attaching a Card

A schedule needs a card before any payment can process. There are three ways to attach one.

Option 1 — On Schedule Creation

Include card fields on the CS request (see above).

Option 2 — Direct (AC)

SUBTYPE=AC — Attach card data directly to an existing schedule.

Required parameters

• TERMID, PASS
• TYPE=L, SUBTYPE=AC
• SCHEDID
• TOKEN — accepts either a One-Time Token (OTT) from Embedded Tokenization or a permanent token from a previous transaction. The gateway handles both the same way.
• CUSTNAME, CUSTEMAIL

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":    "your_termid",
    "PASS":      "your_pass",
    "TYPE":      "L",
    "SUBTYPE":   "AC",
    "SCHEDID":   "U13-Boys-2026-001",
    "TOKEN":     "4xxxxxxxxxxx1111",
    "CUSTNAME":  "Sample Parent",
    "CUSTEMAIL": "[email protected]",
    "JSON":      "Y"
  }'

Option 3 — Customized Checkout or Embedded Components

Pass the schedule's SCHEDID on StartSession. The hosted page collects the card from the customer and attaches it to the schedule. Useful when the customer is signing up for the schedule themselves.

You control whether a payment is processed as part of the same flow:

• Omit REFNUM — the card is attached only. No payment runs until the nightly processor picks up the next due payment on its scheduled date.
• Include REFNUM pointing to a specific scheduled payment — the gateway attaches the card and processes that payment on the hosted page in the same flow.

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":    "your_termid",
    "PASS":      "your_pass",
    "TYPE":      "W",
    "ACTION":    "StartSession",
    "SCHEDID":   "U13-Boys-2026-001",
    "CUSTEMAIL": "[email protected]",
    "REQUESTID": "1712864923456",
    "LANG":      "E",
    "JSON":      "Y"
  }'

Note: AMT, PLATFEE, PLATCHRG, USERFEE, and SPLIT cannot be passed on a StartSession that includes SCHEDID. The amount, if any, comes from the scheduled payment.

See Attaching a Card via Hosted Checkout for the full flow — including the GetResult / Ack handling after the customer returns, replacing a card after a Card Error, and the complete list of prerequisites.

Managing Payments

Adding Payments

SUBTYPE=PA — Add one or more payments to an existing schedule.

Required parameters

• TERMID, PASS, TYPE=L, SUBTYPE=PA
• SCHEDID
• PYMTS — payment list using the bracket syntax. Each entry needs DATE, AMT, and REF.

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":  "your_termid",
    "PASS":    "your_pass",
    "TYPE":    "L",
    "SUBTYPE": "PA",
    "SCHEDID": "U13-Boys-2026-001",
    "PYMTS":   "[DATE=20261201&AMT=125.00&REF=u13-001-pmt4]",
    "JSON":    "Y"
  }'

Adding payments to a Completed schedule moves it back to Ready.

Updating Payments

SUBTYPE=PU — Update the date and/or amount of an unprocessed payment. Approved payments cannot be modified.

Required parameters

• TERMID, PASS, TYPE=L, SUBTYPE=PU
• SCHEDID
• REF — reference of the payment to update
• DATE and/or AMT — the new value(s)

Removing Payments

SUBTYPE=PR — Remove an unprocessed payment from the schedule. Approved payments cannot be removed.

Required parameters

• TERMID, PASS, TYPE=L, SUBTYPE=PR
• SCHEDID
• REF — reference of the payment to remove

Removing all remaining payments from a schedule moves it to Completed.

Processing a Payment Now

SUBTYPE=PP — Process a payment immediately rather than waiting for its scheduled date. Useful for early payment, retrying a declined payment, or running a payment on demand.

Required parameters

• TERMID, PASS, TYPE=L, SUBTYPE=PP
• SCHEDID
• REF — reference of the payment to process

You can also attach new card data on a PP request (same fields as AC) — useful for retrying a declined payment with a different card.

A PP triggers a notification callback to your NOTIFICATION URL just like a nightly-processed payment.

Suspend, Restore, and Cancel

All three require only TERMID, PASS, TYPE=L, the appropriate SUBTYPE, and SCHEDID.

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":  "your_termid",
    "PASS":    "your_pass",
    "TYPE":    "L",
    "SUBTYPE": "SS",
    "SCHEDID": "U13-Boys-2026-001",
    "JSON":    "Y"
  }'

Getting Schedule Status

SUBTYPE=GS — Retrieve the current state of a schedule, including all payments and attached card data. Use this to synchronize your platform's view of the schedule with the gateway's.

Required parameters

• TERMID, PASS, TYPE=L, SUBTYPE=GS
• SCHEDID

The response includes the full Schedule Data Block — see API Reference for the response shape.

Notifications

When a scheduled payment is processed (whether nightly, via PP, or after a hosted attach), the gateway sends an HTTP POST to the terminal's configured NOTIFICATION URL. This is how your platform learns whether each payment was approved or declined.

The notification request includes:

• TERMID, SCHEDID, INVOICE, REF — identifies the schedule and payment
• CODE, TEXT — approval result (0000 = approved)
• The full Schedule Data Block — current state of the schedule after this payment
• SUBTYPE=SP — identifies the message as a scheduled-payment notification

Your endpoint must respond with HTTP 200 to acknowledge receipt. The gateway retries failed deliveries.

To configure a NOTIFICATION URL for your terminals, see Production.

Managing Declined Payments

When a payment declines, its status becomes D. You have three options:

• Retry — issue a PP (Process Payment) request to try the same payment again. Optionally attach new card data if the original card is the issue.
• Remove — issue a PR (Remove Payment) request to drop the payment from the schedule.
• Wait — leave it in place. The gateway does not automatically retry declined payments; they remain in D status until you take action.

When a payment moves from D to A (after a successful retry), the previous decline is preserved as an X (Archived Decline) entry with a blank REF. This keeps the historical record intact.

A payment decline also moves the schedule itself to E (Card Error), signaling that the customer may need a new card. Attaching a new card clears the Card Error status.

For the specific decline and error codes returned on scheduled payments, see Payment Schedules Errors.

API Reference

For the below per-action field reference, see Payment Schedule API Reference:

• Create Schedule (CS)
• Attach Card (AC)
• Process Payment (PP)
• Add / Update / Remove Payment (PA, PU, PR)
• Suspend / Restore / Cancel (SS, SR, SC)
• Get Schedule (GS)

For StartSession with SCHEDID — see Customized Checkout or Embedded Components API Reference