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.

A schedule holds one card, at the schedule level — not one per payment. Every payment that has not yet been processed is charged to whatever card the schedule is currently holding, so replacing the card is a single call and applies to the whole remaining schedule. Payments that have already been charged keep a record of the card that charged them, for reporting; that record is history and does not change when you attach a new card. There is no way to give one payment in a schedule a different card from another. See Replacing the Card on a Schedule.

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
• INVOICE — invoice number for reporting

Optional parameters

• SCHEDID — your schedule identifier, up to 36 characters. Must be unique per terminal. If you omit it, the gateway generates one and returns it — capture it from the response, because every later call needs it.
• DESC — schedule description
• PYMTS — list of payments to add immediately (see Adding Payments)
• FOLLOWUP — override which follow-up emails the gateway sends for this schedule (see Follow-Up Emails)
• 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":  "TEST0058",
    "PASS":    "zX3Ht5va",
    "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":  "TEST0058",
    "PASS":    "zX3Ht5va",
    "TYPE":    "L",
    "SUBTYPE": "CS",
    "SCHEDID": "U13-Boys-2026-001",
    "INVOICE": "REG-12345",
    "DESC":    "U13 Boys Fall Season",
    "PYMTS": [
      { "DATE": "20260901", "AMT": "125.00", "REFNUM": "u13-001-pmt1" },
      { "DATE": "20261001", "AMT": "125.00", "REFNUM": "u13-001-pmt2" },
      { "DATE": "20261101", "AMT": "125.00", "REFNUM": "u13-001-pmt3" }
    ],
    "JSON":    "Y"
  }'

Note: PYMTS accepts a JSON array of payment objects when you post application/json, as above. The bracket string form — "[DATE=20260901&AMT=125.00&REFNUM=u13-001-pmt1][...]" — is the form-encoded equivalent and is also accepted on a JSON body. Use the array form with a JSON request.

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":    "TEST0058",
    "PASS":      "zX3Ht5va",
    "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":    "TEST0058",
    "PASS":      "zX3Ht5va",
    "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.

Replacing the Card on a Schedule

Cards expire, get reissued, and get declined. A schedule whose most recent payment failed for a card reason sits in E (Card Error) and will keep failing until a working card is attached.

There is no separate "update card" action. You replace a card with the same calls you used to attach one — the new card data replaces whatever the schedule was holding, and attaching it clears E and returns the schedule to R (Ready).

Which route you use depends on who has the new card details.

You already hold a token — send AC with the new TOKEN, exactly as in Option 2 above.

You are retrying a specific declined payment — send PP with the payment's REFNUM and the new card fields. This replaces the card and reprocesses that payment in one call, rather than waiting for the next scheduled date. See Processing a Payment Now.

The cardholder needs to enter the new card themselves — send them through Customized Checkout or Embedded Components with the schedule's SCHEDID, as in Option 3. Omit REFNUM to swap the card without taking a payment, or include one to collect the card and process that payment in the same flow. Embedded Components also has a dedicated update-card session variant — see Embedded Components.

Managing Payments

Every payment in a schedule is identified by its REFNUM. This is the field name on every call — creating payments, updating them, removing them, and processing them on demand.

A REFNUM you supply must be unique across every schedule on the terminal, not just the one you are adding it to. A collision is rejected with 8304 DUPLICATE REFNUM. If you derive references from a per-schedule counter, prefix them with something schedule-specific.

Adding Payments

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

Required parameters

• TERMID, PASS, TYPE=L, SUBTYPE=PA
• SCHEDID
• PYMTS — array of payment objects. Each entry needs DATE and AMT; REFNUM is optional and generated by the gateway if omitted.

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":  "TEST0058",
    "PASS":    "zX3Ht5va",
    "TYPE":    "L",
    "SUBTYPE": "PA",
    "SCHEDID": "U13-Boys-2026-001",
    "PYMTS": [
      { "DATE": "20261201", "AMT": "125.00", "REFNUM": "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
• REFNUM — reference of the payment to update
• DATE and/or AMT — the new value(s)

REFNUM identifies the payment; it is not itself editable. To change a payment's reference, remove it with PR and add a replacement with PA.

curl --request POST --url {gateway_endpoint}/ \
  --header 'Content-Type: application/json' \
  --data '{
    "TERMID":  "TEST0058",
    "PASS":    "zX3Ht5va",
    "TYPE":    "L",
    "SUBTYPE": "PU",
    "SCHEDID": "U13-Boys-2026-001",
    "REFNUM":  "u13-001-pmt4",
    "DATE":    "20261215",
    "AMT":     "150.00",
    "JSON":    "Y"
  }'

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
• REFNUM — 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
• REFNUM — 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":  "TEST0058",
    "PASS":    "zX3Ht5va",
    "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, REFNUM — 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.

Follow-Up Emails

Separately from the server-to-server notifications above, the gateway also emails the cardholder about the schedule itself — payment receipts, upcoming-payment reminders, decline follow-ups, and schedule-change notices. Which of these go out is configured at the partner level when you integrate.

If your platform already sends its own customer email, you don't have to use ours. A partner that issues its own receipts doesn't need the gateway sending a second one; a partner that runs its own dunning doesn't want the gateway chasing its customers. You can turn our follow-ups off completely, or keep some and replace others.

Opting Out Entirely

There are two ways to stop the gateway emailing your cardholders. Which one you want depends on whether this is a decision about your platform or about one schedule.

Across your whole account — tell us at integration. If your platform handles all of its own customer email, ask us to configure your account with follow-ups off. Nothing is emailed to any cardholder on any schedule, and you never need to send FOLLOWUP at all. This is the right choice if you own the customer relationship end to end, and it's the one to make before you go live.

For a single schedule — send FOLLOWUP=N. This suppresses every follow-up email for that schedule only, leaving your configured settings intact for every other schedule.

Note: FOLLOWUP can only be set when a schedule is created, and cannot be changed afterwards. If you are relying on FOLLOWUP=N for a blanket opt-out, every CS call has to carry it — one omission means that schedule follows your configured settings and cannot be corrected. If you want the opt-out to apply everywhere, configure it at the account level instead.

Sending FOLLOWUP

FOLLOWUP is an optional field on SUBTYPE=CS, sent alongside INVOICE, DESC and PYMTS. Its value is a short string of letters — one letter per email type you want switched on:

N is the exception — it turns everything off rather than on. Send it on its own, not combined with other letters. See Opting Out Entirely.

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

That schedule gets decline follow-ups and schedule-change notices, and nothing else.

It replaces your configured settings — it does not merge with them

So FOLLOWUP=CS suppresses receipts and upcoming-payment reminders even when both are enabled at the partner level. Send every letter you want on — not just the ones you want to change.

Send the value in uppercase. The gateway checks only that it is letters and no longer than three characters; it does not check that they are recognised letters and does not correct the case. A lowercase or mistyped value is accepted and then simply matches no email type, silently switching everything off for that schedule.

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 REFNUM. 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