Every call your server makes to a payment provider carries a credential, and the kind of credential decides how much damage a leak can do. Payment API authentication comes in three main shapes: a long-lived API key sent with each request, a short-lived OAuth 2.0 access token obtained from a secret, and mutual TLS, where the client proves its identity with a certificate during the connection itself.

Stripe, Adyen, PayPal, Square and Visa’s developer platform each use a different mix, and the differences show up in how you store, scope, rotate and test those secrets. This analysis compares what each provider’s documentation asks of an integration and where the risk sits in each model.

API keys: simple, long-lived, easy to leak

Stripe and Adyen authenticate server calls with keys that do not expire on their own.

Stripe’s API keys guide lists four key types. A publishable key (pk_) is safe to expose in front-end code and can create tokens or PaymentMethods, but not charges. A secret key (sk_) has unrestricted access to every Stripe API, and Stripe now says it does not recommend secret keys for new use cases. A restricted key (rk_) carries only the permissions you assign, and Stripe recommends restricted keys “for most use cases,” including migrating existing secret-key usage to them.

Adyen ties its keys to an API credential with a username in the form ws_123456@Company.YourCompanyAccount and a set of roles, according to its API credentials page. Requests send the key in an x-API-key header, or a username and password in a Basic Authorization header, as its authentication types page describes. Adyen suggests separate credentials for separate systems, such as one that initiates payments and another that captures them.

Because the key itself is the whole credential, both providers put their controls around it:

  • Narrow permissions. Stripe restricted keys and Adyen roles limit what a stolen key can do.
  • Network limits. Stripe says access policies have replaced its older IP address restrictions, so a key can be limited to known servers. Adyen lets you add an allowed IP range to a credential.
  • Rotation. Stripe’s rotation revokes the old key and issues a replacement that works at once, and rotation can be scheduled. Adyen keeps the previous key active for 24 hours after you generate a new one, so systems can switch over without an outage.

The weakness is the lifetime. A key that works until someone rotates it stays useful to an attacker until someone notices.

OAuth 2.0: short-lived tokens from a longer-lived secret

PayPal and Square use OAuth 2.0 access tokens, which expire and must be renewed.

PayPal’s REST authentication guide has the integration exchange its client ID and secret for an access token with the client_credentials grant at /v1/oauth2/token. The response states how many seconds the token is valid, and the integration sends it as Authorization: Bearer until it expires, then requests a new one. The client secret still needs a vault, but it travels only to the token endpoint, not with every payment call.

Square splits the model in two, per its access tokens guide. A personal access token gives unrestricted access to your own Square account and is suitable for production only when you integrate with that account alone. Applications serving many sellers should use OAuth access tokens, which carry only the scopes each seller grants. Square’s OAuth best practices say an access token expires after 30 days and that applications should renew every 7 days or less, so a failed refresh is caught well before the deadline. For mobile apps and single-page web apps, Square recommends the PKCE flow, which removes the need for a client secret on the device; refresh tokens used with PKCE are single-use and expire in 90 days.

OAuth adds moving parts: a refresh job, token storage, and error handling for expired and revoked tokens. Square distinguishes an ACCESS_TOKEN_EXPIRED error from UNAUTHORIZED, and returns 403 FORBIDDEN when a token lacks a scope. In return, a leaked access token stops working on its own schedule.

Mutual TLS: identity in the connection

Mutual TLS moves authentication into the TLS handshake. Visa’s Two-Way SSL guide says Visa Developer authenticates the client with an X.509 certificate issued for the project, while the client authenticates Visa with its server certificate. The setup starts with a certificate signing request, then a keystore holding the private key, the issued certificate and Visa’s CA certificates. Visa uses it for calls into its APIs and for callbacks to the client’s system, and it still pairs the certificate with an HTTP Basic username and password on each request.

The appeal is that the private key never crosses the wire, so a captured request is not enough to impersonate the client. The IETF’s RFC 8705 applies the same idea to OAuth: an authorization server can bind an access token to the client’s certificate, and an API can check that the token was issued to the client presenting it. The cost is operational. Certificates expire and must be renewed, keystores must be deployed to every server that calls the API, and a failed handshake is harder to debug than a 401.

How the three models compare

API key OAuth 2.0 token Mutual TLS
Examples Stripe, Adyen PayPal, Square Visa Developer
Lifetime Until rotated or expired by you Set by the provider; Square: 30 days Until the certificate expires
Sent with each call The key A bearer token Certificate proof in the handshake
Main control Scoping, IP or access policy, rotation Scopes, refresh, revocation Private key custody, certificate renewal
Typical failure Key committed to a repo Silent refresh failure Expired certificate

What to check in your integration

Whatever the model, the same habits close most gaps:

  • Keep test and live credentials apart. Stripe keys are tied to a sandbox or live mode, Adyen requires a new key in the live Customer Area, and Square returns an UNAUTHORIZED error when a token is used in the wrong environment. Our analysis of payment API sandbox testing covers the go-live cutover.
  • Scope before you ship. Start from Stripe restricted keys, Adyen roles or Square OAuth scopes rather than full-access credentials.
  • Automate renewal. Rotate keys on a schedule and refresh OAuth tokens well before expiry.
  • Authenticate the other direction too. Outbound credentials prove who you are to the provider; inbound webhooks need their own check, described in our comparison of payment webhook signatures.

Changes to provider versions and endpoints are logged in our payment API changes tracker, including the Stripe and Square records.

Sources