Paid Memberships Pro Gift Membership - WordPress Plugin

How to Set Up Paid Memberships Pro Gift Membership for Gift Subscriptions

Paid Memberships Pro Gift Membership is not meant for the standard case where a buyer purchases access for themselves. It supports a different flow: one person pays for the membership, while another receives a code and activates access on their own account. In this guide, we will walk through how to prepare membership levels, where to enable gift mode, how the emails work, what the recipient should see, which limitations matter, and how to test the full flow without putting active site members at risk.

This guide is written for a WordPress site owner, membership site administrator, support specialist, or developer who needs more than just turning on the Add On and wants to build a clear gift purchase flow. It does not cover how to buy the product itself or manage the license. The focus here is how to use the plugin once it is already available on a site running Paid Memberships Pro.

Gift memberships may sound simple: the buyer pays, the recipient enters a code, and access is granted. In practice, the quality of the experience depends on level groups, the checkout flow, email copy, the account page, the one-code-per-purchase limitation, and verifying that the buyer did not accidentally receive the level intended for the recipient. That is why this guide is built around the actual sequence of "level -> purchase -> code -> email -> activation -> verification."

Where gift memberships actually make sense

A gift flow works best when the membership itself is perceived as a complete product of value: access to a club, a course, a content library, a professional community, a private knowledge base, a training program, or a seasonal offer. A standard checkout form solves the need of "I want to join." Paid Memberships Pro Gift Membership adds a different intent: "I want to pay for someone else's access without mixing their account with mine."

What sets it apart from a regular discount or coupon is that the Add On ties the purchase to a unique gift code and lets the recipient activate a predefined level. The buyer may already be an active member. They do not have to lose their current level, change their own subscription term, or receive access that was meant for someone else. This is especially useful for clubs and educational projects where one user may want to buy a gift for a friend, colleague, student, or contest winner.

A solid use case for this plugin usually has three characteristics. First, the site already has a clear core level that can be gifted. Second, the gift purchase should not grant the same access to the buyer. Third, the administrator is ready to explain to the recipient where to enter the code and what will happen after activation.

Common use cases the Add On covers

• Time-limited gift memberships. For example, access to a premium section for several months, after which the recipient decides whether to renew.
• A promo gift without manually granting access. The administrator does not create the user by hand, but instead sells a code that the recipient applies on the membership checkout page.
• A gift from an existing member. The buyer keeps their current level, and the code becomes a separate item tied to another account.
• Gifts for events and contests. The organizer can sell or distribute gift access through a carefully planned level and a clear email to the recipient.

That said, the plugin is not a replacement for corporate teams, family plans, bulk distribution of dozens of codes in one payment, or a full certificate system with printable templates. The official limitations clearly state that each gift code requires its own checkout process. If your business model depends on bulk bundles, it is better to evaluate a different approach up front rather than turning support into manual order processing.

When the plugin may be unnecessary

If you simply want to give one person a discount, the standard Paid Memberships Pro discount code system is enough. If you need one payer to manage a group of members, a gift code may be too narrow for that use case. And if your site has not yet fully set up its base levels, payments, checkout pages, and emails, it is better to get the core subscription flow working first and only then add the gift layer on top.

Sanity check: if the gift recipient needs their own account and a separate access term, a gift code is a good fit. If the recipient is supposed to be part of an organization, team, or family plan managed by the buyer, the flow should be designed differently.

What to prepare before installing the Gift Add On

Before installation, it is important to understand that Paid Memberships Pro Gift Membership works on top of an existing membership system. It does not create the entire membership architecture from scratch. Base Paid Memberships Pro should already display membership pages, process checkout, send emails, and properly restrict content. If the core subscription flow is not working, a gift code will only add another layer of uncertainty.

Start by checking the main level the recipient should receive after activating the gift. That level should have a clear name, a defined term, access to the intended content, and predictable behavior after membership expiration. Then create a separate purchase level that the buyer will select and pay for. That is the level marked as a gift level and linked to the level that another person will actually receive.

Basic requirements for a WordPress site

• Paid Memberships Pro is installed and active. The Add On depends on the core system for levels, checkout, and emails.
• You have a working membership checkout page. It must include the checkout block or shortcode; otherwise the recipient will not be able to apply the code in a normal checkout flow.
• Your payment gateway has already been tested. The gift code is created after a successful purchase, so payment errors directly break the gift flow.
• Your site sends transactional emails. If WordPress emails land in spam or do not arrive, the recipient may never see the code or activation link.
• The intended content is actually restricted by the correct level. After gift activation, the user should receive access to exactly what was promised on the membership page.

