Credits and billing
If something fails, was it still charged?
The question that follows the first bounced message, and the rule that answers it for every case.
You send a request, the address was wrong and the message bounces. The question asks itself: if it never arrived, why does the usage show? The answer is consistent, even if it does not look that way the first time.
The rule, and how it applies
| What happened | Was the action performed | How it ends up |
|---|---|---|
| The message went out and bounced | Yes: it was prepared and sent | Recorded as done, and the detail shows it |
| The recipient never opened it | Yes | Same: what was done was sending it |
| You cancelled before sending | No | There was no action |
| Retrying after fixing the address | Yes, it is another action | It counts as the send it is |
| Viewing or downloading what already exists | Not an action of this kind | It does not add up |
Important
The logic behind all this is not the outcome, it is the work done: **what is recorded is what the platform does for you towards the outside, not what the recipient decides to do**. Whether they open it, reply or bin it is not in your hands or anyone's here. If usage depended on the other side answering, half of what you do could not be measured — and the practical consequence is the opposite of what it seems: **fixing before sending is worth more than retrying afterwards**.
How repeat spend is avoided
- 1
Check the address before the first send
Especially for new contacts or ones imported from another system.
- 2
On a large batch, test with two first
If the template has an error, it shows there and not four hundred times.
- 3
And fix the contact card, not just the send
Otherwise the next person to write hits the same thing.
Watch out
A detail worth knowing before retrying in the heat of the moment: **what has gone out is not undone by repeating it**. A sent message is sent, and resending does not replace it: there are two, and the recipient sees both. If the aim was to correct something, cancel the earlier one where possible and explain it in the new one, rather than resending three times hoping the good one sticks.
Where it is actually checked
Worth knowing
If one send appears several times and you do not recognise the retries, look for an automatic rule behind it: what runs on its own leaves its trace too, and it is the commonest explanation.
›What if the failure was the platform's?
That is a different matter: show support the line and it gets reviewed.
›Does cancelling before sending cost anything?
No: what never went out is not an outward action.
›Does a batch of four hundred count as four hundred?
No: a bulk send counts as the single action it is.
A real case
The situation
A company resends a request four times to a mistyped address.
What you do
- Fixes the contact card before the next send and tests the batch with two
What you get
It lands on the first attempt and the same spend stops repeating over a one-character error.
The situation
An action fails and nobody knows whether it consumed.
What you do
- Checks that activity's breakdown
What you get
The doubt is settled by the record.
The situation
It is repeated after a failure just in case.
What you do
- Checks the status before repeating
What you get
Nothing is consumed twice over one failure.
The situation
A process is cut off halfway.
What you do
- Checks what actually ran
What you get
It resumes from where it was.
The situation
Consumption is disputed over a failed action.
What you do
- Provides that activity's breakdown
What you get
The dispute is resolved precisely.
The situation
An error repeats and consumes each time.
What you do
- Reviews the cause before retrying
What you get
The next attempt makes sense.
This article answers
- the email bounced and I was charged
- are credits used if a send fails
- does retrying consume again
- charged even if they never got it