Let MemberPress Members Update Their Card Without Logging In

The simplest way to let a MemberPress member update their card without logging in is to use Stripe's own hosted pages, with no custom code: turn on Stripe's failed-payment and expiring-card emails with the hosted-page link, or share Stripe's customer portal login link. Neither needs a WordPress login. If your team has to send one member one link from WordPress, a custom link that expires and sends the member to Stripe Checkout can do it; see how that works below. Check first that the new card lands on the payment method Stripe charges.

This guide covers members who pay through Stripe. PayPal members update their payment method in PayPal (MemberPress docs). We first published this post in July 2020 and updated it in October 2026.

What MemberPress gives members out of the box

For a Stripe subscription, MemberPress's documentation says the member can go to the Account page on your site, open the Subscriptions tab and click “Update” next to the subscription. That works well when the member can log in.

It stops working when your members area is closed because members get their product by email, when the member is logged out as your failed-payment email lands, or when they have forgotten their password. A password reset gets them in, but it is still a login. MemberPress's own failed-payments article suggests linking the email to the member's account page, which needs that login too. Options 1 and 3 below do not.

Which option fits

Step zero: find out which payment method Stripe charges

Every option above ends with a new card saved in Stripe. Whether that card gets charged depends on where it is saved. Stripe's API reference says a subscription's own default_payment_method takes precedence over its default_source. If neither is set, invoices use the customer's invoice_settings.default_payment_method or default_source.

Stripe's customer portal writes to the customer-level setting: its payment method flow sets customer.invoice_settings.default_payment_method. If a subscription override remains, the subscription wins and the portal's new card is not charged. Stripe also documents that customers can remove a subscription's override through the portal, so test whether your portal flow does.

MemberPress's public documentation does not say whether it sets a default payment method on each Stripe subscription. We could not verify it, so test your own site in Stripe test mode before you rely on any option:

1. Create a test subscription through MemberPress using a test card.
2. Retrieve that subscription in Stripe and look at both default_payment_method and default_source. If either has a value, the subscription has its own override. If both are empty, it falls back to the customer's settings.
3. Update the card using the option you picked, then retrieve the subscription again. Confirm that the next invoice would use the new card, not the old one.

Option 1: Stripe's hosted pages, no code

Stripe can handle this without a line of code from you. There are two ways in.

Emails with a hosted-page link

Stripe's customer email settings let you send an email with a link to a Stripe-hosted page. Stripe describes the link as “a secure, private URL”. On that page, per Stripe's documentation, the customer can “update their payment method for the relevant subscription and pay any outstanding invoices if applicable.”

1. In the Stripe Dashboard, open the revenue recovery email settings.
2. Turn on “Send emails when card payments fail” and “Send emails about expiring cards”.
3. Set the link destination to the Stripe-hosted page, not your own subscription management page. Open one MemberPress subscription in Stripe and confirm it charges automatically, because Stripe leaves the link out for subscriptions that send an invoice by email.
4. Test with a test-mode subscription. In a Stripe sandbox, Stripe does not send these emails on its own, so use an address on your verified email domain or a team member's address.

Two limits. Stripe sends the expiring-card email one month before the expiry of the customer's default payment method or default source, so a card that exists only as a subscription-level override may not trigger it. And the link stops working when the subscription is canceled or unpaid, or when its renewal period has expired. For what happens after a decline, our guide to Stripe failed payments on a WordPress membership site covers retries.

Stripe's portal login link

Stripe can give you one link to put on a page of your site or in an email. The member enters their email address, and Stripe emails them a login link to their own portal. No WordPress account is involved.

1. On the customer portal configuration page in the Stripe Dashboard, click “Activate link” in the “Ways to get started” section.
2. Choose what members can do there. Payment methods are on by default.
3. Share the link on a page or in an email. You can add ?prefilled_email= with the member's URL-encoded address so they do not have to type it. They can still edit it.

Stripe matches on the email address of the Stripe customer. Check that one test member's Stripe customer email is the address they use on your site. If two customers share an address, Stripe picks the newest one that has an active subscription.

Do not email a portal session URL created through the API. Stripe tells you to authenticate customers on your site before creating those sessions, and a new session expires after five minutes.

Option 2: a magic login link, if you keep a members area

If you keep your members area, the shortest path is getting members into their normal account page without a password. We built a free plugin for that, WP Magic Login Link. The member enters their email, gets an emailed link and lands logged in, then uses MemberPress's Update link.