Why you should think through level groups in advance

In Paid Memberships Pro, levels belong to groups. A group determines whether a user can have only one level from that group or multiple levels at the same time. For normal pricing tiers, this is useful: a member chooses, for example, basic or premium access. In a gift flow, that same behavior can cause problems if the gift purchase level sits next to regular levels and starts behaving like another step in the same pricing ladder.

The official Gift Membership documentation recommends putting gift levels in a separate group. That is not just a cosmetic suggestion. It reduces the risk of conflicts with proration, level replacement, and the purchase level being interpreted as a normal subscription. The gift level should function as a "product for buying a code," not as actual access for the buyer to restricted content.

Minimum set of levels

A clear setup usually requires two connected levels. The first is the main level the recipient will receive. The second is the gift level the buyer pays for. It is helpful to reflect the term or purpose in the gift level name, for example "Gift: Premium for 6 Months." In the public description for that level, explain that the buyer will receive a code for someone else, not access for themselves.

What to test on a staging copy

On a copy of the site, create a test main level and a separate gift level. Do not turn on every marketing page, email, and automation right away. First, make sure the base checkout flow can process a payment or test payment and that the system recognizes the order as successful. Only then enable the gift settings and test the full recipient journey.

Installation and first checks in the admin area

The official installation path goes through the Add Ons screen inside Paid Memberships Pro. In the WordPress admin area, open Memberships > Add Ons, find Gift Membership or Gift Levels, then install and activate the Add On. If you are installing it manually, use the standard WordPress screen at Plugins > Add New > Upload Plugin, then activate the plugin from the extensions list.

After activation, do not jump straight to selling it publicly. First, check whether the gift settings appear in the level configuration screen. Go to Memberships > Settings > Levels, open the level that will be used as the purchase level, and look for the additional Gift settings. If they are missing, the most likely causes are that the Add On is not active, core Paid Memberships Pro is not working properly, or you are using the wrong level editing screen.

First technical check

1. Open the list of levels. Make sure you can see the main level the recipient will receive and the separate level used to purchase the gift.
2. Open the gift level for editing. Look for the Gift Level? option and the related Level to Gift field.
3. Check the checkout page. The checkout page should display the selected level, and when a code is present, the recipient should have a place to apply it.
4. Open the email settings. Under Memberships > Settings > Email Templates, gift templates should be available if the Add On is activated correctly.
5. Check the account page. Later, the buyer should see a list of available and used gift codes there.

If you do not see the gift settings at this stage, do not try to work around it with custom code. First check plugin status, admin-side caching, user role, and whether core PMPro is installed. In a normal setup, Gift Membership adds its settings without any manual theme or plugin file edits.

How to configure a gift level without replacing the buyer's access

The most important setting in Paid Memberships Pro Gift Membership is not the email or the front-end button text, but the correct relationship between two levels. The level purchased by the gift giver should create a code. The level the recipient activates with that code should unlock the actual access. If those roles are mixed up, the buyer may get the wrong outcome, and the recipient may see a confusing form or the wrong membership term.

The official flow starts by creating the level that will act as the gift purchase. In that level's settings, enable Gift Level?, then choose the target level for the recipient in Level to Gift. You can also allow an email to be sent to the recipient through Allow Gift Emails and set the term of the gifted membership through Gift Expiration Period if the gifted access should end after a certain period following activation.

Settings you should understand before saving

After saving the level, open the public pricing page or the page that contains the checkout link. The level name should clearly show that the person is buying a gift. If you leave a generic name like "Premium," the buyer may assume they are purchasing membership for themselves. It is better to use wording that makes the role obvious right away: gift, certificate, access for a friend, trial access for a colleague.

Why it is better to separate the gift from the main pricing tier

A gift level should not compete with a regular level in the same pricing group. If it sits in the same group as your core levels, the site may interpret it as an alternate plan for the buyer. That increases the risk of conflicts with proration, level change behavior, and user expectations. A separate group makes the architecture clearer: core levels control access, while gift levels are used to buy codes.

