What is this and why does it matter?
Your Paytronix account is being migrated to Access Identity, our new unified login platform. This migration unlocks access to Rewards and other Evo-powered features now available on your account.
As part of this migration, we'll configure SSO Federation — which means your team will log in to Paytronix using your company's existing credentials (through your identity provider, such as Microsoft Azure AD or Okta) instead of a separate Paytronix username and password. Once it's live, there's nothing your end users need to install or change.
How the setup works
The setup has two parts:
Before you begin
Confirm the following before beginning:
Your Paytronix account agreement has Federation enabled. (If you're unsure, ask your Customer Success Manager.)
Your identity provider supports OpenID Connect (OIDC) and is publicly accessible via HTTPS.
All Paytronix users at your organization use email addresses on a company-controlled domain (e.g., yourcompany.com). Shared domains like gmail.com or outlook.com are not supported.
Step 1: Register Paytronix in your identity provider (IdP)
Your IT admin completes this step. Find your identity provider below and follow the instructions.
Identify your domains
Typically, the domain is your company name followed by .com, for example, in this email address [email protected], the domain is theaccessgroup.com. If in doubt, contact your IT team.
Identify who manages your domain
Typically, someone from your IT department has access to the domain DNS. Get in touch with them and request that they add a TXT record to verify ownership of the domain.
Identify who manages your authentication
Usually, your IT department manages your domain, and they're able to set up an OpenID Connect (OIDC) endpoint to interact with Access Identity.
Common providers are ADFS and Azure AD, for which we supply example steps; however, most authentication providers support this protocol.
Register Access Identity in your IdP
IdP 1: Microsoft Entra ID (Azure AD)
Part A: Create an Enterprise Application
An Enterprise Application is not required, but it lets the app appear on your company's SSO portal. Skip this part if you don't need it there.
Open the Azure Portal → Azure Active Directory → Enterprise applications
Click Create your own application
Name the application (e.g., "Paytronix" or "Access Identity")
Select Integrate any other application you don't find in the gallery (Non-gallery)
Click Create
Go to Users and Groups and add the users or groups who should have SSO access
Part B: Configure the App Registration
Go to Azure Portal → Azure Active Directory → App registrations
Click New registration (or open the Enterprise Application you just created)
Enter a name (e.g., "Access Identity" or "Paytronix SSO")
Click Register
From the Overview page, copy the Application (client) ID and Directory (tenant) ID — you'll need to provide both to Paytronix
Part C: Configure Authentication
Go to Authentication → Add a platform → select Web
Set the Redirect URI to: https://identity.us.access-evo.com/auth/oidc/callback
Under Implicit grant and hybrid flows, check ID tokens (used for implicit and hybrid flows)
Under Supported account types, select Accounts in this organizational directory only.
Click Save.
Part D: Configure API Permissions
Go to API permissions → Add a permission.
Add the following Microsoft Graph delegated permissions: email and openid
Click Grant admin consent for [your organization].
Part E: Create a Client Secret
Go to Certificates & secrets.
Click New client secret.
Enter a description and set an expiration period.
Click Add.
Copy and save the secret Value
⚠️ Important: Save the secret immediately, as it is only shown once. You can create a new secret if needed.
Information needed for Step 2
Item | Where to Find It |
Application (client) ID | App registration → Overview |
Directory (tenant) ID | App registration → Overview |
Client Secret Value | Certificates & secrets (copy immediately after creation) |
Employee email domain(s) | The domain after @ in your employee emails (e.g., yourcompany.com) |
📌 Note: By default, Azure AD does not pass the email claim in the ID token. This is expected — Paytronix will look up the email via a secondary request. If you use a custom field for email addresses, let your Paytronix contact know.
IdP 2: Okta
Part A: Create an App Integration
In Okta, go to Applications → Create App Integration
Set the following:
Sign-in method: OIDC – OpenID Connect
Application type: Web Application
Part B: Configure Redirect URIs
Set the Sign-in redirect URI to: https://identity.us.access-evo.com/auth/oidc/callback
Set the Sign-out redirect URI to: https://identity.us.access-evo.com/
Complete the app creation
Part C: Configure the Sign On Tab
Go to the app's Sign On tab.
Under OpenID Connect ID Token, confirm the Issuer is set to your Okta URL (e.g., https://your-company.okta.com).
Part D: Assign Users
Go to the Assignments tab.
Assign the users and/or groups who should have access to Paytronix.
Information needed for Step 2
Item | Where to Find It |
Client ID | App Integration → General tab → Client Credentials |
Client Secret | App Integration → General tab → Client Credentials |
Provider Metadata URL | See note below |
Employee email domain(s) | The domain after @ in your employee emails |
Provider Metadata URL depends on your Authorization Server setup:
Org Authorization Server: https://{yourOktaDomain}/.well-known/openid-configuration
Default Custom Authorization Server: https://{yourOktaDomain}/oauth2/default/.well-known/openid-configuration
Other Custom Authorization Servers: https://{yourOktaDomain}/oauth2/{authorizationServerId}/.well-known/oauth-authorization-server
The authorizationServerId can be found on the Custom Authorization Server's Settings page in Okta.
IdP 3: AD FS 2016+
Note: AD FS must be version 2016 or later. Earlier versions do not support OpenID Connect and are not compatible with Access Identity Federation.
Part A: Create an Application Group
Open AD FS Management
Navigate to Application Groups → Add Application Group
Name it "Access Identity" (or "Paytronix SSO")
Select the template: Web browser accessing a web application
Copy the generated Client Identifier — you'll need to provide this to Paytronix
Set the Redirect URI to: https://identity.us.access-evo.com/auth/oidc/callback
Set Access control policy to Permit everyone (or your organization's preferred policy)
Part B: Configure Issuance Transform Rules
After creation, edit the Application Group's Web application
Go to Issuance Transform Rules → Add Rule
Select rule type: Send LDAP Attributes as Claims
Configure the rule:
Claim rule name: Email
Attribute store: Active Directory
LDAP Attribute: E-Mail-Addresses
Outgoing Claim Type: E-Mail Address
Part C: Configure Client Permissions
Under Client Permissions, add email as a permitted scope.
Information needed for Step 2
Item | Where to Find It |
Client Identifier | Generated during Application Group creation |
AD FS Server FQDN | Your AD FS server's fully qualified domain name |
Employee email domain(s) | The domain after @ in your employee emails |
IdP 4: Other OIDC Providers (OneLogin, Google Workspace, Custom)
For identity providers not listed above, your IT team needs to complete the following steps.
Part A: Register the Application
In your identity provider's admin console, create a new OIDC/OAuth 2.0 application.
Set the application type to Web Application.
Set the Redirect URI / Callback URL to: https://identity.us.access-evo.com/auth/oidc/callback.
Part B: Ensure Required Scopes and Claims
Confirm that the application requests the openid and email scopes.
Confirm the email claim is included in the ID token.
The email address in your IdP must match the email address on each user's Paytronix account.
Information needed for Step 2
Item | Where to Find It |
Client ID | Your IdP's application settings |
Authority URL / Issuer URL | Your IdP's OIDC configuration page |
Employee email domain(s) | The domain after @ in your employee emails |
Common Authority URLs by provider:
OneLogin: https://{subdomain}.onelogin.com/oidc/2
Google Workspace: https://accounts.google.com
Other: Contact your Paytronix team
Step 2: Configure Federated SSO in Access Identity
Create an Access Identity user
To register each domain with Access Identity, you need to register at least one email address per domain. To do this, go to https://identity.us.access-evo.com/ and click Create New Account.
📌 Note: If you have already registered with Access Identity due to using other Access products, once clicking https://identity.us.access-evo.com/, you can either enter your password or reset your password to access your Identity account if you have forgotten it.
Do this with one email per domain you wish to set up. Ideally, this person should be your administrator in case you need to come back and edit this later.
This is a once-off task with one user per domain. Once the setup is complete, all other users automatically move to Access Identity, without any impact on how they log in.
Repeat this step and further steps once per domain.
Create a Security Policy
Security Policies allow you to set Session, Authentication, Two-Factor Authentication, and Federation policies that are then applied to your users.
To sign in to Access Identity, go to https://identity.us.access-evo.com.
Select Security Policies.
In the Security policies section, select Add security policy.
Enter a Name for the Security Policy, for example, Example Security Policy.
Add any additional Owners — owners will be able to modify this Security Policy.
Scroll down, then select Save changes.
You've now created a new Security Policy, which is a copy of the Default Security Policy. You can now configure and test federation settings.
Configure and test federation settings
Before configuring Access Identity to use your OpenID Connect Identity Provider, you'll need to note the following two configuration settings.
📌 Note: If you are using Azure AD as your OpenID Connect Identity Provider, Client Identifier is referred to as Application ID.
Client Identifier — this is the identifier generated by the OpenID Connect Identity Provider when configuring Access Identity as an Application.
Authority URL — this varies depending on the OpenID Connect Identity Provider being used:
If you are using AD FS 2016, this will be the FQDN of your publicly accessible AD FS server, followed by /adfs, for example
https://server.domain.com/adfs.If you are using Azure AD, this will be
https://sts.windows.net/followed by your Azure Directory (tenant) ID, for examplehttps://sts.windows.net/178a7f3e-c149-48f5-85fe-54a80e26e734.
To find your Azure Directory ID:
Open the Azure Portal.
Select Azure Active Directory, then select Properties.
Copy the Directory ID.
To sign in to Access Identity, go to https://identity.us.access-evo.com.
Select Security Policies.
Select the Security Policy you created above, for example, Example Security Policy.
Scroll down to the Federation section.
Change the Identity Provider to OpenID Connect.
Enter a name for the Identity Provider.
Enter the Authority URL — see above.
Enter the Client ID — see above.
Select Test these settings.
If your OpenID Connect Identity Provider has been configured correctly, you'll be directed to your OpenID Connect Identity Provider's sign-in screen.
Sign in using an account you know to be valid — this will not be used for anything other than this test.
If the federation settings test fails, check your configuration on your OpenID Connect Identity Provider and try again.
If the federation settings test passes, save the Security Policy by selecting Save changes.
You've now configured federation in Access Identity. Before this configuration can be applied to your users, ownership of your email domain must be verified.
Verify email domain ownership
Before federation settings can be applied in Access Identity, you must first verify you are the owner of your organisation's email domain — this is the part of your users' email address after the @.
The process uses an industry standard for domain ownership verification. It requires the owner of the email domain to add a record, containing a verification code generated by Access Identity, to the email domain's DNS (Domain Name System). Once the record has been added, you can request that Access Identity verify the email domain. Once verified, you'll be able to assign a custom Security Policy to your users.
To sign in to Access Identity, go to https://identity.us.access-evo.com.
Select Domains.
In the Unverified domains section, select Add domain.
Enter your Domain name, for example, example.com.
Add any additional Owners — owners will be able to modify this Domain.
Select Save changes.
Access Identity will now generate a Verification Code for your domain. Add this code as a TXT record to your email domain's DNS in the following format:
Host: @
Type: TXT
Value: The entire verification code, including
access-domain-verification=
Once the TXT record has been added to your domain DNS, select Verify to attempt verification.
If verification is unsuccessful, confirm the TXT record has been added to your domain DNS correctly and that the change has fully propagated before attempting verification again.
If verification is successful, you've confirmed ownership of your email domain and can now assign a Security Policy to your users.
Assign the Security Policy to the verified domain
To enable the federation settings within the Security Policy, you need to assign it to a domain listed in your agreement with Access. Contact your Account Manager for further information.
To sign in to Access Identity, go to https://identity.us.access-evo.com.
Select Domains.
In the Verified Domains section, select your Domain.
Change the Security policy drop-list to the Policy you have created.
Select Save changes.
You've now assigned the Security Policy to your verified domain. You can now enable the domain to apply these settings to your users.
Enable the domain
Now that the configuration is in place and you have confirmed it works by performing a test, you can enable the domain. Enabling the domain will cause this configuration to be applied to your users.
To sign in to Access Identity, go to https://identity.us.access-evo.com.
Select Domains.
In the Verified domains section, select your Domain.
Select Enabled.
Select Save changes.
Troubleshooting
Symptom | Likely Cause | What to Do |
Federation test fails immediately | Incorrect Redirect URI | Verify the Redirect URI is exactly https://identity.us.access-evo.com/auth/oidc/callback with no trailing slash |
Test shows IdP login but fails after sign-in | Email claim not returned in the ID token | For AD FS: verify the Issuance Transform Rule and that the email scope is permitted. For other IdPs: confirm the email claim is included in the ID token |
Domain verification fails | DNS propagation delay or incorrect TXT record | Allow up to 48 hours for DNS propagation. Confirm the TXT record value starts with access-domain-verification= |
Users can't access Rewards or Evo features after go-live | Email mismatch between PXS and IdP | Confirm that each user's email in Paytronix exactly matches their email in the IdP |
Test user works, but other users fail | Users not assigned to the app in the IdP | Azure AD: check Users and Groups on the Enterprise Application. Okta: check the Assignments tab. AD FS: check access control policies |
Questions?
Contact Paytronix Support or visit the Access Identity FAQ.