Retry safely.
Charge once.
A checkout run takes the payment, then fails on the next step. Someone has to decide whether it is safe to press re-run. On Spojit it is: the steps that already completed are skipped, the run finishes the rest, and the customer is charged exactly once.
- Create orderShopify · #4821
- Charge customer · $149.00payment captured
- Sync to NetSuitefailed · gateway timeout
- Create orderskipped · already completed
- Charge customer · $149.00skipped · already charged
- Sync to NetSuitecompleted
The failed order you can safely re-run
The run fails after taking payment
The card is charged, then syncing the order to your ERP times out. The work is half-done, and the money has already moved.
You re-run it
Steps that already completed are skipped rather than repeated, because each one recorded that it finished and what it produced.
It finishes, and bills once
Only the outstanding work runs. The order completes, and the customer sees a single charge instead of a second one to refund.
Safe to retry, by design
Stable identity per write
Every write carries an identity that stays the same across retries, so the second attempt is recognized as the same action rather than a new one.
Native vendor keys where they exist
Where a vendor supports idempotency natively, we use it, so deduplication happens at their end and is authoritative.
Covered where they do not
Where a vendor offers no such support, the platform holds the line itself, so an action whose outcome was never confirmed is not blindly repeated.
Retries stay switched on
Because retrying is safe, transient failures can be retried automatically instead of being left for a human to untangle.
Resume without repeating
When a run resumes after a crash, completed steps are not re-executed, so recovery never doubles a side effect.
Across the write path
The same rule covers payments, notifications and connector writes, rather than being special-cased for one integration.
Where firing twice actually costs you
Payments and refunds
A duplicate charge is a refund, a support ticket, and a customer who trusts you less. A duplicate refund is money gone.
Orders and shipments
Shipping the same order twice costs the goods, the freight, and the recovery effort, and it is rarely caught quickly.
Customer messaging
Sending the same email or SMS twice looks careless at best, and at volume it damages your sender reputation.
Inventory and ledgers
Applying the same movement twice silently corrupts your counts, and the error usually surfaces long after the run.
Exactly-once vs at-least-once
Most automation tools retry. Very few can tell you what the retry did.
Exactly-once gives you
- A retried charge that bills the customer once
- Retries you can leave enabled without fear
- Recovery that never duplicates completed work
At-least-once retries
- A timeout can become two charges
- Retries get switched off, so blips become failures
- Duplicates found later, by a customer or an auditor
Every run, on the same guarantees
Automate the things that move money
Start free and build a workflow you can safely retry, on the steps where it matters most. No card needed.