Behavly

Follow up a failed payment the moment it fails.

Your backend sends Behavly the event, and a Trigger Campaign emails the person at once, with the plan and the amount in the email.

One event, one person, at once.

Failed-payment follow-up in Behavly is a Trigger Campaign. Your backend sends a payment_failed event with the person’s email and its details, like the plan and the amount, and the campaign takes them in the moment it arrives. Urgent emails never wait for the guardrails, and the event’s details can fill the email.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

01

What does my backend send?

One request to send_event with the event’s key, like payment_failed, the person’s email, and its details as JSON, using a key with Send events only access.
02

What if a payment fails again next month?

Set If it happens again to a new case each time: it suits problems that come back, like a failed payment. By default each person goes through once.
03

Can a retry from my server send two emails?

No. Send an idempotency_key when you retry: the same key twice is one event, counted once.

Meet the Behavly Agent.

It reads what each user does in your product and writes their follow-ups. Free to start, no credit card.