Checkout Laravel Package

Getting Started

composer require 64robots/checkout
php artisan vendor:publish --tag=checkout-config
php artisan vendor:publish --tag=checkout-migrations
php artisan migrate

Where to look first:

1. config/checkout.php (published) — this is the control surface. Model bindings, route prefix, middleware, and auth guard are usually defined here. Read it top to bottom before touching anything else.
2. routes/ inside the package — confirm the exact URI prefix and HTTP verbs, since the README may lag behind the code. php artisan route:list --path=api is faster than reading docs.
3. src/Models/ — the Cart, CartItem, Order, and Coupon models. These are the things you will extend.

First use case — the happy path:

• Authenticate a request (the package ships API routes; wire up Sanctum or Passport to match your config/checkout.php guard).
• POST an item to the cart endpoint → receive a cart identifier.
• POST a coupon code against that cart → verify the discount reflects in the cart totals.
• POST to the checkout endpoint → assert an Order row is created with the correct line items and total.

Run that sequence in a Pest/PHPUnit test before writing any product code. You will discover the package's assumptions about auth, currency, and totals immediately — far cheaper than discovering them after you've built a storefront on top.

Nova: if you use Laravel Nova, the package registers resources for managing orders and coupons out of the box. Install Nova first, then the package, so the resource registration doesn't silently no-op.

Implementation Patterns

Configure, don't fork. The intended extension path is the config's model map: swap Cart::class for your own App\Models\Cart extends \Robots\Checkout\Models\Cart and override the binding. Add your custom columns via a separate migration that alters the package tables. Forking the package to add a notes field is the wrong trade — you inherit merge pain forever for a one-column change.

Cart-to-order as a service boundary. Keep the checkout conversion behind a single application service (PlaceOrder), even if the package gives you a controller that does it. That service is where you hang the things the package deliberately doesn't do: inventory decrement, payment capture, email dispatch, order-number generation. The package creates the order record; your service makes it real.

DB::transaction(function () use ($cart, $payment) {
    $order = $this->checkout->convert($cart);      // package
    $this->inventory->reserve($order);             // yours
    $this->payments->capture($payment, $order);    // yours
    event(new OrderPlaced($order));                // yours
});

Observe the order lifecycle, don't edit it. Order status transitions are the natural hook point. A model observer on Order for created/updated (watching status) keeps your side effects out of the package's code path and survives upgrades.

Coupons belong in admin, not in code. Create coupons through Nova, then validate them by hitting the cart endpoint with a bad/expired/over-limit code in tests. The three failure cases worth encoding: expired, minimum-spend-not-met, and already-consumed. Assert the cart total is unchanged on failure — a discount applied and not rolled back is the classic bug here.

Guard against double-conversion. Checkout is not idempotent by default. Two rapid POSTs on the same cart can produce two orders. Either add a unique constraint tying an order to a cart, or make the endpoint idempotent behind a payment-intent key.

Integration tip — wrap the API client. Call these routes from your SPA/mobile through a thin typed client, not scattered fetch calls. When the package's response shape shifts between minor versions, you fix one file.

Testing: the package ships factories; use them to build carts with items and coupons rather than driving every test through the HTTP layer. Reserve HTTP-level tests for auth, validation, and the coupon failure cases.

Gotchas and Tips

Auth guard mismatch is the #1 first-run failure. The routes ship with middleware pointing at a guard you may not have configured. A 401 on a route you know exists almost always means the guard name in config/checkout.php doesn't match your config/auth.php. Fix it in config — don't disable the middleware.

Currency and tax are yours to own. Packages in this weight class store a total and a currency string; they do not compute tax per jurisdiction or handle rounding across line items. Decide early whether you're single-currency and tax-inclusive, and write that decision down. Retrofitting tax logic into a package-owned totals calculation is painful.

No inventory control. There is no stock reservation or oversell protection. This is expected — inventory is application domain, not cart domain — but it surprises people. Reserve stock in your PlaceOrder service, inside the same transaction as the order creation.

Model overriding requires cache clearing. After changing the model map in config, config caching will serve the old bindings. php artisan config:clear before you conclude your subclass "isn't being used."

Migrations and UUIDs. Check whether the package migrations assume auto-incrementing IDs or UUIDs before you write foreign keys to these tables in your own migrations. Publish the migrations first, read them, then write yours.

Coupon stacking is likely single-coupon. If your product needs multiple simultaneous discounts, verify before committing — extending the coupon engine is more invasive than extending a model.

Watch the maintenance signal. 38 stars and low activity means you are largely on your own for bugs. Pin the version exactly ("64robots/checkout": "1.0.*") rather than using ^, read the source for anything you depend on, and keep your extensions in config/observers/subclasses so you can drop the package if you have to. Budget a day to read the checkout controller and coupon validation logic end-to-end — it is the highest-leverage hour you will spend on this dependency.

Debugging tip: when a total looks wrong, dump the CartItem rows and the Coupon row separately before trusting the cart's stored total. Stale denormalised totals are the usual culprit, and recomputing from items is the quickest way to isolate whether the bug is in the package or in your own mutation of the cart.