Release notes: Banking.Live 2.22
CLR-661: Addition of unique identifier in FAST HTTP Header in clearing messages
FAST requests go through multiple network devices and applications, such as reverse proxies and load balancers, the addition of a unique identifier will ease the troubleshooting of a particular FAST request.
This unique identifier is an optional product feature and aligns with the previously released AUTH-992 in BL2.21 for FAST Authorizations
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | All | Processing: Clearing: FAST |
Enablement
If you wish to enable the FAST Header unique identifier, please contact your Client Executive.
This is an optional product feature and is controlled by a product flag.
Note: this product flag is disabled by default.
Technical info
Paymentology alerts clients when FAST messages timeout. In the event the request fails to reach the application, troubleshooting of the transaction is simplified with the use of this unique identifier as it allows clients to track the transaction with ease and efficiency.
Format:
- The header will follow the standard UUID format (e.g., 123e4567-e89b-12d3-a456-426614174000).
- The header will be unique for every settlement request and will not be reused, ensuring accurate tracking for each individual transaction.
A sample of the HTTP request header “X-REQUEST-ID” below:
**X-REQUEST-ID: 3b1d0580-da62-491f-be00-7bb132df886e**
PECA-645: Introduction of a new optional field in Create Card V2 for tokenization card art configuration
This is a non-breaking change to the Create Card V2 endpoint (v2_pws_create_card).
We are adding a new optional field for clients using MeaWallet and Mada tokenization. This field allows setting the Product Configuration ID (PCID) or Card Art Reference ID (cardArtRefID) during card creation.
This update of a new optional field in Create Card V2 is to enhance support for clients with more than one card art per product, simplifying the process and providing greater flexibility in tokenisation configurations.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | Mada | Tokenized cards using Paymentology provided tokenization services (MeaWallet). | API: Tokenization |
Enablement
For Mada and MeaWallet tokenization clients, you can follow the technical info provided below.
This new field is optional. If you have any questions, please reach out to your Client Executive.
Technical info
If you have more than one Card Art or PCID implementation for tokenization and wish to set them during card creation:
MeaWallet Tokenization Implementation:
- Previous Implementation:
- Clients created a card via the Create Card endpoint and then updated the PCID separately via the Update Token Product Configuration endpoint.
- New Implementation:
- Clients can now directly utilize the
product_configuration_idfield in Create Card V2 to set thePCIDduring card creation. - This eliminates the need for a separate call to the Update Token Product Configuration endpoint.
- Clients can now directly utilize the
Mada Tokenization Implementation:
- Clients to utilize the
product_configuration_idfield in Create Card V2 to set thecardArtRefIDduring card creation. - Important note: The feature to return
cardArtRefIDduring thecheckEligibilitycall to Mada is still under development. The Paymentology team will provide updates on its availability.
AUTH-1054: FAST Lite X FAST V3 concatenation
We have introduced a feature flag to concatenate FAST V3 in FAST Lite to provide extensive data for clients to utilize. The FAST V3 data will assist clients in making decisions, especially helping to identify transactions that may be related to fraud.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | Cards using FAST Lite. | Processing: FAST Lite (Authorizations) |
Enablement
This is an optional product feature and is controlled by a product flag.
If you wish to enable the FAST Lite X FAST V3 concatenation product flag, please contact your Client Executive.
Note: this product flag is disabled by default and ONLY applicable to clients on FAST Lite.
Technical info
Testing is required in UAT by FAST Lite clients who wish to have this enabled. You will need to contact your Client Executive to enable this in UAT. Once testing has been signed off, it can be enabled in your production environment.
PECP-426: Refactor Login page to allow for automatic SSO-support detection
To allow for a user-friendly approach for users to login with SSO, the login page was refactored to make the user enter their email address first, and then their password on a following page.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | PayControl: Login |
Enablement
Clients interested in enabling SSO login for their organisation can reach out to their Client Executive to begin testing.
Note: We can only support clients using Azure Active Directory as their identity provider.
Technical info
For clients with SSO login enabled:
This will facilitate a smoother login experience as they will only enter their email address, and PayControl will identify if the user’s email domain is configured for SSO or not, and if the user is authenticated or not.
For clients without SSO enabled:
The user will notice the login page now requires the email to be entered first and must then click next to enter the password and 2FA. If the user has saved their credentials, then the impact is minimal as the email and password are entered automatically.
AUTH-845 & AUTH-1035: Enable_time_constraints_for_TID search feature flag
The addition of the enable_time_constraints_for_TID feature flag optimizes authorization TID (Transaction Identifier) searches within advisements, optimizing database efficiency.
Previously, advisements from Visa and Mastercard triggered TID searches across the entire database, often leading to high CPU utilization, timeouts, and service disruptions.
With this release, TID searches can be restricted by transaction type (e.g., refund, pre-auth, decline) with specified time ranges, ensuring faster and more reliable responses to advisement searches. By reducing database load and improving performance, it minimizes the risk of transaction interruptions and delays, benefiting end users and cardholders.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Processing: Authorizations |
Enablement
If you wish to have this feature flag enabled, please contact your Client Executive or raise a ticket via our Customer Support Platform.
Technical info
Feature flag enabled:
When this feature flag is enabled the following search history limits are applied:
- Pre-Auth Incremental/Completion Advice: Limited to 3 months.
- Refund Advice: Limited to 6 months.
- Decline Advice: Limited to 7 days.
- All Other Advices: Limited to 3 months.
Feature flag disabled:
(default)
If disabled, the search history limits logic reverts to the previous behaviour e.g. the search history limits logic currently used (all history is searched).
CBK-169: TQR4 file processing optimization - improved transaction handling
This release optimizes the TQR4 file processing by enhancing the matching function and implementing a permanent batch processing model. The changes address performance bottlenecks and transaction delays, ensuring seamless handling of high-volume files for clients. Additionally, the re-enabled TQR4 process will now operate efficiently without causing timeouts or service disruptions.
Clients benefit from improved performance, reduced operational risks, and greater scalability, which support their business continuity and customer satisfaction.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | Mastercard | NA | Chargebacks |
Enablement
No enablement required.
These are updates that have been implemented on Banking.Live's backend. Clients using the TQR4 process are automatically enrolled in this optimization.
If you have any questions or support requirements, please direct these to your Client Executive.
Technical info
Impact on Users:
- Functionality: Clients will experience reduced processing times and consistent performance, even with large file volumes.
- User Interface: No changes to user interfaces are expected.
- Workflow/Processes: Affected clients will see the reactivation of TQR4 file processing with improved efficiency.
- Regions/Schemes: The update is system-wide and affects all regions using the TQR4 process.
PECA-592: Renew Card V2 documentation missing 3DS fields
We have updated the specification documentation for the Card Renew/Replace V2 API.
The documentation will now include the already existing API fields:
is_3ds_enrolled3ds_enrollment_failure_reason
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| NA | NA | NA | API: Documentation |
Enablement
No enablement required.
This is strictly a documentation update and does not have any impact to the API itself.
Technical info
The documentation found on PayControl and the Developer Portal for Card Renew/Replace V2 will now reflect the existing API fields:
is_3ds_enrolled3ds_enrollment_failure_reason
PECP-403: Addition of new filter to search by DE37 (RRN) and DE38 (Auth Code)
This update allows clients to search/filter by DE37 (RRN: Retrieval Reference Number) and DE38 (Authorization Identification response) on the Transactions tab in PayControl.
These additional filters primarily benefit dispute teams as they can be used in chargebacks and claims.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | NA | NA | PayControl |
Enablement
No enablement required.
Technical info
This is specific to the Transactions tab in PayControl.
These filters can be found under the Advanced section dropdown list, and once selected, the search field (to the right) will allow the user to input.
CLR-609: BL STIP - Changes to the maximum record limit for balance listing batch files
This release increases the maximum record limit for balance listing batch files. This change sees the maximum limit change from 10,000 to 1,000,000 records.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | NA | Cards enrolled in BL STIP | Processing: BL STIP |
Enablement
No enablement required.
For clients enrolled in BL STIP, you will be able to send balance listing batch files with a maximum record count of 1,000,000 once BL2.22 is released into your Production Environment.
Technical info
You can refer to the BL STIP documentation here here and the balance listing batch files documentation here for further information.
