Payment API keys beyond Stripe: Leak Response for Six Payment and Finance Platforms

A leaked payment or banking API key is not a billing nuisance: depending on its scope it can read customer and transaction data, issue refunds, change payout details or start money transfers. This page covers six platforms whose keys share the same leak-response shape: Square, Checkout.com, GoCardless, Paddle, Mercury and Ramp. For each it explains how keys and tokens are scoped, who can create and revoke them, what GitHub secret scanning detects and whether the provider is told, and which controls cut the damage a leaked key can do. It is written for payments engineers, finance systems owners and security teams. Stripe has its own page: see the Stripe API Keys Security Guide.

Key takeaways

• Revoke, then replace, then investigate: every platform here lets an administrator disable or delete a key immediately; the only reason to wait is to stand up the replacement first, and for a money-moving key even that wait may be too long.
• Some providers auto-revoke: Paddle scans public GitHub repositories and automatically revokes high-risk exposed keys, so a leak can become an outage without anyone in your team acting.
• Scope is the difference between an incident and a loss: a Mercury Read Only token cannot move money; a Read and Write token can initiate transactions without admin approval, which is why Mercury requires an IP allowlist for it.
• Push protection is not universal: GitHub push protection covers Square, Checkout.com, Paddle, Mercury and Ramp secrets, but not GoCardless access tokens, which are detected only after they are committed.
• Disabling a person does not disable their tokens: GoCardless notes that disabling the admin who created a token does not revoke it, a pattern worth assuming on every platform.

How identity and access work in payment API platforms

Paddle's documented key format is precise enough to validate in your own scanners: 69 characters, five underscores, matching ^pdl_(live|sdbx)_apikey_[a-z\d]{26}_[a-zA-Z\d]{22}_[a-zA-Z\d]{3}$. Legacy 50-character keys created before 6 May 2025 do not match this format, do not support permissions and are not covered by Paddle's secret scanning; Paddle recommends replacing them.

Admin roles and privileged access

• Square: tokens and the application secret are managed in the Developer Console (Credentials and OAuth pages). Anyone with Developer Console access to the application can see or reissue credentials, so restrict console access to the people who need it. Webhook subscriptions and the Events API require the personal access token, which makes it harder to retire entirely.
• Checkout.com: keys live under Dashboard, Developers, Keys. Admins, Developers and custom roles with "Create new keys" or "View the list of keys" can create and list keys, but only the Account owner role can edit or delete existing keys. Make sure more than one trusted person holds an Account owner role, or a leak will wait for one person.
• GoCardless: only Admins can create access tokens, and a token is shown once. Disable tokens from API settings with "Disable access token".
• Paddle: manage keys with expiry dates (default 90 days, maximum one year). Subscribe to the api_key.expiring webhook (seven days before) and api_key.expired.
• Mercury: tokens are created under Settings, Tokens by users an admin has permitted. Read and Write tokens can initiate transactions and manage recipients without admin approval: treat them as privileged credentials and require IP allowlisting, which Mercury enforces.
• Ramp: apps are managed under Company, Developer in app.ramp.com; rotating a client secret may require identity verification.

Protect the dashboards as well as the keys: on every platform here, a user who can sign in to the dashboard with key-management rights can mint a new secret, so a phished finance or developer account is equivalent to a leaked key. Require strong, ideally phishing-resistant, multi-factor authentication or SSO for these users, review who holds key-management roles each quarter, and alert on new keys created outside a change record.

Integrations, API tokens and service accounts

• Prefer scoped credentials: Square OAuth tokens with the minimum scopes over a personal access token where the integration allows; Checkout.com secret keys split per API; Mercury Custom scopes such as RequestSendMoney, which starts payments that still need admin approval, over Read and Write.
• Separate by environment: every platform here separates sandbox from live. Never put live keys in test configuration; Square returns AUTHENTICATION_ERROR with code UNAUTHORIZED when a token is used against the wrong environment, which is a useful canary when environments are mixed.
• Restrict network origin: Mercury requires IP allowlisting for Read and Write tokens. Where other platforms offer allowlisting, use it for server-side keys.
• Own the token, not the person: document an owning team for each token, because tokens outlive the administrator who created them.
• Keep secrets server side: Checkout.com public keys exist for client-side use; secret keys must never appear in front-end code or mobile apps. See the Payment Gateway Integration Security Guide.

Logging and detection

"Partner alert" means GitHub notifies the provider when the secret appears in a public repository. Square is not a partner for these types, so a public leak of a Square token depends on your own scanning. Paddle documents what happens on its side: it emails the account owner, automatically revokes high-risk keys, and emits api_key_exposure.created and api_key.revoked webhooks. Subscribe to them and route them to security on-call, not just to the payments team.

