Stripe allows you to begin accepting payments in only a matter of minutes. But there are certain steps you should take before going live, enumerated in the two checklists below:
- One specific to your Stripe account, intended for account holders
- One specific to your Stripe integration, intended for developers
You'll want to review one or both checklists, depending on your particular situation.
Your Stripe account checklist
The items within this checklist focus on your Stripe account itself. The ideas apply whether you have an account through a connected website, simply use a Stripe plugin, or developed a custom integration (yourself or through a developer).
For security purposes, we highly recommend enabling two-step authentication on your Stripe account, which adds an additional requirement to log in. With two-step authentication, not only are your username and password needed, but you'll also have to provide a code received by your mobile device. This makes it much harder for someone else to access your Stripe account.
(Two-step authentication is also sometimes called "two-step verification" or "two factor authentication" or "2fa", all of which refer to the same concept.)
The statement descriptor appears on customer statements when you charge their card. Missing or incorrect information can result in confused customers creating disputes, so review your information in the Dashboard. Statement descriptors are limited to 22 characters and must not consist solely of numbers.
You may also want to have text on your site telling the user what they'll see on their statements.
Note that the card issuer can automatically include other account information—e.g., business name, address, email, or phone number—to show on your customer's statements. Check that all of this information in your Stripe account is fine for your customers to see.
Stripe can automatically send emails for some account activity. At the very least, we recommend you specify that you'd like to be emailed for successful charges and disputes. (There are other notification settings, but those two are the most important.)
These settings are specific per team member, so your preferences won't affect anyone else's.
Fraud and disputes are unfortunate realities in all commerce, although Stripe is constantly improving its tools to help reduce both. Still, your diligence is imperative, and before going live we recommend you're set up to:
If you process charges in multiple currencies and have multiple bank accounts, also confirm you've established the correct default currency. Multiple bank accounts for additional currencies are optional as Stripe can convert any payments into your default currency.
When reviewing your bank information, set your preferred transfer schedule. The recommended and default option is daily—as funds become available—but you can change this to best suit your business and reporting needs.
Stripe supports a team of people being able to access the same Stripe account. Different team members can even be given different permissions corresponding to their roles.
Please use this capability and do not give others your login credentials. After inviting a team member, recommend they use two-step verification on their login as well.
Once a team member no longer needs access to your Stripe account, be certain to remove them.
Your Stripe integration checklist
If you are a developer, or had a developer perform an integration for you, you should also consider the following items before going live. If you're using Stripe through a connected website or a plugin, most won't apply.
We've created several test values you can use to replicate various states and responses. Beyond these options, perform your due diligence, testing your integration with:
- Incomplete data
- Invalid data
- Duplicate data (e.g., retry the same request to see what happens)
We also recommend you have someone else test your integration, especially if that other person isn't a developer themselves.
Once you've gone live is an unfortunate time to discover you've not properly written your code to handle every possible error type, including those that should "never" happen. Be certain your code is defensive, handling not just the common errors, but all possibilities.
When testing your error handling, especially watch what information is shown to your users. A card being declined (i.e., a
card_error) is a different concern than an error on your backend (e.g., an
Stripe logs every request made with your API keys, with these records being viewable in the Dashboard. We recommend that you log all important data on your end, too, despite the apparent redundancy. Your own logs will be a life-saver if your server has a problem contacting Stripe or there's an issue with your API keys—both cases would prevent us from logging your request.
Regularly examine your logs to ensure they're storing all the information you may need and they aren't storing anything of a sensitive nature (e.g., credit card details or personally identifiable information).
Stripe objects created in test mode—such as plans, coupons, products, and SKUs—are not usable in live mode. This prevents your test data from being inadvertently used in your production code. When recreating necessary objects in live mode, be certain to use the same ID values (e.g., the same plan ID, not the same name) to guarantee your code will continue to work without issue.
Your Stripe account can have both test and live webhook endpoints. If you're using webhooks, make sure you've defined live endpoints in your Stripe account. Then confirm that the live endpoint functions exactly the same as your test endpoint.
While examining your webhooks status, also take a moment to check that your production endpoint:
- Gracefully handles delayed webhook notifications
- Gracefully handles duplicate webhook notifications
- Does not require event notifications to occur in a specific order
We recommend all developers subscribe to our API updates mailing list to keep up with new features as we release them.
As a security measure, we recommend rolling your API keys on a regular basis, and also just before going live. This is in case they have been saved somewhere outside of your codebase during development. Make sure your workflow doesn't result in your API keys being represented or stored in multiple places—this leads to bugs—or even ending up in your version control software.