Paid Frontend Page Access with Stripe, Paddle or Mollie

Use Pagible Cashier when you want to sell a subscription, a one-time purchase, or both for pages in your public site. You install one payment provider, assign a named access value to a pricing package, and restrict the pages with that same value. Verified provider webhooks grant, renew, and revoke access automatically.

Pagible automates the local integration while you retain control of application code, provider dashboards, products, and CMS content.

Your application needs PagibleAI CMS, Laravel authentication, a named login route, and a stored Eloquent user. Set APP_KEY and a public HTTPS APP_URL before configuring webhooks. Checkout sends guests to the named login route and resumes after they sign in.

Choose exactly one provider package. Composer prevents you from installing competing Pagible or upstream Cashier drivers in the same application.

The selected package registers its Cashier driver, checkout integration, webhook listeners, migrations, and frontend assets. There is no separate provider setting to maintain.

Add Pagible's CashierAccess trait and your provider's Billable trait to the application user model. Stripe and Mollie use this model setup:

For Paddle, import Laravel\Paddle\Billable instead. Do not add access to $fillable or update users.access yourself. Pagible reserves, hides, casts, and guards this payment-derived authorization data.

Register the values editors may assign to pricing packages and restricted pages. Put a fixed catalog in an application service provider for a simple installation:

The callback may return different values for each tenant. Use the same exact value in the pricing package and on every page that package unlocks. 

If you need editor-managed roles, an authorization package, or custom catalog callbacks, use the more sophisticated setup in Frontend Access Control for PagibleAI CMS.

After configuring the public APP_URL, STRIPE_KEY, and STRIPE_SECRET, clear cached configuration and run the installer. Accept the default yes answer when it offers to create the registered webhook. The adapter supplies all required payment, subscription, refund, and dispute events.

For a non-interactive deployment, request webhook creation explicitly:

After Stripe creates the endpoint, retrieve its signing secret from the Stripe dashboard and add it to your environment:

Reload cached configuration, then confirm that the complete local setup is ready:

Create recurring and/or one-time Stripe prices in Stripe. Use each price_... ID in the matching CMS price.

Create a public notification destination for https://example.com/paddle/webhook. Include Cashier's normal event set and make sure it contains transaction.completed, subscription.created, subscription.canceled, adjustment.created, and adjustment.updated. Copy the destination's endpoint secret into PADDLE_WEBHOOK_SECRET. Create recurring and/or one-time Paddle prices and use their pri_... IDs in the CMS.

Enable the payment methods you want to offer in Mollie. Pagible derives opaque webhook route segments from APP_KEY; keep all generated Cashier Mollie webhook routes public. Run Laravel's scheduler continuously because the adapter schedules cashier:run every five minutes for subscription renewals. If you rotate APP_KEY, keep the previous key in APP_PREVIOUS_KEYS until old subscriptions and webhook retries have ended.

Run the installer once after the user model, access catalog, and initial provider configuration are ready. If you already followed the Stripe sequence above, this step is complete:

cms:install:cashier detects the installed provider, checks that users.access is not owned by your application, publishes the provider and adapter migrations, and runs all outstanding migrations by default. Use --no-migrate only when your deployment pipeline runs migrations separately, and add --force when production migrations must run non-interactively.

After adding any secret returned by the provider dashboard, reload configuration and verify readiness:

The readiness check verifies everything it can inspect locally, including routes, model traits, migrations, the access catalog, API credentials, and webhook secrets. Its Developer next steps section lists dashboard work and purchase-flow tests that still require you.

Add a pricing element to a public sales page. Create a package such as Membership, select premium-members as its frontend access value, and add up to five prices. You can offer a subscription, a one-time purchase, or both.

For every provider, use a three-letter uppercase currency code. Stripe and Paddle ignore the CMS billing interval because their price object controls recurrence. The amount, displayed price, and unit fields control the pricing display; the provider reference remains authoritative for the charge. Set the package target to a local URL beginning with /, preferably a public account or payment-status page, then publish the pricing content.

1. Open the page being sold in the CMS admin.
2. Choose Access and select Restricted.
3. Add the same access value used by the pricing package, such as premium-members.
4. Apply the change. Apply it recursively when the page's descendants should require the same purchase.
5. Keep the sales and return pages public.

The access change requires page:publish and access:view. A verified one-time payment grants permanent access until a full refund or chargeback. A subscription grants access through its provider-confirmed paid period. Scheduled cancellation keeps access until that paid period ends.

Pagible configures the private file disk as Laravel's non-public local disk by default. Enable Protect with page access for each paid download. Set CMS_PRIVATE_DISK only when you want to use another non-public Laravel disk; it must be different from the public disk. Pagible delivers local private files through its access-controlled route and uses temporary URLs for supported remote private disks.

Bundled themes generate page-aware protected URLs automatically. In a custom Blade template, use cmsasset($page, $file) so Pagible can authorize the file against its page. Do not use cmsurl() for a protected file.

Complete the whole flow in the provider's test or sandbox environment:

• A guest is sent to your named login route and checkout resumes after sign-in.
• A subscription webhook grants access and a paid user can open the restricted page.
• A one-time payment grants access.
• Cancellation preserves access through the paid period.
• A full refund and a dispute or chargeback revoke access.
• An unauthorized user cannot open protected pages or private files.
• Failed webhook processing returns a non-success response and the provider retries it.

Monitor failed and exhausted webhook deliveries in production. Provider retries are the recovery path when synchronous access updates fail.

Use these package guides when you need implementation details:

• Pagible Cashier integration guide
• Pagible Cashier Stripe setup
• Pagible Cashier Paddle setup
• Pagible Cashier Mollie setup