Zum Inhalt springen
NeuSo funktioniert es
Fehlerbehebung

Credit top-ups are never lost

Credit purchases now record reliably even when a payment notification arrives late or twice, so a completed top-up always appears in your balance.

Credit purchases now land reliably. A payment that went through always appears in your balance, even if the notification from the payment provider arrives late, arrives twice, or arrives out of order.

What changed

When you buy credits, the payment provider takes the money and then tells us it happened. That notification is a separate message over the internet, and separate messages can be late, duplicated, or delivered in the wrong order.

The old handling assumed the notification would arrive once, promptly, and in order. Usually it did. When it did not, the payment succeeded and the credits did not appear, which is the worst possible split: money taken, nothing delivered.

Recovering meant contacting support and having someone add the credits by hand. That worked, and it should never have been necessary.

The handling now expects the messy cases. A duplicate notification is recognised and does not add credits twice. A late one is processed whenever it arrives. An out of order one is placed correctly rather than overwriting something newer.

Why it matters

A payment that takes money without delivering is the single worst kind of bug a product can have. It is not a feature not working. It is money leaving an account for nothing.

The practical harm compounds. Credits are what run your campaigns, so a failed top up stops the work you bought them to do. If it happens overnight, campaigns sit idle until someone notices in the morning.

And it damages trust in a way that is disproportionate to how often it happened. A person who has once had a payment vanish checks their balance after every purchase from then on.

How to use it

Nothing changes in how you buy. Purchase credits as before.

Credits appear in your balance as soon as the payment is confirmed, usually within seconds. If a notification is delayed on the provider's side, they appear when it arrives rather than not at all.

Your billing history shows every purchase with its date and amount, so a completed payment is always traceable to the credits it produced.

If a balance still looks wrong

Refresh first. The balance is read when the page loads, so a purchase completed in another tab may not be reflected in the one you are looking at.

Check billing history next. If the purchase is listed there, it went through. If it is not, the payment did not complete and no money was taken, whatever the checkout page appeared to say.

If the purchase is in your history and the credits are not in your balance, contact support with the date and amount. That combination should not happen now, and it is worth investigating rather than working around.

Duplicate notifications

Payment providers deliberately send a notification more than once when they are unsure the first was received. This is correct behaviour on their side and it is our job to handle it.

Each purchase now carries an identifier, and a notification for an identifier already processed is acknowledged and ignored. You are never credited twice for one payment.

This also means a genuinely retried payment, where you actually paid twice, is treated as two purchases, because it carries two identifiers.

Refunds and adjustments

Refunds and manual adjustments go through the same path and are recorded in your billing history the same way.

A refunded purchase removes the credits it added. If those credits have already been spent, the balance goes to zero rather than negative, and the difference is recorded rather than silently absorbed.

Why payment notifications go wrong

The payment happens at the provider. We find out about it because the provider sends us a message, and that message travels the same unreliable internet as everything else.

Providers know this, so they build for it. If they are not certain a message was received, they send it again. If their first attempt fails, they retry on a schedule that can stretch over minutes. Neither behaviour is a fault, and both produce exactly the situations that used to break things: the same notification twice, or a notification arriving well after the payment.

Handling that correctly means treating every notification as possibly a repeat and possibly late, and matching it to the purchase it names rather than to whatever happened most recently.

What "at least once" means for you

The practical guarantee is that a completed payment eventually produces credits, and never produces them twice.

Eventually is usually seconds. When a provider is retrying, it can be minutes. What it is no longer is never, which was the old failure and the only one that mattered.

If you buy credits and the balance has not moved after a minute, refreshing is the right first move rather than buying again. Buying again is how people end up paying twice for credits they were always going to receive.

Reading your billing history

Every purchase is listed with its date, amount, and the credits it added, and that list is the record. If a purchase appears there, the money was taken and the credits were granted.

Refunds and adjustments appear in the same list rather than as silent changes to the balance, so a balance that has gone down without spending always has a line explaining it.

What happens if a payment genuinely fails

Nothing is charged and no credits are added. A failed payment is not a partial one, so there is no half state to clean up.

