How to tell customers about a failed payment in Crisp
How to use Crisp to tell customers about a failed payment: the Stripe sidebar, profile events, automated campaigns by chat or email, and handling replies.
By Florian
When a renewal fails, the customer usually does not know yet. If they talk to you through Crisp, the chatbox in your app is one more place to tell them, often a better one than an email that lands next to newsletters. This guide shows how to get payment failures into Crisp, how to message the customer with Crisp’s automated campaigns, and how to handle what they reply.
It sticks to Crisp’s own documentation: how to connect Stripe with Crisp, how to push Crisp profile events, how to use automated campaigns, getting started with segments, how to push custom data, the $crisp methods for the Web Chat SDK and the REST API reference (all accessed November 2026).
Crisp does not retry payments
Crisp is a messaging tool. It does not charge cards, retry failed payments or update payment methods. Retries and the card update page stay in your billing system (Stripe, Chargebee and so on). What Crisp adds is a channel: a message in the chatbox or an email from your support address, and a place where the customer’s answer arrives.
So the setup has two halves: get the failure into Crisp, then decide what Crisp sends.
Seeing billing in Crisp: the Stripe plugin
If you bill with Stripe, Crisp has a Stripe integration: install it from Plugins › Stripe and authorize your Stripe account. It shows billing details and history in the conversation sidebar for conversations linked to a Stripe customer. Crisp’s Stripe page describes it as read-only for agents; to change a subscription or payment, you open the customer in Stripe.
This helps the agent answering “why was I charged?” or “my card failed”. It does not, by itself, send anything to the customer. For that you need an event.
Getting the failure into Crisp as an event
Crisp profiles can receive events, and automated campaigns can be triggered by them (pushing profile events). There are two ways to push one.
From the chatbox (front end)
The Web Chat SDK pushes an event on the current session with $crisp.push(["set", "session:event", ...]), giving the event name, optional data and a color ($crisp methods). Your app can push a payment:failed event when the signed-in user loads a page and their account is past due.
From your server (REST API)
The REST API has an Add A People Event route, POST /v1/website/{website_id}/people/events/{people_id}, which takes a text name, optional data and a color, with the website:people:events scope (REST API reference). This fits better with billing webhooks: when your billing system reports a failure, your server pushes the event to the customer’s Crisp profile.
Crisp’s campaign article describes the trigger event being pushed through the chatbox SDK. If you push from the server instead, test that it triggers your campaign before relying on it.
Events vs data vs segments
Crisp notes that it keeps only the most recent events for a contact, and recommends custom data for stable information (pushing events). A clean split:
| Crisp feature | Use it for |
|---|---|
Event payment:failed |
Triggering the campaign, once per failure |
Custom data (billing_status: past_due, update_url) |
What an agent sees on the profile while it is true |
Segment past-due |
Filtering the inbox and contacts list |
Custom data is updated with Update People Data (merges keys) and segments with Update People Profile (custom data, segments). Remove both when the payment succeeds, or your team will chase customers who have already paid.
Sending the message: automated campaigns
Crisp’s automated campaigns send a chat message or an email when a matching event arrives. From Crisp’s docs:
- You set the trigger event name in the campaign’s automation flow, and can add filters and a delay in minutes.
- Event data can be used in the message as template variables, so the card update link can come from the event’s data.
- You can prevent the same campaign from reaching the same user more than once.
- An email needs an email address on the session; Crisp can hold events until the email is known.
- Email campaigns need a verified sending setup, such as a custom email domain or custom SMTP.
- Automated campaigns are available on the Essentials and Plus plans.
Chat or email?
| Channel | Strength | Weakness |
|---|---|---|
| Chat message in the chatbox | Seen in context, while the customer is using your product | Only reaches people who come back to the app |
| Reaches everyone, including those who stopped logging in | Competes with everything else in the inbox |
Use both, with different jobs: the email goes out on the failure, the chat message reaches the customer next time they are in the app. Keep your billing system’s own failed payment emails in mind so the customer does not get three versions of the same news.
Writing the message
A failed payment message in a chatbox should be short enough to read in one glance:
- Say what happened, without blame. “Your last payment for the Pro plan didn’t go through.”
- Give the consequence and the date. “Your account stays active until 18 November.”
- One link. The card update page from your billing system, passed in the event data.
- An open door. “Reply here if something is wrong; a person will answer.”
Avoid the decline reason in the message. Some reasons, such as a card reported lost or stolen, should never be shown to the customer, and “your bank declined it” is enough for the others.
Handling the replies
The advantage of Crisp over a no-reply email is that answers come back to your inbox. Prepare for the common ones:
- “I updated my card”: check your billing system, and confirm only once the payment succeeds.
- “Why was I charged?”: the Stripe sidebar shows the history; answer with the date and plan.
- “I wanted to cancel”: cancel as asked, quickly and without hiding the option. Offering an alternative is fine; making the customer argue is not.
- “My company pays by invoice now”: route to whoever handles billing changes.
Keep track of these conversations so you can count them later, and clear the past-due segment once the account is settled.
A checklist
- Your billing system’s retries and failure emails are configured.
- Payment failures push a Crisp event, from the app or from your server.
-
billing_statusdata and apast-duesegment are set on failure and removed on success. - An automated campaign sends one chat message and, if needed, one email per failure.
- The message has one link, from the event data, and no decline reason.
- Your team knows how to answer the common replies.
Doing this with NoChurn
NoChurn handles the billing side that Crisp does not: smart retries timed to the decline reason and to likely paydays (on Stripe), AI-written recovery emails that you review, and a hosted card update page you can link to from a Crisp message. Its Crisp connector is read-only, so it does not send Crisp messages for you; your campaigns stay in Crisp. It reads conversations and ratings, matched to customers by email (doubtful matches are suggested, never merged automatically), and uses them in the churn score and as evidence in disputes. See NoChurn + Crisp.