LifterLMS Stripe Payments - WordPress Plugin

What This Payment Gateway Actually Solves

In LifterLMS, course sales revolve around the access plan. This is not a separate WooCommerce product, but a course or membership access option inside the LMS. An access plan can be free, one-time, recurring, trial-based, visible, hidden, or available only to members of a specific membership. LifterLMS Stripe Payments adds a payment gateway to that model, allowing it to process both one-time and recurring payments through Stripe.

When a student selects a paid access plan, LifterLMS sends them to the checkout page. There, the user creates or uses an existing account, enters payment details, applies a coupon if one is available, and confirms the purchase. After a successful transaction, the order receives the appropriate status and the student is automatically granted access to the course or membership.

The main value of the add-on is that it connects payment and learning access without requiring manual enrollment. If a payment fails, the order and access should not be treated as successful. If a recurring payment is canceled or cannot be charged, LifterLMS needs to reflect that in both the order and the student's access. That is exactly why webhooks, logs, and end-to-end testing matter more than simply checking the box to enable the gateway.

Where the Product Is Especially Useful

This add-on is a strong fit for sites where LifterLMS remains the main learning platform and Stripe is needed as the direct processor for bank cards and supported payment methods. Typical use cases include:

• Selling individual courses with one-time payments and automatic enrollment immediately after successful checkout.
• Selling membership access to a group of courses with recurring billing.
• Launching plans with a trial period, limited access duration, or hidden promotional plans.
• A school website where the administrator wants to track orders, transactions, refunds, and access status directly inside LifterLMS.
• A project that wants to avoid sending users into a more complex external cart when the standard LifterLMS checkout is enough.

When Another Approach May Be Better

LifterLMS Stripe Payments may be unnecessary if courses are sold as part of a large store with physical products, shipping, complex tax rules, gift cards, and dozens of payment methods through WooCommerce. In that case, it makes more sense to compare the native gateway with LifterLMS WooCommerce Integration. If your audience strongly prefers PayPal, it is worth keeping LifterLMS PayPal Payments alongside Stripe, or at least evaluating it as a second payment option.

Another case is custom corporate payments by invoice, bank transfer, or manual approval. For that, the Manual Payment Gateway in LifterLMS may be enough, especially if payments are handled off-site and the administrator is willing to approve orders manually.

What to Check Before Installing It on WordPress

A payment gateway affects money, user accounts, and access to learning content, so preparation matters more than installation speed. You should not simply activate the plugin on a live site and immediately ask students to pay. First, make sure the core LifterLMS setup is correct, the checkout page exists, access plans are published, and the server can communicate with Stripe securely.

The Minimum Technical Baseline

The official product page lists requirements for LifterLMS, WordPress, and PHP. This guide does not lock those version numbers in as permanent truth because they can change, but you should always verify them on the product page and against your own environment before installation. If the site is significantly behind on WordPress, PHP, or the LifterLMS core plugin, update a test copy first rather than upgrading the payment module directly on the live site.

• The core LifterLMS plugin must be active in WordPress.
• The required LifterLMS system pages must exist, especially the checkout page and student dashboard.
• The site must load over HTTPS, and the WordPress site address in settings must not point to an old HTTP version.
• The server must meet Stripe's current secure connection requirements, including TLS 1.2 or a newer stack.
• On a staging copy, you need to know whether automatic recurring payments are enabled so the test clone does not start behaving like production.

Checking the Checkout Page and Access Plans

If a course does not have an active access plan, visitors will not see a valid purchase path. If the access plan is hidden, it will not appear in the pricing table, even though it may still be available through a direct link. If a recurring access plan is not supported by the active gateway, LifterLMS may hide it on the public site so users do not end up at a dead-end checkout.

Before connecting Stripe, open one test course and confirm that it has at least one published paid access plan. Then verify that the course page includes either a pricing table or a working checkout button.

Administrator Access and Key Security

The setup should be done by a user with WordPress administrator permissions and access to the Stripe Dashboard. If an agency works on the site, do not send secret keys through chats, tickets, or generator prompts. The modern connection method through Stripe Connect reduces the need to copy keys manually. The legacy option with publishable and secret keys is still documented, but it should only be used intentionally.

