Which description applies to the Secret Key sk_?

Which description applies to the Secret Key sk_?

• A. Use this on the client-side to tokenize payment information.
• B. Use this on the server-side. They must be secret and stored securely in your web or mobile app's server-side code to call stripe APIs.
• C. Use this to sign webhook events.
• D. Use this as public read-only access for dashboards.

Answer: (B)

Secret keys are credentials used to authenticate requests from your server to Stripe. They must stay on your backend and never be exposed in client-side code or apps, because they grant powerful access to your Stripe account. That server-side use is what lets your backend perform actions like creating charges, customers, subscriptions, and other API calls. So, the description that matches this is: use the secret key on the server side, stored securely, to call Stripe APIs. This is why it’s correct for sk_—it’s the credential you keep secret and use only in your server code. Reasons the other descriptions don’t fit: client-side tokenization relies on the publishable key, not the secret key, to safely tokenize payment details without exposing sensitive capabilities. Webhook event verification uses a separate webhook signing secret, not the API secret key. Public read-only access for dashboards would be governed by a different type of key with restricted permissions, not the secret API key used for server-to-Stripe actions.

Secret keys are credentials used to authenticate requests from your server to Stripe. They must stay on your backend and never be exposed in client-side code or apps, because they grant powerful access to your Stripe account. That server-side use is what lets your backend perform actions like creating charges, customers, subscriptions, and other API calls.

So, the description that matches this is: use the secret key on the server side, stored securely, to call Stripe APIs. This is why it’s correct for sk_—it’s the credential you keep secret and use only in your server code.

Reasons the other descriptions don’t fit: client-side tokenization relies on the publishable key, not the secret key, to safely tokenize payment details without exposing sensitive capabilities. Webhook event verification uses a separate webhook signing secret, not the API secret key. Public read-only access for dashboards would be governed by a different type of key with restricted permissions, not the secret API key used for server-to-Stripe actions.