Build for ShopKeeprr.

Plugin packages

ShopKeeprr modules live in modules/{slug} and are described by a module.json file. A module is trusted, executable code. It runs with the same privileges as the store, so keep the package small, auditable and free of unrelated dependencies.

{
  "name": "Stripe Connect Payouts",
  "slug": "stripe-connect-payouts",
  "version": "1.0.0",
  "type": "payments",
  "namespace": "Vendor\\StripeConnect\\",
  "source": "src",
  "provider": "Vendor\\StripeConnect\\ServiceProvider",
  "description": "Split payments and pay sellers.",
  "requires": {
    "shopkeeprr": ">=1.0.0 <2.0.0",
    "module_api": "1.0"
  }
}

The required manifest fields are name, slug and provider. namespace and source let ShopKeeprr autoload your classes; type and description are shown in the admin module manager. Keep migrations under database/migrations; they run when the module is installed.

Register routes, admin navigation, settings and scheduled work from your provider. Do not modify files under app/, config/ or another module. A new core release must not overwrite your work.

Declare your compatibility in requires.shopkeeprr and requires.php. If you ship a composer.json, the scanner also reads require.php, require.laravel/framework and extra.shopkeeprr.requires. Packages that exclude the current PHP or ShopKeeprr release are approved with a compatibility warning.

Theme packages

ShopKeeprr themes are complete storefront presentations: a palette, typography choices, card/button radii and Blade overrides for the storefront views. A theme must preserve the commerce markup and accessibility behaviour; it should change presentation, not checkout logic.

A theme package should contain a short theme.json descriptor with its key, label, palette and supported product columns, plus a folder of Blade overrides. Theme listings are reviewed manually because a theme can expose customer-facing regressions. Upload the package as a normal versioned release and include setup notes in the release notes.

theme-name/
  theme.json
  views/
    home.blade.php
    partials/header.blade.php
    partials/footer.blade.php
    product/show.blade.php

Do not include compiled assets, customer data or license keys in a theme archive. Use the same design tokens as the core so store owners can adjust colours without editing your files.

Storefront components

A component is a ShopKeeprr module of type component that adds a new section to Appearance → Storefront builder. The store owner can drag it onto the homepage, edit its fields in the settings panel or directly on the page, duplicate it and publish — no core files change.

Use the same module.json contract as a plugin, with "type": "component". Register the section from your service provider after loading your views:

<?php

namespace Vendor\CountdownStrip;

use App\Services\Storefront\BlockRegistry;
use Illuminate\Support\ServiceProvider;

class ServiceProvider extends ServiceProvider
{
    public function boot(BlockRegistry $blocks): void
    {
        $this->loadViewsFrom(__DIR__.'/../views', 'countdown-strip');

        $blocks->register('countdown-strip', [
            'label' => 'Countdown strip',
            'description' => 'A slim deadline banner for launches.',
            'category' => 'Conversion',
            'icon' => 'clock',
            'view' => 'countdown-strip::block',
            'defaults' => ['heading' => 'Doors open in', 'ends_at' => ''],
            'fields' => [
                'heading' => ['type' => 'text', 'label' => 'Heading', 'max' => 120, 'inline' => true],
                'ends_at' => ['type' => 'datetime', 'label' => 'Countdown ends'],
            ],
            'style' => ['background' => 'brand', 'padding' => 'sm', 'width' => 'wide'],
        ]);
    }
}

Supported field types are text, textarea, url, number, color, select, toggle, image and datetime. Add inline to a text field to let the owner edit it directly in the live preview. Every save is normalised server-side: unknown block types are dropped, URLs are restricted to http(s), / or #, markup is escaped, and the page is capped in size.

Use a vendor-prefixed block key, keep the Blade view self-contained and render with the storefront CSS variables so the section follows the active theme. Registering a block is enough for discovery — the builder library is rebuilt on each request. Package the module as a normal versioned ZIP; the security scan and review process are identical to plugins.

Releases and review

1. Create the listing in My listings and complete the description, features and cover image.
2. Upload a ZIP under Releases. Every file gets a SHA-256 checksum and is stored privately.
3. The package is scanned automatically. Critical findings quarantine the release; warnings are shown to you and the marketplace team.
4. The marketplace team reviews the listing and publishes it when it is ready.
5. When you ship an update, upload a new version. The current release becomes the default download for licensed buyers.

Keep your version numbers semantic. Never reuse a version number for different bytes. If a release is broken, upload a corrected version; buyers can see the release notes and checksum.

Security scan. Uploads are inspected without being executed or extracted. The scan blocks eval(), shell execution, remote includes, request-data extract(), PHP hidden in images and executable .htaccess rules. It marks risky APIs, encoded payloads, nested archives and bundled vendor/ code as warnings. A blocked release cannot become current, be published, or be downloaded by buyers. A warning release is approved with warnings so you can ship, but review the report before the next version. You can re-run the scan from the release card after changing the package or when the scanner rules are updated.

Do not bundle vendor/ or node_modules/ when a Composer or npm install will resolve them. Bundled dependencies are skipped by the automated scan and always produce a manual-review warning.

Licensing

The marketplace issues and validates licenses for every paid order. Your listing does not need to implement its own license server, activation keys or entitlement checks, and third-party sellers do not receive the internal license API reference.

Store the product slug and version in your package metadata, keep your code free of hard-coded buyer credentials, and direct buyers to their ShopKeeprr account for licenses and downloads. If you need a custom entitlement rule for your plugin, contact the marketplace team before building it.

Commission and payouts

The marketplace keeps a percentage of each completed sale. The default rate is 20.00%; your account can have an individual rate. The rate is snapshotted on the sale, so later rate changes do not rewrite history.

Gross is the product line total. Commission is gross × rate. Your share is the remainder. Refunded orders are marked reversed and excluded from payable totals.

Automatic split payouts. Open Developer center → Payouts and press Connect Stripe account. Stripe Express handles identity verification, bank details and payout timing. Once your account is active, each eligible purchase is charged as a Stripe destination charge: your share is transferred to your connected account at payment time and the marketplace commission is retained automatically. There is no separate withdrawal request.

Orders that cannot be routed to a single connected seller (for example a mixed-seller cart) stay on the platform balance and are settled manually by the marketplace team. Refunds issued from the admin reverse the developer sale record; for destination charges Stripe is also asked to pull the transfer back and return the platform fee, so a refunded order does not leave you holding funds for a reversed sale.

Active developer accounts also receive a discount on a ShopKeeprr core license. The developer price is shown on the product page and applied automatically at checkout.

Support and contact

Questions about a listing, a release or a payout: support@shopkeeprr.com. Include the listing slug and version in every message.