StripePaymentLinks

Lightweight ProcessWire module to handle Stripe Checkout Payment Links.
It takes care of:

• Handling the Stripe redirect (success URL)
• Creating or updating the user account
• Recording purchases in a repeater field
• Issuing access links for products that require login**
• Sending branded access mails
• Rendering Bootstrap modals for login, reset, and set-password flows

The module is designed for small e-commerce or membership scenarios where a full shop system would be overkill.

Features

• Checkout processing

  • Works with Stripe Checkout session_id
  • Records all purchased items in a single repeater item (purchases)
  • Stores session meta including line_items for debugging/audit

• User handling

  • Auto-creates new users on first purchase
  • Supports "must set password" flow with modal enforcement
  • Automatic login after purchase

• Access control

  • Products with requires_access=1 are protected
  • Delivery pages auto-gate users without purchase
  • Access links with optional magic token for new users

• Mail & branding

  • Branded HTML mail layout (logo, color, signature, tagline)
  • Access summary mails (single/multi-product)
  • Password reset mails

• Magic Links

  • Manual access link delivery via module config
  • Multi-product & multi-user sending
  • Each user receives ONE email with all owned product links
  • Configurable token validity (TTL)
  • Test mode (dry-run) before actual sending

• Modals (Bootstrap)

  • Login
  • Request password reset
  • Set new password (via token)
  • Force password set after purchase
  • Notices (expired access, already purchased, reset expired)

• Synchronization (Sync Helper)

  • Admin helper to synchronize Stripe Checkout sessions into ProcessWire users
  • Supports dry-run mode (no writes, for inspection only)
  • Options for update existing purchases and create missing users
  • Date range filters (from, to)
  • Optional email filter to sync sessions for one user only
  • Generates a plain-text report with all actions (LINKED, CREATE, UPDATE, SKIP) and line items

• Internationalization (i18n)

  • All strings are pulled from defaultTexts() using $this->_()
  • No hardcoded UI strings in templates or services

Requirements

• ProcessWire 3.0.200+
• PHP 8.1+
• Stripe PHP SDK (installed in StripePaymentLinks/vendor/stripe-php/)
• Repeater field purchases on user template (created automatically on install)

Installation

1. Copy the module folder StripePaymentLinks/ into your site’s /site/modules/.
2. In the ProcessWire admin, go to Modules > Refresh.
3. Install StripePaymentLinks.
4. Enter your Stripe Secret API Key in the module config.
5. Select which templates represent products.

Usage

1. In Stripe, create a Payment Link and set its success URL to your ProcessWire thank-you page, e.g.:

   https://example.com/thank-you/?session_id={CHECKOUT_SESSION_ID}

2. On your product pages templates the module added two checkboxes:

• requires_access
• allow_multiple_purchases

Check/uncheck them on your product pages as needed.

3. In ProcessWire templates, call the module’s render method:

   echo $modules->get('StripePaymentLinks')->render($page);

• On the thank-you page, the module will display an access buttons block if the checkout contained products that require access.
• On delivery/product pages marked with requires_access, users are gated: if they are not logged in or have not purchased, they are redirected to the sales page and prompted to log in.
• After first purchase, new users will see the set-password modal on the delivery page.
• Access summary emails are sent automatically according to the configured policy (never, newUsersOnly, or always).

Stripe Webhook & Subscription Handling

The module supports real-time synchronization between Stripe subscriptions and ProcessWire user access.

Webhook Endpoint

Add a webhook endpoint in your Stripe Dashboard under
Developers → Webhooks → + Add endpoint

Set the URL to:

https://yourdomain.com/stripepaymentlinks/api/stripe-webhook

This endpoint automatically processes the following events:

• Subscription cancellation, pause, resume, or renewal
• Invoice payment success/failure

Webhook Events to Enable

When adding the webhook in Stripe, either:

• Send all events (recommended for testing), or
• Select only the relevant subscription-related events:

  customer.subscription.updated
  customer.subscription.deleted
  customer.subscription.paused
  customer.subscription.resumed
  invoice.payment_succeeded
  invoice.payment_failed

Note:
Some Stripe accounts don’t show explicit paused or resumed events.
In those cases, Stripe sends them as customer.subscription.updated events where the pause_collection field changes.
The module automatically handles both forms.

Webhook Secret

After creating the webhook, copy the Webhook Signing Secret from Stripe and paste it into
Modules → Stripe Payment Links → Webhook Signing Secret.

Behavior