Practical rule of thumb: if users choose between "Basic," "Premium," and "VIP" inside one level group, it is better to move the gift level out of that group. It can still appear on a separate gift page or in a dedicated block on the pricing page, but logically it should not behave like another standard tier for the buyer.

Setting price and duration without making unsupported promises

The price of the purchase level and the duration of the target level depend on your membership model. The documentation includes an example of a limited-term gift, but it does not require every site to use the same period. What matters is that the buyer understands what they are paying for, and the recipient gets the access duration promised in the gift description.

Do not pack too many conditions into a single gift level. If you offer a one-month gift, a six-month gift, and a one-year gift, it is often easier to create separate gift levels and link each one to the appropriate setup. That makes it easier to test emails, checkout, and user expectations. A complicated one-level-all-purpose approach may look convenient for the administrator but remain unclear for the buyer and the support team.

How a purchase becomes a code and an activated membership

The useful part of the Add On happens in the gap between payment and access. The buyer selects a gift level and completes checkout, and once the order succeeds, a unique code is created. That code is not just an informational string in an email. It becomes the mechanism another user uses on the checkout page to apply the gift and receive the predefined membership level.

This behavior explains several limitations. The buyer does not receive the target level because their role is to pay for the code. The recipient must go through their own checkout because the site needs an account to assign the membership to. The code cannot be applied on the same account that purchased it, because otherwise the gift would turn into a workaround for the buyer's own level change.

State flow

It is helpful to think of Gift Membership as a transition between states:

1. The buyer selects the gift level. At that point, the site already knows which level should be gifted because the relationship is defined in Level to Gift.
2. The payment or order completes successfully. Only after successful checkout is the code created and ready to pass to the recipient.
3. The code becomes available to the buyer. It appears in an email, on the confirmation page, or in the account area depending on your settings and templates.
4. The recipient uses the code during checkout. They complete checkout for the target level, and the code applies the gifted access rights.
5. The site changes the recipient's account state. After successful activation, the recipient's account receives the correct level and duration.

If the expected outcome is missing at any point in that sequence, troubleshoot the exact point where the chain breaks. No email arrived - check the template and mail delivery. No code was created - check the order status and payment gateway. The code will not apply - check the checkout page, the level, the buyer-account restriction, and whether the code is still valid. The recipient received the wrong level - go back to Level to Gift.

Where the administrator can see evidence of the transaction

The documentation and changelog indicate that buyers can view the history of purchased, available, and used codes, while administrators can see gift codes in related parts of the admin area, including the user record or discount code screen. That matters for support: if the recipient says "the code doesn't work," there is no need to guess based on emails alone. Check the order, the buyer, the generated code, its usage status, and the target level.

From a practical support standpoint, it is worth agreeing in advance on which details your team may request from users. Usually the buyer's email, the recipient's email, the approximate purchase time, and the code itself are enough if the user is willing to share it. Do not ask for passwords, card details, or mailbox access. The gift flow is tied to a payment, but code troubleshooting should not turn into unnecessary collection of personal data.

Emails for the buyer, the recipient, and the administrator

Gift membership does not work well when the user journey is clear only to the administrator. The buyer should get confirmation, the recipient should get the code and clear instructions, and the administrator should get a purchase notice. Gift Membership adds three email templates: Gift Recipient, Gift Purchased, and Gift Purchased (admin). It is worth configuring them before publishing the gift level.

Go to Memberships > Settings > Email Templates and open each gift template. Do not rewrite the message as a marketing banner. A transactional email should answer practical questions: who sent the gift, what access was gifted, where to apply the code, what to do if the link does not open, and where to contact support if something goes wrong.

Email variables and the new syntax

The official Add On page lists gift variables in the old double-exclamation format: !!pmprogl_giver_display_name!!, !!pmprogl_gift_message!!, !!pmprogl_gift_code!!, and !!pmprogl_gift_code_url!!. The GitHub changelog notes that recent versions of the Add On support a Liquid-like syntax for newer PMPro versions while retaining backward compatibility with the old format. So when editing a template, use the variable list shown in your admin area instead of blindly copying an example from an older article.

Cautious best practice: if the template editor shows newer variable hints, use them. If the site is running an older combination of versions, do not replace every variable in one bulk pass. Send a test email first, then run a real test purchase using a small test level.

What to include in the recipient email