If you have a staging site, configure test mode there first. For a payment product, that is not a formality. It is the normal workflow: you verify checkout, webhooks, order statuses, and access before any real money moves through live mode.

Installing the Add-On and Running the First Check

Installation works like a standard ZIP plugin upload in WordPress. The official documentation describes the path through Plugins > Add New Plugin > Upload Plugin, selecting the ZIP file, clicking Install Now, and activating it. After activation, however, installation alone does not mean the site can accept payments. The gateway still needs to be enabled and connected to Stripe.

What to Do Right After Activation

1. Open the WordPress admin panel and go to LifterLMS > Settings.
2. Open the Checkout tab and find the Stripe section.
3. Enable Enable Stripe Payment Gateway, but do not switch the site to live payment processing until testing is complete.
4. Click Connect Stripe if you are using the modern Stripe Connect flow.
5. After returning from Stripe, check the connection message and the Webhook Status.
6. Save the settings with Save Changes.

If your version shows legacy key fields, do not fill them in blindly. Test and live keys must never be mixed. Mistakes here can be deceptive: a test transaction may work in one mode while live payments fail or create incorrect customer identifiers.

How to Tell Whether the Initial Connection Works

The first indicator is the Stripe connection status and webhook status in the gateway settings. The second is the ability to open checkout for a test access plan. The third is the appearance of a test transaction in the Stripe Dashboard while test mode is enabled. Until all three are working, the setup should not be considered complete.

Do not switch to live mode until a full test order works from access plan selection all the way to student access being granted. A payment module is validated by the complete purchase flow, not by the settings screen.

Configuring LifterLMS Stripe Payments After Installation

The most useful settings area is under LifterLMS > Settings > Checkout > Stripe. Individual field names may vary by version, but the logic stays the same: the gateway is enabled, the site is connected to Stripe, test mode allows safe purchase testing, webhooks send Stripe events back to WordPress, and debug logging is only for troubleshooting.

The First Settings You Should Verify

Test Mode as a Required Stage, Not a Draft Setup

Test mode is not just for checking a card number. It proves that your access plan, checkout page, order status, enrollment, and webhook events all work together. The LifterLMS documentation states that once test mode is enabled, all transactions are sent to Stripe as test transactions. That means you must view test data in the Stripe Dashboard during verification, otherwise you may wrongly assume the payment was never created.

Quick Test Mode Check

1. Enable Enable Stripe Test Mode and save the settings.
2. Open the course as a normal user, ideally in a private browser window.
3. Select the paid access plan and complete checkout using Stripe test payment data.
4. Check the order in LifterLMS: its status, transaction, course link, and enrollment.
5. Check the Stripe Dashboard in test data mode: the payment, customer, and webhook delivery.

Webhooks: Why a Green Status Matters More Than a Nice Checkout

Stripe may show a successful checkout, but the site still needs to receive the event back. Webhooks notify LifterLMS about events such as completed checkout, failed payment, refunds, and expired sessions. The official documentation lists the events the add-on uses when setting up the webhook endpoint. If the webhook is missing or cannot receive events, the order, renewal payment, or refund may not be reflected in WordPress the way the administrator expects.

If Webhook Status is not confirmed, save the gateway settings once more first. The LifterLMS Stripe release notes mention improvements related to webhook updates when settings are saved, including cases where the site URL has changed. If the status still does not update, open the Stripe Dashboard, go to Developers > Webhooks, select the site's endpoint, and review the Logs.

Debug Logging: Enable It Only While Investigating

Debug logging is useful when payment processing or customer creation breaks, but it does not recover past errors. The official instructions make this clear: the log only appears after the mode has been enabled and the problem has been reproduced again. The correct sequence is this: enable logging, repeat the failed checkout, open LifterLMS > Status > Logs, choose the file starting with stripe-, save the output for analysis, and then disable logging.

Do not leave debug logging enabled permanently on a live site. It is for short-term investigation, not normal background operation.

Access Plans, Checkout, and Automatic Student Enrollment