• Paused or canceled subscriptions immediately block access.
• Resumed subscriptions automatically restore access.
• Renewed subscriptions extend access based on the new billing period.
• Each purchase stores a per-product period_end_map (timestamp of subscription end).
  The webhook updates this automatically when the subscription changes.

Magic Links

Magic Links allow manual sending of access links for already purchased products to customers.

Usage

1. Open Module Config under Send Magic Links:
   • Products: Select one or more products (only products with requires_access=1)
   • Token validity: Link validity duration in minutes (1–10080)
   • Recipients: Enter email addresses (one per line)
   • Test mode: First check with test mode enabled (no emails sent)
   • Send now: Activate checkbox and save to send
2. Each recipient receives one email with links to all selected products they own.
3. The report shows which emails were sent and which users don't own any of the selected products.

Tip: Always check in test mode first before actually sending emails!

Multi-Email Account Merge

Some customers purchase with different email addresses and end up with multiple accounts. The Account Merge tool consolidates all purchases from a source account into a target account.

Usage

1. Open Module Config under Merge User Accounts:
   • Source email: The email address whose purchases should be transferred (e.g. the old account).
   • Target email: The email address that will receive all purchases.
   • Test mode: Simulate the merge without writing anything – shows what would be transferred.
   • Execute merge: Activate the checkbox and save to run the actual merge.
2. The source account is deleted after a successful merge.

Note: Always run a test-mode merge first to verify the expected purchases are listed before committing.

Synchronization / Sync Helper

For advanced scenarios (e.g. when purchases were made outside the normal flow, or to backfill history), the module provides a Sync Helper:

• Run via module config or CLI.
• Fetches Stripe Checkout Sessions via API and writes them into the purchases repeater.
• Options:
  • Dry Run → simulate sync, only produce a report (no writes).
  • Update Existing → overwrite already linked purchases.
  • Create Missing Users → auto-create new users if no account exists for the checkout email.
  • Date Filters → limit sessions by from and/or to date.
  • Email Filter → restrict sync to a single customer.

The sync produces a plain-text report with:

• Session ID, date, customer email
• Status: LINKED, MISSING, CREATE, UPDATE, SKIP
• Line items with product ID, quantity, name, amount

This makes it easy to audit or re-import purchases safely.

Right of withdrawal

The module ships an electronic withdrawal function for B2C distance contracts. Delivered as a three-step Bootstrap modal flow rendered on every frontend page — no dedicated pages, no template choice, no theme rewrite.

What the module does

• Adds a repeater spl_withdrawals to the user template (13 spl_withdrawal_* sub-fields). The companion module StripePlAdmin reads/manages these entries.
• Renders three modals on every frontend page:
  • #withdrawalFormModal — step 1: contract identification + reason
  • #withdrawalConfirmModal — step 2: review + explicit confirmation
  • #withdrawalSuccessModal — step 3: receipt confirmation
• On submit:
  • if the entered email matches an existing user → appends a new spl_withdrawals repeater item;
  • if no user matches → no repeater item is created, but the admin still gets the notification mail;
  • in both cases, a receipt confirmation mail is sent to the consumer (durable medium) and an internal notification mail is sent to the admin.
• Withdrawals are reachable without login.
• HMAC-SHA-256 IP hash (peppered with $config->userAuthSalt), CSRF, honeypot, rate-limit (3 per IP per hour, 30 min session TTL).

Refund and any subscription cancellation are handled manually by the admin in the Stripe dashboard.

Setup

1. Optionally set Internal notification email in the module config (defaults to $config->adminEmail).

2. In your theme footer, render the legally required trigger link:

   echo $modules->get('StripePaymentLinks')->renderWithdrawalLink();

   Optional CSS class / custom label:

   echo $modules->get('StripePaymentLinks')->renderWithdrawalLink('nav-link fw-bold');
   echo $modules->get('StripePaymentLinks')->renderWithdrawalLink('', 'Widerruf');

That's it. The existing $modules->get('StripePaymentLinks')->render($page); call in your theme already injects all three modals on every frontend page; the link above triggers the flow.

Consumer-rights block in the order-confirmation mail

After a successful Stripe checkout the module sends an order-confirmation mail. Two TinyMCE config fields drive what consumer-rights wording the mail contains, classified per product via the existing requires_access flag:

Mixed orders show both blocks, each prefixed with {products} if you include that placeholder.

The module ships no hardcoded legal wording — it deliberately stays jurisdiction-neutral. You write the texts that match your jurisdiction once in the module config and they appear in every confirmation mail.

