Laravel Magento Customer Prices Laravel Package

Getting Started

1. Install and publish config

   composer require justbetter/laravel-magento-customer-prices
   php artisan vendor:publish --tag="magento-customer-prices-config"
   

2. Set the connection in .env (names follow the published config): the Magento base URL, an integration/admin token, and the store/website code you want to target. Missing or wrong store code is the most common source of silent no-ops.
3. Read the config file first — it defines which "source" class resolves prices, whether syncing is queued vs. synchronous, batch sizes, and logging channel. Everything else in the package hangs off that one file.
4. Implement (or bind) a price source. The package is built around a configurable source contract: you either point the config at the shipped source or bind your own class that implements the source interface. Your class is responsible for returning customer-scoped price rows (customer identifier, SKU, price, currency/qty as applicable).
5. First use case: manually push a single customer's prices, then confirm in Magento (Customers → price list for the customer, or the product's advanced pricing view). Once that round-trip works, schedule the sync.

The fastest sanity check is a one-off artisan call against a known test customer, tailing storage/logs/laravel.log and watching the Magento request response. Don't wire up the scheduler until a single customer round-trips correctly.

Implementation Patterns

Custom source as the primary extension point. Bind your source in a service provider rather than editing the config's class string inline — it keeps environment overrides and test fakes clean:

$this->app->bind(CustomerPriceSource::class, DatabasePriceSource::class);

Shape the source so it can return a scoped set (one customer, or a chunk) — the package will call it per customer or per batch depending on config, and a source that always dumps the whole catalogue will be unusably slow.

Batch/scheduled sync. Drive the full sync from a scheduled command with a sensible withoutOverlapping() and a batch size matched to your Magento API rate limits. For catalogues with millions of price rows, chunk by customer or by SKU range so a single failure doesn't invalidate the whole run.

Event-driven updates. For price changes that happen at runtime (a quote is accepted, a contract is renegotiated), dispatch the package's sync job for just that customer. This keeps Magento near-real-time without re-pushing everything. Wrap it in your own domain event listener so the pricing logic stays out of controllers.

Queued syncing for volume. Configure the package to push each customer (or price chunk) as a queued job. Give it a dedicated queue with its own worker count so Magento latency doesn't starve your normal jobs, and set retry_after and tries explicitly — Magento will occasionally 5xx or rate-limit, and default retries are too shallow for external API work.

Testing. Bind an in-memory / array source in your test suite and assert that the sync job produced the expected payloads. Mock the HTTP client (via Http::fake() if the package uses Laravel's HTTP client) so tests never hit a real Magento instance. Assert on the price rows you sent, not just that the job ran — scope, currency, and rounding are the fields that break.

Idempotent re-sync. Design your source so calling it twice for the same customer produces identical output. Prices are state, not events; you should be able to re-run yesterday's sync safely.

Gotchas and Tips

• Magento cache and the price index. New customer prices often won't show in the storefront until the relevant index/cache is refreshed on the Magento side. If the API returns 200 but the price looks stale, this is almost always the cause — not your package.
• Store vs. website scope. Prices are scoped. A customer bound to the wrong website (or a sync that omits the store code) will write rows that never surface. Pin the scope in config and log it with every sync.
• Customer group vs. customer ID. "Customer-specific" is ambiguous in Magento. Be explicit about whether you're targeting individual customers or customer groups — mixing them up produces prices that apply to everyone in a group.
• Decimal and currency handling. Magento expects precise decimal strings; PHP floats will drift. Cast to number_format(..., 2, '.', '') (or your currency's precision) at the boundary, and keep the currency code alongside the price.
• Token expiry. Integration tokens expire. Configure the client with a fresh token (or short-lived token fetch) and make the 401 path retriable — a sync job that dies on expiry and never retries will leave prices silently stale for days.
• Rate limits and timeouts. Set HTTP timeouts lower than you'd expect (Magento can hang), and throttle the queued jobs. One worker hammering the API is the classic way to get yourself blocked.
• Partial failures. If a batch contains 500 rows and 3 fail, make sure errors are logged per-SKU with enough context (customer, SKU, attempted value) to fix them manually. Silent partial success is the hardest bug to diagnose.
• Logging channel. Point the package's logger at a dedicated channel so Magento sync noise doesn't pollute application logs, and keep at least a rotation for failures.
• Config caching. If you rely on env vars in the config, run php artisan config:clear after changes; stale cached config showing the old endpoint is a frequent false alarm.
• Extension points to reach for before forking: the price source binding (custom logic), the sync job middleware or failed handler (custom alerting/Slack), and package events/dispatchers for post-sync hooks. Override these rather than copying package internals into your app — you'll lose the ability to pull upstream fixes (last release 2026-04-02).