What to ask customers after a failed payment

Send the update-payment link first

A failed payment is usually a billing problem before it is a product problem. The card expired, the bank declined a charge or the account ran out of funds. The customer wants the service to keep working, and the fastest way to help them is a link that updates the payment method. Anything else in that message is a distraction.

Your billing system owns this email. Most billing tools send dunning messages automatically, and the wording and timing belong to your team. Put the update-payment link first, in the first lines and as the main button. If you add a feedback link, place it lower, after the payment instructions, and label it clearly as optional.

Ask one question only when the card is not the problem

Some failed payments are card problems. Others happen because the customer no longer wants to pay. Those two groups need different messages. A card problem needs a link and a short line of reassurance. A customer who is leaving may need a question, because their reason is information you can use.

Your billing system usually knows the decline code, but you may not want to read it inside the feedback form. A simple rule works well. Send the feedback link only after your normal reminder period has passed without a successful payment. A customer who has just fixed their card should not receive a question about why they were leaving, so check the payment status before the message goes out.

Use the hosted feedback page in the email

The hosted feedback page lives at /f/<product-slug>, and it works without a login or a script on your site. Add ?lang= for the language and ?email= to prefill the address. The page uses the product's accent color, so it looks like part of the product and not an outside form.

The link in a billing email might look like this, with your-product replaced by your product slug and the address filled in by your email template:

https://escutaproduto.com/f/your-product?lang=en&email=customer@example.com

The prefilled address appears in the link, so use it only in messages sent to that customer. Do not paste it into a public page or a shared document. The hosted page is not indexed by search engines, which keeps the link out of public results.

Escuta Produto does not send customer emails. The billing system or your own email tool sends the message, and you control the copy. The hosted page docs describe every parameter.

Write the question as a single line

Keep the feedback question short and open. A line such as "If you are leaving for a reason we could fix, tell us what it was" invites an honest answer without making the customer feel accused. Avoid asking them to rate the product or choose from a list. A customer dealing with a declined card does not want a survey.

Do not ask the customer to explain the payment failure in the feedback box. Card problems belong to the billing link and your support team. Feedback is for the product. If the message says "my bank declined it", reply with the update-payment link and do not file it as product feedback.

Tell card problems from intent to leave

When the feedback arrives, read it with two questions in mind. First, is this a billing problem the customer can fix? Second, is this a product reason they might leave? A message such as "the card keeps failing on your site" is a billing support item. A message such as "I am not using the reports anymore" is a churn signal.

Use the kind to help. Set the type to other for churn reasons and bug only when the message describes a product error, such as a checkout page that fails for every card. The distinction matters because billing bugs and product bugs go to different owners.

Protect the customer from a sales tone

A failed payment is stressful. A message that sounds like a sales pitch, offering a discount or a plan change, feels pushy at that moment. Keep the tone neutral. Say what happened, show the update link, and ask the one question if you need it. Do not offer incentives in the same email. If you have a retention offer, send it separately and only to customers who ask about their options.

Read failed payment feedback as a churn signal

Read the answers once a month, grouped by reason. Customers who wrote about a missing feature or a changed workflow are telling you why the product stopped fitting their work. Count distinct accounts, not messages. The guide to cancellation feedback uses the same method, and the two lists can be read together.

If many customers mention the same failure in the checkout flow, treat that as a bug. A cluster of messages about a broken payment page is a product issue, even when each customer blames their bank.

How to route failed payment feedback in Escuta Produto

Create a product for the app, then add the hosted link to the billing email template after the update-payment button. Use the product's notification webhook if you want the team to see churn-related messages quickly, or read the inbox in the weekly review. The triage routine explains how to separate billing support from product feedback during that review.

Set the product's allowed origins only if you also use the widget on the same product. The hosted page does not depend on them, and the billing email does not run on your site. The notifications docs describe the Slack and Discord messages that new items send.