• Platform activity to watch: refunds, payout or bank detail changes, new recipients (Mercury), new or modified webhooks, new API keys or OAuth apps, and API calls from unfamiliar IP addresses.
• Reconcile money movement: daily reconciliation of payouts, refunds and transfers against your own systems catches abuse that looks like normal API traffic.
• Inactivity: Mercury notes tokens can be deleted for inactivity; an unexpected "token not found" may be housekeeping, but confirm before assuming.

Measure whether the programme is working:

Leak response, step by step

1. Classify the credential: live or sandbox, key or OAuth secret or token, and what it can do (read, refund, payout, transfer). Sandbox leaks still need rotation but are not a financial emergency.
2. Contain: for money-moving credentials (Mercury Read and Write, Checkout.com secret keys with payment or payout scope, Square personal access tokens), disable first and accept the outage. For read-only credentials, create the replacement first if the outage would be severe.
3. Revoke using the platform's mechanism:
   • Square: replace the token or application secret in the Developer Console (the access token page checked does not describe the steps; confirm in the console).
   • Checkout.com: an Account owner deletes the key in Dashboard, Developers, Keys.
   • GoCardless: API settings, select the token, "Disable access token".
   • Paddle: revoke the key (it may already be auto-revoked) and create a new one with an expiry.
   • Mercury: revoke the token and generate a new one, as Mercury's documentation instructs for exposed tokens.
   • Ramp: Rotate client secret, Create, update the app, then Revoke the old secret, choosing whether to invalidate access and refresh tokens issued with it ("Revoke only" leaves them active). Revoke leaked access and refresh tokens through the token revocation endpoint. A leaked client ID alone is public and needs no rotation.
4. Review activity for the exposure window: Paddle explicitly advises reviewing logs for unauthorised calls before revocation. Look at refunds, payouts, recipient changes, transfers, webhook changes and data exports.
5. Restore the integration with a narrower credential than before, and confirm the old one is rejected.
6. Engage the provider and finance: report suspected fraud to the provider quickly, since recall windows for transfers can be short, and involve finance for reconciliation.
7. Assess notification duties: if cardholder or personal data could have been read, involve your privacy and PCI teams.
8. Fix the cause and follow the Leaked Credential Response Playbook for the post-incident review.

Hardening baseline

For card environments, PCI DSS v4.0 Requirement 8.6 covers application and system accounts, including not hard-coding their passwords in scripts and files, which applies directly to payment API credentials in code. Use of a stolen key against a provider account maps to ATT&CK T1078.004 Cloud Accounts.

Small versus large organisations: a small business with one payment provider should keep one live key per integration in a secrets manager, turn on every alert the provider offers and keep at least two people able to revoke keys. A larger organisation with several providers should centralise key issuance, require approval for any credential that can move money, and run quarterly revocation drills in sandbox.

Where identity fits

Payment keys are non-human identities with direct financial authority. Give each an owner, a purpose, an expiry and an inventory record, and include them in leaver and change processes, because disabling the person who created a token does not disable the token. AI agents that can call payment APIs need tighter limits still. See the Agent Payments Protocols Guide and the API Keys vs OAuth Tokens Guide.

Common misconfigurations

• Personal access tokens in production integrations: a Square personal token gives unrestricted account access when an OAuth token with limited scopes would do.
• One all-powerful secret key: a single Checkout.com secret key covering every API, when per-function keys would limit a leak.
• Read and Write where Read Only would do: Mercury integrations that only report balances holding transfer rights.
• Legacy keys still live: Paddle legacy keys lack permissions and secret scanning.
• Single key owner: only one Checkout.com Account owner able to delete keys, unavailable during an incident.
• Exposure alerts going to a shared inbox nobody reads: auto-revocation emails and webhooks unseen until payments fail.

Practitioner checklist

• Inventory every payment and banking credential with platform, environment, scope, owner and storage location.
• Replace personal and all-powerful keys with scoped OAuth tokens or per-function keys.
• Use Mercury Read Only or Custom scopes unless transfers are genuinely needed, and allowlist IPs for Read and Write.
• Set expiry on Paddle keys and replace any legacy keys created before 6 May 2025.
• Enable GitHub push protection and add your own scanning for Square and GoCardless gaps.
• Route Paddle exposure and revocation webhooks to security on-call.
• Ensure at least two people can revoke keys on every platform.
• Write a per-platform revoke runbook, including Ramp's choice to invalidate issued tokens.
• Reconcile refunds, payouts and transfers daily against internal records.

Standards and references

• GitHub Docs: Supported secret scanning patterns
• Paddle: API keys
• Ramp: What to do if OAuth credentials are leaked
• Mercury: Getting started with the API
• Square: Access tokens and other credentials
• Checkout.com: API keys
• GoCardless: How to create an access token
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Stripe API Keys Security Guide · Leaked Credential Response Playbook · Payment Fraud Guide · Payment Gateway Integration Security Guide