Release notes: Banking.Live 2.14
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:
- Additional ‘saving’s account’ for existing cardholder:
- Client creates card with Paymentology
- Client creates additional ‘saving’s account’ on client system
- Client calls Update EMV Script to update card chip profile – to include ALL chip profiles linked to this card
- Upon a successful authorization (script is updated), cardholder is enabled with ATM transaction with the additional ‘saving’s account’.
- Create credit account for existing cardholder
- Client creates card with Paymentology (saving’s account only)
- Client creates ‘credit account’ on client system
- Client call calls Update EMV Script to update card chip profile – to include ALL chip profiles linked to this card
- 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:
- Pre-auth then incremental then completion then settlement.
- Pre-auth then incremental then second (Multiple) incremental then completion then settlement.
- Pre-auth then incremental then settlement.
- Automated Fuel Dispenser
The below table identifies elements which are set during pre-auth, incremental and completion for Mastercard and Visa:
Network | Pre-auth | Incremental | Completion |
|---|---|---|---|
Mastercard | DE61_7 = 4 | First Incremental only: DE63_48 = DE63 of pre-auth + DE15 of previous message | DE18 = 5542 |
Visa | DE60_12 = 2 | DE63 = DE63 of pre-auth + "3900" | DE63 = DE63 of pre-auth + "3900" |
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.
- 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 ofac_ext_refof the system. - If the value in EMV transaction A/C Number of the transaction is different to
ac_ext_refin 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 theac_ext_refof the system. - If the value in EMV transaction A/C Number of the transaction is different to
ac_ext_refin 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. - If the value in EMV transaction A/C Number of the transaction is different to
ac_ext_refin 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 theac_ext_refof 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.
AUTH-426 | Handling of Mastercard transaction – not setting indicator of expiry check |
|---|---|
Defect Condition | 60th bit check indicator hasn’t been set in the Mastercard’s stored procedure. Even though the expiry result verification fails, the unset bit check would give indication of expiry was either not done at all or had passed. This resulted in the bit check not being set and the FAST message field “ |
Defect Fix | 60th bit check indicator is now set in Mastercard’s stored procedure. |
| DEFECT-1176 | View all transactions for this transaction thread are not working properly (specific client) |
|---|---|
| Defect Condition | When trying to fetch related transaction using "View all transactions for this transaction thread" no output related to the transaction was returned. |
| Defect Fix | Hotfix deployed for specific client. Related transaction output is now returned when fetching using "View all transactions for this transaction thread". |
| CLR-392 | Paymentology STIP: Balance update bug fixes |
|---|---|
| Defect Condition | 1. Balance Update FAST request should not be sent if the client endpoint is throttled. Despite the FAST endpoint being throttled the request is still sent to the client. 2. A balance file containing the token is being processed for a token that is linked to multiple accounts and the first account linked with that token that is found gets the balance updated. This might NOT be the default account. |
| Defect Fix | 1. IF the client endpoint is throttled (is_throttling=true from conf_pauth for that endpoint) the request is saved but not sent. Request is sent only when the endpoint becomes unthrottled. 2. The default account will get the balance updated. |
| CLR-398 | Fix bug in TaskConfig where username is getting re-encrypted instead of decrypted |
|---|---|
| Defect Condition | Username is re-encrypted when it should be decrypted. |
| Defect Fix | Username is now decrypted when it should be. |
| AUTH-616 | Spend Type ‘NA’ being sent in FAST message for Mastercard Payment transaction |
|---|---|
| Defect Condition | For Payment transaction DE_3_1 = 28, currently Banking.Live is sending Spend_Type = ECOM – NA in the SUMMARY node of the FAST message. The proper spend/transaction type should be specified instead of NA. |
| Defect Fix | For Payment transaction DE_3_1 = 28, Banking.Live will send Spend_Type = ECOM – Payment Transaction in the SUMMARY node of the FAST message. |
| AUTH-629 | Failed passive feed messages job not picked in SendAdviceMessage Job task (specific client) |
|---|---|
| Defect Condition | “SendAdviceMessage” Job task didn’t pick a failed Passive feed message. |
| Defect Fix | “SendAdviceMessage” Job task will now behave correctly and pick failed Passive feed messages to resend. |
| DEFECT-1164 | Wrong Purchase date in transaction (specific client) |
|---|---|
| Defect Condition | Incorrect purchase date specified for a transaction. A TID showed two settlement transactions 8 months apart. |
| Defect Fix | Manual adjustment made and other test cases performed to validate purchase date behaving correctly. |
| PECR-296 | Remove VAU renaming after transfer |
|---|---|
| Defect Condition | When VAU was renamed, it was not removed once file was transferred. |
| Defect Fix | Once VAU file is transferred, the renaming is now removed. |
| MCCP-140 | When installment is cancelled, mark the remaining unposted installment plan properly |
|---|---|
| Defect Condition | Currently, when the installment is canceled, all the installment plans are marked as canceled even when some were posted to the account. However, the payment to those posted plans is correctly done but they are marked as cancelled so we need to mark those plans only that are not posted till the cancellation time. |
| Defect Fix | When the installment is canceled, the installment plans are marked as canceled apart from the payments that were posted to the account. Showcasing the correct behaviour and posting of installment payments. |
DEFECT-1221 | Shared UAT – FAST out sends an approval decision to the client even when DE3_1 = 99 (test case for specific client) |
|---|---|
Defect Condition | Unregistered value of |
Defect Fix | Validate the value of • You can find the full list of reason codes, their descriptions, and decision/reason code scenarios under Reason codes. |
| AUTH-690 | PayPower: when transaction contains DE120 with length 18, Auth Engine throws an error when logging transaction |
|---|---|
| Defect Condition | When transaction contains DE120 with length less than 29, Auth Engine throws an error when logging transaction |
| Defect Fix | When transaction contains DE120 with length less than 29, Auth Engine will process transaction correctly, no exceptions will occur, and transaction is logged. |
| DEFECT-1154 (FIX Part 2) | SCA soft decline for tokenized transaction |
|---|---|
| Defect Condition | For tokenized transaction, SCA check was triggered, and the transaction were soft declined with RC 65. |
| Defect Fix | Change has been made to bypass SCA check if the transaction is tokenized. This change is behind flag and is enabled by default. |
| DEFECT-1384 | AVS result not included in MDES transaction response |
|---|---|
| Defect Condition | AVS result code in DE48_83 and AVS request indicator in DE48_82 not included in DE48 response to scheme for MDES transaction |
| Defect Fix | Include DE48_82 (AVS request indicator) and DE48_83 (AVS result code) if present in DE48 response of MDES transaction. |