Notification Re-Attempts

Quick summary

When a notification delivery fails, CommBank Connected Payments retries up to maxAttempt times using a Fibonacci backoff schedule. If all attempts fail and an email is configured, a final fallback email is sent.

Code Sample Disclaimer

Code samples within this document are provided for reference purposes only and are not intended for production use.

---

When a retry is triggered

A retry is triggered whenever the delivery attempt does not receive an HTTP 200 OK response — this includes connection failures, timeouts, and any non-200 status code. A 200 response stops all further retries.

---

Retry delay schedule

Delays between attempts follow a Fibonacci sequence, capped at 15 minutes:

Attempt	Delay from previous	Approx. total time elapsed
1	1 min	1 min
2	1 min	2 min
3	2 min	4 min
4	3 min	7 min
5	5 min	12 min
6	8 min	20 min
7	13 min	33 min
8+	15 min (cap)	+15 min per attempt

Reference points

Attempts	Total time elapsed
10	~78 minutes
15	~153 minutes (~2.5 hours)
20	~228 minutes (~3.8 hours)
30	~378 minutes (~6.3 hours)

Timing variability

Due to asynchronous processing, actual delays may vary by up to 5 minutes during peak load. If a previous attempt timed out, the next retry delay is counted from the point the timeout occurred — not from when the original attempt was sent.

---

Email fallback

If all maxAttempt attempts fail and the notification rule has an emails array configured, CommBank Connected Payments sends a final notification via email to every address in the list. This is a last-resort fallback — always configure at least one email address on rules where delivery is critical.

{
  "maxAttempt": "15",
  "emails": ["[email protected]", "[email protected]"]
}

---

Recommended maxAttempt values

Use case	Recommended value	Retry window
Critical transactions (e.g. payments)	20–30	~4–6 hours
Standard notifications	10–15	~1–2.5 hours
Non-critical events	5–10	~12–78 minutes
Real-time only (rely on email fallback)	1–3	Minutes

---

Implementing your endpoint

Return 200 Immediately

Return 200 immediately

Respond with 200 OK as soon as the notification is received — before any heavy processing. This prevents unnecessary retries caused by slow processing times pushing responses past the timeout.

app.post("/notifications", async (req, res) => {
  // Acknowledge receipt immediately
  res.status(200).json({ success: true });

  // Process asynchronously after responding
  await processNotification(req.body);
});

Best practice

Always respond with 200 first, then process the notification asynchronously. This ensures CommBank Connected Payments receives acknowledgment quickly and doesn't trigger unnecessary retries.

Handle Duplicates

Handle duplicate deliveries

Because retries can overlap with delayed successful deliveries, the same notification may arrive more than once. Make your handler idempotent by checking whether the transaction reference has already been processed.

app.post("/notifications", async (req, res) => {
  res.status(200).json({ success: true });

  const { txnReference } = req.body;
  const alreadyProcessed = await db.notifications.exists({ txnReference });

  if (!alreadyProcessed) {
    await processNotification(req.body);
    await db.notifications.insert({ txnReference, receivedAt: new Date() });
  }
});

Idempotency

Store processed transaction references in your database to prevent duplicate processing. Use the txnReference field as a unique identifier.

---

Common issues

For notification delivery troubleshooting, see the Troubleshooting Guide in the FAQ & Support section.

---