Stripe API keys are credentials that let software identify your account when it communicates with Stripe. The right key makes a payment integration work. A missing, expired, or deleted key causes authentication errors, while an exposed secret key can give someone else powerful access to your account.
This guide explains the key types, the boundary between test and live data, and the safest way to store and rotate credentials. It also clarifies when WP Full Pay needs manual keys. WP Full Pay is the Stripe payment plugin covered on this site.
If your goal is to connect Stripe, build a form, and run a test payment, use the separate Stripe and WordPress integration guide. This article stays focused on the credentials themselves.
Why Stripe API keys matter
Stripe uses API keys to authenticate requests made by your website, server, mobile app, or another connected system. The key tells Stripe which account is making the request and whether that request belongs in a testing environment or in live mode.
A key does not describe what a payment should do. Your integration still supplies the amount, currency, customer, and other request details. The key controls identity and access, so choosing the correct type and protecting it are foundational security tasks.
💡 Important: A publishable key is designed for client-side use. A secret or restricted key belongs on a trusted server only. Never paste a secret key into a page, browser script, mobile app, support message, or public repository.
Types of Stripe API keys and related secrets
Stripe accounts normally have a publishable key and a secret key for testing, plus another publishable and secret pair for live mode. You can create restricted keys when a system needs narrower permissions. Webhook endpoints use a separate signing secret, which is not an API key.
| Credential | Where it belongs | Main purpose |
|---|
| Publishable key | Browser or mobile app | Initializes Stripe’s client-side payment tools without granting secret API access |
| Secret key | Trusted server | Authenticates server-side requests with broad account access |
| Restricted key | Trusted server | Authenticates only the API resources and actions you permit |
| Webhook signing secret | Webhook handler | Verifies that an incoming webhook payload was signed for that endpoint |
Stripe publishable keys
Publishable keys start with pk_test_ in a testing environment and pk_live_ in live mode. They can be included in frontend code because they cannot perform the privileged server-side actions available to a secret key.
Public does not mean interchangeable. A test publishable key only works with test data, and a live publishable key belongs to the live account context. Pair it with the matching mode used by the server-side integration.
Stripe secret keys
Secret keys start with sk_test_ or sk_live_. Stripe’s current API key documentation says a live secret is shown only once when it is created, so move it directly into an encrypted secret store or protected environment variable.
A live secret key can authorize sensitive actions and access private account data. Keep it out of WordPress page content, JavaScript, mobile app bundles, screenshots, analytics, debug output, tickets, chat, and email.
Restricted Stripe API keys
A restricted key lets you choose read or write access for specific Stripe resources. For example, an internal reporting service may need to read balances but should not create payments or issue refunds. Stripe does not create restricted keys by default.
Use least privilege for custom systems and third-party services. Do not substitute a restricted key for a plugin’s documented credential unless the integration specifies the exact permissions it needs.
Webhook signing secrets
A webhook signing secret usually starts with whsec_. It does not authenticate your outbound API calls. Instead, your webhook handler uses it with the raw request body and the Stripe-Signature header to verify incoming events.
Each webhook endpoint has its own signing secret, and a secret produced by the Stripe CLI is different from the secret for a Dashboard-managed endpoint. The webhook signature guide explains this distinction.
Test, sandbox, and live modes
Testing and live environments keep separate keys and separate Stripe objects. A customer, product, price, subscription, or webhook endpoint created for testing does not automatically become a live object. This separation helps you test safely without changing live customers or charges.
When to use Stripe test mode or a sandbox
Use test mode or a Stripe sandbox while building, changing, or troubleshooting an integration. Use Stripe’s documented test payment methods rather than real card details. Confirm successful payments, expected failures, refunds, subscriptions, and webhook handling before touching live credentials.
When to switch to live mode
Switch only after the complete payment flow works in testing and the live Stripe account is ready to accept payments. Replace both sides of the key pair, confirm that forms reference live products and prices, and check live webhook configuration. A mixed test and live configuration is a common cause of missing objects and failed requests.
How to access your Stripe API keys
- Sign in to the Stripe Dashboard with a role that can manage API keys.
- Open the API keys page. Stripe may present this through its Developers area or Workbench as the interface evolves.
- Confirm that you are viewing the intended testing environment or live mode before copying anything.
- Copy the publishable key if the client-side integration needs it. Create or reveal a secret key only when the server-side integration requires one.
- Name new secret or restricted keys for the system that uses them, store them immediately, and record where each key is deployed.
Never copy a credential simply because a tutorial shows a key field. First verify the integration’s current connection method and the required mode.
How WP Full Pay uses Stripe API keys
For ordinary WP Full Pay setup, manual API keys are no longer required from version 7.0 onward. The standard flow uses Stripe Connect. In WordPress, open Full Pay → Settings → Stripe account and use the connection controls shown for the selected mode.
The official WP Full Pay API key guide documents two exceptions: customized code that uses the plugin’s internal API, and the WP Full Members add-on. Those cases can require direct Stripe secret keys for test and live operation.
📖 Keep the setup scopes separate: Use this article to understand credentials. Use the integration guide for the complete Connect, form, test, and go-live workflow.
How to keep Stripe keys safe
- Store secrets outside code. Use a secrets manager, encrypted deployment variable, or another protected server-side store.
- Limit human access. Give key-management permissions only to people who need them, then review access when roles change.
- Use least privilege. Prefer a restricted key for a custom service when the required API permissions are known.
- Restrict source IP addresses. Stripe supports IP restrictions for secret and restricted keys when your server has stable outbound addresses.
- Monitor request logs. Look for unknown IP addresses, unexpected API resources, or unusual request volume.
- Practice rotation. Document every deployment that uses a key so you can replace it quickly without leaving an old copy behind.
Stripe’s secret-key best practices recommend treating any unintended exposure as a potential compromise. Searching repositories, configuration, and deployment pipelines for live secret and restricted key patterns can help you find accidental leaks.
What to do if a Stripe key leaks
Rotate an exposed secret or restricted key immediately, even if there is no confirmed misuse. Replace it in every system that needs it, verify that those systems now use the new credential, and expire the old key. If a short delayed expiration is necessary to avoid downtime, keep that window as short as possible.
Next, review Stripe’s API request logs for activity you do not recognize. If the affected server or credential store may have exposed more than one key, rotate every potentially affected secret and restricted key. Contact Stripe support when the logs show unknown activity.
⚠️ Do not test a leaked key. Rotating first limits risk. Investigation comes after the exposed credential can no longer authenticate requests.
Stripe API key questions
Is a Stripe publishable key safe to use in a browser?
Yes. Stripe designs publishable keys for client-side code. They do not grant the privileged API access of secret or restricted keys. Use the publishable key for the correct account and mode, and never place a secret key beside it.
Can you retrieve a Stripe secret key later?
A newly created live secret key is displayed once. If the saved value is lost, create or rotate to a replacement rather than copying a secret from an untrusted location.
Does WP Full Pay need manual Stripe API keys?
Not for the ordinary Stripe Connect setup in WP Full Pay 7.0 and later. Manual secret keys remain relevant for the documented internal API and WP Full Members exceptions, as well as older installations that were connected manually.
Is a webhook signing secret an API key?
No. It verifies webhook signatures for one endpoint. It does not replace a publishable, secret, or restricted API key. For the full WordPress notification flow, read the Stripe webhooks guide.
A practical Stripe API key checklist
- ✅ Confirm the account and mode before copying a key.
- ✅ Keep publishable keys on the client and secret credentials on the server.
- ✅ Use Stripe Connect for a standard WP Full Pay connection.
- ✅ Give custom systems only the permissions they need.
- ✅ Track every place where a secret or restricted key is deployed.
- ✅ Rotate immediately after exposure and review request logs.
You can install WP Full Pay from WordPress.org, connect your Stripe account, and test a payment form before switching to live mode.