Change Log
API Idempotency Key Bug Fix
Applies to: All APIs
What's Changed: We've fixed a bug that previously caused a 500 error when an idempotency key was reused after its validity period.
Previous Behavior: If a merchant sent a POST request with idempotency-key "x" and then reused the same key "x" in an API request post the idempotency key validity period (30 days), the request would result in a 500 error.
New Correct Behavior: When a merchant sends a request with API idempotency-key "x" and then resends a POST request to the same API with idempotency-key "x" again post the idempotency key validity period (30 days), a new resource will be created.
Enhanced Error Handling for Cancelled Mandates
Applies to: PayTo Mandate Creation Flow
What's Changed: Banked has improved how mandate cancellations are handled and reported in the API. This change introduces more accurate and contextual code, error_code, error_message, and network_code values for mandate cancellations triggered in different scenarios.
Previous Behaviour: For all mandate cancellations, Banked previously returned the following static state reason:
{
"network_error_code": "MD17",
"code": "PAYEE_ACTION",
"error_code": "PAYEE_ACTION_MANDATE_DEACTIVATED",
"error_message": "Payee Has Suspended / Cancelled the Mandate"
}
The network_code field was pre-populated with a presumed value (e.g., MD17) which did not always match the eventual code received from the NPP network.
New Behaviour: Banked now provides specific error metadata based on the cancellation scenario. The network_code will no longer be presumed, it will remain null until the code is received from the NPP network. Please see the following scenarios:
Scenario 1 - Upon Checkout session timeout (10 minutes)
The following state and state_reason will be returned:
{
"state": "declined",
"state_reason": {
"code": "TIMEOUT_AUTO_CANCELLED",
"message": "The mandate was automatically cancelled after the authorisation timeout was reached.",
"network_code": null
}
}
When received from the NPP network the network_code will contain "NPP_MD17" value.
Scenario 2 - When Payer cancels via Banked UX
The following state and state_reason will be returned:
{
"state": "declined",
"state_reason": {
"code": "PAYER_ACTION_MANDATE_CANCELLED",
"message": "The mandate was cancelled by the payer via the Banked UX.",
"network_code": null
}
}
When received from the NPP network the network_code will contain "NPP_MD17" value.
Scenario 3 - When the merchant cancels a mandate attempt
The following state and state_reason will be returned:
{
"state": "cancelled", // if mandate was active
"state_reason": {
"code": "PAYEE_ACTION_MANDATE_CANCELLED",
"message": "The merchant cancelled the mandate before completion.",
"network_code": "NPP_MD17"
}
}
Upon cancellation of an active mandate, the network_code will display "NPP_MD17" after being received from the NPP network.
Why This Matters:
- Improves transparency for merchants and consumers
- Prevents confusion from mismatched or presumed network codes
- Allows more accurate error reporting and debugging in client systems
POLi Adapter
Merchants having an existing POLi integration can enable Pay by Bank without any re-integration or code changes required. Please reach out to Banked support@banked.com if you would like to discuss this option with us.
Why This Matters: This means a seamless transition to Pay by Bank for merchants already using POLi, significantly reducing the effort and resources typically associated with adopting new payment methods.
API request signatures linked to auth keys
Applies to: All APIs
What's Changed: A new feature now allows API request signature public keys to be linked to both OAuth Client Keys and Basic Auth Keys. This means we can now have different API request signature public keys for test and live business applications.
Previous Behavior: API request public keys could only be linked at the business (merchant) level.
Current Behavior: API request signature public keys can now be independently linked to both OAuth Client Keys and Basic Auth Keys, enabling distinct keys for test and live environments.
Why This Matters:
- Use more secure keys in production to reduce compromise risk
- Developers use separate, less sensitive keys for testing without impacting live systems
- Merchants gain more control over API security across application stages