DEC-304: Introduction of an API endpoint to remove Cardholder Adjustable Values that were set for a card

With the Set rule parameters for a card API, users are able to override limit values at an individual cardholder level. To allow users, the ability to remove those individual values, and have them returned to the default values that were originally set, we are introducing the Remove RFC parameters API.

You can include the new Remove RFC parameters API in your implementations if you wish to offer cardholders the ability to set previously overridden limits back to default.

Applicability

Enablement

You can speak with your Client Executive or raise a ticket via our Customer Support Platform to have this new API endpoint enabled.

Technical info

The Remove RFC parameters API uses the token and ruleID as the arguments.

You can refer to the API specification found here or on PayControl.

DEC-384: Inclusion of a distinct token check in the check merchant activity rule

The merchant activity check rule checks activity across the whole product. However, if this rule is used and a single token meets the criteria set on the rule, the rule will trigger.

To make this rule more functionally purposeful, we have made available a field within the rule that will allow us to set a parameter for a number of distinct tokens based on a percentage.

By introducing this, Rules Engine clients who choose to have this enabled will see less false positives when this rule is triggered.

Applicability

Enablement

Please speak with our Fraud Team for more information on this change and how it can be implemented.

CLR-703: FAST Lite x FAST concatenation (clearing)

We have introduced a feature flag to concatenate FAST (Clearing) in FAST Lite to provide extensive clearing data for clients to utilize. The FAST data will assist clients in making decisions, especially helping to identify transactions that may be related to fraud.

This feature aligns with the previously released AUTH-1054: FAST Lite x FAST concatenation (Authorization) in BL2.22.

Applicability

Enablement

This is an optional product feature and is controlled by a product flag.

If you wish to enable the FAST Lite x FAST 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

The full FAST data will be added under a new JSON tag "fullFastFeed".

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.

AUTH-187: Introduction of Faster Refund Original Credit Transaction (OCT)

Applicable jurisdictions for Faster Refund OCTs: Faster Refund OCTs will apply only for domestic transactions in India, intraregional transactions between European Economic Area (EEA) countries, Gibraltar, and the U.K., or domestic transactions in the EEA, Gibraltar, and the U.K.

Issuers that fall under one of the applicable jurisdictions and are signed up to Visa’s Fast Funds program are obligated to make funds available to the cardholder within 30 minutes of receiving the authorization from the merchant for this load, as opposed to waiting for settlement as would be traditional.

This applies to all 0100 messages received on participating issuers.

In support of Visa Mandate TL 102023 3.12 (Visa will implement changes in V.I.P. to support the use of original credit transactions (OCTs) to process merchandise or service returns in India and in specified countries in the Europe region.), we have implemented support via a Product Flag to handle these types of transactions.

When the “Fast Funds” Product Flag is enabled, and a Faster Refund OCT (0100) is received, Banking.Live will post the credit once the transaction has been approved.

Applicability

Enablement

If you fall under one of the applicable jurisdictions, are enrolled with Visa's Fast Funds program and have a Local Store of Value product with Paymentology (Banking.Live holds the ledger) you can contact your Client Executive or raise a ticket on our Customer Support Platform to have this Product Flag enabled.

Technical info

When this product flag is enabled, and a Faster Refund OCT is received, the credit will be posted to the cardholders account once the transaction is approved.

---

DEC-312: Introduction of the Product Scope to rules

Rules can now be configured at the product level, which means that all cards under that product will be impacted by those rules.

The product scope enables faster rollout of rules. This is an advantage when looking at the speed at which fraud-based rules need to be implemented

Applicability

Technical info

Please speak to our Fraud Team for more information on how the use of rules at the Product level could be beneficial to you.

CLR-662: Ability to disable the FAST transmission of second presentments

As a client, you may have the preference to post second presentments offline by using the Presentments report (instead of in real-time via FAST).

Due to this we have now introduced the option to disable FAST transmission of second presentments for clients.

Applicability

Enablement

If you wish to disable the FAST transmission of second presentments you can speak with your Client Executive or raise a ticket via our Customer Support Platform.

Technical info

If you choose to disable FAST transmission of second presentments you should be making sure you are still posting these presentments based off the data received in the Presentments report. For more information on the Presentments report, please refer to the information found here.

PECR-511: QMR - Align the cards/accounts section logic

An adjustment has been made to align the cards/accounts logic used in our QMR (Quarterly Mastercard Report).

Applicability

Enablement

N.A.

Technical info

The adjusted logic means that account metrics are equal to card metrics. For further information on this report you can refer to the report specifications found here.

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

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

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

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

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

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

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

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

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

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.

AUTH-992: Addition of unique identifier in FAST Active and FAST Passive Header (optional)

FAST requests go through multiple network devices and applications, such as revers proxies and load balancers, the addition of a unique identifier will ease the troubleshooting of a particular FAST request (when/if required).

This unique identifier is an optional product feature.

Applicability

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.

Please find a sample of the HTTP request header “X-REQUEST-ID” below:

**X-REQUEST-ID: 3b1d0580-da62-491f-be00-7bb132df886e**

DEFECT-2239 & DEFECT-1948: PaySecure specification reminder

This is a reminder related to PaySecure API, specifically Set PIN, Set PIN V2, Verify PIN and Verify PIN V2.

Set PIN & Set PIN V2:

• the PIN value provided in these two API's must adhere to the format specified in the PaySecure API documentation.
• the expected length is 16 characters, values shorter than this will fail validation.
• expected value should match the format below:
  • in case PIN it should be PIN block format.
  • 246784FFFFFFFFFF (2 = ISO format, 4 = PIN length, 6784 = Actual PIN, FFFFFFFFFF = Padding)

Verify PIN & Verify PIN V2:

• PAN format is clear text and AES encrypted.
• masked PAN is not accepted.
• if incorrect value, such as masked PAN is used, we will return error "Failed to verify pin due to an invalid PAN"

You are encouraged to review the PaySecure API documentation and ensure compliance with the defined PIN and PAN structure. Please refer to the specific API links provided above.

Applicability

PECA-600: New Tokenization Customer Service API for account holder messaging in Apple Wallet

We have introduced support to integrate with the Mastercard CS API - Account Holder Messaging.

Account Holder Messaging enables Issuers to display customized messages per token within ApplePay Wallet.

This enhancement allows you to send tailored communications directly below the digitized card image in the Apple Wallet, improving engagement with your cardholders.

If your enabling your cardholders to use ApplePay Wallets, you can now leverage this functionality to share relevant updates, notifications, or promotional messages directly with them.

Applicability

Enablement

If you wish to use this API, please refer to the API specification available and contact your Client Executive to have it enabled.

Note: this is specific to clients using tokenization services through Paymentology (MeaWallet).

Technical info

Functionality:

• messages are displayed within Apple Wallet.
• messages can be customized for each token to provide timely and relevant cardholder communication.

API specifications for this new API are available on PayControl and on the API Explorer under Account Holder Messaging.