The checkout will say what went wrong where the provider tells us, which is usually a declined card or a failed verification step. Where the provider does not say, the message is vaguer, and the card issuer is the right place to ask rather than us.

Trying again is safe. A failed payment leaves no record that interferes with a later successful one.

Automatic top-ups

Where automatic top-ups are switched on, they use the same path and get the same guarantees. A top-up triggered at two in the morning by a campaign running low lands the same way a manual purchase does.

This is the case where the old bug hurt most, because nobody was watching. An automatic top-up that silently failed left campaigns stalled until somebody checked in the morning, and the whole point of automating it was that nobody should have to.

Availability

Live now on all plans. No action required, and it applies to every credit purchase.

Alle Neuigkeiten

Akquise, die weiterläuft, wenn du offline bist.Leads, E-Mails, Follow-ups und Antworten, erledigt.

Verbinde unbegrenzte Postfächer und lass KI-Agenten Leads finden, jede E-Mail schreiben und nachfassen. Oder sende deine eigenen Vorlagen im manuellen Modus. Ab $29/Monat.

$1 für 3 Tage · Jederzeit kündbar · Kein Vertrag

Mit KI installieren

Dein Coding-Agent richtet die FirstSales CLI und Skills für dich ein.

Prompt für Claude Code

I'm setting up FirstSales (https://firstsales.io), an AI outbound sales platform: campaigns, contacts, a reply inbox, deliverability and lead signals. Help me get my workspace sending real, good emails end to end, from Claude Code.

Read these first so you know how FirstSales works:
- Developer docs and API: https://developer.firstsales.io
- CLI: https://www.npmjs.com/package/@firstsales.io/cli
- Skills for coding agents: https://github.com/firstsalesio/firstsales-skills (read README.md and GUIDE.md)

Setup
1. Install the CLI: npm install -g @firstsales.io/cli
2. Install the FirstSales skills:
   claude plugin marketplace add firstsalesio/firstsales-skills
   claude plugin install firstsales@firstsales
3. Ask me if I already have a FirstSales account. If not, send me to https://app.firstsales.io to sign up.
4. Ask me to create an API key under Settings → API → API Keys, with only the scopes we need.
   Never ask me to paste the key into this chat. Tell me to run this in my own terminal, so the key stays hidden:
   read -rs FS_KEY && firstsales auth login --api-key "$FS_KEY"; unset FS_KEY
5. Run `firstsales whoami` and tell me which workspace and organisation we are connected to.

Then ask me about my business: what I sell, who I sell to (roles, company size, countries), my best customers, and what I use today for outbound (tools, lists, mailboxes). Walk me through:
1. Teaching FirstSales my business: website, offer, proof points and case studies in the knowledge base, so the AI writes like someone who knows the product.
2. Connecting my sending mailboxes and checking my sending domain: SPF, DKIM, DMARC and warm-up. If anything is unhealthy, tell me the exact DNS record to add.
3. Bringing in contacts: import my CSV or CRM export into a clean list, remove duplicates and bad emails, and block domains I must never email (customers, competitors, my own).
4. Building my first campaign: the right list, senders, steps and timing. Write the sequence with me, show me the drafts, and do not launch until I say yes.
5. Setting up Signals if it fits: find people engaging with LinkedIn posts about topics my buyers care about, and turn them into leads.
6. Inviting my team and giving each person the right access.

Once campaigns run, show me how to work the reply inbox from here: which replies need an answer, draft responses in my voice, and move good conversations into deals. If I use Cal.com, connect it so follow-ups can offer my booking link (not the first email).

Throughout, as you learn about my business, proactively suggest and help create:
- Reply templates for the questions and objections my prospects are likely to raise, based on my product, site and codebase if you can see them.
- Campaign ideas and segments worth testing, with the reason for each.

Safety rules:
- Show every change as a dry run (--dry-run) first and wait for my yes. Never send emails, launch campaigns or delete anything without my yes.
- Tell me before anything that spends credits, and how many.

Be opinionated. If the docs give a sensible default, just use it. Don't make me choose between five options.