Stripe Sandbox for Bookkeepers: Test Before It Goes Live

A bookkeeper is asked to sign off on a change. The business wants to start offering a 14-day free trial on its Stripe subscriptions, or switch refunds from full to partial, or finally decide what to do with disputes. Every one of those changes produces records in Stripe, and every one of those records ends up in QuickBooks. The usual way to find out what they look like is to make the change on the live account and wait for the first real customer to hit it.

That is backwards. Stripe gives every account an isolated place to run the exact scenario first, with test cards that produce disputes, failed refunds and subscription renewals on demand, and a clock you can move forward a month at a time. Developers use it constantly. The person who signs off on the books rarely does, and that person is the one who most needs to see the records before they are real.

This guide is the finance-side case for a Stripe sandbox: what it is, which accounting scenarios you can rehearse in one, and what it cannot tell you. It is bookkeeping guidance, not tax or legal advice.

If you want the live Stripe activity in your QuickBooks file without building any of this yourself, Acodei syncs it. Start a free trial.

What a Stripe sandbox is

Stripe's definition is short: "A sandbox is an isolated test environment." Payments you create there "aren't processed by card networks or payment providers," so nothing moves real money, and nothing you do in a sandbox touches your live account.

A few properties matter to someone who is not writing code:

• You can have up to five. Stripe caps an account at five sandboxes. Name each one for its purpose, for example "Refund policy test" or "Annual plan rehearsal".
• A sandbox can start as a copy of your live settings. When you create one, the option "Copy live account to sandbox" is on by default and copies settings and capabilities from your existing account. Leave it on when the point is to rehearse a change against the configuration you actually run.
• You can be invited without seeing live data. Stripe lets a business invite another user, "such as an implementation partner or design agency," to all sandboxes or a specific one, "without providing them access to your live mode data." An outside bookkeeper or accountant can be given a sandbox to test in without any view of real customers.
• Deleting one is permanent. Stripe's note: "Deleting a sandbox deletes all the data associated with the sandbox." There is no undo.

You open a sandbox from the account picker in the Stripe Dashboard: Switch to sandbox, then Create sandbox or Manage sandboxes. A banner at the top of the Dashboard tells you when you are in one.

Stripe also still has an older test mode, which it now describes as the "test mode sandbox." Its guidance is to use general sandboxes for new work and keep the test mode sandbox for existing integrations that depend on it. For a bookkeeper, the practical point is to create a named sandbox for each rehearsal rather than reusing whatever test data is lying around, because Stripe recommends separate sandboxes so automated tests "don't affect your settings or data."

Why the bookkeeper is the one who should use it

Every setting change in Stripe has an accounting consequence. Turning on trials creates zero-value invoices. A partial refund followed by a dispute produces two separate balance movements. A failed refund puts money back in the balance after it has already left. None of these are exotic. They are the ordinary events that turn up in the first month after a change, and they are where a reconciliation goes wrong.

A developer testing the same change is checking that the checkout works and the webhook fires. They are not checking which account the dispute fee lands in, or whether the trial invoice will show up as a sale. If the person who owns the books never sees the scenario before it goes live, nobody does.

We covered how Stripe settings changes reach your books separately. A sandbox is how you look at those consequences before you commit to them.

What you can rehearse

Stripe publishes test card numbers that behave in specific, repeatable ways. In a sandbox, you take a payment with one of these numbers from the Dashboard and Stripe produces the event that card is designed to produce. Here are the ones that matter for the books.

Disputes, start to finish

Test card	What Stripe does
4000 0000 0000 0259	The payment succeeds, and Stripe creates a fraudulent dispute during the payment request.
4000 0000 0000 2685	The charge succeeds, then is disputed as product not received.
4000 0000 0000 1976	The charge succeeds, then is disputed as an inquiry.
4000 0004 0400 0079	The charge succeeds, then is disputed multiple times.
4000 0084 0000 0795	The payment succeeds. If you then partially refund it, Stripe creates a fraudulent dispute for the amount that was not refunded.

The last card is the most useful one for a bookkeeper. Stripe's own example: "refunding 3 USD of a 10 USD payment creates a 7 USD dispute." That is the exact sequence that confuses people in a live account: a sale, a partial refund, and a dispute for the remainder, three movements on one charge, and no single number that is obviously "the" loss.

