back
Mar 17, 2026

IIMMPACT API — Breaking Change Notice

Effective Date: 23 March 2026

What's Changing

The Make Payment endpoint (POST /v2/topup) is updating its error response format for the following validation errors to match the standard documented response:
- Invalid amount (e.g. decimal amount for integer-only product)
- Missing account number
- Invalid account number format
- Missing account number for JomPAY

Before (Current)

These validation errors currently return a non-standard format: HTTP 400
{
  "message": "The given data was invalid.",
  "errors": {
  "amount": ["The amount must be an integer."]
  }
}


After (23 March 2026)

These errors will return the standard payment response format: HTTP 400
{
  "data": {
  "statusCode": 58,
  "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-03-23 12:00:00",
  "note": "",
  "voucherlink": ""
  }
}


Action Required


The response structure for these validation errors is changing entirely. If your integration handles HTTP 400 responses from /v2/topup, update your error handling to parse the new data object instead of the message/errors fields. This is the same response structure already used by all other payment errors (insufficient balance, invalid denomination, invalid product, etc.).

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 https://docs.iimmpact.com/reference/topup.html

Questions?
Contact support@iimmpact.com for assistance.

Subscribe