The recipient email should be as practical as possible. The person may not have an account on your site, may not know Paid Memberships Pro, and may not understand why they are being asked to go through checkout. The email should therefore explain that the gift giver has already paid, and that the recipient needs to create or use their own account so the membership can be assigned to them.

• Who sent the gift. Use the gift giver's name if it is available and appropriate.
• What exactly was gifted. The level name and duration should match the public gift description.
• Where to activate the code. Provide a checkout link or clear instructions on how to reach the activation page.
• What to do if something goes wrong. Include support contact details and specify what information to provide without sharing passwords or payment details.

What to include for the gift giver

The gift giver mainly needs purchase confirmation and a way to find the code again later. If the recipient does not receive the email, the buyer is often the first person to contact support. For that reason, it helps to explain in the gift giver email where they can see available and activated codes in their account. Do not overload the email with technical detail. It is enough to briefly show that the purchase succeeded, the code was created, the email was sent, and the status can be checked in the account area.

What to leave in the admin email

The administrator email should not reveal unnecessary information, but it should support troubleshooting. Include the gift level name, the buyer's email, confirmation that the code was created, and a link to the related order or account if the template and available variables allow that. If those variables do not exist in your editor, do not invent them. It is better to keep the email simpler and more reliable.

Email check: a test send from the template editor is useful, but it does not always populate data in the same way as a real purchase. Be sure to run a full test order and review the live emails in your mail log or inbox.

Practical example: gifting temporary access to a Premium section

Let's look at a concrete example. The site has a restricted content library for the "Premium" level. The owner wants to let users buy access as a gift for a friend for a limited period. The buyer should pay for the gift, add a message and the recipient's email address. The recipient should receive an email, follow the link, create an account or log in to an existing one, and activate access.

Goal

Build a separate gift level that sells a code for the "Premium" level but does not itself grant the buyer access to the restricted library. After code activation, the recipient should see the Premium content and membership term if a term is configured.

Preparation

1. Make sure the main "Premium" level already exists and grants access to the correct materials.
2. Create a separate level group for gifts so the gift does not get mixed into the main pricing group.
3. Create a new level with a public name such as "Gift: Premium."
4. Set the purchase level price so it matches the promised gift access.
5. Check the checkout page and delivery of regular PMPro emails.

Setup steps

1. Open Memberships > Settings > Levels and edit the "Gift: Premium" level.
2. Enable Gift Level? so the level becomes a gift code purchase.
3. Select the main "Premium" level in the Level to Gift field.
4. Enable Allow Gift Emails if you want the buyer to send the code directly to the recipient.
5. Set Gift Expiration Period if the gifted membership should end after a specific time following activation.
6. Save the level and open the public page from which the buyer will go to checkout.
7. Edit the Gift Recipient and Gift Purchased templates so they explain how to apply the code.

Checking the outcome

Create a test buyer who either already has a regular level or has no membership at all. Purchase the gift level using the payment gateway's test mode. After the order succeeds, check four outcomes: the buyer did not receive the "Premium" level as their own membership, a gift code was created, the recipient email contains the code or link, and the buyer's account shows the code status.

Then open the activation link in a different browser or private window, log in as a test recipient, and apply the code. After checkout is completed, the recipient should receive "Premium," and the code should move to a used state. If you run the test on the same account, you will hit an intentional limitation: the code cannot be activated on the account that purchased it.

A common pitfall

The public description for the level should be written for the gift buyer, not for the future member. If the level page says "Get access to Premium," the buyer may assume the access is for them. It is better to say it directly: "You are purchasing a code that another person will activate on their own account." That reduces support requests and makes the checkout flow more honest.

The recipient journey: from email to the first protected piece of content

The flow does not end when the buyer sees the code. For the business, the real outcome appears only when the recipient activates the gift, enters the protected area, and understands what to do next. That is why, when configuring Gift Membership, you need to design not only the buyer's checkout but also a separate journey for the recipient. It should contain less commercial copy and more clear instruction.

Recipients often arrive on the site with no context. They may have received the gift from a friend, employer, contest organizer, or community member. If the email drops them directly onto a form with payment fields and technical level names, they may assume they are being asked to pay again. A good activation page explains that the gift has already been purchased, and that checkout is only needed to create an account and attach the level to that account.

What should be clear before the code is entered

On the page or in the email before checkout, explain three things. First, the gift has already been paid for by the buyer if the code came from an official site email. Second, the access is tied to the recipient's account, so logging in or registering is a normal part of the process. Third, the code grants a specific level and duration, not an open-ended discount on any plan.