PECA-587: pws_linked_acc_card_list documentation

This release aligns the API response documentation with the actual API response for the List Accounts Linked To Card API.

Applicability

Enablement

No enablement required.

Technical info

Now when you call the List Accounts Linked To Card API the response will return the cu_id as per the API documentation.

DEFECT-2022: Addition of product setting flag "Consider ASI eCommerce"

We have introduced the product flag "Consider ASI (Account Status Inquiry) eCommerce".

This flag allows products the ability to differentiate between ASI and eCommerce transactions, allowing ASI transactions to not be declined when the "Decline all eCommerce transactions" product flag is enabled.

Applicability

Enablement

No enablement required.

The "Consider ASI eCommerce" product flag is enabled by default - therefore, products with the "Decline all eCommerce transactions" product flag enabled will see no change to their processing logic.

If you are wanting to disable the "Consider ASI eCommerce" product flag, you can speak with your Client Executive or raise a ticket via our Customer Support Platform.

Technical info

You can now choose to allow eCommerce-initiated ASI transactions to be approved when the product flag "Decline all eCommerce transactions" is enabled.

This is done by disabling the newly introduced "Consider ASI eCommerce" product flag (it is enabled by default).

PECA-606: Inclusion of decrypted values (CardInfoData, TokenData & RiskInformation) in MADA Tokenization Notifications

Applicable only to Mada Tokenization clients.

We have updated the tokenization notifications sent to you to include decrypted CardInfoData, TokenData & RiskInformation from the originally encryptedData field.

This change allows you to process risk and fraud monitoring data, ensuring
compliance with SAMA’s (Saudi Arabian Monetary Authority) requirements for Issuers.

• Decrypted risk scores: you now receive decrypted RiskInformation in notifications, extracted from the encryptedData field.
• Compliance with SAMA requirements: this update ensures adherence to mandatory checks for Issuers as required by SAMA.
• Improved risk monitoring: provides you with actionable insights to strengthen their fraud and risk management efforts.
• RedactedPCI related fields: to ensure you remain within PCI scope - PAN, Security Code (CVV), Expiry Date, Token & Token Expiry is redacted.

Applicability

Enablement

This is a configurable feature, please reach out to your Client Executive to enable/disable this feature.

Technical info

Decrypted encryptedData data is now included in notifications across the following:

• Tokenization eligibility request (TER): CardInfoData
• Tokenization authorization request (TAR): CardInfoData & RiskInformation
• Tokenization activation code request: CardInfoData
• Activation methods request (AMR): CardInfoData & RiskInformation (RiskInformation is for VTS (Visa Token Services) only)
• Tokenization notification request (TNR): CardInfoData, TokenData & RiskInformation

If you require tokenization message samples for this, please reach out to your Client Executive and reference PECA-606.

For more details, please refer to the corresponding sections in the Mada documentation (pages 51, 56, 66, 70, 84, 95, 103, and 109).

AUTH-987: Parsing of DE104 for Visa Direct transactions

This release introduces further parsing to DE104 of Visa Direct transactions in FAST authorization messages.

For Visa - Field 104, usage 2 is a variable length data element based on the ISO composite TLV format. The elements of a TLV-formatted field are defined as follows:

• The length subfield is a one or two-byte binary subfield that contains the number of bytes in the field. This number includes the total length of all dataset IDs and dataset lengths, along with the lengths of
  the TLV elements.

Applicability

Enablement

No enablement required.

Technical info

If you are requiring further information on Field 104 and its sub-fields, please refer to Visa's processing documentation related to Visa Direct Transactions.

---

DEC-347: Improve pws_list_rules response time

Applicability

Defect condition

The List Rules API response time was taking longer than it should.

Defect fix

This fix optimizes the List Rules API processing and reduces the response timeframe to be within acceptable timeframes i.e. within 1 second.

DEFECT-2107: pws_virtual_to_physical response error on UAT

Applicability

Defect condition

An internal server error was being returned in some cases when calling the Virtual Card To Physical Card Conversion API on UAT.

Defect fix

This fix resolves the specific issue and introduces the new general API error code response of 987 with description “We are temporarily unable to handle this request. Please try again later". If you receive this error response, you should re-attempt the API call.

You can find the full list of API error response codes here.

DEFECT-2162: pws_rules_list fix

Applicability

Defect condition

It was identified thatthe List Rules API was failing in some intances on UAT.

Defect fix

This fix resolves the issue.

CLR-610: Improve performance of ps_get_iso_v3

Applicability

Improvement

This improvement further optimizes the performance of the internal ps_get_iso_v3 function. The function is used as part of processing clearing and settlement messages received and collating the presentments reports.

PECA-615: (UAT) pws_load_balance V2 API fix

Applicability

Defect condition

An issue was identified where Load Balance V2 was not behaving as it should in UAT. The specific issue was that the Load Balance V2 API was allowing funds to be loaded onto cards when
the cards had "Block load" enabled.

Note: this was specific to UAT.

Defect fix

This fix resolves the issue. This means that when Load Balance V2 is used to load a card with "Block load" enabled, the card will decline the specified load amount.

AUTH-833: VISA MANDATE - Requirements to support Visa Secure Smart Attempts Service for Visa Secure Issuers

Issuers in the below listed regions that either participate or do not participate in Visa Secure will participate in the Visa Secure Smart Attempts service:

• AP (except India)
• Canada
• CEMEA (except Albania, Azerbaijan, Georgia, Kosovo, Moldova, Montenegro, North Macedonia and Ukraine)
• LAC

In the U.S. region non-participating issuers will participate in the Visa Secure Smart Attempts service.

The existing Visa Secure Attempts service responds to authentication request messages on behalf of the issuer when either the issuer does not participate in Visa Secure or the issuer participates but their access control server (ACS) is unavailable. The existing Visa Secure Attempts service provides an electronic commerce indicator (ECI) and Cardholder Authentication Verification Value (CAVV) in the authentication response to show that the merchant attempted to obtain authentication. The Visa Secure Smart Attempts service will return an ECI 05 and a CAVV that uses a new authentication method value and a new 3-D Secure (3DS) indicator value for qualifying attempts transactions.

For further information you can refer to the Visa October 2024 and January 2025 VisaNet Business Enhancements Global Technical Letter and Implementation Guide for further information.

Applicability

Enablement

Visa clients should make sure they can process the value provided below (89).

Technical info

Banking.Live will recognize Visa Secure Smart attempt transactions and skip CAVV validation result (PKS result for CAVV) for these transactions, instead checking CAVV result code in Field 44.13.

New value of 89 in Field 126.9—Usage 3, position 2 will be applicable to the following existing CAVV key indicators in Field 126.9—Usage 3, position 3, CAVV Key Indicator:

• 10 (Visa CAAV attempts/Visa-generated CAVV first key set)
• 11 (Visa CAAV attempts/Visa-generated CAVV second key set)
• 12 (Visa CAAV attempts/Visa-generated CAVV third key set)
• 13 (Visa CAAV attempts/Visa-generated CAVV fourth key set)

