A payment service provider runs almost entirely on machine credentials: the keys in its HSMs, the API keys it issues to every merchant, the certificates and signing keys that connect it to card schemes, and the service accounts that glue its platform together. Most guidance looks at one of these in isolation. This guide looks at them together from the PSP's side, as a single non-human identity estate with one inventory, one ownership model and one set of lifecycle controls. It covers the four credential families, how to design merchant credentials so leaks are found and revoked quickly, how to run scheme connectivity credentials, and how this maps to PCI DSS and PCI PIN. It is for PSP, payment facilitator, gateway and acquirer processor security and platform teams. Deep detail on HSMs and on merchant-side leak response is in linked guides and is not repeated here.
Key takeaways
- Four credential families, one inventory. HSM keys, merchant-facing credentials, scheme and acquirer connectivity credentials, and internal workload identities need a single register with owners, expiry and blast radius.
- You are the issuer as well as the user. Every merchant API key and webhook secret you mint is a credential you must be able to detect when leaked and revoke without breaking the merchant.
- Design keys to be found. A unique prefix, high-entropy body and checksum let public secret scanning programmes spot your tokens and send them to you for revocation.
- Scheme credentials are long-lived and critical. Mutual TLS client certificates and request signing keys connect you to card networks; an expired one is an outage and a leaked one is an impersonation risk.
- Separate keys from the data they protect. Encryption keys kept beside card data, and secrets readable by any workload, turn one foothold into a card data breach.
The PSP credential estate
The table below is the map we recommend PSPs start from (NHI Mgmt Group guidance). Each family has different owners, different standards and a different failure mode, which is why they drift apart without a common register.
| Family | Examples | Typical owner | Main standard | Failure if mismanaged |
|---|---|---|---|---|
| HSM and cryptographic keys | Zone and key encryption keys, PIN encryption keys, base derivation keys, card data encryption keys, tokenisation keys | Key custodians, crypto operations | PCI PIN Security, PCI DSS key management, NIST SP 800-57 | Decryption of PINs or stored card data; costly re-keying with partners |
| Merchant-facing credentials | Secret API keys, publishable keys, restricted or scoped keys, webhook signing secrets, OAuth clients for platforms | Developer platform and merchant onboarding | PCI DSS (as a service provider), your own key design | Fraudulent refunds and payouts, data access, merchant account takeover |
| Scheme and acquirer connectivity | Mutual TLS client certificates, request signing keys, host-to-host link keys, SFTP keys for settlement files | Scheme integration, network operations | Scheme developer and connectivity rules | Impersonation of the PSP to the network; outage at expiry |
| Internal workload identities | Service accounts, database accounts, cloud roles, CI/CD tokens, secrets manager access | Platform engineering, identity team | PCI DSS requirements for system and application accounts, cloud provider controls | Lateral movement into the cardholder data environment |
For a general approach to building the register, see the API Key Management Guide and the Machine Identity, PKI and Certificate Lifecycle guide.
HSM keys: what the PSP adds to the HSM guide
Payment HSMs, key hierarchies and TR-31 key blocks are covered in the Payment HSMs guide, and the operational rules for PIN key management in the PCI PIN Security and Key Management Operations Guide. PCI SSC describes the PIN Security Standard as covering the secure management, processing and transmission of PINs, with key lifecycle requirements spanning creation, conveyance, loading, usage and administration. Applicability is decided by the payment brands and acquirers that run compliance programmes, so confirm with yours.
The PSP-specific points that sit on top:
- Treat HSM application credentials as NHIs: the host applications that call the HSM authenticate to it. Those credentials, and the service accounts behind them, belong in the same register and the same access reviews as the keys.
- Record every key exchange partner: each acquirer, processor or scheme link has its own zone key and exchange ceremony. Keep the partner, key check value, custodians and next rotation date together.
- Keep data encryption keys away from data stores: keys for stored card data or token vaults should live in an HSM or key management service, with application access by a narrowly scoped identity.
- Plan cryptoperiods with partners: NIST SP 800-57 Part 1 Rev. 5 sets out general key management practice, including protection by key type. Agree rotation schedules with each counterparty in advance, as re-keying a shared zone key is a joint operation.
Merchant-facing credentials: designing keys you can protect
As a PSP you mint credentials for thousands of merchants whose security you do not control. Those keys will appear in public repositories, mobile apps and support tickets. The design choices below decide whether that becomes a quick revocation or a fraud loss. They are NHI Mgmt Group recommendations.
| Design choice | What to do | Why it helps |
|---|---|---|
| Recognisable format | Unique prefix per key type and environment, high-entropy random body, checksum | Lets your own scanners and public secret scanning programmes match your tokens with few false positives |
| Separate publishable and secret keys | Publishable keys for client-side use with no power to move money or read data; secret keys server-side only | A key embedded in a web page or app cannot be used for refunds or payouts |
| Scoped or restricted keys | Let merchants create keys limited to specific resources and actions (for example read-only reporting) | Integrations hold only what they need; a leaked reporting key cannot issue refunds |
| Test and live separation | Different prefixes and different backends for sandbox and production keys | Test keys shared in code samples cannot touch real funds |
| Rolling rotation | Allow a new key to be issued while the old one stays valid for a set overlap, then expires | Merchants rotate without downtime, so they actually do it |
| Optional network restrictions | Per-key IP allow lists for server-to-server keys | A stolen key fails from attacker infrastructure |
| Signed webhooks | Per-endpoint signing secrets, timestamp in the signed payload, merchant-side verification guidance | Merchants can reject forged or replayed events |
| Visible key metadata | Created by, last used, last used from, scopes, expiry shown in the dashboard and API | Merchants can find unused or misused keys |
Joining public secret scanning programmes
Code hosting platforms run partner programmes that scan public content for issuers' token formats and send matches to the issuer. GitHub's secret scanning partner program, for example, asks the provider for a name and precise regular expression per secret type, a test account and an endpoint URL. GitHub posts matches found in public sources to that endpoint, which must verify the request signature (the Github-Public-Key-Signature header, using ECDSA-NIST-P256V1-SHA256 against the raw body) before acting. GitHub recommends treating reported secrets as public and compromised. Matches in private repositories go to the repository's admins and committer rather than to the provider.
For a PSP the receiving service should: verify the signature, look up the key, revoke or suspend it according to its type (we recommend immediate revocation for live secret keys), notify the merchant through a verified channel, and log the event for fraud monitoring. Merchant-side response steps are in the Payment API keys beyond Stripe guide, and webhook design is covered in the Webhook Secrets Security Guide.
Scheme and acquirer connectivity credentials
Connections to card networks and acquirers use some of the most sensitive and longest-lived credentials a PSP holds. The two largest card schemes' developer platforms show the two common patterns. Schemes are listed alphabetically; this is not a ranking, and each scheme's current documentation is the authority for its settings.
| Scheme developer platform | Credential pattern described in its docs | Lifecycle points to manage |
|---|---|---|
| Mastercard Developers | OAuth 1.0a request signing: a consumer key identifies the application and a 2048-bit RSA signing key signs each request with RSA-SHA256, with a nonce and timestamp for replay protection | Keys are created and managed per project in the Project Dashboard. Renewing before expiry keeps the consumer key; revoking issues new keys and a new consumer key |
| Visa Developer | Two-way SSL (mutual TLS): a client certificate issued for the project from a CSR, plus an HTTP Basic username and password per credential; Visa also uses it for outbound callbacks | Credentials are managed under Credentials, Two-Way SSL in the project; CA certificates differ between Sandbox and Certification or Production |
Controls we recommend for this family:
- Generate private keys where they will be used, ideally in an HSM or key management service: submit your own CSR rather than receiving a generated private key where the platform offers the choice.
- Separate environments completely: different keys, certificates and secrets stores for sandbox, certification and production, with production access limited to the runtime identity.
- Track expiry centrally: put every scheme certificate and signing key in your certificate inventory with alerts well ahead of expiry, and rehearse renewal. See the mTLS Guide.
- Store companion secrets with the certificate: the Basic credentials or key passwords that accompany a certificate are as sensitive as the key; keep them in the secrets manager, not in configuration files.
- Know the revocation path: document how to revoke and reissue each scheme credential out of hours, who can do it, and what changes downstream.
- Apply the same to acquirer links and settlement transfers: host-to-host keys and SFTP keys for settlement and dispute files are often forgotten because they change rarely.
Internal workload identities
The rest of the platform, from authorisation services to the token vault, runs on service accounts, cloud roles and database credentials. PCI DSS v4 includes requirements for managing system and application accounts and protecting their passwords; the detail is in the PCI DSS Requirements for Service Accounts and NHIs Guide. For PSPs, three points stand out:
- Split the vault: scope secrets per workload, so the service that renders a dashboard cannot read the tokenisation key or the scheme signing key.
- Alert on bulk secret reads: a workload reading dozens of secrets it does not normally use is an early sign of compromise.
- Prefer short-lived credentials: workload identity federation and dynamically issued database credentials expire on their own, unlike passwords in configuration files.
The AI Agent Retail Card Theft Campaign 2026 is a merchant-side case, but it shows each failure in miniature: database credentials in a configuration file, a bulk dump of secrets from a cloud secrets manager, a storage key with write access it did not need, and an encryption key kept near the card data it protected.
Implementation: a phased programme
- Inventory (weeks 1 to 6): build one register of all four families with owner, purpose, location, expiry, last rotation and blast radius. Start with scheme and HSM credentials because they are fewest and most critical.
- Quick wins (weeks 4 to 10): move scheme companion secrets and HSM application credentials into the secrets manager; add expiry alerts; remove stale merchant keys unused for a period you set.
- Merchant key design (one to two quarters): introduce prefixed, checksummed formats for new keys, scoped keys and rolling rotation. Run old and new formats side by side, and migrate merchants with dashboard prompts rather than forced cut-overs.
- Leak intake: join public secret scanning partner programmes, build the verified intake endpoint, and test it with test-mode keys before enabling automatic revocation of live keys.
- Workload identity: replace static internal credentials with short-lived ones, starting with services inside the cardholder data environment.
- Test and roll back: rehearse a scheme certificate renewal and a zone key rotation in certification environments; keep the previous credential available until the new one is proven, then revoke it.
Decision guidance
- Small PSP or payment facilitator: lean on a cloud HSM or the acquirer's key management where contracts allow, and focus effort on merchant key design and scheme credential expiry tracking.
- Large or multi-region PSP: dedicate a crypto operations function, automate partner key exchange records, and run the leak intake service as a production system with an on-call owner.
- Automatic versus manual revocation: revoke automatically for publicly exposed live secret keys; for restricted or test keys, notify first and revoke on a short timer.
Detection and measurement
- Log: merchant key creation, use, source IP and scope; HSM command and administrator activity; scheme API authentication failures; secrets manager reads by identity; certificate issuance and renewal.
- Alert on: a merchant key used from a new country or hosting provider; refund or payout spikes on one key; bulk secret reads; authentication with a revoked key; scheme credentials used outside the production runtime.
Metrics:
- Register coverage: share of credentials in all four families with an owner and expiry recorded.
- Leak to revoke time: median minutes from a partner programme report to revocation of a live key.
- Scoped key adoption: share of merchant API traffic using scoped keys rather than full-access secret keys.
- Expiry headroom: number of scheme and partner credentials expiring within 30 days without a renewal ticket.
- Static internal secrets: count of long-lived passwords and keys in configuration files inside the cardholder data environment.
Framework mapping
| Control area | PCI standards | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| Cryptographic key management | PCI PIN Security; PCI DSS key management requirements | SC-12, SC-13 | PR.DS-01 |
| System and application accounts | PCI DSS system and application account requirements | IA-5, AC-6 | PR.AA-01 |
| Certificates and mutual TLS | PCI DSS protection of data in transit | SC-8, SC-17 | PR.DS-02 |
| Monitoring credential use | PCI DSS logging and monitoring | AU-6, SI-4 | DE.CM-09 |
| Third parties and merchants | PCI DSS third-party service provider requirements | SA-9, SR-6 | GV.SC-07 |
For how responsibilities split between a PSP and its merchants, see PCI DSS for Service Providers and Responsibility Matrix Guide.
Common failure patterns
- Merchant keys with no recognisable format: leaks in public code go unnoticed because neither scanners nor the PSP can tell the string is a live key.
- One all-powerful merchant key: the same key serves the checkout page, the reporting job and the refund tool, so any leak exposes everything.
- Scheme certificate expiry surprises: renewal depends on one engineer's calendar, and the first sign is failed authorisations.
- Companion secrets in configuration files: the private key is protected but the Basic credentials or keystore password sit beside it in plain text.
- Encryption keys next to the data: a database or file share holds both the encrypted cards and the key, as the card theft campaign showed on the merchant side.
- Flat secrets access: any service can read any secret, so one compromised workload reaches the token vault.
Practitioner checklist
- Build one register covering HSM keys, merchant credentials, scheme and acquirer credentials and internal workload identities.
- Record every key exchange partner with key check values, custodians and next rotation date.
- Issue merchant keys with a unique prefix, high-entropy body and checksum, separate test and live.
- Offer scoped keys, rolling rotation and per-key IP allow lists to merchants.
- Join public secret scanning partner programmes and verify every incoming report's signature.
- Generate scheme private keys in an HSM or key management service and track every expiry centrally.
- Keep certificate companion secrets and keystore passwords in the secrets manager.
- Scope secrets per workload and alert on bulk reads.
- Rehearse scheme credential renewal and partner re-keying in certification environments.
Standards and references
- PCI Security Standards Council: PIN Security
- PCI Security Standards Council: PCI Data Security Standard
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- Mastercard Developers: Using OAuth 1.0a to Access Mastercard APIs
- Visa Developer: Two-Way SSL
- GitHub Docs: Secret scanning partner program
Related NHI Mgmt Group resources: Payment HSMs · Payment API keys beyond Stripe · Network Tokenisation for Payments Guide · Payment Gateway Integration Security Guide