You do not need a long legal explanation. A short block above the form or next to the activation button is enough. For example: "Enter the code from your email to activate gifted Premium access on your account. If you already have an account, sign in before activating." A line like that removes two common points of confusion: why registration is required, and why the code should not be used on the gift giver's account.

For a new user

A new user should go through checkout in a way that creates an account and assigns the membership to it. Check which fields your site's checkout requires. If you collect additional User Fields, they should be truly necessary for the recipient. Do not force someone who was gifted access to a course or library to fill out extra marketing fields before their first activation. The shorter the path, the fewer support requests you will get.

For an existing user

An existing user should sign in first. If they apply the code before logging in and accidentally create a second account, support may have to untangle expectations manually. It is useful to add a gentle note in the recipient email: if you already have an account, sign in before activating your gift. This matters especially in communities where someone may already have a free level or an old registration.

Verifying access to the first piece of content

After the code is activated, do not stop at checking the status in the admin area. Open one protected item that should be available to the target level. The recipient should see not just the account page but the actual content as well. If the account shows an active level but the protected item is still unavailable, the issue may be in content restriction rules, caching, a custom access message template, or selecting the wrong target level.

Practical check: prepare one test protected item with a clear title and use it as your control point after each gift level adjustment. That way you are verifying not just the code, but real access.

For support, it helps to keep a short internal sequence in mind: "buyer -> order -> code -> recipient -> level -> test content." If every point in that chain checks out, the user's issue is most likely tied to a specific browser, email, link, or an attempt to reuse the code. If the chain breaks for every test user, look for a system-wide configuration issue.

How a gift code differs from a standard discount

Gift Membership uses code-based behavior at checkout, but the meaning of a gift code is different from a standard marketing discount. A normal discount code helps someone purchase their own level at a lower price or under special terms. A gift code transfers access rights from the buyer's purchase to the recipient's account. If those two concepts are mixed together, the gift page becomes confusing, and support starts getting questions about why the code is "not a discount" or why the buyer did not become a member.

This comparison matters especially for sites that already use promo codes. An administrator may habitually call the gift a "coupon." That may sound understandable internally, but users usually associate coupons with a discount at checkout. In Gift Membership, it is better to call it a "gift code" or "gift activation code" because the recipient is not redeeming a discount, but activating a membership that has already been paid for.

Difference in purpose

This difference affects copy, buttons, emails, and troubleshooting. For a discount, you can say "use the promo code at checkout." For a gift, it is better to say "activate the gift code on your account." In the first case, the person is paying for their own membership. In the second, they are claiming access that has already been purchased for them.

Why you should not replace a gift with a manual discount code

Technically, an administrator can create a regular discount code and send it to someone. But that option is a poor fit for a gift flow. It does not create separate logic for the gift giver, does not show the buyer a list of gift codes and statuses, and does not separate the public purchase level from the target level as clearly as Gift Membership does. For a one-off manual promotion it may work, but for an ongoing "Gift Access" page, the specialized Add On is the better fit.

There is also the opposite case. If a marketer simply needs to send subscribers a discount, Gift Membership is unnecessary. A standard discount code is simpler because the person receiving the discount is the one buying the membership. Do not introduce gift mechanics where there is no second person in the flow. It makes checkout more complicated without adding value.

Support checklist: what to review after launch

After publishing the gift level, the main burden shifts from development to support. User questions will sound ordinary: "the email never arrived," "the code doesn't work," "I paid but there's no access," "the recipient doesn't know where to click." To respond quickly, the team does not need database access. It needs a clear review sequence in the admin area and on the public-facing site.

Create an internal troubleshooting card. It should include these fields: gift giver email, recipient email, gift level name, target level, order status, code present or not, code status, checkout link, and the result of testing access to a protected item. This kind of checklist helps you distinguish a payment issue from an email issue or an activation issue.

Which statuses matter for support

A gift purchase has several observable states. The order may be successful or incomplete. The code may be created or missing. The email may be sent or undelivered. The code may be available, used, or not valid for the current account. The recipient's level may be active, missing, or different from what was expected. When support can see these states separately, fixes become more precise.