FASTimpact: These values will be parsed through to clients in Field 126 of the FAST message, when populated by Visa. Note: Field 126 is already a parsed through field in FAST, therefore there is no format change to FAST.

Reports impact: No impact, this field is not included in any reports.

DEFECT-1735: New decline reason codes and descriptions for SCA related transactions

This release introduces three new decline reason codes and their descriptions for Mastercard issuing clients.

Applicability

Enablement

FAST clients issuing with Mastercard will need to make sure they can process these new decline reason codes and descriptions.

Technical info

These decline reason codes and descriptions will be parsed through in the "Processor_Reason_Code" and "Processor_Descision_Desc" fields of the "SUMMARY" node of the FAST message when applicable:

• 191: SCA Contactless Limits Exceeded (sample FAST message can be found here)
  • Example: When a contactless transaction without a PIN is declined with response code 65 due to the SCA limit being exceeded, it indicates that the cumulative transaction amount or count has surpassed the threshold permitted for PIN-less transactions under Strong Customer Authentication requirements.
• 192: SCA Ecommerce Limits Exceeded
  • Example: When an eCommerce transaction is declined with response code 65 due to the SCA limit being exceeded for low value SCA exemption, it signifies that the transaction amount or cumulative count has surpassed the allowable threshold set for Low value SCA exemptiontransactions without additional authentication under Strong Customer Authentication guidelines.
• 193: Soft Decline Requires SCA (sample FAST message can be found here)
  • Example: When a transaction is declined with response code 65 due to a general SCA requirement, it indicates that additional Strong Customer Authentication is needed, as the transaction does not meet the criteria for exemption or simplified authentication.

You can find the full list of reason codes and their descriptions here.

---

PECR-288: Addition of Network Response and Description in Authorizations report

This release introduces a new version of the Authorizations report (V3.0) which includes the Network Response Code and its corresponding description.

These new columns provide you with vital insight into transaction statuses, offering a clearer distinction between the network's initial decision and Paymentology's final response. These additions help to provide greater transparency in transaction reporting and addressing reconciliation issues.

Applicability

Enablement

To enable the new version (v3.0) of the report you can raise a ticket though our Customer Support Platform or speak with your Client Executive.

The older version of the report (v2.0) will continue to be supported as it is today. There is currently no retirement date for v2.0, so there is no immediate need to upgrade to v3.0 at this stage.

Technical info

The new version (v3.0) of the Authorizations report includes:

1. Additional columns:
   1. network_response_code (Network response)
   2. network_reponse_code_description (Network response description)
2. Renaming of existing columns:
   1. response_code (v2.0) will now be paymentology_response_code (v3.0)
   2. response_code_description (v2.0) will now be paymentology_response_code_description (v3.0)

Both versions of the report specifications are available here.

CLR-467: BL STIP - Implement file duplication prevention with unique indicators

For clients utilizing Banking.Live STIP we have introduced unique indicators in the balance update file format to prevent duplicate processing, so that Banking.Live distinguishes between different instances of the same file and avoids duplicate files/records.

Applicability

Enablement

No enablement required.

This item is specific to clients using Banking.Live STIP.
For clients that do not currently use our STIP, you can speak with your Client Executive if you wish to learn more.

Technical info

• Handling duplicate files: If an individual balance update file shares a name that has previously been used by the client, the entire file will be flagged as failed during processing.
• Handling duplicate records: If a duplicate record identifier is encountered during processing of an individual balance update, the update will be flagged as a failure. This is specific to v2.0 of the balance update file. v2.0 now includes record_id.
  • Balance update file v2.0 fields: record_id, account_id, bill_ccy, act_balance, blk_balance, token
  • Record ID field format: The record ID (record_id) can range from 1 to 40 alphanumeric characters, including hyphens and underscores, which allows for the convenient use of a UUID as a unique identifier. Please note that it cannot contain spaces.

PECP-298 & PECP-332: Show the re-attempt logs of failed/timeout passive FAST message on Transaction Details screen in PayControl

For clients using Passive FAST, you will now be able to view the logs of re-attempted Passive FAST notifications on the Transaction Details screen on PayControl. Passive FAST notifications are re-attempted in the event the first Passive FAST notification failed.

Applicability

Enablement

No enablement required.

This is purely a visual update to the PayControl Transaction Details screen.

Technical info

The Transaction Details screen will now show logs of a Passive FAST re-attempt on the Logs and Timings tabs.
Note: re-attempts only occur in the event the first Passive FAST notification failed.

PECP-183: View Parent Account tab in rules screen on PayControl

In relation to DEC-148: Introduction of Parent Accounts which was released in BL2.16, we have introduced a "Parent Account Based Rules" tab to PayControl's Rules screen. This tab allows users to:

• View Parent Account rules
• Create Parent Account rules
• Link/Unlink cards to Parent Account rules

Applicability

Enablement

No enablement required.

Technical info

N.A.

CLR-495: BL STIP - Excluding outdated balance updates

Due to the nature of batch file preparation and processing, there is a risk of inadvertently updating an older balance value and overwriting a more recent one.
This release item includes system checks to prevent such occurrences during batch processing of balance updates files.

If a balance update file is prepared and sent by the client for processing, and it is discovered during processing that the balance for the particular account was recently updated by another method (e.g. API, FAST response), the batch file update will be skipped and marked as a failure.

Applicability

Enablement

No enablement required.

This item is specific to clients using Banking.Live STIP.
For clients that do not currently use our STIP services, you can speak with your Client Executive if you wish to learn more.

Technical info

When updating the balance through a batch file, Banking.Live will verify if the last updated balance on the account is newer than the balance provided in the file. If it is, the update will be skipped and the client will be notified with an appropriate error code in the FAST Administrative Message and the Feedback File.

PECP-321: Add Parent Account scope to Add New Rule screen on PayControl

In relation to DEC-148: Introduction of Parent Accounts which was released in BL2.16, we have introduced Parent Account to the "Scope" section in the "Add New Rule" screen in PayControl.

Applicability

Enablement

No enablement required.

Technical info

N.A.

PECP-323: Add new section for Parent Account rules in Rules and Limit screen on PayControl

In relation to DEC-148: Introduction of Parent Accounts which was released in BL2.16, we have introduced "Parent Account Rule" section to the "Rules and Limit" screen on PayControl. This allows users to:

• View Parent Account rules linked to the specific card.

Applicability

Enablement

No enablement required.

Technical info

N.A.

AUTH-852: Configurational bypass offline PIN check for contactless chip transaction

This item introduces a feature flag to both product level and client level to bypass offline PIN checks for contactless transactions (DE22.1 = 07) for Mastercard issuers. This means no CVM is required for contactless chip transactions if enabled.

Applicability

Enablement

To enable this feature flag please raise a request via our Customer Support Platform or speak with your Client Executive.

Technical info

