> For the complete documentation index, see [llms.txt](https://docs.roadmap.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roadmap.so/subscriptions/managing-subscriptions/customizing-the-payment-method-update-email.md).

# Customizing the Payment Method Update email

Edit the subject and body of the Payment Method Update email customers receive when you trigger the ShopPay $1-checkout recapture flow.

When you trigger the Send checkout order link action on a contract (or run the bulk Update payment method action), the customer receives an email with a checkout link to capture their new payment method via the $1-checkout flow.

This article covers how to edit that email's subject and body, what Liquid variables you can use, and how to test changes before they go to real customers.

The email being edited here is the Roadmap-specific email for the ShopPay $1-checkout flow. The Shopify-native option's email is sent by Shopify, not Roadmap, and isn't editable from this template. See Updating a customer's payment method for the full picture of when each email goes out.

#### Where to find the editor

In Roadmap, open Settings → Mail Templates → Payment Method Update.

You'll see two areas:

* Email subject — single-line text input
* Body editor — HTML editor for the email body

Both support Liquid variables for personalization.

#### Default content

The default email subject is "Action Required: Update Your Payment Method for {{ shop.name }}".

The default body explains the situation, includes a prominent Update Payment Method call-to-action button linking to the $1 checkout, and has a "HOW IT WORKS" section explaining that the customer will be charged $1 and refunded automatically once their new payment method is captured.

These defaults work for most stores out of the box. Edit when you want to match your brand voice or add store-specific instructions.

#### Available Liquid variables

| Variable                   | What it inserts                                        |
| -------------------------- | ------------------------------------------------------ |
| `{{ customer.firstName }}` | The customer's first name                              |
| `{{ customer.lastName }}`  | The customer's last name                               |
| `{{ customer.email }}`     | The customer's email address                           |
| `{{ checkoutUrl }}`        | The link to the $1 checkout (the CTA button uses this) |
| `{{ contractId }}`         | The subscription contract ID being recovered           |
| `{{ nextBillingDate }}`    | Formatted next billing date for the contract           |
| `{{ shop.name }}`          | Your store name                                        |
| `{{ shop.url }}`           | Your store URL                                         |
| `{{ shop.domain }}`        | Your store domain                                      |
| `{{ shop.email }}`         | Your store contact email                               |

The `{{ checkoutUrl }}` is the most important variable — it must be present in the body for the customer to actually be able to update. If you remove it accidentally, the email becomes useless. Always include it as a clearly-labeled CTA button or link.

#### What to keep when customizing

A few things customers expect to see explained — keep them in even if you reword:

* Why they're getting the email — their subscription couldn't bill, you need them to update their payment method.
* The $1 charge and auto-refund — without this explanation, you'll get support tickets about an unexpected $1 charge. The default body covers this in a "HOW IT WORKS" section; preserve that messaging.
* A clear CTA — the Update Payment Method button (or whatever you label it) should be visually prominent. Customers skim payment-related emails; the action needs to jump out.
* A way to contact you — include `{{ shop.email }}` or a support link so customers who run into trouble can reach you.

#### Testing changes

There's no in-editor test send — to verify the email looks right, you trigger the recapture flow on a real contract that you control:

1. Set up a test subscription contract in your store using a card you own.
2. From the contract page, Update payment method → Send checkout order link.
3. Receive the email yourself, click through, and confirm the $1 checkout works.
4. Roll back the test by updating the payment method to something benign or canceling the test subscription.

Always test after editing — Liquid variable typos break the personalization without warning.

#### Common scenarios

**"Customers are confused about the $1 charge"**

Strengthen the "HOW IT WORKS" section in the body. Make the auto-refund explicit and put the explanation above the CTA so customers read it before clicking.

**"I want to add my brand colors and logo"**

Edit the body's HTML. Inline CSS is best for email-client compatibility. Keep the structure simple — many email clients strip complex CSS.

**"The link in the email opens a Shopify checkout, not the Roadmap admin"**

That's intentional. The customer is supposed to land on Shopify's checkout to complete the $1 order — that's how the new payment method gets captured. If they're landing somewhere unexpected, check that `{{ checkoutUrl }}` is intact in your body.

**"The customer didn't get the email"**

Confirm the Enable auto Shop Pay update email toggle is on in Subscriptions → Dunning Settings. When this toggle is off, even merchant-triggered Send checkout order link actions complete silently without sending the email — see Failed payment retries (dunning).

#### Related guides

* Updating a customer's payment method
* Failed payment retries (dunning)
* Working with subscriptions in bulk


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.roadmap.so/subscriptions/managing-subscriptions/customizing-the-payment-method-update-email.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.