My own Laravel application
Behind DawsonyWeb: Laravel, Stripe and plugin licensing
A technical walkthrough of my own Laravel application: server-rendered Vue pages, validated Stripe checkout, queued subscription updates and WordPress plugin licences.
The requirement
This site needs to explain my services and support the software I sell. The public pages, customer accounts, paid subscriptions and plugin access sit in one Laravel application. A successful payment needs to become the right licence, and later changes to that subscription need to reach the plugin.
What I built
- Built public pages with Laravel routes, Inertia and Vue, with server-side rendering for the first request.
- Connected plugin plans to Stripe Checkout, with checks on the configured product, currency, price and billing interval.
- Added background licence synchronisation for checkout, invoice and subscription events.
- Built licence activation and protected plugin download endpoints alongside customer account access.
Public pages and application screens share one backend
Laravel controllers supply the data and choose the Inertia page. Vue provides the interactive interface, while the initial public page is rendered on the server. The application also supplies canonical URLs, metadata, structured data and a sitemap.
This is useful when a business website grows into a product platform: the marketing pages and customer workflows can share the same authentication, routing and application rules. It still needs disciplined data loading and a working SSR process after deployment.
Checkout validates the plan before accepting payment
The server loads the selected price from its own database and checks that the product and price are available. Before redirecting to Stripe it checks the remote price against the expected currency, amount and recurring interval. Production checkout also requires a live-mode price.
Purchase terms are recorded with the plan. On the return from Stripe, the application checks the session belongs to the signed-in customer, is complete and represents a qualifying subscription payment before it queues synchronisation. The return URL alone does not grant a licence.
Webhooks trigger a fresh subscription read
Stripe events are handled through Laravel Cashier. Checkout completion, invoice events and subscription changes queue the same licence synchronisation job. The job has four attempts, with retry delays of 30 seconds, two minutes and ten minutes.
The job retrieves the current Stripe subscription and re-reads it under a database lock for the customer. It maps that state to the local licence, including product tier, billing interval, site limit and expiry. This reduces the risk of an older event overwriting a later subscription change.
Active and trialling subscriptions map to active access; payment problems can suspend access; cancellations map to cancelled access. A manually revoked licence is preserved. The code also rejects unknown subscription states and unmapped prices instead of guessing.
Test the failure paths as well as the purchase
The application has automated tests around checkout terms, the Stripe licence lifecycle and the licence API. These are the boundaries where a small mistake can affect money or access, so they deserve more attention than a successful checkout screenshot.
The same principle applies to enquiries. Messages are saved before an email notification is attempted, and the browser receives a saved-enquiry receipt. That keeps the contact record available when email delivery fails.
Explore the public products
Corevum and Print Label Designer are my own WordPress products. Their public pages show real interfaces and explain the available features. This walkthrough describes the application behind them without exposing customer accounts, licence keys or payment records.
What this makes possible
The same Laravel application connects public product information, checkout, customer subscriptions and plugin access. The walkthrough gives you a concrete example of how I approach the handovers between systems, using software I own and maintain.
Why the detail matters
A business application needs to stay understandable when payments arrive late, jobs retry or subscriptions change. The work is in deciding which system owns each fact, validating the handover and making failures recoverable.
Need a Laravel application connected to payments or other systems?
Send me the outline and any deadline. We can agree a useful first piece of work and a realistic timescale.
Talk to Adam about your project