A feature flag has been introduced to both product level and client level (bypass_offline_pin_check_contactless_transaction).

When this flag is enabled, offline PIN check will be skipped for contactless chip transactions.

This feature flag is disabled by default.

---

CLR-419: Presentment reversal requests received before presentment requests

Applicability

Defect condition

There was an instance where some presentment reversal requests were received by clients prior to the initial presentment request.

Investigation showed that this was due to the initial presentment and the presentment reversal being in the same settlement file sent by the network.

Defect fix

The fix released includes settlement file checks to avoid this type of behaviour (i.e. the presentment reversal is received prior to the initial presentment by the client).

It ensures the initial presentment will get transmitted to the FAST client endpoint before a presentment reversal even if the reversal presentment and initial presentment are received in the wrong order in the same network file.

EST-658: Settlement issue in Card Test Simulator related to pre-auth-incremental and completion test cases.

Applicability

Defect condition

Test cases for Mastercard pre-auth-incremental and completion settlements were failing on the Card Test Simulator.

Defect fix

Fix restores the expected behaviour of pre-auth-incremental settlements for Mastercard test cases on the Card Test Simulator.

DEC-271: Incorrect error message being returned when trying to delete a tag if it is linked to a rule

Applicability

Defect condition

Incorrect error message of "Tag does not exist" was being returned when trying to delete a tag linked to a rule.

Defect fix

Fix restores the expected behaviour when deleting a tag from a rule.

Expected behaviour: when deleting an existing tag from a rule PayControl will populate the pop-up screen with:

"Are you sure you want to delete this tag[tag name]?
Following rules will be unlinked from the tag: [rule name] [rule name]"

DEFECT-1592: pws_rules_list API slowness

Applicability

Defect condition

pws_rules_list API was taking more than 2 seconds for some users.

Defect fix

Fix released increases speed of pws_rules_list API.

DEC-272: Rules Engine - PIN entry mode checks (DE22_2) not functioning as expected

Applicability

Defect condition

Defect encountered where PIN entry mode checks (DE22_2) were not functioning as expected when being used as part of a rule.

Defect meant that a rule with the operators "=" and "IN" when used in conjunction with DE22_2 was not triggering when it should have.

Defect fix

Fix released restores the expected behaviour of this type of rule, meaning that a rule with the operators "=" and "IN" when used in conjunction with DE22_2 will trigger as expected.

NOTE: this has been released to some environments as a HOTFIX.

DEFECT-1681: ApplePay provisioning failure due to 10 max active DPANs linked to FPAN

Applicability

Defect condition

As part of the ApplePay Lab Certification, we identified a scenario where Check Card Eligibility failed due to a limit on DPAN's.

When a token notification is received with the reasonCode = DELETED_FROM_CONSUMER_APP and no tokenState, the token status was previously not updated.

Defect fix

This fix ensures that the token status is updated to DELETED in such cases and that tokens removed from user devices are accurately reflected in our system.

The system checks the token notification request for both reasonCode and tokenState - if the reasonCode is DELETED_FROM_CONSUMER_APP and tokenState is missing, the token status is updated to DELETED.

You can find more information on Tokenization Notifications here.

DEFECT-1687: SCA checks overriding Nwk status decline codes

Applicability

Defect condition

An issue was identified where some transactions were getting declined with code 1A on an inactive token.

Investigation showed these transactions were getting declined due to SCA checks and then overriding the network status decline code of 05 to 1A.

Defect fix

Fix ensures these types of transactions will not have the network status decline code of 05 overridden with 1A.

DEFECT-1713: SCA exemptions not applied for transactions

Applicability

Defect condition

It was identified that some ASI and MIT type transactions that had reference to an initial authenticated transaction in DE 48, were being declined based on SCA principles when they should have been approved as they qualified as being SCA exempt.

Defect fix

Fix resolves defect of ASI and MIT soft declines for new ASI/MIT transactions and their subsequent transactions, as well as handling subsequent transactions where the initial transaction occurred prior to this release.

Additional information:

• ASIwith SLI 21: not soft declined.
• ASIauthenticated followed byMIT: approved.

DEFECT-1780: Issue with PIN change when tok flag "SEND_PIN_CHANGE_SCRIPT" is enabled

Applicability

Defect condition

When a card has tok flag “SEND_PIN_CHANGE_SCRIPT” (bit position 2) enabled and its first transaction is a PIN change request, the PIN still shows as old PIN when calling any ‘get PIN’ related API’s even though PIN change has been successful.

Defect fix

Fix resolves this issue by excluding PIN change request from "SEND_PIN_CHANGE_SCRIPT” tok flags logic.

Now when a card has tok flag “SEND_PIN_CHANGE_SCRIPT“ (bit position 2) and its first transaction is a successful PIN change request, the new PIN shows when calling any ‘get PIN’ related API’s.

PECA-240: Network Status Code Enhancement: Introduction of Status Codes 1007 and 1009 in API

We have introduced two new network status codes, 1007 and 1009, and improved the way we manage network status codes by using dynamic configuration tables instead of hardcoded values. This change provides more flexibility and better maintenance.

This update allows for more flexible and maintainable handling of network status codes, improving the system's ability to adapt to future changes seamlessly.

Applicability

Enablement

Clients should update their systems to recognize the new status codes 1007 and 1009.

The improved configuration management ensures a more streamlined and maintainable system.

Technical info

❕

Currently only applicable to Visa clients and will be made available to Mastercard clients in future.

In Paymentology's client facing API's, card status is field status_nwk

The new Visa statuses are:

• Status = 1007, Reason Code = 414, Response Code = 12 = Inactive card - formal decline
• Status = 1009, Reason Code = 415, Response Code = 46 = Void card - formal decline

Behaviour:

You can find further information on Card Status and API’s that use Card Status here.

This specific enhancement is currently only applicable to Paymentology's client facing API's.

---

The following release items (PECP-318, PECP-276, PECP-317, PECP-250 & DEC-217) are part of a new Rule Tagging Feature in the Banking.Live Rules Engine.

Rule tags are simply text values which can be linked to a rule. They have no effect on rule processing and are a purely visual aid to help clients group/categorize and identify rules.

• For existing Banking.Live Rules Engine clients, you can raise a ticket through our Customer Support Platform or speak with your Client Executive.

• For clients that do not currently use Banking.Live's Rules Engine, please speak with your Client Executive.

PECP-318: Rule tags: Manage rule tags on PayControl

Rule Tags offers clients a way to group rules into different categories by creating custom tags - labels - and applying them to different rules.

Rule Tags have no effect on rule processing and are a purely visual aid to help clients group/categorize and identify rules.

Applicability

Enablement

For existing Banking.Live Rules Engine clients, you can raise a ticket through our Customer Support Platform or speak with your Client Executive.

For clients that do not currently use Banking.Live's Rules Engine, please speak with your Client Executive.

Technical info

New sub-section introduced beneath the Rules section, in the Client Control dropdown menu on PayControl. [Tag Management].