You can also decide how each dispute ends. Stripe lets you submit evidence that simulates winning or losing, and for an inquiry, evidence that either closes it or escalates it to a full chargeback, which, in Stripe's words, "debits your account for the amount of the dispute and related fees." Run both outcomes. A won dispute and a lost dispute leave different trails in the balance, and you want to have seen both before the first real one arrives. The inquiry case has its own accounting wrinkle, because an inquiry is not yet a chargeback.

A refund that fails after it succeeds

Test card 4000 0000 0000 5126 makes the charge succeed. Refund it, and the refund starts as succeeded, then "after a few minutes, its status transitions to failed" and Stripe sends a refund.failed event.

This is worth seeing because of what it does to the timeline. The money left the balance when the refund was created, and comes back when it fails. If those two dates fall in different months, the month-end numbers look wrong in both. We explain how a failed Stripe refund reaches QuickBooks in detail. The sandbox is where you watch the two events happen, a few minutes apart instead of a few days.

Subscriptions, months ahead

Subscription changes are the hardest to rehearse on a live account, because their consequences arrive at the next renewal. Stripe's answer is test clocks. In a sandbox you open a subscription, click Run simulation, and advance simulated time "by any increment, up to two subscription intervals at a time." For a monthly plan, that is two months per step.

Stripe's own walkthrough for a 7-day free trial shows what you will see. The subscription starts in trialing status and "generates a zero-value invoice for the free trial." Advance the clock past the trial and the first real invoice is created and paid. Advance one more cycle and the subscription renews.

For the books, the zero-value invoice is the interesting record. It is a real Stripe invoice with nothing on it, and the question of whether it should appear in QuickBooks at all is one you want answered before a thousand of them exist. Stripe also suggests using test clocks to rehearse "a payment failure at an annual renewal without waiting a year," which is the event that tests your revenue schedule and your collections process at the same time.

When you are done, Finish simulation deletes the customer, the subscription and everything attached to them from the sandbox. Stripe notes that it "doesn't affect live mode."

Funds you can actually see in the balance

By default, a successful test payment goes to the pending balance. Test card 4000 0000 0000 0077 is the exception: "Funds are added directly to your available balance, bypassing your pending balance." Use it when the scenario you are rehearsing needs available funds, such as a refund from balance.

Your month-end queries

Stripe Sigma, the SQL reporting tool inside the Dashboard, is free in sandboxes. Stripe's wording: "Sigma is free to use in sandboxes, with no usage limits. You can run unlimited queries against your test data at no cost. Activities in sandboxes don't count toward your charge-based entitlement and don't incur any fees."

That makes a sandbox the place to build and check the Sigma queries you use at month end. Run a handful of the scenarios above, then write the query that is supposed to find them. If the query misses the partial-refund dispute you just created on purpose, it will miss the real one too.

What a sandbox cannot tell you

The sandbox is a rehearsal, not a replica. Four limits matter to the books.

Settlement timing is different. Stripe says plainly that test transactions "settle instantly and are added to your available test balance," and that this "differs from live mode, where transactions can take multiple days to settle." Any question that depends on when money becomes available, such as which payout a charge lands in, or whether a month-end charge is in this month's deposit, cannot be answered in a sandbox. Settlement timing is something you only learn from live data.

Some pricing cannot be tested. Stripe lists one pricing limitation outright: "You can't test IC+ pricing in a sandbox." If your account is on interchange-plus pricing, the fee structure is something to confirm against live statements, not sandbox data.

Connect platforms are partly out of reach. Stripe states: "You can't create connections between a Connect platform's sandbox and connected account sandboxes." A platform can rehearse its own side, but not the full chain through to a connected account's sandbox.

