Development stores

A development store is a free store of your own for building and testing plugins. You create it from the partner dashboard, open it as its owner, install your plugins on it, and place test orders that mark themselves paid without any money moving. It never expires, and it can never become a live store.

Development stores are a partner feature that Orbit switches on. When they are on for your account, Development stores appears in the partner dashboard navigation between Plugins and Themes.

What a development store is

A development store is a complete store in your partner organisation with a development flag set. The flag is enforced across the platform, not just displayed:

• No live payments. Card and wallet providers cannot be connected and payment intents are refused. The only payment method is Test payment, and that method can only be enabled on a development store.
• Nothing to pay for. The store cannot be billed or moved to a paid plan, and every plan feature is available on it. A paid plugin installed on it runs on a trial that never bills, so you can test your own pricing.
• Never a merchant's store. A development store cannot be transferred to a merchant. To build a store for a client, use the agency or affiliate paths instead.
• Not a public shop. The storefront shows a development store notice and asks search engines not to index it. It uses its Orbit address only; custom domains cannot be attached or bought for it.
• Never expires. It stays until you close it.

Storefront emails (order confirmations and the like) send normally, within a daily cap per development store, so email-driven plugins can be tested.

Creating one

Open Development stores and choose Create development store.

You need a verified email address, because the storefront is reachable from the public internet. You can keep a small number of stores open at a time and there is a daily limit on new ones; the page shows your usage. At the limit, close a store to create another.

The store is provisioned in a few seconds and appears as a card with its name, label, storefront address and these actions:

• Open store signs you in to the store dashboard as the store's owner. Your team members reach it through their organisation role.
• Sample data shows added, adding, none or failed, with Add sample data or Retry where it applies. A failed seed does not stop you using the store.
• Close moves the store to the trash and takes its storefront offline.

Sample data

Sample data is a pack of products, customers and orders, added by a background job so the store is usable straight away. Add sample data on a store that already has some tops it up.

Test payment

Checkout on a development storefront offers Test payment. No money is taken and the order is marked paid straight away, so it lands as a paid order with a successful payment: order.created fires, then payment.succeeded, and order emails, stock and everything downstream behave as they do for a paid order. Refunds work. Card entry, wallets and 3-D Secure are not part of it, so a plugin whose job is payment processing cannot be tested end to end here.

The trash

Closing a store moves it to the Trash section, where its card shows the date it is deleted for good. Until then, Restore brings it back, as long as that fits within your open-store allowance, and Delete now removes it immediately. Deletion cannot be undone, and a deleted store's storefront address stops answering.

Testing your plugins on it

Each plugin page in the partner dashboard has a Test on a development store panel with Install, Open in store and Test webhooks for every open store. Testing your plugin walks through the loop, including running the plugin from your own machine over a tunnel with a development release, and Webhooks covers the signing secret and test deliveries.

The API

Every route is called with your partner dashboard session (Authorization: Bearer <partner JWT>), resolves your partner account from that session, and only ever sees your own development stores: another partner's store id and an unknown id are the same 404.

partner:dev-store:read is held by every partner role; partner:dev-store:manage, like partner:plugin:dev-release, by organisation owners, organisation admins and partner admins.

A store in a list or in the create response looks like this:

{
  "id": "0f3c8b2a-1d4e-4a6b-9c2f-7e5a1b2c3d4e",
  "storeId": "8a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d",
  "label": "Stock sync testing",
  "status": "active",
  "storeName": "My plugin test store",
  "storeDomain": "my-plugin-test-store",
  "storefrontUrl": "https://my-plugin-test-store.<storefront domain>",
  "seedStatus": "done",
  "seededAt": "2026-09-29T10:02:11.000Z",
  "lastOpenedAt": "2026-09-29T10:05:40.000Z",
  "createdAt": "2026-09-29T10:01:58.000Z",
  "closedAt": null,
  "purgeDueAt": null,
  "dashboardUrl": "https://<store dashboard>"
}

• storeId is the id the plugin routes take: devStoreIds on a development release, dev-stores/{storeId}/install, and storeId on a test webhook.
• storeDomain is the store's slug in the store dashboard, /stores/<slug>/, and the next you can pass to the login token route is a path under it.
• seedStatus is none, queued, seeding, done or failed.
• status is active or closed; a closed store has closedAt and purgeDueAt set and no storefrontUrl.

Responses to expect

Next steps

• Testing your plugin: install, run from your machine, place a test order, send a test webhook
• Webhooks: the signing secret and test webhooks
• Publishing your plugin: what happens once it works