The link logs the member into their account, not into a card form. The plugin's FAQ says you cannot revoke a magic link for one user yet, and that link sharing is no safer than sharing a password. We did not re-test its compatibility with current WordPress and MemberPress versions for this update. If you only want members to change a card, use Option 1 or 3.

Option 3: how a safe custom link works

We are not publishing copy-and-paste code for this. The claim logic has to be atomic, and it needs testing against your own WordPress, MemberPress and Stripe setup before it handles real cards. A safe version needs:

• A random token. 256 bits, stored only as a hash, with an absolute expiry time. No page shows or accepts a Stripe customer ID.
• Confidential delivery. Send the link only to the member's verified account email. Whoever holds the link can change the card, so treat it as a bearer credential: serve it over HTTPS end to end, keep it out of analytics, access logs and support tickets, and delete old tokens quickly.
• A button page. Opening the link only shows one button, so an email scanner that loads the page cannot consume the link.
• State in a database table, not transients. WordPress transients are not atomic. A table lets you claim the link for exactly one subscription with a conditional update, and move it through explicit pending, processing and completed states. Use Stripe idempotency keys on the calls that create or change anything.
• Stripe Checkout in setup mode, bound to the right customer. The card is entered on Stripe's page, so card data never touches your site. Create the session for the subscription's existing Stripe customer, as Stripe's guide to updating payment details with Checkout does, pass the subscription ID in setup_intent_data.metadata, and store the session ID against the pending row.
• The subscription's default, set only when everything matches. Before you set default_payment_method on the subscription (the same guide has you do this yourself), check that the session, its setup intent, the customer, the subscription in the metadata and your stored pending row all agree, and that the link has not expired, inside the same conditional claim.
• A webhook as backup, and reconciliation. The checkout.session.completed webhook covers members who close the tab before the redirect. Verify every webhook's signature before acting on it. Keep pending operations in the table so a lost or late event can be found and finished, instead of being acknowledged and dropped.
• Legacy records. Older MemberPress records can hold a cus_ ID where current ones hold sub_ (MemberPress docs). Those need separate handling, and the tool should say so instead of reporting no subscription.
• Real tests. Run it on a staging site in Stripe test mode first: overlapping clicks, an authentication challenge, a closed tab, a lost webhook and the next billing run.

If you want this built and tested on your site, that is MemberPress development work.

Why the 2020 version had to go

The code in the original post had six problems:

• It built an SQL query by pasting the POSTed email into the string. WordPress documents $wpdb->prepare() for this.
• The update page trusted a customer ID posted back from a hidden field, so anyone who could load the page could try any ID.
• It treated MemberPress's subscr_id as a Stripe customer ID. On current versions it starts with sub_, per MemberPress's docs.
• It saved the card as the customer's default source. Stripe has deprecated the Sources API, and a subscription's own default payment method outranks a customer's default source.
• The secret key sat in a theme template.
• The admin screen checked the administrator role and had no nonce. WordPress says a nonce is not authorization.

If you still run the 2020 templates, remove them and rotate any Stripe key that was ever pasted into one.

Frequently asked questions

Can MemberPress members update their card without logging in?

MemberPress's documented update flow needs a login: the “Update” link sits on the Account page. Stripe's hosted-page emails and portal login link need no WordPress login, and a custom expiring link can send a member straight to Stripe Checkout.

Will MemberPress show the new card if the member changes it in Stripe?

We could not confirm it. MemberPress's changelog lists “Auto-updated card details on Stripe Subscriptions”, but its documentation does not say how that works. Stripe charges the card, and MemberPress's docs tie a missing payment in MemberPress to the webhook. Test with one subscription and look at what MemberPress displays afterward.

Does the new card retry a failed payment right away?

It depends on the route. Stripe's hosted page lets the customer pay outstanding invoices when they update. A custom link that only saves the card leaves retries to your Stripe retry schedule, which our failed payments guide explains.

What about members who pay with PayPal?

They update the payment method in PayPal. MemberPress's docs also say you cannot switch a subscription between Stripe and PayPal without canceling it and signing up again.

Next step

If you want someone to look at how your payments, webhooks and member access fit together, a technical audit starts from $1,000.

Reviewed by Vic Dorfman, founder of MemberFix. Last updated: October 2026.