Release 14/01/2025
Version: v2025.01.14.1
Date: 14th January 2025
What's included?
- Enhancement to Transactions List Export for Direct Debit Reconciliation
- Updates to Accounts Endpoints:
- New GET /accounts Endpoint
- Field Name Standardisation for POST /payments/internal-transfer
- Auto-Retry Functionality Enhanced for Transaction Requests
- Bug fixes:
- Resolved Validation Error for Updating Customer Last Name
- Corrected Typo in Hosted Checkout Error Message
- Removed unsupported characters for Cashflows requests
- Updated Mapping for CashFlows Response to Improve Accuracy
- Incorrect case in /payments/recurring endpoint
- Mandate cancellation issue
Enhancement to Transactions List Export for Direct Debit Reconciliation
To assist merchants in efficiently reconciling their Direct Debit payments, we have introduced a new column, “Charge Date,” in the Transactions List Export. This enhancement addresses the lack of visibility into settlement dates for Direct Debit transactions.
- The “Charge Date” is populated using the actual_collection_date field from the Direct Debit table.
- This field is exclusively populated for transactions with the payment method Direct Debit.
- If no associated record exists in the Direct Debit table, the “Charge Date” will remain blank.
This improvement ensures merchants can more easily determine when Direct Debit payments are settled, streamlining their reconciliation processes.
Updates to Accounts Endpoints
New GET /accounts Endpoint
A new GET /accounts
endpoint has been introduced to streamline account management and improve developer experience. This endpoint allows users to retrieve a paginated list of accounts associated with their organisation, eliminating the need to query individual account IDs.
Key Features:
- Header Parameter: Optionally specify a Company-Id to filter accounts by a specific company. If omitted, accounts for the default Company-Id are returned.
- Pagination Support: Use limit and offset query parameters to retrieve a subset of accounts, with a default of 25 records per page and a maximum of 100.
- Filter Option: Specify fields to include in the response using the filter query parameter, reducing response payload size when needed.
- Enhanced Response Structure: Includes meta information for pagination and a detailed data array with account information.
- Error Handling: Returns appropriate error messages for invalid query parameters or unauthorised Company-Id values.
Check out the documentation here:
Field Name Standardisation for POST /payments/internal-transfer
The POST /payments/internal-transfer endpoint has been updated to align field naming with the rest of the API, ensuring consistency and clarity.
Key Changes:
- Field Renaming:
from_account_id
has been renamed tofrom_mid
.to_account_id
has been renamed toto_mid
.
- Request Payload Update:
{
"transaction": {
"order_id": "1f1f2a61-5b68-4725-a0ce-9560514ec00b",
"amount": 15.02,
"currency": "gbp"
},
"payment": {
"from_mid": "6cf0fed2-fa2c-4145-876f-38091fddcb1d",
"to_mid": "a303519e-3b65-4a1e-b8b9-b480ade983f7",
"reference": "InternalTransfer001"
}
}
Check out the documentation here:
Auto-Retry Functionality Enhanced for Transaction Requests
The auto-retry functionality has been updated to ensure it is only applied to transactions posted at the company level. Previously, the auto-retry was triggered for all transactions, regardless of whether they targeted the company or a specific MID.
Key Changes:
- Auto-retry will now only trigger when the transaction request is posted at the company level (no Mid or
company_mid_id
specified). - Transactions targeting a specific MID (Mid header or
company_mid_id
) will no longer trigger auto-retry, even if the configured retry response code (e.g., 05 - Do Not Honour) is returned.
This enhancement improves control over retry functionality, ensuring it aligns with the intended configuration and reduces unnecessary retries at the MID level.
Bug Fixes
We continue to resolve bugs within the system.
- Resolved Validation Error for Updating Customer Last Name:
The issue causing the PUT request to fail with a 400 Bad Request when updating a customer's last name to "O'Dear" has been resolved, and the request now succeeds with a 200 OK response.
- Corrected Typo in Hosted Checkout Error Message:
The error message displayed for unsupported card numbers in the hosted checkout has been updated from "Carder Number not accepted" to "Card Number not accepted" for improved clarity and accuracy.
- Removed unsupported characters for Cashflows requests:
There was a bug whereby we were sending unsupported characters such as ç which was causing encoding issues with Cashflows. This has now been resolved.
- Updated Mapping for CashFlows Response to Improve Accuracy:
The mapping for a specific CashFlows response has been corrected. Previously, when CashFlows provided the response D|04S0126DADF|000|D005|On our blacklist|||
, it was incorrectly mapped to 401 - Declined:Fraudulent
. This has been updated to map accurately to 252 - Blocked:Card Blacklisted
, ensuring merchants receive the correct response and improving the accuracy of transaction processing.
- Incorrect case in
/payments/recurring
endpoint:
The /v1/payments/recurring
request now correctly formats subscription reason text in snake case, addressing issues with values such as unscheduled_payment
, re_authorisation
, re_submission
, delayed_charges
, and no_show
.
- Mandate cancellation issue:
Addressed a timing issue in the Direct Debit mandate cancellation process to ensure notifications are promptly sent via webhooks, resolving potential delays and improving clarity for merchants regarding mandate status updates.