Diagnose provider setup, callback, account matching, placement, Guardrail, redirect, and integration issues in VentraConnect Social Login.
Most Social Login problems fall into a small number of areas: provider configuration, callback URLs, credentials, account matching, placement, account-creation rules, redirects, or caching.
This guide covers:
- Social Login button not showing
- Provider callback and redirect errors
- Invalid or wrong provider credentials
- Provider application access restrictions
- Existing-user matching problems
- Guardrails and new-account behaviour
- WooCommerce and integration placement issues
- Wrong post-login redirects
- Caching and stale configuration
- A complete diagnostic checklist
Social Login Button Is Not Showing
If a provider button is missing, first confirm the provider is enabled and the current login surface supports that placement.
Check:
- The provider is configured in VentraConnect → Login Methods
- The provider is set to Active
- Required provider credentials are saved
- The page you are testing is one of the enabled Social Login placements
- If you are testing WooCommerce, LMS, membership, community, or comments placements, VentraConnect Pro is active where required
- The page is not showing an old cached version
There is also an existing dedicated guide for this issue: Social Login Button Not Showing Up.
Callback or Redirect URI Errors
OAuth providers usually require the callback / redirect URL to match the value configured in the provider application.
Verify:
- The callback URL in the provider application matches the URL shown by VentraConnect
- The domain is correct
- HTTP vs HTTPS is correct
- The path is correct
- You are not using staging callback settings on production or production settings on staging
Small URL differences matter. A different protocol, hostname, path, environment, or other callback mismatch can cause the provider to reject the login request.
Invalid or Wrong Provider Credentials
If authentication fails before the provider completes login, confirm the credentials belong to the same provider application you configured for the site.
Do not post secrets publicly when asking for support. Redact Client Secrets, App Secrets, and other private provider credentials from screenshots and logs.
Provider Application Restrictions
A provider application can be configured correctly in VentraConnect but still reject a user because of provider-side restrictions.
Review the provider application for:
- Test / development mode restrictions
- Allowed tester or developer accounts
- Required provider-side approval
- Allowed redirect URLs
- Application status or access restrictions
Provider dashboards and approval requirements can change independently of VentraConnect. Use the provider's current dashboard as the source of truth for provider-side access rules.
Existing User Is Not Being Matched
If the provider login succeeds but VentraConnect does not authenticate the expected existing WordPress user, check the account-linking path.
Check:
- Whether the provider identity is already linked to the expected WordPress account
- Whether the provider returned the expected email address
- Whether the provider explicitly indicates that email is verified when email-based matching is needed
- Whether the user has another linked provider identity
- Whether you are testing with the correct provider account
Do not weaken verified-email matching to force a login. VentraConnect Free v1.4.4 intentionally refuses unverified email fallback for existing-account matching.
For the detailed matching flow, see Social Login Account Linking & Existing Users and Social Login Security & Verified Email Matching.
Unexpected New Account Creation
If a Social Login attempt creates a new WordPress user when you expected existing-user-only behaviour, first identify which surface is being used.
Social Login does not use the Magic Link / Email OTP Login Only / Login & Register selector.
WooCommerce or Integration Placement Issues
If Social Login works on core WordPress login but not inside WooCommerce, an LMS, membership plugin, community platform, or comments flow, treat that as a placement-specific issue.
Verify:
- VentraConnect Pro is active where the placement requires Pro
- The relevant integration placement is enabled
- You are testing the correct login / checkout / registration surface
- The provider itself works on a standard VentraConnect login surface
- The integration template has not been heavily overridden by the theme or another plugin
- Cached markup is not hiding a newly enabled placement
Test each surface independently. WooCommerce My Account, checkout, membership login, registration, and LMS enrollment can have different account-creation and placement behaviour.
Wrong Redirect After Login
If authentication succeeds but the user lands on the wrong page, check the redirect configuration separately from provider authentication.
Check:
- The configured login redirect
- Any shortcode redirect_to value
- Whether the flow is using same-page, referrer, home, or a custom redirect
- Integration-specific redirect behaviour
- Whether another plugin or theme is changing the redirect after VentraConnect completes authentication
A correct provider login followed by a wrong destination usually means authentication succeeded and the remaining issue is redirect handling.
Caching and Stale Configuration
Caching can make a correct configuration appear broken or make an old configuration appear to still be active.
When settings or buttons do not appear to update:
- Clear the WordPress page cache
- Clear any CDN / reverse-proxy cache
- Clear browser cache or use an incognito session
- Retest while completely logged out
- Confirm the current page is not a cached copy of an older login form
Diagnostic Checklist
Work through these in order:
- Confirm the provider is Active in VentraConnect
- Confirm the provider credentials belong to the correct application
- Confirm the callback / redirect URL is correct
- Confirm the provider application allows the test account
- Test in a private/incognito browser session
- Confirm the provider button appears on the intended surface
- Test provider authentication itself
- If authentication succeeds, check existing-user matching separately
- Review Guardrails only when the issue is new-account creation
- Remember WooCommerce checkout is an intentional account-creation flow and is not blocked by the login-form Guardrail
- Check redirect settings only after authentication succeeds
- Clear caches and retest
- Review VentraConnect diagnostics / logs for the failing step
Isolate the problem first. Determine whether the failure is provider authentication, account matching, account creation, placement, or redirect behaviour before changing multiple settings at once.
