For a behavioral health software platform already processing payments, changing providers comes down to two operational questions: how must engineering change, and how should existing practices switch?
Behavioral health creates recurring payment activity by design. A client scheduled once a week can generate roughly 50 encounters over a year. Each encounter can bring another copay, deductible balance, private-pay charge, or card-on-file transaction into the workflow.
The payment volume grows with utilization, not only with the number of practices using the software.
Under a Managed Payment Facilitation model, the software company can earn a share of the revenue generated by that payment volume while a registered payment facilitator holds the PayFac role. Under the card-network model, merchants are onboarded as sub-merchants of the payment facilitator – which doesn’t require the software company itself to become the registered PayFac.
For a behavioral health platform changing payments providers, the migration must support both the practices already processing and the product team maintaining those workflows.
Why does behavioral health create so much recurring payment activity?
Behavioral health tends to create repeated financial interactions with the same patient or family.
A weekly outpatient client may return dozens of times during a year. Longer courses of care can mean the same card, responsible party, patient balance, and payment workflow appearing again and again.
That creates a different payment pattern from a single encounter followed by a single bill.
The platform may be supporting:
- Copays collected around the time of a session
- Deductible and other patient-responsibility balances
- Private-pay services
- Cards stored for future payments
- Recurring payment plans
- Refunds and payment adjustments
For an ISV already supporting those workflows, payment volume can increase as its practices add clinicians, clients, and encounters. The software license mustn’t change for that transaction volume to grow.
If the platform creates the workflow behind the transaction, what does the current processing arrangement return to the software company?
That question grows more relevant as reimbursement changes.
What is changing in behavioral health reimbursement in 2026?
The payer side of behavioral health is changing too, although those changes don’t affect every practice or payer in the same way.
CMS’s Innovation in Behavioral Health Model currently includes Michigan, New York, and South Carolina. The model is in a pre-implementation period through 2027. Beginning in 2028, participating practices can receive per-person-per-month payments and additional performance-based payments tied to the model’s care-delivery requirements.
Prior authorization requirements are also changing for certain federally regulated payers. Beginning in 2026, Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid managed care plans, and CHIP managed care entities must generally return decisions within 72 hours for expedited requests and seven calendar days for standard requests. Most of the API requirements under the same CMS rule begin in 2027.
At the state level, reimbursement is moving in different directions. KFF found that 23 states implemented fee-for-service rate increases for one or more outpatient behavioral health providers in FY2025, while 14 planned increases for FY2026. Nebraska, for example, adjusted its Medicaid ABA reimbursement rates effective August 1, 2025 after conducting a regional rate analysis.
Those changes don’t automatically create more card volume, but patient and family balances still need to be collected.
Where do the payment economics go?
If a behavioral health platform already manages scheduling, billing, patient balances, or cards on file, it already holds the information tied to that payment. The session happened. A balance exists. The responsible party is required to pay it. The software is helping create the path from one to the other.
The processing relationship determines what happens economically after that.
Managed Payment Facilitation allows the software company to participate in payment revenue without registering as the payment facilitator itself. NUMBER operates as a registered Payment Facilitator (PayFac) and works with ISVs and SaaS platforms to embed payment functionality and create payment-related revenue streams.
For a platform already processing through another provider, this is a provider switch, not a brand-new payments integration.
What changes when a behavioral health platform switches payment providers?
Signing a new payments agreement changes the commercial relationship. It doesn’t switch the existing practice base or change the software integration on its own. Those are separate projects.
Switching the practices
Each practice that will process through the new PayFac must make it through the new provider’s merchant onboarding process.
Card-network rules place merchant onboarding and oversight responsibilities on the payment facilitator. Mastercard defines a payment facilitator as a service provider registered by an acquirer to facilitate transactions for sub-merchants, while Visa’s model likewise places the underlying merchant relationship beneath the facilitator.
For an ISV with an established customer base, the operational questions are:
- Who contacts the practices?
- What information must each practice provide?
- Who follows up when an office does not complete onboarding?
- Who answers merchant questions during the transition?
- Who owns merchant support after the practice goes live?
Behavioral health adds another consideration: many practices may already have recurring family payments and stored payment methods in active use.
The migration plan should define how existing workflows will continue before practices switch. If the transition creates too much friction, practice adoption can stall, and the expected payment volume stays with the prior provider. Better economics only deliver value when practices actually migrate.
What should engineering establish before the platform commits?
The other cost of switching sits with the product team.
Before engineering estimates the project, it needs to know what will change in the existing payments integration.
That includes questions such as:
- Can the existing payment experience stay intact?
- Which API calls or payment flows must change?
- How will existing stored-payment credentials be handled?
- What happens to recurring payment schedules?
- Do webhooks or transaction-status handling change?
- Does reporting or reconciliation require a new data model?
- What does the testing and cutover process look like?
Those answers show whether engineering can adapt the existing integration or needs to rebuild parts of it.
That distinction belongs in the evaluation process before a provider is selected. A sales demo cannot give engineering that estimate. Technical documentation can.
NUMBER publishes its integration options, REST API reference, testing documentation, and downloadable Postman collections so product teams can inspect the available payment methods and request structure directly. Its documentation currently covers capabilities including:
- Cards on file
- Recurring payments
- Reporting
- Refunds
- Online payments
As well as multiple integration methods.
Engineering should see that material early enough to scope the project against the current integration.
Who owns the regulated payments work after the switch?
Changing providers doesn’t eliminate merchant underwriting, card-network requirements, transaction monitoring, or payment risk. It changes who owns them.
In a PayFac model, the registered payment facilitator works with the acquirer and facilitates transactions for its sub-merchants. As a registered PayFac of KeyBank, NUMBER allows the behavioral health ISV to participate in the payments relationship without becoming the registered PayFac itself.
PCI is a little more specific. A PayFac relationship doesn’t automatically remove every PCI responsibility from a software company. Scope depends on how the integration handles cardholder data. NUMBER’s documentation, for example, describes hosted and SDK-based options that keep card-data collection within its PCI-compliant environment, along with direct API options whose requirements differ depending on how card data is collected.
That distinction should be clear before implementation, rather than assuming the PayFac handles all compliance responsibilities.
What does a good behavioral health payments migration look like?
The best outcome is hassle-free:
A practice completes onboarding, staff know where to go for payment support, and engineering has a clearly defined scope. New practices can be added continuously through the same process.
As more payment volume moves through the platform, the ISV can participate in that revenue. In behavioral health, recurring care means that volume can grow with each client’s ongoing treatment.
For platforms already processing with another provider, bring NUMBER your current payment flow. We can map what needs to change and how the practice transition would be handled before you commit to a switch.
Frequently asked questions
What is Managed Payment Facilitation?
Managed Payment Facilitation allows a software company to earn revenue from payments processed through its platform without becoming the registered PayFac. The payment facilitator handles the PayFac relationship with the acquiring bank and card networks, while practices process as sub-merchants under its registration.
What happens to practices already processing with another provider?
Practices switching to a new PayFac must complete that provider’s onboarding and underwriting process before they can begin processing. The exact requirements vary by provider and acquiring relationship. For an established ISV, practice outreach, follow-up, and activation should be planned as part of the migration, not after the agreement is signed.
What should engineering ask before switching payment providers?
Engineering should identify which parts of the current integration can stay, which APIs or data structures must change, how stored payment methods and recurring payments will be handled, and what testing and reporting changes are required. The provider’s technical documentation should be reviewed before the team estimates the project.
Sources:
1. Centers for Medicare & Medicaid Services. “Innovation in Behavioral Health (IBH) Model” and “Innovation in Behavioral Health Model Frequently Asked Questions.”
(CMS IBH Model | CMS IBH Model FAQs)
2. Centers for Medicare & Medicaid Services. “CMS Interoperability and Prior Authorization Final Rule CMS-0057-F.” January 17, 2024. (CMS prior authorization final rule fact sheet)
3. KFF. “A View of Medicaid Today and a Look Ahead: Balancing Access, Budgets and Upcoming Changes.” Medicaid Budget Survey for State Fiscal Years 2025 and 2026.
(KFF Medicaid budget survey)
4. Nebraska Department of Health and Human Services. “Medicaid Provider Bulletin 25-14: Applied Behavior Analysis Rates.” July 1, 2025. (Nebraska Medicaid ABA rate bulletin)
5. Mastercard and Visa. Payment facilitator definitions and card-network role descriptions.
(Mastercard: About Payment Facilitators | Visa: Third Party Agent Functional Descriptions)