PECP-276 & PECP-317: Rule tags: Link/Unlink tags to rules on PayControl

Rule Tags offers clients a way to group rules into different categories by creating custom tags - labels - and applying them to different rules.

This item adds a new option to the context menu when right-clicking on a rule to allow the user to Link/Unlink a Tag to it. A new field has also been introduced in Rule Creation screen to Link a Tag to a rule as it is being set up.

Applicability

Enablement

For existing Banking.Live Rules Engine clients, you can raise a ticket through our Customer Support Platform or speak with your Client Executive.

For clients that do not currently use Banking.Live's Rules Engine, please speak with your Client Executive.

Technical info

Rule Tags have no effect on rule processing and are a purely visual aid to help clients group/categorize and identify rules.

• New field introduced in Add New Rule screen
• New option in Context Menu to Link/Unlink Rule Tags when right-clicking on an existing rule in Rules screen.

PECP-250: Rule tags: Manage rule tags on PayControl

Rule Tags offers clients a way to group rules into different categories by creating custom tags - labels - and applying them to different rules.

Applicability

Enablement

For existing Banking.Live Rules Engine clients, you can raise a ticket through our Customer Support Platform or speak with your Client Executive.

For clients that do not currently use Banking.Live's Rules Engine, please speak with your Client Executive.

Technical info

As part of the new rules tagging feature, clients who wish to use this functionality will be able to manage rules tagging via PayControl, this includes:

• Listing tags
• Creating a new tag
• Editing an existing tag
• Deleting an existing tag
• Viewing rules linked to a tag
  This is all performed via the new "Rules Tag" context menu. This menu is available on PayControl under "Client Control > Rules Management > Rules Tag"

DEC-217: Rule tags: Manage rule tags via API

As part of the new rule tagging functionality, clients who use this will be able to manage their rule tags via API. This enhancement allows clients to add tags to their rules and manage them via API, providing an intuitive and efficient way to visually categorize and organize them.

Applicability

Enablement

For existing Banking.Live Rules Engine clients, you can raise a ticket through our Customer Support Platform or speak with your Client Executive.

For clients that do not currently use Banking.Live's Rules Engine, please speak with your Client Executive.

Note: API endpoints are enabled by Paymentology. Therefore, if you are wanting to test these endpoints please follow the instructions above.

Technical info

API specifications for the below listed endpoints are available on the API specification screen on PayControl and will be made available on the Developer Portals API Explorer in the coming days.
You can use these specifications to understand how the endpoints function and once you have the endpoints enabled by Paymentology, you can begin testing them through UAT or the API Explorer. API endpoints include:

• Add a tag to the rule (pws_link_tag)
• List all tags (pws_list_tags)
• Update a tag (pws_update_tag)
• Delete a tag (pws_delete_tag)
• Remove a tag from the rule (pws_unlink_tag)
• List rules by a tag (pws_list_rules_by_tag)
• Create a new tag (pws_create_tag)
• List tags assigned to a rule (pws_list_rule_tags)

---

PECP-152: Add SCA counter limits for Visa and MC products

Configuring transaction limits and counters for SCA on a product level as part of revised PSD2 (Payment Services Directive).

The enhancement supports our clients by allowing them to set limits and counters on transactions such as contactless and ecommerce.

Transactions amounts that fall below the limit can be processed securely, however once the limit is reached, the cardholder will be required to authenticate themselves. For example, if the cardholder performs a contactless transaction above $100, then PIN entry must be enforced to avoid fraudulent purchases.

Applicability

Enablement

This functionality is available to clients in the EU region that fall under PSD2 jurisdiction.

If you are requiring this functionality to be enabled. You can speak with your Client Executive or raise a ticket through our Customer Support Platform.

Technical info

The Paymentology team first configures the "psd2_check" to "1" on the product level. This then enables the "Add/Edit" SCA limits menu on the Product List screen.

The Add/Edit PSD2 Limits for Product pop-up screen allows for the configuration of the following PSD2 type limits:

• PSD2 Contactless Single Transaction Limit
• PSD2 Contactless Cumulative Transaction Limit
• PSD2 Contactless Transaction Counter
• PSD2 Ecommerce Single Transaction Limit
• PSD2 Ecommerce Cumulative Transaction Limit
• PSD2 Ecommerce Transaction Counter

DEC-148: Introduction of Parent Accounts

The new Parent Account scope will allow cascading of rules to the Main children accounts. Essentailly - a rule will be applied to the transaction if the scope of the rule is a parent of the main account of the card the transaction belongs to.

This functionality provides our B2B clients more flexibility in rule application.

Applicability

Enablement

For existing Banking.Live Rules Engine clients, you can raise a ticket through our Customer Support Platform or speak with your Client Executive.

For clients that do not currently use Banking.Live's Rules Engine, please speak with your Client Executive.

Technical info

Any rules that are configured with this enhancement will allow cascading of rules to the main children accounts. Meaning a rule that is set at a parent account level will automatically apply to the main children accounts of the parent account.

PECP-149: Product Configuration ID on Product add/edit screen

The type of design shown to the cardholder is based on a product configuration ID passed to the scheme in the provisioning responses. This setting has been introduced to PayControl and can be set on a per-product basis through the Product Add/Edit screen.

Ability to set different card designs for different products that will be made visible through the cardholder’s mobile wallet. This will tie into the Issuer’s card segmentation, for example, being able to display a different design for a Platinum cardholder as opposed to a Signature cardholder.

Applicability

Enablement

This feature is set by Paymentology internally via PayControl.

If you choose to utilise this feature, please speak with your Client Executive or raise a request via our Customer Support Platform.

Technical info

UI change on Product Setup page. Clients will not see the UI change as the page is not accessible to them and only performed by Paymentology.

PECA-515: Documentation Update: 3DS during Create Card V1 and V2 APIs

We have added two important informational bullet points to the documentation for both Create Card and Create Card V2 API's.

These updates clarify the availability and process of auto-enrollment to 3DS and the steps required if 3DS enrollment fails.

Applicability

Enablement

NA. This is only a documentation update and does not require any enablement.

Technical info

The specific updates to the API documentation for Create Card and Create Card V2 are on the PayControl API specification screen and the API Explorer . The documentation additions are:

• Auto-Enrollment to 3DS: Auto-enrollment to 3DS is now available by enabling the feature in the Product configuration. Clients should contact Paymentology to enable this feature.
• Manual Enrollment Requirement: If 3DS enrollment fails, clients will need to manually call the "Enroll Card to 3DS" API.

---

DEFECT-1177: Fix mobile number format to prevent validation errors when calls made to Apata

Applicability

Defect condition

A specific client encountered failures when calling pws_update_customer API. Investigation showed this was occurring when the card was enrolled in 3DS (through Apata) due to a mobile number validation error.

Note: The specific client is aware of this, and it does not impact others.

Defect fix

Fix put in place. For clients that do use Apata 3DS services through Paymentology and use pws_update_customer API, we require you to input only "+" and digits for the mobile number. Please do not use other non-digit characters. "+" is acceptable.

