The purchase access helper

pom_lms_user_purchased_course( int $course_id )

Answers whether the current user has a qualifying purchase for a course.

The return value

Falsy when there is no qualifying purchase. When there is one, the helper returns the identifier of the product that granted it — so a truthy result tells you not just that they bought it, but which product counted.

Treat it as a boolean unless you need the product:

$product_id = pom_lms_user_purchased_course( $course_id );

if ( $product_id ) {
    // Optionally: link to the product they bought.
}

That is how the My courses table names the product in its access column.

What counts as a qualifying purchase

The helper looks at the current customer's orders and asks whether any of them contains a product attached to the course.

Two conditions narrow it:

• The order must be in a paid status. Pending, on-hold, cancelled, refunded and failed orders do not count.
• If the product is a subscription product, the customer must additionally have an active subscription for it. A lapsed subscription does not grant access, even though the original order is still paid.

That second condition is what makes subscription-based selling behave like a membership rather than a one-off purchase.

Requirements

WooCommerce must be active. Subscription handling additionally requires the WooCommerce subscriptions extension; without it, subscription products behave as ordinary purchases.

Guard accordingly, and remember that a site can lose WooCommerce — a paid course on a site with WooCommerce deactivated cannot grant access to anyone.

Current user only

No user-ID parameter, and no supported way to ask on behalf of someone else. Check at render time.

Cost

This is the expensive helper. It reads the customer's orders and inspects their line items, so it is not something to call in a loop over a large catalogue.

If you are listing courses, cache the result per course for the duration of the request.

When to call it directly

Rarely. For deciding whether to show content, call the course access helper — it applies the login gate and the permission rule first, which this helper does not.

Direct calls make sense for:

• Labeling, when you want to name the product a student bought.
• Cross-selling, when you want to offer a related product to someone who already owns this one.
• Order-side integrations, where you are reacting to a purchase and want to know which course it unlocked.

What it does not do

• It does not consider permission rules. A student who has access through a rule and never bought anything returns falsy here.
• It does not consider the login gate.
• It does not tell you when the purchase happened. Date conditions are expressed in permission rules, not here.
• It does not grant anything. It reports.