Okta
Identity provider for single sign-on and user provisioning
ProPay integrates with Okta for single sign-on and provisioning, not claims data. Okta is an identity provider used for single sign-on and user provisioning across an organization's software. This governs how your team runs ProPay as enterprise software.
Okta is an identity provider used for single sign-on and user provisioning across an organization’s software. This isn’t a claims integration, Okta is about how your organization runs ProPay itself as procured enterprise software: single sign-on and provisioning.
What ProPay does with Okta
ProPay supports SAML-based single sign-on through Okta, so your team logs into ProPay with the same Okta credentials they use for everything else. User provisioning and deprovisioning follow your existing Okta lifecycle rules, so access is removed automatically when someone leaves the team or changes roles.
This sits apart from ProPay’s claim-handling integrations entirely. Okta doesn’t touch claim data, parts sourcing, or payment execution, it’s the layer that governs how your team accesses and monitors ProPay as a system, the same way it governs every other vendor you run Okta against.
How the Okta connection works
ProPay’s authentication layer accepts Okta as a SAML identity provider, configured during onboarding.
This is configured during enterprise onboarding rather than left to a self-serve setup, since it touches how your team authenticates or how your operations team gets alerted.
What stays in Okta
Okta continues to manage identity, observability, or incident routing exactly as it does for every other tool in your stack. ProPay is one more system governed by the rules you already have in Okta, not a special case.
Data handling and security
ProPay is SOC 2 compliant, with both Type I and Type II audits complete, and each client runs on a company-specific instance, a property directly relevant to how access through Okta is scoped, since there’s no shared environment to accidentally expose.
Every claim recommendation ProPay makes is logged with a confidence level and its supporting inputs, independent of whatever visibility Okta is configured to provide, Okta adds a second layer of oversight on top of an already-audited system, not a replacement for it.
Setting this up
A dedicated Forward Deployed Engineer configures the Okta connection as part of enterprise onboarding, working with whoever owns identity or operations tooling on your side.
Frequently asked questions about ProPay and Okta
Is Okta used for claims data, like ProPay’s other integrations?
No. Okta governs how your organization accesses or monitors ProPay itself; claim, parts, and payment data move through ProPay’s separate category-specific integrations.
How does ProPay connect to Okta?
ProPay’s authentication layer accepts Okta as a SAML identity provider, configured during onboarding.
Is Okta required to use ProPay?
No. Okta is available for enterprise clients who want ProPay to run under their existing identity, observability, or incident management setup, it isn’t required for ProPay’s core claims functionality.