Your other systems may not be connected. A sandbox has its own keys (Stripe's sandbox secret keys start with sk_test_), and any tool that reads from Stripe has to be pointed at those keys to see sandbox activity. Whether a given accounting integration can connect to a sandbox is a question for that integration's vendor. Ask before you plan a rehearsal that depends on it, and if the answer is no, the rehearsal stops at the Stripe records. That is still worth doing. Knowing exactly which balance transactions a change produces is most of the work.

The QuickBooks side of a rehearsal

QuickBooks has a practice environment too, but it is built for a different job. Intuit's test drive opens a demo company, "Craig's Design and Landscaping Services," which you reach by signing out of your Intuit Account or using a private browser window.

Two of Intuit's rules decide what it is good for. First: "The demo doesn't save any changes you make, so go ahead and experiment." Second: "we don't let you connect this test company to your bank." Intuit's advice is that "if you need to test online banking, use either an active or trial QuickBooks Online account."

So the test drive is the right place to practice a QuickBooks procedure: recording a refund receipt by hand, setting up a new account in the chart of accounts, seeing what a deposit screen looks like. It is the wrong place to keep the results of a rehearsal, because nothing persists. For a rehearsal you want to come back to, with the accounts and products set up the way you plan to run them, a separate trial QuickBooks Online company is the option Intuit itself points to.

A rehearsal, start to finish

Here is the shape of a useful session, using a partial-refund policy change as the example.

1. Create a named sandbox with "Copy live account to sandbox" left on, so your products, prices and settings match the live account.
2. Write down the question before you start. For example: "If we refund 30% of an order and the customer still disputes, what does the balance show, and which QuickBooks accounts does each movement belong in?"
3. Run the scenario. Take a 100.00 payment with 4000 0084 0000 0795, refund 30.00, and let Stripe create the 70.00 dispute.
4. Read the balance transactions, not just the payment. Open the payment in the Dashboard and look at every balance movement attached to it: the charge, the refund, the dispute. Each one is a row your books have to handle, and Stripe's balance transaction types are what decides where each row should go.
5. Run the losing and the winning outcome on two separate payments, so you have seen both trails.
6. Write the answer down as a short note: the records produced, the accounts they belong in, and anything that surprised you. That note is the sign-off.
7. Finish or delete the simulation or the sandbox when you are done, so the next rehearsal starts clean.

The whole session takes less time than investigating one real dispute that was booked to the wrong account.

Common mistakes

• Rehearsing in a blank sandbox. A sandbox without your live settings tests Stripe's defaults, not your configuration. Copy the live account unless you specifically want a clean slate.
• Treating sandbox timing as real. Instant settlement makes every scenario look tidy. Do not draw conclusions about payout timing or month-end cutoffs from a sandbox.
• Testing only the happy path. The successful payment is the one scenario that rarely causes an accounting problem. Spend the time on disputes, failed refunds and renewals.
• Leaving the sandbox full of old tests. Five sandboxes is the cap. Name them, finish simulations when you are done, and delete the ones you no longer need, remembering that deletion cannot be undone.
• Assuming the QuickBooks test drive keeps your work. It does not save changes. Use a trial company for anything you want to come back to.

Frequently Asked Questions

What is a Stripe sandbox?

It is an isolated test environment inside your Stripe account. Payments created in a sandbox are not processed by card networks or payment providers, so no real money moves, and nothing you do there affects your live account. An account can have up to five sandboxes, and each can start as a copy of your live settings.

Can my bookkeeper use a Stripe sandbox without seeing live data?

Yes. Stripe lets you invite another user, such as an implementation partner, to all sandboxes or to a specific one without giving them access to live mode data. That lets an outside bookkeeper or accountant rehearse changes without any view of real customers or payments.

How do I test a Stripe dispute without a real chargeback?

Take a payment in a sandbox with one of Stripe's dispute test cards. 4000 0000 0000 0259 creates a fraudulent dispute during the payment, 4000 0000 0000 1976 creates an inquiry, and 4000 0084 0000 0795 creates a dispute for whatever you do not refund after a partial refund. You can then submit test evidence to simulate winning or losing.

Does Stripe charge for Sigma queries in a sandbox?

No. Stripe states that Sigma is free to use in sandboxes with no usage limits, that you can run unlimited queries against test data at no cost, and that sandbox activity does not count toward your charge-based entitlement or incur fees.

Is there a test version of QuickBooks Online?

Intuit offers a test drive with a demo company called Craig's Design and Landscaping Services. It does not save changes and cannot be connected to a bank. Intuit's advice for testing online banking is to use an active or trial QuickBooks Online account, which is also the better choice for any rehearsal you want to keep.

The short version

A Stripe sandbox lets the person responsible for the books see the records a change will produce before any real customer produces them. Copy your live settings into a named sandbox, run the dispute, refund and renewal scenarios with Stripe's test cards and test clocks, and read every balance transaction each one creates. Do not trust it for settlement timing, IC+ fees or a Connect platform's full chain, and keep any QuickBooks rehearsal you want to revisit in a trial company rather than the test drive.

When the change goes live, Acodei records the real Stripe activity in QuickBooks Online, from the sale to the refund and the dispute. Start a free trial.