• Order status. If the order is not complete, the code may never appear. Start troubleshooting here.
• The relationship between the gift level and target level. If the wrong Level to Gift is selected, the recipient will receive the wrong access.
• Code status. If the code has already been used, reactivation should not create new access.
• The recipient's account. If the recipient is signed into the wrong account, the access will not appear where they expect it.
• Email delivery. If the code exists but the email does not, the issue is in the template or mail delivery, not the gift level itself.

How to avoid breaking live orders while fixing issues

If you discover a problem after the first purchases, do not change everything at once. Reproduce the issue on a test level first. Then fix one setting and rerun the test. Only after that should you decide how to handle live orders. For example, if a button pointed to the target level instead of the gift level, fix the link first, but review older orders separately: who received access, who should have received a code, and who needs a clarification email.

Do not "fix" gift codes by directly editing database tables. Even if a developer knows PMPro's schema, manual edits can break the relationships between order, code, and user. It is safer to use the admin area, official hooks, or the product developer's support. For a content team, correct copy, correct links, and a clear email are usually enough.

Writing the gift page: what to say without over-selling

The public gift page should explain the process faster than the user can become uncertain. It should not repeat the entire standard membership page. The visitor already understands the value of the product or arrived through a recommendation. Their job now is to understand what exactly they are buying, how the recipient activates access, and what happens after payment.

The page structure can stay short: who the gift is for, what the recipient gets, how activation works, what the email contains, and what limitations apply. Next to that, place the checkout button for the gift level. If the site offers several gift durations, split them into separate cards and do not bury the difference in a long paragraph.

Language that reduces confusion

• For the buyer: "After payment, you will receive a gift code for another person. Your current membership level will not change."
• For the recipient: "Activate the code on your own account to access the protected content."
• For the help page: "If you already have an account, sign in before activating the gift."
• For support: "If the code will not apply, please share the gift giver's email, the recipient's email, and the code itself."

These lines do not replace proper setup, but they reduce incorrect assumptions. The user sees the separation of roles before paying. The recipient understands why they need to use their own account. Support receives specific information instead of a vague "it doesn't work."

Promises you should avoid

Do not promise that the email will always arrive instantly. Delivery depends on the site's mail setup, spam filters, and whether the address was entered correctly. Do not promise that the code can be used at any time without restrictions if you have configured a gifted membership term or internal activation rules. Do not say the gift is suitable for group access if each code requires a separate checkout. An honest page hurts sales less than later disputes with users.

How to place the gift purchase on the site without confusing users

Once the technical setup is complete, you need to present the gift on the site in a way that makes the path clear to the buyer. You can use the default PMPro levels page, a dedicated gift page, a checkout button block, or the [pmpro_checkout_button] shortcode. The right choice depends on how different the gift flow is from a normal sign-up.

If the gift is an additional seasonal offer, it is often easier to create a separate "Gift Access" page and display only gift levels there. If the gift is a permanent part of the product, you can add a dedicated block on the pricing page. In either case, do not mix two calls to action in the same paragraph: "join yourself" and "gift to someone else" should be visually and textually distinct.

Button on a dedicated page

PMPro documentation describes the Membership Checkout Button block and the [pmpro_checkout_button] shortcode, both of which create a checkout link for a specific level. That is convenient for a gift level: you can place the button next to the gift explanation, and checkout will open with the correct level already selected. If you use the shortcode, double-check that you are using the ID of the gift level, not the recipient's target level.

[pmpro_checkout_button level="12" text="Gift Premium Access"]

This example shows the idea, not a ready-made value to copy. The number in level must be the ID of your gift level. If you accidentally use the main level ID, the buyer will be sent to a normal membership checkout for themselves instead of a gift code purchase.

Activation page for the recipient

The recipient needs a simple path: the email or code should lead to a checkout page where the gift code can be applied. Do not bury that path in general documentation. If your audience is not used to membership sites, create a short help page called "How to Activate Your Gift" and explain three steps: open the link, create an account or sign in, and complete the code activation. Even if the email link already contains a direct path, leave a fallback option for people who copy the code manually.

The buyer's account page

The official Add On page shows that the gift giver can see purchased codes and their statuses in the account area. This is a useful self-service feature. Add a short line to the gift giver email explaining where to view the code again. Then if the recipient loses the email, the buyer can either find the code themselves or contact support with specific information.

Limitations, compatibility, and launch decisions

