Payment gateway API keys: treat machine credentials like bank credentials

Payment gateways use API keys, secrets and webhook credentials to let websites and back-end systems create payments, refunds and other financial actions. A leaked key can be as dangerous as a compromised payment user, so machine credentials need controlled storage, limited permissions and rapid rotation.

Never place secret keys in public code or browser scripts

Payment providers separate publishable or client-side identifiers from secret server credentials. Secret keys should remain on secure back-end systems.

Do not commit live keys to public repositories, share them in chat or hard-code them in mobile applications where users can extract them.

Separate test and live credentials

Development and staging systems should use test-mode keys and fake payment data wherever possible. Live credentials belong only in production or tightly controlled operational tooling.

This reduces the chance a developer experiment issues a real refund or charge.

Use restricted keys and service roles where supported

If an application only reads balances, it should not have permission to create refunds or payouts. Least privilege limits damage if one service is compromised.

Document which system owns each key and which operations it can perform. Unowned credentials should be revoked.

Use a secrets manager or secure key vault

Store production secrets outside source code and configuration files that are broadly accessible. Use platform secrets management, access logging and encryption.

Restrict who can reveal values even if they can deploy the application. Developers often need systems to use a secret without needing to see it.

Verify webhook signatures

Merchants should verify signed webhook messages from the payment provider rather than trusting any internet request claiming a payment succeeded.

Without signature verification, an attacker can send a fake "payment complete" event and trigger fulfilment without real settlement.

Rotate and investigate immediately after exposure

If a secret key is exposed, revoke or rotate it through the provider, update dependent systems and review logs for unauthorised charges, refunds or configuration changes.

Do not merely delete the leaked Git commit. Assume the key was copied once it became accessible outside the controlled environment.

Worked example: a developer accidentally commits a live refund-capable key to a public repository for ten minutes. Even after the repository is made private, the company should rotate the credential and review activity because automated scanners can capture secrets almost immediately.

Keep an API credential inventory with owner, environment, permissions, creation date and rotation history. Machine access should receive the same periodic recertification as human payment users.

Use monitoring for unusual API behaviour such as a burst of refunds, new payout destinations or access from unexpected systems. Credential security is stronger when misuse is detectable as well as difficult.

Separate refund permissions from payment-creation permissions. A fulfilment service may need to read payment status but should not be able to issue refunds or change payout destinations. Narrow scopes reduce the blast radius if one microservice is compromised.

Rotate credentials on employee and vendor changes, not only on a fixed calendar. When an external developer or agency loses access, confirm that no shared production secret remains in their systems or deployment pipelines.

Keep webhook endpoints protected against replay where the provider supports timestamps or event IDs. A valid old event should not be able to trigger shipment twice simply because its signature is genuine.

Use separate keys for separate services where possible. If checkout, refunds and reporting all share one master secret, an incident in the reporting service can expose unnecessary payment authority. Segmented credentials make rotation and investigation easier.

Protect continuous-integration and deployment systems because they often hold production secrets. A secure application can still be compromised if an attacker gains access to the pipeline that injects live API keys during deployment.

Set alerts for newly created API keys and permission changes. An attacker with dashboard access can create a fresh credential that survives after the original password is reset. Administrative events deserve monitoring alongside payment transactions.

Document an emergency rotation procedure and test it. A company discovering a leaked key at midnight should know which services depend on it, who can revoke it and how to deploy the replacement without taking checkout offline for hours.

Restrict production dashboard access with MFA and role-based permissions. Protecting the key in code is not enough if any employee with a shared admin password can reveal, create or rotate live credentials from the provider console.

Keep test keys out of public repositories too. Although they may not move real money, they can reveal account structure, webhook endpoints or integration logic useful to an attacker preparing a production compromise.

Review secret-management controls during vendor audits and penetration tests. Payment keys often sit outside the main application database, so security testing should include deployment pipelines, environment variables and cloud-secret stores rather than examining only checkout code.