For example for mobile phone number 02040413299:

• INCORECT FORMAT: +64-2040-413-299
• CORRECT FORMAT: +642040413299

PECA-399: Fix for idempotency issue in Renewal V2 API

Applicability

Defect condition

We identified an issue where the Card Renew/Replace V2 API could halt mid-process due to an unhandled exception in the stored procedure.

This caused log records to remain in a pending status, affecting idempotency checks.

Defect fix

This fix ensures accurate idempotency checks by correctly updating the status of log records, preventing inaccurate error messages and improving the reliability of the Card Renew/Replace V2 API.

To address this issue, we:

• Handle the exception thrown to ensure the process continues and updates the status in the paycore.api_log table.
• This will prevent the log status from remaining in a pending state and ensure proper idempotency checks.

This fix ensures log records are correctly marked as failed if the process encounters an error, avoiding indefinite pending statuses. It prevents inaccurate error messages by ensuring that the status of the original request if correctly reflected, reduces the risk of halted processes and improves the overall reliability of the Card Renew/Replace V2 API.

DEFECT-1400: Active FAST feed and Passive FAST feed use different transaction identifier for the same AuthHold

Applicability

Defect condition

Original issue is that the external reference id for incremental authorization was different in the FAST active and FAST passive messages, when the id should be the same.

NOTE: This defect is only applicable to clients using FAST Lite and Mastercard i.e. using Mambu as the Core processor and issuing with Mastercard.

Defect fix

Change is only to replace UUID with 19 digit value. No change to actual logic.

For example: deeb6434-15cd-41ba-a931-e89f7d62a85d → 99xxxxxx12345 (19 digit).

• Change is done only for Mambu clients (Mastercard) to comply with FAST 3 message.

DEFECT-1421: User unable to unblock amount via PayControl

Applicability

Defect condition

Users were unable to unblock an authorization amount via PayControl and received an error when attempting to do so.

Defect fix

Issue is now fixed, no impact to clients or change to logic.

DEFECT-1435: Hot fix: V2_SC_GET_PIN API call failure (specific client)

Applicability

Defect condition

A specific client encountered errors when using Get PIN V2 API.

Defect fix

Issue was investigated with full fix put in place and deployed as a hot fix.

NOTE: this only impacted one specific client. No logic was changed in fix deployed and no action required by any client.

DEC-262: pws_list_rfc_params is not available in the permissions config screen in PayControl

Applicability

Defect condition

Access to pws_list_rfc_params was not available in the permissions configuration screen on PayControl.

This specific screen is where Paymentology enables access to specific API's for clients. Therefore, the pws_list_rfc_params was unable to be enabled for clients.

Defect fix

pws_list_rfc_params has now been added to the permissions configuration screen in PayControl. Allowing Paymentology to enable the API for client use.

If you are wishing to use this API/have it enabled, please raise a ticket through our Customer Support Platform.

The API specifications are already available here.

DEFECT-1504: Garbage settlement transactions shown on PayControl with "exclude garbage" filter enabled

Applicability

Defect condition

Garbage settlement transactions were showing on PayControl despite enabling the "exclude garbage" filter.

NOTE: this only impacted one specific client.

Defect fix

Hotfix was deployed for specific client. No change to existing logic and no impact to other clients.

DEFECT-1512: ARQC validation failed transaction response code getting updated to 65

Applicability

Defect condition

A transaction was rejected for ARQC error, however on checking SCA the response code got updated from 88 to 65, which was not correct.

For example: A transaction declined but response code was set to 88 (crypto failure) despite the card failing due to its status (restricted).

NOTE: this only impacted one specific client.

Defect fix

Fix deployed means transactions declined with response code (DE39) mapped to the card status (restricted: 1062).

CLR-338: Providing 1644 recon messages to our clients through FAST

Provide 1644 reconciliation messages from Mastercard through FAST.

Applicability

Enablement

This new feature is available to clients issuing with Mastercard and using FAST Settlement V3. Enabling these messages is performed through PayControl by Paymentology.

• If you are using FAST Settlement V3 and issuing with Mastercard you can speak with your Client Executive to have this enabled.
• If you are issuing with Mastercard and not using FAST Settlement V3, you can speak with your Client Executive about upgrading to the latest FAST Settlement Version.

Technical info

The specific 1644 message types in-scope are:

• File Currency Summary (680)
• Financial Position Detail (685)
• Settlement Position Detail (688).

FAST sample messages are available under Reconciliation samples - Mastercard.

---

PECA-381: Reorganise swagger API params by required first followed by optional - changes

In line with company strategic goals and feedback received from clients, the reorganization of swagger API parameters aims to improve clarity and usability.

These changes are to the original release item (PECA-287) where some fields were not organised in the mandatory first, optional second order.

Clients will find the API specifications easier to understand, reducing the time needed for integration and assists clients in onboarding to our services as quickly and as smoothly as possible.

NOTE: This does NOT change how our APIs function or are processed.
This update ONLY changes how the fields appear on the API Explorer and PayControl's API specification screen.

Applicability

Enablement

No enablement required.

Changes are purely visual in display on the PayControl API specification screen and the API explorer.

Technical info

PayControl's API specification screen and the the API explorer now reflect this.

PECA-376: PCID outbound API missing API key and basic auth

We have updated the outbound API for PCID to include API key and basic auth support, which were previously missing. This enhancement ensures secure and flexible authentication methods for our clients.

• The outbound API now supports API key and basic auth for secure authentication.
• The API will use the appropriate authentication method based on the provided configuration.
• This ensures seamless and secure integration for clients using the outbound PCID API

Applicability

Enablement

Implementation Manager will help in setup via PayControl.
The implementation will:

• Send the API key in the header if the API key configuration is present.
• Send basic auth credentials in the header if basic auth configuration is present.

If you are using the outbound PCID API, please reach out to your Implementation Manager or Client Executive.

NOTE: This outbound API is optional and specific to client's utilizing Paymentology's tokenization services.

Technical info

You can find further information on this outbound API under Retrieve Product Configuration ID.

AUTH-656: Bypass PIN validation step for tokenized virtual cards

As some merchants in South Africa require a PIN for virtual card transactions, a feature flag has been created to enable this process.

Applicability

Enablement

This is enabled by enabling a feature flag. This is performed by Paymentology internally. All clients have this feature flag disabled by default.

Technical info

NA. All clients are disabled by default.

---

DEFECT-1384: AVS check not including MDES transactions

Applicability

Defect condition

AVS result code in DE48_83 is not including in the response to scheme of MDES transaction with:

• DE48_26 in ('103, '216, '217', '327')
• DE48_82: 52 (AVS requested)
• card token flag allow avs check fail is turned on
• product setting flag of 'allow_avs_fail_as_avs_supported' is set to TRUE

Defect fix

DE48_82 (AVS request indicator) and DE48_83 (AVS response) result is now included in the DE48 output and sent in the reponse to scheme for MDES transactions.