It is better to explain Gift Membership's limitations to the team before going live. Some of them may look like bugs if this is the first time someone is working with a gift flow. In reality, they protect the product's intended behavior: buyer and recipient are separate, the code is activated separately, each code purchase requires its own checkout, and gift levels are best kept outside the main level group.

One code, one checkout

The official documentation states that bulk purchasing of gift codes in a single checkout is not supported. The user must complete a separate checkout for each gift code. That is fine for one-off gifts, but inconvenient for a corporate order involving dozens of recipients. If that use case comes up often, prepare a manual admin-assisted process in advance or consider a solution designed for group access from the start.

The buyer does not receive the membership

Gift Membership deliberately does not assign the target level to the buyer. This is important for existing members: their own membership should not change just because they bought a gift. That needs to be stated plainly on the gift page. The user should not have to contact support asking why they do not see Premium content after payment.

The code will not activate on the same account

The code cannot be applied to the same account that purchased it. For testing, this means you cannot validate the entire flow using one user alone. You need two test accounts or a private window for the recipient flow. For support, it means that when someone says "the code doesn't work," you should confirm whether the buyer is trying to activate their own gift on the same account.

Payment gateways and asynchronous statuses

The Add On changelog includes fixes related to Stripe Checkout and other asynchronous gateways where email delivery and code creation could depend on order status. That is not a reason to avoid Stripe or other gateways, but it is a reason to test the gift flow using the exact payment method enabled on your site. Check not only successful payment, but also what happens after returning from an external payment page if the gateway uses redirects.

Caching and membership pages

Checkout, account, confirmation, and pages showing personal status information generally should not be served from a static cache shared by all visitors. PMPro has its own caching documentation and core changes related to cookies and page behavior. For the gift flow, the practical rule is simple: if a user sees someone else's status, an outdated code, or a form missing an expected field, first check cache exclusions for PMPro pages.

Safe improvements without editing the plugin core

Gift Membership already provides the main settings in the admin area, and the official Add On documents the pmprogl_gift_code_settings and pmprogl_gift_code_purchased hooks for developers. But not every idea should turn into code. If the problem can be solved through a level name, email copy, a separate help page, or a checkout review, use those options first. They are easier to maintain and less likely to break during updates.

When code makes sense

Code is appropriate when you need to change gift code parameters during creation or run an action after a code is purchased, such as sending an event to your own internal log. Those customizations should live in a separate functionality plugin or Code Snippets, not in edits to PMPro, Gift Membership, or the active theme files. PMPro documentation specifically recommends storing customizations safely so updates do not overwrite them.

If a developer uses the $pmprogl_gift_levels array, it is important to remember the official warning: this PHP-based setting can override the configuration set in the admin area. That is a powerful option for complex setups, but a poor fit for a site where levels are frequently edited by a content manager without developer involvement.

A small CSS tweak for clearer messages

A safe and reversible example is making checkout messages and the discount code label more noticeable on PMPro pages. This does not interfere with payment logic or change how the gift code works. Add this CSS through Appearance > Customize > Additional CSS, through the Site Editor for a block theme, or in a separate file inside your custom functionality plugin.

.pmpro_message.pmpro_success,
.pmpro_message.pmpro_alert,
.pmpro_message.pmpro_error {
  border-radius: 6px;
  padding: 14px 16px;
  line-height: 1.45;
}

.pmpro_tag-discount-code {
  font-weight: 700;
  letter-spacing: 0;
}

.pmpro_form .pmpro_form_submit {
  margin-top: 18px;
}

After adding the CSS, open checkout and the confirmation page, apply a test code, and verify that the messages are easier to notice without hurting form accessibility. If the style conflicts with the theme, remove the snippet from where you inserted it and clear the cache. Do not edit the plugin's own files: your changes will be lost on update, and troubleshooting will become harder.

A practical pairing with email delivery and mail logging

Gift Membership depends heavily on email. If the site sends transactional notifications regularly, it is worth using a reliable SMTP setup or a mail delivery service through a standard WordPress email plugin. This is not an official Gift Membership integration by itself, but a practical setup based on the fact that the Add On sends gift notifications through the site's email system. Gift Membership creates the code and triggers the email; the mail delivery layer improves the chances that the email actually arrives.

The setup order is straightforward: first test the gift flow without extra automation, then enable transactional email delivery, then repeat the test purchase and confirm that the recipient email, gift giver email, and admin notification all go out with the correct sender details. If emails stop arriving after the mail service is connected, roll back the mail delivery change and return to a basic review of the PMPro templates.

