Follow up a failed payment the moment it fails.
One event, one person, at once.
Send it from your server.
Each time a payment fails, your backend sends the event with the person’s email, using a key with Send events only access, so if it ever leaks it cannot read your contacts or change anything.
Urgent, so it never waits.
Urgent emails, like a failed payment, never wait for the guardrails that space out your other campaigns. The plan and the amount go into the email, and when they fix it, the path can end.
Name the moment and its details.
Make a trigger like Payment failed. Its key follows the name, and under Payload you list the details each event carries, or paste an example and apply it.
Try it without code.
Every trigger’s page has Send a test event. It sends the event for the address you enter, exactly as your server would, and the last events show what each one did.
From a declined card to a fixed one.
Make a trigger.
Give it a Name, like Payment failed. The Key follows it (payment_failed): it is what your code sends. Under Payload, list the details each event carries, each with a type and whether it is required.
Send the event from your server.
Create an API key with Send events only access, keep it on your server, and send each event to send_event with the person’s email and its details.
The person enters at once.
Every active Trigger Campaign that starts on it takes the person in the moment it arrives. An event that arrives at night starts the path, and the first email waits for the sending window.
The details go into the email.
Each payload field can go into the emails as a merge tag, like {{event.plan|your plan}}, where the words after the | are what it says when the event carried no value. It works in the subject, plain-text emails and designed ones.
Urgent never waits.
Set the campaign’s Priority. Urgent emails, like a failed payment, never wait for the guardrails; low ones, like newsletters, also wait 3 days after any other campaign’s email.
The rules around every failed payment.
- Priority
- Urgent emails, like a failed payment, never wait for the guardrails. Low ones, like newsletters, also wait 3 days after any other campaign’s email.
- If it happens again
- Once per person by default. A new case each time suits problems that come back, like a failed payment; Again after a break lets someone go round again 7, 30 or 90 days after leaving.
- Safe retries
- Send an idempotency_key when you retry: the same key twice is one event, counted once.
- Send events only
- A key with this access sends events and nothing else, so if it ever leaks it cannot read your contacts or change anything.
- Sending window
- An event that arrives at night starts the path, and the first email waits for the window you set.
- Plans
- Trigger Campaigns work on every plan, Free included, and there is no plan limit on how many are active.
Questions about failed payments.
01What does my backend send?
02What if a payment fails again next month?
03Can a retry from my server send two emails?
More in the Help Center
Start a campaign from a triggerAgent guardrails across campaignsAPI documentation