baks-dev/ozon-orders
Laravel module for managing Ozon marketplace orders with support for FBS and DBS schemes. Includes profile type, payment, and delivery console commands. Requires PHP 8.4+ and installs via Composer.
Confirm the stack fit before anything else. baks-dev/ozon-orders ships Symfony Console commands (php bin/console ...) and is part of the BaksDev ecosystem. In a Laravel app you will not get php artisan commands for free — you'll either run them through a Symfony Console bridge or replicate the three setup calls in your own artisan commands/seeders. Verify this before you sell the package internally.
Minimum steps:
# 1. PHP 8.4+ is a hard floor — check first
php -v
# 2. Install (pin the exact version; releases are tiny and undocumented)
composer require baks-dev/ozon-orders:7.4.48
# 3. Pick your fulfilment model and run its three setup commands
# FBS (fulfilment by seller, Ozon delivers)
php bin/console baks:users-profile-type:ozon-fbs
php bin/console baks:payment:ozon-fbs
php bin/console baks:delivery:ozon-fbs
# DBS (seller delivers)
php bin/console baks:users-profile-type:ozon-dbs
php bin/console baks:payment:ozon-dbs
php bin/console baks:delivery:ozon-dbs
# 4. Run the packaged tests
php bin/phpunit --group=ozon-orders
Where to look first: the three commands are the entire documented surface area. Read their source under src/ (or vendor/baks-dev/ozon-orders/) before running them — they write rows into your profile-type, payment, and delivery tables, and the README states no migrations are shipped. Understand exactly what they insert, and into which tables, before you run them against anything that matters.
First use case to target: onboarding a single Ozon seller account in FBS on a staging database — run the three FBS commands, confirm the profile type, payment method, and delivery method appear in your admin, then place one real sandbox order end-to-end. That single loop exercises every part of the package the README actually describes. Add DBS only after FBS is green; treat them as separate rollouts, not one.
Also decide up front where Ozon credentials live (client_id / client_secret). The README doesn't say — assume you own this. Put them in .env + config/services.php, never in the repo.
Treat the CLI commands as seed-like, environment-scoped setup — not as migrations. The cleanest pattern is a wrapper command or a php artisan ozon:setup --model=fbs --env=staging that shells out to the three BaksDev commands in the correct order (profile type → payment → delivery, since the latter two likely reference the profile type). Wire this wrapper into your deploy runbook so a fresh environment is reproducible, and guard it so it only runs once per environment.
Model-per-environment, not model-per-tenant, unless you've verified otherwise. The commands are global-looking (baks:delivery:ozon-fbs takes no tenant argument). Don't assume multi-seller support. If you need several Ozon accounts, spike this early on staging with two sets of credentials and see whether the second run collides with the first.
Pipeline ordering in CI:
- php -v # fail fast if < 8.4
- composer install --no-dev
- php bin/phpunit --group=ozon-orders # cheap regression gate
The --group=ozon-orders suite is the only automated signal you get. Run it on every upgrade of the package — it's the closest thing to a changelog this project has.
Wrap everything you actually call day-to-day. The README documents setup only — it says nothing about order sync, webhooks, status transitions, or refunds. Assume those are either absent or undocumented. The practical pattern is a thin adapter layer of your own (App\Services\Ozon\Orders, Ozon\Payments) that owns retries, logging, and idempotency, and delegates to the package where it genuinely provides behaviour. This keeps the blast radius small if you fork or replace the package later — a real risk at 1 star and 0 dependents.
Queue Ozon API calls; never call them inline in a web request. Whether it's polling for new orders or reconciling payment state, put it behind a job with tries, backoff, and a dead-letter path. The package does not advertise circuit breakers or retries, so your job layer is the retry layer.
If you implement an Ozon webhook endpoint yourself (the package won't do it for you), make it idempotent from day one: persist the Ozon event ID in a unique column, return 200 fast, dispatch a job, and dedupe on replay. Ozon retries; you will see the same payload twice.
Feature-flag the integration per channel. Something like config('features.ozon_fbs') gating order creation and status callbacks lets you ship the package, run it against staging, and flip production without a redeploy — useful when you're unsure how the package behaves under your real order volume.
baks:delivery:ozon-fbs twice?" is "unknown" until you test it. Test it on a scratch database.v7.4.48 says "v7.4.48". The version cadence is aggressive. Pin the exact version in composer.json, and on every bump diff vendor/baks-dev/ozon-orders/ between tags rather than reading the changelog. Budget ~30 minutes per upgrade for this.bin/console is Symfony, not Artisan. Laravel developers will instinctively type php artisan. Don't assume the package registers service providers, facades, or config publishing — nothing in the README suggests it does. Verify what, if anything, gets auto-discovered.src/ to confirm which classes are concrete vs. interface-backed before you design around it.--group=ozon-orders test run in CI permanently, even after go-live. It's the cheapest way to catch a breaking change during a routine composer update sweep before it reaches a customer order.How can I help you explore Laravel packages today?