Troubleshooting common gift code issues

Problems with gift memberships almost always trace back to one of five points: the level is not configured as a gift, the order did not complete successfully, the email was not sent or did not populate variables, the recipient is trying to apply the code in the wrong place, or caching is showing an outdated state. Troubleshooting works best when you follow the chain instead of changing several settings at once.

The code is not created after purchase

Symptom: the buyer completes checkout, but there is no gift code in the email or account area. A likely cause is that the order did not receive a successful status, the level was not enabled as Gift Level?, the wrong level was selected, or the payment gateway returned the user in a way the site did not expect.

First open the PMPro order and check its status. Then open the purchase level and make sure it is connected to the target level through Level to Gift. If you use an external checkout or an asynchronous gateway, test using that exact payment flow. If the problem happens only with a specific gateway, verify that PMPro and Gift Membership are up to date, because the changelog already includes fixes for similar cases.

The buyer received access instead of the recipient

Symptom: after purchase, the gift giver's level changes, and the gift flow behaves like a normal sign-up. This usually means the user purchased the wrong level or the checkout link points to the target level ID instead of the purchase level ID. Check the button, shortcode, direct link, and level settings.

The fix starts with the path itself. If the page uses [pmpro_checkout_button], the level value should point to the gift level. If the link is built manually through ?pmpro_level=ID, that ID must also be the gift level ID. After correcting it, run a new test order. Handle older incorrect orders carefully through the admin area without editing database records directly.

The recipient did not receive the email

Symptom: the code was created and the buyer can see it, but the recipient received nothing. Possible causes include Allow Gift Emails not being enabled, the buyer not entering the recipient's email address, the message landing in spam, the template being disabled, or the site having broader transactional email delivery problems.

Check the Gift Recipient template, send a test email, then run a real test purchase using a separate recipient address. If the email does not send at all, review PMPro sender settings and the site's mail log. If the email sends but does not include the code, check the template variables and the syntax supported by your PMPro and Add On versions.

The code will not apply at checkout

Symptom: the recipient enters the code, but checkout does not accept it or does not open the correct level. First confirm that the buyer is not trying to use the code on their own account. Then check whether checkout is open for the target level, whether the discount code field is displayed, whether the page is stale because of caching, and whether the code has already been used.

If the code has already been activated, it should not grant access again. If the code is unused but the form does not show a field to apply it, check the PMPro discount code field settings and whether a code exists for that level. Sometimes the issue is not in Gift Membership at all, but in a custom checkout template that hides required form elements.

The gift status is missing from the gift giver's account

Symptom: the buyer cannot find the purchased code or its activation status. Check whether the site uses the standard PMPro account page or a heavily customized template. If the account page has been replaced by a builder layout or a custom template, some of the Add On output may be hidden.

Temporarily switch to the standard account block or shortcode on a test page and see whether the code list appears. If it does, the cause is in the page customization. Restore the necessary elements carefully through the template or page layout without removing PMPro system components.

The gift level conflicts with proration

Symptom: buying a gift triggers strange calculations, level replacement, or behavior that looks like switching between pricing plans. The official limitation points to possible incompatibility with proration when the gift level is in the same group as core levels. The fix is to move gift levels into a separate group and test checkout again.

If you already have live orders, do not change levels in bulk without a plan. First create a test group and a test gift level, repeat the flow, confirm the problem is gone, and only then move your production configuration during a calm period.

When Paid Memberships Pro Gift Membership is the right choice

Paid Memberships Pro Gift Membership is worth using if your site already runs on PMPro, you already have a working access level, and you want to give buyers a clear way to pay for someone else's membership. The Add On's strength is the simple link between a gift level, a unique code, the recipient email, and activation on a separate account. That is exactly what sets it apart from a standard discount.

Before launch, check more than just whether the Add On is enabled. Review the full user journey: a separate level group, a clear gift name, the correct Level to Gift, email templates with working variables, a test purchase, code activation from another account, the status in the gift giver's account, and the recipient's access to protected content. If all of that works without manual fixes, you are ready to publish the gift page.

If you are ready to test the flow on your own site, you can download the ZIP archive near the download section, install the Add On on a staging copy, and walk through the complete path from purchase to gift code activation. That test will tell you more than any purely theoretical settings review.