NOTE: This has no impact to FAST messages. In FAST messages we send the iso message received from the scheme (as part of the FAST ISO node), in 0100 messages this won't be present in DE48 from the scheme, we send the AVS check result in the response to the scheme.

DEFECT-1373: PayControl test simulator not sending settlement records

Applicability

Defect condition

Test simulator was not sending settlement records.

Defect fix

Fix released. Test simulator is now sending settlement records.

DEFECT-1368: Missing DE39=NO in filtering condition on PayControl transactions screen

Applicability

Defect condition

On PayControl transactions screen there was no ability to filter for: 'Filter By: Response Code; DE39 = NO'.

Defect fix

Fix deployed allows for filtering of DE39=NO i.e. 'Filter By: Response Code; DE39=NO'.

DEFECT-1336: DE18 Merchant_Category missing from FAST message (MCC 5816)

Applicability

Defect condition

Defect specific to MCC 5816: where Merchant_Category (SUMMARY node) was passing NA when there was a merchant category on the transaction itself and DE18 (ISO_MSG node) is present.

Defect fix

Fix deployed: Merchant_Category (SUMMARY node) will pass 5816 when merchant category on the transaction itself and DE18 (ISO_MSG node) is 5816 and present.

PECA-385: Mada tokenization flow could insert messageReasonCode into 'status' column in p_card_wallet_token_lifecycle

Applicability

Defect condition

An internal method can return messageReasonCode that will be stored in the status column in backend table, when it shouldn't. The staus column should contain the information on the token status that can be used to see the history/lifecycle of the token.

Defect fix

Fix deployed will not insert any record in backend table if there is no information on the token status in the request payload.

DEFECT-1301: Missing DE51 for Jetco certification

Applicability

Defect condition

Jetco balance inquiry transactions were getting declined with DE39 = 78 during handleAuth call as MNQ transactions don't have any DE49 and DE51 fields.

Defect fix

Fix deployed: For Jetco MNQ transactions, currency check is bypassed (DE51).

All other schemes are not affected.

DEFECT-1286: MC completion advice transaction failed due to 0 amount

Applicability

Defect condition

Advice transaction was received with 0 amount in DE4, DE5, DE6 resulting in transaction failure.

Defect fix

Investigation showed DE48 SE63 was invalid for specific transaction advices from acquirer.

We have still put a fix in place to handle invalid DE48 SE63. Now when the same invalid issue occurs with DE48 SE63, transaction advice can still be processed normally.

CLR-413 & AUTH-702: Creating index in backend tables to improve function performance in PayCore DB

Applicability

Defect condition

Issue where authorization transactions were timed out intermittently due to time it took for Rules Engine processing checks.

The specific clients impacted are already aware.

Defect fix

This fix improves the processing performance by adding specific indexes for two functions in PayCore DB in all Banking.Live environments.

The fix resolves the specific cause of the issue.

PECA-371: Bug fix for pws_action_list api endpoint so that it works for requests with type "alert"

Applicability

Defect condition

The List Action API had a bug when it is called with the type “alert”. The API response would return with error id: 989.

NOTE: no clients were using this specific feature.

Defect fix

Fix deployed: when pws_action_list API endpoint is called with type "alert", API response will return as per the documentation specification for pws_action_list.

DEFECT-1154: 3DS ecommerce transaction declined with incorrect code

Applicability

Defect condition

A transaction was received where merchant sent authorization request without 3DS and was declined with reason code 57: Decline - card enrolled to 3DS verification but verification failed.

Since the transaction didn't fail but wasn't tried we need to respond to MC with reason code 65, so the merchant retries with 3DS.

Defect fix

Fix deployed to decline this type of transaction with reason code 65, so the merchant can retry with 3DS.

DEFECT-1143: Internal settlement matching task failed and had to be run manually.

Applicability

Defect condition

Internal settlement matching task failed and was run manually. Investigation carried out revealed underlying cause.

Defect fix

Fix deployed to fix cause of task failure.

❕

NOTE: internal monitoring systems and support team were alerted to task failure and were able to manually run the specific task and file that initially failed. No impact to clients.

DEFECT-1342: MAX PAN updated to lowest PAN value on backend table (HOTFIX already deployed)

Applicability

Defect condition

MAX PAN value for any product should be the lowest possible PAN value plus the number of created cards.

However, the MAX_PAN value of any product is changed to the lowest possible PAN number each time there is any change in product level from PayControl.

Defect fix

HOTFIX already deployed: This fix rectifies the above and means the MAX_PAN value is NOT updated to lowest PAN value during a change in product level from PayControl.

No clients are impacted.

DEFECT-908: Encoding incorrect for merchants with special characters

Applicability

Defect condition

A transaction with merchant name: Krónan ehf. was encoded as: Kr�nan ehf. In the FAST message sent to client it was Kr�nan ehf. when it should have been Krónan ehf.

Defect fix

This fix allows for special characters to be parsed through in the FAST message to clients and displayed correctly in PayControl.

No transactions have been declined or impacted specifically by this defect and the fix means that special characters can now be parsed through to clients as they are initially received by the scheme.

FOR YOUR REFERENCE:

• Mastercard uses ISO 8859-1 single byte encoding (for ASCII), this fix allows all character representations from ISO 8859-1 to be forwarded in the FAST message and displayed correctly in PayControl.
• You can refer to the Mastercard Customer Interface Specification documentation for their full list of supported character sets.

MCCP-139: CloseOperationalDay_s function closes days only within the cycle

Applicability

Defect condition

CloseOperationalDay_s function closes days only within the cycle and does not pick up days from previous cycle.

Defect fix

Fix deployed for CloseOperationalDay_s closes all past days irrespective of cycle.

MCCP-154: Issue in reversal function for the credit function

Applicability

Defect condition

Issue in reversal function logic caused some transactions that were auto-unblocked to not impact the balance on the credit side due to the issue in specified function.

Defect fix

Fix deployed means that a transaction that is auto-unblocked will be in a reversed state, therefore impacting the balance on the credit side.

MCCP-157: Payment Details from credit statement api fetch all cycles payment data

Applicability

Defect condition

With existing logic, we are receiving all the payment from 1st cycle to the current cycle when pws_get_credit_statement API is called. There is no filter of cycle id for the data selection since in this API we will have cycle id as input param we need to filter the data based on the cycle id.

Defect fix

Fix deployed means when pws_get_credit_statement API is called it returns only payments that are done within that cycle.

PECA-282: EMV chip profile enablement

This feature introduces a new endpoint: /pws_update_emv_script that allows issuers supporting Jetco in Hong Kong to enable a new chip profile on physical cards.

By POSTing values in the fields account_number, account_type, account_restriction, and account_currency_code, issuers can stage a script to update the physical chip. The chip will be updated upon the cardholder’s successful ATM authorization. Currently, this feature supports Jetco in Hong Kong.

Impact to Clients

