- Ya
- 14 Agosti 2026, 01:19 UTC
- Mwandishi
- kamo
- Ahadi ya
- caaf7e0
Six fields on the payroll cards were never consumed by anything. A registration field nobody loads is worse than a missing one: an operator fills it in, believes the vendor is configured, and the failure surfaces later as an unexplained auth error against credentials that were sitting right there. - The whole ADP card. Its adapter authenticates from the organization's own certificate pair and never reads the registry, so the partner client id, secret and PEM pair here were inert. **************** stays reserved for whenever the Marketplace path is built. - Paylocity's WebLink pair. Paylocity has two issuers; only the API Hub pair is held by the shared token service. The token service can hold one grant per provider, so the adapter reads the WebLink pair from the org's own config — where the setup screen already asks for it. - The environment fields on Gusto and Paycor. Sandbox versus production is a per-organization choice and is read from the org's own toggle; these were never consulted. What remains is verified against its consumer: clientId, clientSecret, redirectUri and scopes go to PayrollOAuthFlowService and PayrollOAuthTokenService; Rippling's appName and Paycor's subscriptionKey to PayrollOAuthEndpointResolver. The per-organization client-id fields on the provider setup screen are NOT duplicates of these — they are the customer-direct fallbacks for vendors that publish both models (ADP API Central, Paychex, Paylocity WebLink), or the only model for the four vendors that issue credentials per tenant.