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

RegionSchemeCard typeProduct
AllAllAllProcessing: 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

RegionSchemeCard typeProduct
AllMadaTokenized 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_id field in Create Card V2 to set the PCID during card creation.
    • This eliminates the need for a separate call to the Update Token Product Configuration endpoint.

Mada Tokenization Implementation:

  • Clients to utilize the product_configuration_id field in Create Card V2 to set the cardArtRefID during card creation.
  • Important note: The feature to return cardArtRefID during the checkEligibility call 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

RegionSchemeCard typeProduct
AllAllCards 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

RegionSchemeCard typeProduct
AllAllNAPayControl: 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

RegionSchemeCard typeProduct
AllAllNAProcessing: 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

RegionSchemeCard typeProduct
AllMastercardNAChargebacks

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_enrolled
  • 3ds_enrollment_failure_reason

Applicability

RegionSchemeCard typeProduct
NANANAAPI: 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_enrolled
  • 3ds_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

RegionSchemeCard typeProduct
AllNANAPayControl

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

RegionSchemeCard typeProduct
AllNACards enrolled in BL STIPProcessing: 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.