Notifications — Getting Started

Quick summary

The Connected Payments Notification service sends server-to-server postbacks (webhooks) to your endpoint whenever a transaction event occurs. Use them as the authoritative source for payment outcomes — not client-side redirects or PostMessages.

---

How it works

You configure one or more notification rules in the Connected Payments dashboard, each pointing to an endpoint URL. Rules can be broad (all transactions) or conditional (specific response codes, amounts, merchant references, etc.). When a matching transaction occurs, Connected Payments POSTs the transaction data to that URL as a JSON body.

---

Common rule examples

Use case	Description
All transactions	Send every transaction to your backend for logging and reconciliation
Declined only	Notify only when a transaction is declined (e.g. response code ≠ 00)
High value alerts	Alert on transactions above a certain dollar amount
Route by reference	Route notifications to different endpoints based on merchant reference prefix

Important

Your endpoint must return an HTTP 200 OK to acknowledge receipt. Any other response — or a timeout — is treated as a failure and the notification will be retried. See Notification Re-Attempts for the retry schedule.

Always use notifications as authoritative source

Always use notifications as the authoritative source for payment outcomes. Client-side responses (redirects, PostMessages) can be blocked or manipulated by the browser and should only be used for UI feedback.

---

Authentication

All API requests to create or manage notification rules use userName and password in the JSON body. These are the same credentials used across other Connected Payments APIs.

{
  "userName": "your-username",
  "password": "your-password"
}

Authentication rules

Rule	Description
Content-Type	Include Content-Type: application/json on every request
HTTPS only	Use HTTPS only — HTTP requests are rejected
Case sensitivity	Usernames are not case-sensitive; passwords are
Security	Never pass credentials as URL parameters or in logs

Credential sets

You receive two credential sets at account setup: one for sandbox (username prefixed with TEST) and one for production. Use sandbox credentials when developing and testing — no real transactions or notifications will be sent to live systems.

For alternate authentication methods: Authentication Methods

---

Validating incoming notifications

Because your notification endpoint is publicly accessible over HTTPS, it is your responsibility to verify that incoming requests genuinely originate from CommBank Connected Payments and have not been spoofed. Use one or both of the following methods — using both together provides the strongest security.

IP Whitelisting

Method 1: IP whitelisting

CommBank Connected Payments sends notifications from static IP addresses per environment. Resolve these using an NS lookup and add them to your firewall allowlist:

Environment	Domain
Sandbox	simulation-notifications.connectedpayments.commbank.com.au
Production	notifications.connectedpayments.commbank.com.au

Use domain names

Use the domain names in your allowlist rather than hardcoded IPs — IP addresses may change with advance notice, but the domains will always resolve to the current correct addresses.

# Resolve current IP addresses for your firewall rules
nslookup simulation-notifications.connectedpayments.commbank.com.au   # Sandbox
nslookup notifications.connectedpayments.commbank.com.au              # Production

Configure your firewall or security group to allow inbound HTTPS traffic from these resolved addresses on port 443.

Custom Headers

Method 2: Custom authentication headers

When creating a notification rule, pass a headers object containing any key-value pairs you choose. CommBank Connected Payments will include these headers on every notification request sent to your endpoint. Your server checks for the expected header and value before processing the payload — effectively treating it as a shared secret.

This works similarly to a webhook secret token used by services like GitHub or Stripe.

Notification rule payload (example):

{
  "userName": "ABC",
  "password": "passwordABC",
  "url": "https://your-endpoint.com/notifications",
  "headers": {
    "X-Notification-Secret": "your-secret-token"
  }
}

Validation on your server:

Node.js

app.post("/notifications", (req, res) => {
  const secret = req.headers["x-notification-secret"];

  if (secret !== process.env.NOTIFICATION_SECRET) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  // Process notification payload
  console.log(req.body);

  res.status(200).json({ success: true });
});

Python

@app.route('/notifications', methods=['POST'])
def handle_notification():
    secret = request.headers.get('X-Notification-Secret')

    if secret != os.environ['NOTIFICATION_SECRET']:
        return jsonify({'error': 'Unauthorized'}), 401

    # Process notification payload
    print(request.json)

    return jsonify({'success': True}), 200

Store secrets securely

Store your secret header values in environment variables — never hardcode them in your application.