The concept comes from OAuth 2.0 (RFC 6749), which divides applications into confidential clients, such as a backend server that can keep a secret out of public reach, and public clients, such as mobile apps and single-page web apps, which cannot. Only confidential clients receive a client secret. Public clients use PKCE, a per-request proof, because anything shipped inside an app can be extracted from it.

In the client credentials grant, used for machine-to-machine calls, the application sends its client ID and client secret to the provider's token endpoint, either in an HTTP Basic header or in the request body. The server returns an access token, often valid for 3,600 seconds and limited to specific scopes such as `payments:read`. The application then calls the actual API with that token as a Bearer header. The secret itself travels only to the token endpoint, and only when a new token is needed.

In the authorization code flow, the secret is used once more: when the application swaps the one-time code received at its redirect URI for tokens, proving that the party redeeming the code is the registered app.

An API key is a single static credential sent with every request. If someone intercepts a single request, they hold a key that works until someone notices and revokes it. A client secret is exchanged for short-lived, scoped tokens, so a leaked token expires within the hour and a single intercepted API call never exposes the secret. Many payment providers still use API keys for simplicity; banking and open-banking APIs lean toward OAuth.

One naming trap: some payment APIs return a "client_secret" for an individual payment intent, designed to be passed to the browser to confirm that one payment. It is not an OAuth credential and cannot open the account.

A client secret is symmetric: the server holds the same value, so a breach on either side exposes it. High-security profiles such as FAPI replace it with a signed JWT (`private_key_jwt`) or mutual TLS, where the private key never leaves the client. Under PSD2, third-party providers identify themselves to banks with eIDAS certificates rather than by a shared secret alone.

Secrets belong in a secrets manager or vault, never in source code, mobile builds or front-end bundles. PCI DSS v4.0.1 requires that credentials for application and system accounts are not hard-coded in scripts or files. Providers that allow two active secrets at once make rotation possible without downtime, and a buyer reviewing a fintech's security posture will ask when secrets were last rotated.