We've added a new Embedded Components integration that lets partners render the SportsPay payment fragment directly inside their own checkout page instead of redirecting customers to a hosted page.

What this means

The SportsPay payment fragment is rendered inside your own checkout flow — in a modal, side panel, or inline step — keeping the customer on your site while still taking advantage of SportsPay's PCI-safe, server-hosted card capture. The fragment seamlessly handles advanced functionality like schedules, CustomerPay, Platform Fees, wallets, and retries, with no additional integration work on your side.

Documentation:
(Embedded Components)

Action required

None. Embedded Components is an optional integration method and can be adopted as needed.

We’ve added a new Merchant Provisioning section that outlines how gateway credentials and terminals are created and delivered after onboarding approval.

What this means

The Merchant Provisioning documentation clarifies the post-approval lifecycle, including:

• Merchant creation on the gateway
• Terminal (termID) generation
• Credential delivery via the Merchant Credential Callback
• Identifier usage (orgID, merchID, partnerID)

Documentation:
(Merchant Provisioning)

Action required

None. This is optional and can be adopted as needed.

We’ve added a new Onboarding API that allows partners to programmatically onboard merchants into the SportsPay platform.

What this means

The Onboarding API streamlines merchant setup by enabling automated submission of onboarding data, reducing manual processes and speeding up activation timelines.

Documentation:
(Onboarding API

Action required

None. This API is optional and can be adopted as needed.

We’ve added the following fields to all GetResult API responses:

• CARDMASK – Masked card number (e.g., ****4242)
• CARDEXP – Card expiration date (e.g., 12/30)
• CARDHASH – Tokenized hash of the card number for tracking and reconciliation

What this means

These fields provide additional visibility into card transactions while maintaining PCI compliance. They can also assist with card recognition when using the TOKEN returned in the response for any customer vault implementation. No changes are required to existing integrations—this update is fully backward compatible.

Action required

None. Integrations can optionally begin consuming these fields as needed.

We’ve standardized the formatting for all numeric amount fields (AMT, USERFEE, PLATFEE, PLATCHRG, etc.) across all integration types. Previously, Direct Payments required amounts to be sent without a decimal (e.g., 100 for $1.00), while Redirect Payments required a decimal format (e.g., 1.00 for $1.00).

What’s changed?

• Now, all integration types allow numeric amounts to be sent with or without a decimal.
• When an amount is sent without a decimal, the gateway will assume the decimal placement two digits from the right:
  • 500 → $5.00
  • 5.00 → $5.00
  • 5.→ $5.00
  • 5 → $0.05\
    
• Preferred format: Sending amounts with a decimal point and two digits (e.g., 5.00) ensures the most clarity.

For Direct Payment transaction calls, all new integrations must use Embedded Tokenization. This means transactions will now be processed WITH TOKEN instead of WITH CARD.

What's changed?

• Legacy integrations that process Direct Payments WITH CARD will continue to be supported.
• However, all new integrations must use Embedded Tokenization, meaning Direct Payment transaction calls will now be WITH TOKEN.