In LifterLMS, payment is not separate from learning access. The buyer selects an access plan, goes through checkout, LifterLMS creates the order, Stripe processes the payment, and then the system updates the student's access. That is why issues often start not in Stripe, but at the course level: no suitable plan exists, the plan is hidden, the pricing table is missing, the checkout page was created incorrectly, or the required gateway does not support the selected payment model.

How an Access Plan Relates to the Payment Gateway

The access plan defines the access terms: one-time payment, recurring billing, duration, trial period, visibility, and eligible membership holders. The payment gateway determines whether the site can actually process that type of plan. The official LifterLMS documentation states that the system only shows access plans that can be fully handled by an installed and active gateway. This protects users from seeing a plan that cannot actually be purchased.

The practical takeaway is straightforward: if the pricing table is empty, do not start with CSS or the theme. First check whether there is a published access plan, whether it is hidden, whether the active gateway supports the payment type, and whether the checkout page exists.

One-Time Payment vs. Recurring Subscription

A one-time access plan is simpler: a successful payment usually leads to a completed order and access being granted under the plan rules. A recurring subscription is more complex because it involves future charges, failed attempts, statuses such as Active, On Hold, Failed, cancellations, and possible retry attempts. In these scenarios, webhooks and proper payment method support in Stripe matter even more.

Stripe supports many payment methods, but not every method works for subscription mode. The official LifterLMS documentation specifically notes that if you use a one-time payment method for a recurring access plan, the payment may fail. So when enabling additional payment methods in the Stripe Dashboard, always verify that the method supports recurring charges.

The Checkout Page and the Student Account

The LifterLMS checkout page does more than collect payment. It is where the user logs in, registers, enters billing information, and applies a coupon. The LifterLMS documentation states that guest checkout is not supported: an account is required for course enrollment. That makes sense in an LMS, because lesson access, progress, certificates, and the dashboard all need to belong to a specific user.

What to Check on the Checkout Page

• The page includes a valid LifterLMS checkout block or shortcode.
• The registration form does not conflict with the theme, caching, or third-party script optimization tools.
• After a successful payment, the user sees a clear next step rather than a blank page.
• The student dashboard is accessible after purchase and shows the correct course or membership.

Stripe Checkout, Additional Payment Methods, and Enabling Beta Mode Carefully

The standard LifterLMS Stripe flow displays payment inside the LifterLMS checkout. The documentation also describes Stripe Checkout, where the user is sent to a page hosted by Stripe. This mode is marked as beta, so it should not be enabled as a quick replacement without testing. Its main practical benefit is access to additional payment methods, including wallets such as Apple Pay and Google Pay, if they are available and configured in Stripe.

When Stripe Checkout May Be Worth Using

This mode is worth considering if your audience expects more than just bank card payments and needs a broader set of payment methods available in the Stripe Dashboard. However, the available methods depend on the account country, currency, checkout mode, and payment type. The restrictions are tighter for recurring plans than for one-time purchases. The best approach is not to enable everything at once, but to make a short list of the methods you actually need and test each one for compatibility with either one-time payments or subscriptions.

If you sell subscriptions, verify recurring payment support before publishing the plan. The problem often appears only at checkout, when the user has already selected the plan and expects to pay.

How Beta Stripe Checkout Is Enabled

The official instructions require adding a constant to wp-config.php, after which the Stripe settings show a payment flow selector. This change should be made by someone who knows how to edit WordPress configuration safely and roll it back if needed. Before making the change, back up the file and test the site on staging.

define( 'LLMS_STRIPE_ENABLE_STRIPE_CHECKOUT', true );

After adding the constant, go to LifterLMS > Settings > Checkout > Stripe, choose the Accept Payments in Stripe (Stripe Checkout) flow, save the settings, and check the webhook status. If the status indicates that the webhook is not installed, save the settings again or create the endpoint manually using the official instructions.

How to Roll Back a Risky Setting

If beta mode behaves inconsistently on your site, do not try to fix payment issues with random changes. Restore the previous payment flow in the settings, remove or comment out the constant in wp-config.php, clear the cache, and run the test access plan again. On a live site, it is important not to leave users stuck between two payment flows.

Practical Example: Sell a Course with a One-Time Payment and Verify Access

