What's Changing

The Make Payment endpoint (POST /v2/topup) currently returns a non-standard error format for the following validation errors:

• Invalid amount (e.g. decimal amount for integer-only product)

• Missing account number

• Invalid account number format

• Missing account number for JomPAY

All other payment errors (insufficient balance, invalid denomination, invalid product, etc.) already return the standard data response format. We are standardising these remaining validation errors to use the same format.

Before (Current)

These validation errors currently return a non-standard format:

{
  "message": "The given data was invalid.",
  "errors": {
    "amount": ["The amount must be an integer."]
  }
}

After (1 August 2026)

These errors will return the same standard payment response format already used by all other errors:

{
  "data": {
    "statusCode": 44,
    "status": "Failed",
    "account": "60123456789",
    "product": "DB",
    "productName": "Digi Postpaid",
    "amount": 22.23,
    "sn": "",
    "pin": "",
    "expiry": "",
    "cost": 0,
    "balance": 50.54,
    "remarks": "The amount must be an integer.",
    "refid": "your-ref-id",
    "timestamp": "2026-08-01 12:00:00",
    "note": "",
    "voucherlink": ""
  }
}

Early Opt-In with API Header Versioning

You can test the new response format right now by adding the following header to your API requests:

X-API-Version: 2026-04-01

How it works:

• Send the header X-API-Version: 2026-04-01 on your request to receive the new response format immediately

• Omit the header to continue receiving the current format

• On 1 August 2026, the new format becomes the default for all requests regardless of the header

Action Required

We recommend reviewing your integration's error handling for the Make Payment endpoint to ensure it supports the standard data response format. You can use the X-API-Version: 2026-04-01 header to test against the new format before 1 August 2026.

Important: Retry Behavior for HTTP 400

HTTP 400 responses mean no transaction was created. Your refId is not consumed and can be safely reused after correcting the request parameters. This is different from HTTP 200 + Failed, which indicates a final transaction failure requiring a new refId.

For full details, refer to the API documentation at here

Questions?

Contact support@iimmpact.com for assistance.