CustomerPay lets merchants pass fees to the cardholder at checkout. When enrolled, the cardholder is charged AMT + USERFEE, and the merchant receives AMT as their deposit — no fees come out of their revenue.

The fee is calculated by SportsPay based on the merchant's pricing model. Your platform's job is to:

1. Ask the gateway what USERFEE is,
2. Display it to the cardholder, and
3. Send it alongside AMT on the transaction request.

Enrolling a Merchant in CustomerPay

CustomerPay is a pricing model the merchant agrees to when signing up for their SportsPay account. New merchants can select CustomerPay during onboarding.

Existing merchants can switch to CustomerPay, but the change requires signing an updated pricing agreement. Merchants should email [email protected] to request the form and next steps.

Partners with questions about the pricing model, enrollment process, or merchant status can email [email protected].

When a merchant is not enrolled, USERFEE returns 0.00 regardless of what you pass — it is always safe to include.

How USERFEE Works per Integration Method

Pick the section for your integration method.

Customized Checkout and Embedded Components

The hosted page handles USERFEE for you by default. Omit it on StartSession and the gateway calculates and displays it to the cardholder automatically.

When to call CheckUserFee first: only if you need to display the fee on your own page before the hosted page loads (for example, to show the total on a summary screen). Otherwise, skip it.

See Hosted Check UserFee for the full specification.

Required parameters: TERMID, PASS, TYPE=W, ACTION=CheckUserFee, AMT
Optional: PLATFEE — include if you're also charging a Platform Fee.

The response returns USERFEE, which you then pass on the subsequent StartSession.

Direct with Embedded Tokenization

Your platform calculates USERFEE server-side and passes it on the Sale (or Force Post / Pre-Auth / Completion) request. You are responsible for displaying it at checkout.

How you get the value depends on the card source:

New card data (Embedded Tokenization flow)
Include AMT in your GetAPIKey call. The gateway returns the calculated USERFEE alongside the API key so you can display it on your checkout page before the customer pays. See Steps for Direct with Embedded Tokenization — Step 1.

Stored permanent token (recurring charge, saved card)
Call Direct Check UserFee to calculate the fee without generating a new API key.

Required parameters: TERMID, PASS, TYPE=Z, SUBTYPE=UF, AMT
Optional: PLATFEE — include if you're also charging a Platform Fee.

The response returns USERFEE, which you then pass on the Sale request.

Sending USERFEE on a Transaction

Always send AMT and USERFEE as separate fields:

{
  "AMT":     "150.00",
  "USERFEE": "0.80"
}

The cardholder is charged AMT + USERFEE ($150.80). The merchant receives AMT ($150.00) as their deposit. The USERFEE is retained.

Important Notes

• Not enrolled? USERFEE returns 0.00 regardless — always safe to include USERFEE=0 on transactions.
• Always display USERFEE to the cardholder before they confirm payment. It must be visible at checkout.
• Charging transactions only — USERFEE applies to Sale, Force Post, Pre-Auth, and Completion. See Transaction Types.
• Refunds don't return USERFEE — if a transaction was charged with a USERFEE, the refund returns only AMT to the cardholder.