Let us take a concrete task: a school has a course that needs to be sold through Stripe with automatic enrollment after payment. We do not just want to see a card field. We need to confirm that LifterLMS created the order, Stripe accepted the payment, the webhook returned to the site, and the student gained access to the lessons.

Goal and Preparation

The goal is a one-time paid access plan for a course that works in test mode. Before starting, the following conditions should already be met: LifterLMS is installed, the checkout page exists, LifterLMS Stripe Payments is activated, Stripe is connected, test mode is enabled, and webhook status has either been confirmed or is at least understood well enough to diagnose.

Scenario Steps

1. Open the target course in the admin panel and go to the access plan section.
2. Create a new paid one-time plan with a clear name and Visible visibility.
3. Make sure the pricing table or plan selection block is displayed on the course page.
4. Open the public course page in a private browser window.
5. Select the access plan and proceed to checkout.
6. Create a test student or log in with a test account.
7. Complete checkout using Stripe test payment data and confirm the payment.
8. Return to the admin panel and open LifterLMS orders.

Verifying the Result

LifterLMS should show an order with the correct student, course, payment gateway, and transaction. For a one-time payment, a successful order should normally reflect a completed purchase, and the student should gain access to the course. A matching payment should also appear in Stripe Dashboard test data. If the order is stuck in LifterLMS while the payment exists in Stripe, inspect webhook delivery and logs.

Quick summary of the scenario: success is not the "thank you" page, but the full chain of access plan -> checkout -> Stripe payment -> LifterLMS order -> student enrollment.

A Nuance for Recurring Plans

If you are testing a subscription instead of a one-time payment, add checks for the renewal payment and order statuses. In LifterLMS, a recurring order may become Active, On Hold, Failed, or Pending Cancellation depending on the situation. For this kind of plan, it is important to understand in advance what notifications the student receives after a failed payment and whether automatic retry rules are enabled for the supported gateway.

Recurring Payments, Refunds, and Orders in LifterLMS

A payment gateway should not be judged only by the first checkout. On a live site, what matters just as much is the later life of the order: what happens during renewal charges, how a student cancels a subscription, what the administrator sees in order notes, how to issue a refund, and whether a refund affects course access.

How to Read Order Statuses

The official LifterLMS documentation describes orders as the foundation of payments, enrollment, and access control. For an administrator, this is the support center: it shows payment attempts, subscriptions, renewals, refunds, cancellations, and activity history. If a student says they paid for a course but have no access, check the order, transaction, and enrollment first, not just the Stripe Dashboard.

• Completed usually applies to a successful one-time purchase.
• Active matters for a recurring order where future charges are still expected.
• On Hold is often tied to recurring payment issues.
• Failed means the payment attempt did not go through.
• Refunded reflects a full or partial refund that may affect access.

Failed Payments and Automatic Retries

LifterLMS supports automatic retry of failed payments for certain gateways, including Stripe. This helps avoid cutting students off immediately because of a temporary card issue. By default, the system applies a sequence of retry rules: it moves the order to On Hold, waits for the configured interval, may send notifications, and after the final failed attempt changes the order to Failed.

The practical value of this feature is that it gives the student time to update their card or resolve the issue with their bank. But the administrator still needs to understand which notifications are sent, how long the retry window lasts, and what access remains during the On Hold period. If the rules were changed by a developer through a filter, make sure that is documented in the site's technical documentation.

Refunds Through Stripe and Course Access

LifterLMS distinguishes between manual refunds and automatic refunds through the gateway. A manual refund only records the refund inside LifterLMS and requires the money to be returned separately through the payment service. An automatic refund through Stripe sends the refund through the API. The LifterLMS documentation also warns that a refund may automatically unenroll the student from the course or membership, and if access should be preserved, it will need to be restored manually.

Before issuing a refund, always treat two questions separately: money and access. The financial operation and educational access are related, but in edge cases the administrator needs to decide whether the student should keep the materials after a partial refund or an exception-based refund.

Video Guide for Setting Up LifterLMS Stripe Payments

This video complements the guide: a product-specific walkthrough. Open it after the basic setup to compare the interface and the sequence of steps.