This endpoint /pws_update_emv_script allows issuers supporting Jetco in Hong Kong to dynamically update EMV chip profiles on physical cards, enhancing the flexibility and functionality of card management.

Clients who support Jetco in Hong Kong should prepare to integrate with the new endpoint and follow the provided specifications to enable EMV chip profile updates.

USE CASE EXAMPLES:

1. Additional ‘saving’s account’ for existing cardholder:
   1. Client creates card with Paymentology
   2. Client creates additional ‘saving’s account’ on client system
   3. Client calls Update EMV Script to update card chip profile – to include ALL chip profiles linked to this card
   4. Upon a successful authorization (script is updated), cardholder is enabled with ATM transaction with the additional ‘saving’s account’.
2. Create credit account for existing cardholder
   1. Client creates card with Paymentology (saving’s account only)
   2. Client creates ‘credit account’ on client system
   3. Client call calls Update EMV Script to update card chip profile – to include ALL chip profiles linked to this card
   4. Upon a successful authorization (script is updated), cardholder is enabled with ATM transaction with the ’credit account’.\
      

CLR-344: Visa Mandate (April 2024 and July 2024 VisaNet Business Enhancements): Changes to support Global Processing Alignment for Issuers

Visa is implementing processing enhancements along with the Electronic
Data Quality Program. This new processing is designed to improve data
integrity and maintain processing integrity throughout the life cycle of a transaction.

Impact to Clients

No impact to clients.

This mandate requires Paymentology to simply receive information. There are no changes to any of the data clients receive from Paymentology.

The specific mandate requirement is listed under 2.1 Changes to Support Global Processing Alignment for Issuers of Visa’s April 2024 and July 2024 VisaNet Business Enhancements: Global Technical Letter and Implementation Guide.

CLR-364: Providing 1644 recon messages to our clients through report

A new reconciliation report for clients issuing through Mastercard has been created. This report includes the reconciliation/1644 messages from the Mastercard T112 IPM Clearing file, so that Mastercard issuing clients can have access to reconciliation data through a report.

Impact to Clients

No impact to clients as default.

If you are a Mastercard issuing client and wish to receive this report, you can raise a request through our Customer Support Platform or by contacting your Client Executive.

The report specifications are now available under Reconciliation - Mastercard. We suggest you review these specifications prior to requesting to receive the report.

EST-250: Pre-Auth, Increment & Completion test cases support in Card Test Simulator

Card test simulator feature to support Pre-Authorization, Increment and Completion (Capture) transaction testing.

Impact to Clients

Clients will be able to run test scenarios for Pre-Authorization, Increment and Completion (Capture) transactions. These test cases include:

1. Pre-auth then incremental then completion then settlement.
2. Pre-auth then incremental then second (Multiple) incremental then completion then settlement.
3. Pre-auth then incremental then settlement.
4. Automated Fuel Dispenser

The below table identifies elements which are set during pre-auth, incremental and completion for Mastercard and Visa:

Pre-auth/Incremental options are shown only for Mastercard/Visa on the test screen as we do not support these test cases for other networks:

This is performed via the Card Test Simulator on PayControl. You can read more on this tool here.

PECP-203: Creating bulk PAN to Token and Token to PAN conversion tool on PayControl

A new tool on PayControl has been created for the Paymentology Fraud Team to better serve our clients by enabling them to easily convert PANs to Tokens and Tokens to PANs to solve the client's issue, and better investigate fraud incidents.

Impact to Clients

No direct impact to clients.

This tool allows the Paymentology Fraud Team to respond more effectively to incidents where we receive the full PAN from Mastercard alerts. Sharing the full PAN with a client can breach PCI DSS, and some clients won’t be able to investigate without the Token.

---

AUTH-645: Account number selection for Jetco transactions based on A/C number received in transaction

Populate the customer_account field in the FAST request message sent to the client with the account number received in the transaction message from Jetco.

Impact to Clients

This feature is only applicable to clients in Hong Kong using the Jetco switch and relates to PECA-282 (above).

This feature means that instead of directly populating the customer_account field in FAST2.0 of Jetco with the ac_ext_ref from the system, Banking.Live will compare it against the value received in the EMV transaction A/C Number of the Jetco transaction.

1. If the value in EMV transaction A/C Number of the transaction is same as ac_ext_ref (removing the hyphen to compare) in the system for this card, then use the same value of ac_ext_ref of the system.
2. If the value in EMV transaction A/C Number of the transaction is different to ac_ext_ref in the system for the card but is equal to the PAN number (which can be checked against the value received in the DF20 tag of EMV request field), then use the value of the ac_ext_ref of the system.
3. If the value in EMV transaction A/C Number of the transaction is different to ac_ext_ref in the system for the card also isn’t equal to the PAN number but is equal to one of the account numbers present in DF20 tag of the EMV request field, then use the value of the EMV transaction A/C Number with hyphen ”-” between third and forth character.
4. If the value in EMV transaction A/C Number of the transaction is different to ac_ext_ref in the system for the card, isn’t equal to the PAN number and also isn’t equal to one of the account numbers present in DF20 tag of the EMV request field, then use the value of the ac_ext_ref of the system. This condition is highly unusual but just to handle the exceptional case.

PECP-236: Provide UI toggle for Visa STIP advice retrieval mode

Create a Toggle on PayControl to control start transmission of advices from Visa. This will be under the options menu on the Client Configuration page.

• When enabled, the pop up will read: Advice retrieval mode is on for this client. Do you want to "disable" advice retrieval mode for this client: [client_name]? Yes/No
• When disabled, the pop up will read: Advice retrieval mode is off for this client. Do you want to "enable" advice retrieval mode for this client: [client_name]? Yes/No

Impact to Clients

No impact to clients by default.

This is a PayControl enhancement to be used by internal Paymentology teams during client configuration and will better support clients using Visa STIP.

DEC-155: Core Implementation of rule tagging

Rule tagging will provide clients with total freedom over how they wish to categorize rules. It provides the ability to group rules by tags, helping client’s fraud and engineering teams when managing sets of rules.

Tagging is a visual cue and has no impact on rule processing. However, it is a helpful tool for Rules Engine users to group rules according to their own naming conventions.

Impact to Clients

No impact to clients at this stage, as this feature implementation is only the core functionality of rule tagging.

There are two separate pieces of work in which a public API will be built for rule tag management as well as additions to PayControl.

Once these pieces of work are complete, clients using Banking.Live’s Rules Engine (PayRule/Decision Engine) will be able to use this functionality.

❕

Note: these additional pieces of work will be communicated in release notes once the full and complete functionality is released, at that stage we will communicate further details of how to enable and use them.

CLR-363: Paymentology STIP: Adding support for token in balance update file

This enhancement will allow our clients to be able to use token for updating account balances to be later used while STIP.

Impact to Clients

No direct impact to clients.

This forms part of Paymentology’s STIP functionality improvement. You can read more on Paymentology STIP under Stand-in Processing.

---