Available placeholders inside the texts

Simple value placeholders (replaced with the matching string): {products}, {provider}, {contact_email}, {order_id}, {order_date}, {name}, {email}, {today}.

Anchor-pair placeholders (rendered as <a href="…">linktext</a> — TinyMCE strips raw {…} inside href, so a wrapping pair is the only way to keep the linktext separate from the URL):

• {withdrawal_mail}LINKTEXT{withdrawal_mail_end} — pre-filled mailto: (subject + body filled from the order data)
• {withdrawal_online}LINKTEXT{withdrawal_online_end} — site root + ?withdraw=1 (opens the online withdrawal modal)

For a plain mailto: to the contact address, use TinyMCE's link tool directly — no placeholder needed.

Setup

1. In Withdrawal:
   • Privacy policy page (page selector)
   • Terms and Conditions page (page selector)
   • Contact email for withdrawal (used inside the {contact_email} and {withdrawal_mail} placeholders; falls back to the sender email when empty)
   • Withdrawal text — TinyMCE; see placeholders above
   • Waiver text — TinyMCE; see placeholders above
2. The pre-filled mailto: link (subject + body) is editable via the ProcessWire Translator under mail.fagg.withdrawal_mailto_subject and mail.fagg.withdrawal_mailto_body.

Custom mail layout?

If you use an own mail layout (config option Mail layout), add a slot for the consumer-rights block. The module passes raw HTML in $faggBlock:

<?php if ($has('faggBlock')): ?>
<tr>
  <td style="padding:0 22px 4px 22px;">
    <?= $val('faggBlock') ?>
  </td>
</tr>
<?php endif; ?>

Compliance note: Setting Access mail after purchase to never disables the entire confirmation mail — including the consumer-rights block. This is a config-level decision; the module does not override it.

Configuration

• Stripe Secret API Key
• Stripe Webhook Signing Secret (optional, needed only for handloing subscriptions)
• Product templates (to enable requires_access / allow_multiple_purchases flags)
• Access mail policy (never, newUsersOnly, always)
• Magic link TTL in minutes (default TTL for access tokens)
• Mail branding (logo, color, from name, signature, etc.)
• Sync options (dry-run, update existing, create missing users, date range, email filter)
• Magic Links (manual access link sending: product selection, TTL, recipients, test mode)

Optional: Bootstrap via CDN

The module’s modal dialogs and access UI are styled with Bootstrap 5.
If your site does not already include Bootstrap, you have two options:

1. Automatic inclusion (recommended for quick setup)
   In the module configuration, enable “Load Bootstrap 5 from CDN”. The module will then insert css and js assets automatically into your frontend.

This ensures the module’s modals, buttons, and notices render correctly, even if your site does not already use Bootstrap.

2. Manual inclusion
   If your frontend already includes Bootstrap (from your theme or build pipeline), you can leave the config option disabled. No additional assets will be injected, avoiding duplicates.

Developer Notes

• Purchases are stored as one repeater item per checkout.
• All purchased product IDs are stored in meta('product_ids').
• Session meta (Stripe Checkout session) is stored in meta('stripe_session').
• Recurring products store per-product expiry timestamps in meta('period_end_map').
• The webhook endpoint keeps these timestamps and paused/resumed states in sync.
• Access control uses hasActiveAccess($user, $product) to evaluate current entitlement.
• Modals are rendered via ModalRenderer.php with a clean Bootstrap view.
• Texts are centralized in defaultTexts() and must be accessed with mt() / t().
• Sync Helper (PLSyncHelper) implements the same persistence logic as checkout.
  It ensures that data structure in spl_purchases is identical whether created live or via sync.

Roadmap

• Sync helper for syncing older purchases or for controlling reasons since v1.0.7
• Support for auto handling subscriptions of gated content since v1.0.8
• Sending magic links for already purchased products to customers since v1.0.14
• Support for multiple webhooks since v1.0.19
• Grant users free product access since v1.0.23
• Multi-email account merge tool since v1.0.25
• Electronic withdrawal function (modal flow + audit log) since v1.1.0
• Order-confirmation mail with consumer-rights block — withdrawal instructions for redeemable products, waiver acknowledgment for digital-immediate products since v1.2.0
• Optional framework support (UIkit / Tailwind) via JSON view mappings
• Add more payment providers (Mollie, PayPal, …)

License

MIT License.
Copyright © 2025 frameless Media KG