Release notes: Banking.Live 2.13
AUTH-446: Addition of Acquirer Country Code to Authorization Messages (Mastercard Mandate AN 7411)
Issuers will have the acquirer country code provided in authorization messages when available. This may prevent delays in their transaction processing and provide necessary information for regulatory requirements. Issuers may need to conduct a separate lookup process in the event data element (DE) 19 (Acquiring Institution Country Code) is not present.
Impact to Clients
Currently Banking.Live uses DE43_5 to identify the merchant country. With the addition of DE19, Banking.Live will now use the following logic:
- If DE19 exists then use DE19 as merchant country, else use DE43_5 for merchant country.
DEC-115: Management of Rules Engine - User Adjustable values via APIs
In the Rules Engine you can create a rule with user-adjustable values. These user-adjustable values are set up and maintained via the PayControl UI, however, you are only able to override those default values on an individual card level by inserting an entry into our database.
- We will provide the functionality to set these values on a card level via API.
- We are also going to provide a new API which allows you to view the user-adjustable values for a specific rule & card combination.
- We will be altering the List Rules API to return the user-adjustable default values if they have been set for a rule.
Impact on Clients
Two new APIs are being provided:
- /pws/pws_set_rfc_params Sets Rule Parameters For a Card
- /pws/pws_list_rfc_params List Card Params For Rule
One API response has been altered:
- /pws/pws/list_rule List Rules
AUTH-572 & AUTH-607: Paymentology STIP: For Internal STIP clients add a balance update feature in the FAST response
STIP-enabled clients can include balance optionally in extra balance fields in fast response for the balance update and Banking.Live will rewrite/update the balance of that account with the balance present in new balance fields. This will be an optional feature for Internal STIP-enabled clients only.
Impact on Clients
No impact on clients by default as it is an optional feature targeted for STIP enabled clients only.
For more information on how this works, you can refer to the Shadow balance fields in FAST response section of the Stand-in Processing guide.
AUTH-608: Paymentology STIP: Handle shadow balance check in handle auth PayCore for MC and VISA
Back-end function to accept value forwarded by client in FAST response and to store in respective database tables. This is part of the Paymentology STIP functionality and allows Paymentology to keep a shadow balance of external authorization clients (with STIP enabled).
Impact on Clients
No impact to clients as default.
You can read more on our STIP functionality here and this specific type of STIP balance maintenance here.
CLR-175: Paymentology STIP: Determining unthrottling of the client endpoint
This enhancement will allow the system to determine whether the client is back to responsive state and is able to respond back to FAST messages.
This forms part of the Paymentology STIP functionality.
Impact on Clients
No impact to clients as default.
You can read more on our STIP functionality here.
CLR-349: Paymentology STIP: Improvements for STIP Advice message transmission
This introduces a new dedicated job for handling STIP advice messages, which will allow the system to only transmit STIP advice messages once the client comes back up from throttling.
This forms part of the Paymentology STIP functionality
Impact on Clients
No impact to clients as default.
This is a measure put in place to make sure that STIP advice messages are not transmitted to a STIP client who is
offline.
You can read more on our STIP functionality here.
CLR-363: Paymentology STIP: Adding support for a token in the balance update file
Currently the balance synchronization process requires a balance file update that carries account number as the only field to update a balance in our system for STIP processing. But depending on the client setup, it will not always happen that clients have access to account numbers and they may require an alternate method for updating those balances. This is where the token field will come into play.
This forms part of the Paymentology STIP functionality.
Impact on Clients
No impact to clients as default.
This enhancement will allow our clients to be able to use token for updating account balances as part of Paymentology STIP.
You can read more on our STIP functionality here and specific details on the format of the bulk balance update file here.
PECR-220: New Columns for Fee Transparency and Reconciliation in the Authorizations Report
This release introduces two new optional columns to the Authorizations Report to enhance visibility into transaction costs during authorization and streamlined reconciliation processes:
billing_amount_fees: Shows program fees deducted from the available balance during authorization, providing clear visibility into transaction costs upfront (subject to change after settlement).rid_authorization: The unique identifier for each authorization record, simplifying linking multiple authorizations to a single settlement.
Impact on Clients
No impact to clients as default.
These columns are currently optional and available upon request. If you wish to receive them in your Authorizations Report, you can raise a request via our Customer Support Platform or by contacting your Client Executive.
You can read more on our Authorozations Report here.
DEC-197: Paymentology STIP: The addition of the ability to reference if a previous transaction was enabled for STIP
Our rules engine can allow a transaction to be made available for STIP via a rule. Therefore, if the call to the client’s value store were to then fail Paymentology would stand-in.
However, we cannot currently see if we stood in for a past transaction. With this change you will now be able to check if historic transactions were STIP enabled and the call to the client’s value store failed.
Impact on Clients
No impact to clients by default.
Rules can be created that reference the historical STIP outcome value for a transaction. ie. If there have been X STIP’s in the past X hours - do not make this transaction available for STIP enablement.
This is made available via a new Feature Set which can be used in any of the rules.
If you wish to utilize this in your rules, you can raise a request via our Customer Support Platform or by contacting your Client Executive.
You can read more on our STIP functionality here.
PECA-346: Enhancements to UpdateAccountBalance API endpoint
We have made two important updates to the pws_update_balance API to improve its functionality and clarity:
- Limit list to max. 25 calls: Each API call is now limited to a maximum of 25 items.
- Documentation update for bill_ccy field: The description for the
bill_ccyfield has been updated to clarify its behavior.
Impact on Clients
These updates ensure better performance and clearer documentation, enhancing the user experience and preventing potential issues related to currency conversion and call limits.
- API call limit: Each call to pws_update_balance is now limited to 25 items, improving performance and preventing overload.
- Clearer documentation: The
bill_ccyfield documentation now specifies that if a different currency is provided, it will be converted to the account’s base currency.
Clients should be aware of the new 25-item limit per API call. Additionally, the bill_ccy field should be used with the understanding that any provided currency will be converted to the account’s base currency.
Updated description for bill_ccy field:
- Bill Currency: Balance currency of account. If other currency is provided, it will be converted to the account’s base currency.
PECP-152: Add SCA counter limits for Visa and MC products
Configuring transaction limits and counters for Strong Customer Authentication on a product level as part of the revised Payment Services Directive (PSD2).
Note: PSD2 is specific to the EU.
This enhancement supports our clients by allowing them to set limits and counters on transactions such as contactless and ecommerce. Transaction 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 purchase.
Impact on Clients
This change is available/enabled for clients that fall under the PSD2 jurisdiction.
The change is available on the UI (PayControl) when psd2_check is set to 1 and performed by the Paymentology team.
If you fall under the jurisdiction and require this to be enabled, you can raise a request through our Customer Support Platform or by contacting your Client Executive.
PECA-325: MADA Token Inquiry API is partially implemented
We have enhanced the Mada Token Inquiry API to ensure correct routing to MADA instead of VTS. Previously, the API incorrectly called the VTS API, causing unexpected behavior and timeouts. This update includes query adjustments and a refactored implementation to align with the intended functionality.
Impact on Clients
This update ensures that the Mada Token Inquiry API correctly interacts with MADA, improving reliability and preventing errors related to incorrect API calls.
- Correct API Routing: The API now correctly calls MADA for token inquiries, ensuring accurate and expected behavior.
- Improved Reliability: By addressing the root cause of the issue, the API interaction with MADA is now more reliable.
PECP-205: Viewing token group rules from the Rules page
This story is concerned with adding an expander to view rule details, including the conditions and actions. Previously, users could only view, add, or edit Account Groups from the rules page, but to view Token Groups, users had to navigate to a different page entirely.
Impact on Clients
No impact to clients.
This change has been made for internal Paymentology teams. It means that our Fraud Monitoring and Support Teams can better support our clients.
Change to User Interface on PayControl (Rules Screen).
AUTH-579: Fix how Partial Reversals should be displayed in PayControl
Fixed an issue with the partial reversal amount calculation for PayControl UI where the partial reversal amount was not displaying correctly.
Impact on Clients
Before this release: the replacement amount (DE95_1 or DE95_3) was displayed in ‘Loc Amt’ and ‘Bill Amt’ on the PayControl transactions screen (PayControl/transactions).
Post this release: The reversed/released amount (DE4 – DE95_1 or DE6 – DE95_3) will be displayed in ‘Loc Amt’ and ‘Bill Amt’ on the PayControl transactions screen (/PayControl/transactions).
Note: This change is ONLY applicable to PayControl and does NOT impact FAST messages, any FAST UI or reporting.
DEC-203: Skipped rules stored
Rules can be skipped if the prior rule is set to either:
- stop_further_processing or
- skip_if_declined
Rules that are skipped due to this are now tracked and stored.
Impact to Clients
No impact to client.
DEC-53: Paymentology STIP: Internal STIP advice should not be considered in the Rules Engine
Rules Engine should not consider Internal STIP to avoid any impact on transaction count and amount. Notifications should not be inserted in the back end of the Rules Engine for historical data.
This forms part of the Paymentology STIP functionality.
Impact on Clients
No impact to clients as default.
This is a measure to ensure the Rules Engine is not causing errors by considering internal STIP messages in limit counts.
You can read more about our STIP functionality here.
PECP-210: Update the API documentation endpoint reference in PayControl
To accommodate recent API specification updates, the API documentation endpoint in PayControl has been updated.
The API specification updates mean the mandatory fields in the API specification available on PayControl and via the Developer Portal will appear above optional fields. This is one of the final steps in the API specification update and should reflect on the API Explorer within the next 2 weeks.
Impact on Clients
No impact to clients as default.
This is a part of an update made to the API specification documentation available on PayControl and the Developer
Portal.
INT-191: Visa STIP: Network message for advice retrieval mode sign on and sign off
This feature is for Visa, to enable a STIP advice on/off through a network management message to the scheme by calling the corresponding API.
Impact on Clients
No impact to clients.
This is part of the communication compliance testing procedures for Visa STIP and Banking.Live.
PECA-353: Ensure that the language field is optional in the Enroll Card to 3DS endpoint
We have addressed an issue where the 3ds_lang field, documented as optional, was being auto-defaulted. This fix ensures the field remains truly optional, aligning with its intended functionality. If populated, it will update the language as specified; if left empty, no default value will be applied.
Impact on Clients
This update provides greater flexibility and accuracy, allowing clients to choose when to override the language setup at the APATA product level without unintentionally defaulting to a specific language.
- Optional Language Field: The
3ds_langfield is now correctly treated as optional in the Create Card and Enroll Card to 3DS endpoints. - Accurate Language Handling: If the field is populated, it updates with the specified ISO 639-1 two-letter language code. If left empty, it remains empty without defaulting to any language.
Clients should ensure that the 3ds_lang field is populated only when a specific language override is desired. The endpoints affected by this update are:
AUTH-600: Send FAST passive notification for unblocked authorization (Mada clients)
Send passive FAST notification when an authorization has been unblocked.
Impact on Clients
Only applicable to Mada internal auth clients and an optional feature. Clients not using Mada already have this option. A sample of this FAST notification can be found on the Developer Portal here and you can refer to the below table for use case examples:
Given | When | Then |
|---|---|---|
A pre-authorization of 100 SAR is performed successfully. | The auth unblock job triggers and the original pre-authorization was not settled. | The authorization is considered expired, and the funds 100 SAR are released and credited back to the cardholder account. |
A pre-authorization of 100 | The auth unblock job triggers and the original pre-authorization is already settled. | No action will be taken. |
DEFECT-1027 | Renew Card API is not updating the digital token |
|---|---|
Defect Condition | During the card replacement process, we identified an issue where the new PAN was mistakenly sent as the old PAN in requests to MeaWallet for digital token updates. This caused Visa to reject the requests due to validation checks, while Mastercard did not perform the same validation. |
Defect Fix | This fix ensures that the correct old PAN and new PAN are sent during card replacements, preventing rejections by Visa and ensuring successful updates for digital tokens. • Correct PAN Update: The correct old PAN and new PAN will now be sent to MeaWallet, ensuring that Visa accepts the requests. Clients do not need to take any action. The fix involves updating the implementation to use the oldPublicToken property correctly, ensuring that the old PAN is properly distinguished from the new PAN. |
| DEFECT-1095 | Card status update failing from PayControl |
|---|---|
| Defect Condition | pcjs_card_status_edit API call is failing and the client was unable to change the status of the card. |
| Defect Fix | Failure resolved. |
| DEFECT-945 | While adding a limit from the Load/Unload Limit Rule Groups page on PayControl, getting an error as Model Validation Failed. |
|---|---|
| Defect Condition | Validation was removed in error. |
| Defect Fix | Add validation to frequency which accepts 2 characters while load unload rules. |
| DEFECT-1099 | Card history shows requests not related to the token |
|---|---|
| Defect Condition | Where multiple tokens belong to the same account the card history for other tokens linked to the account was displayed, which should not be the case. |
| Defect Fix | The client will see requests for the specified token when viewing card history. |
| DEFECT-1077 | Discrepancy in the Credit Balance Summary report |
|---|---|
| Defect Condition | Current_Outstanding_Balance displayed with 2 decimal places for Jordanian clients. |
| Defect Fix | Current_Outstanding_Balance displayed with 3 decimal places for Jordanian clients. |
| DEFECT-1047 | MADA transaction incorrectly declined |
|---|---|
| Defect Condition | MADA Transaction declined with 909 due to the value being too long for type character varying (16) |
| Defect Fix | Fix parsing sub-element 6 for DE47 in the rule engine. |
| DEFECT-1066 | The blocked amount was not removed while posting the settlement |
|---|---|
| Defect Condition | At the time of settlement and posting blocked amount was not released and incorrectly the amount was debited force fully from customer's account when we received the Settlement Credit Voucher for the partial amount followed by a settlement - sales draft against the original authorization amount. |
| Defect Fix | Add missing changes in Visa V4 matching logic. |
DEFECT-576 | Revert changes to add new approved reason code for MC 3DS AAV OBS case |
|---|---|
Defect Condition | The approved transactions by Paymentology have a wrong 3DS_Check indicator of "FAIL" for 3DS due to bypassed conditions: • iav_validated_by_mastercard OR impacting the client's decision-making |
Defect Fix | Paymentology has introduced new approved reason codes to indicate that a transaction is approved due to 3D Secure bypassed conditions. • iav_validated_by_mastercard OR will have reason code 240. • skip_aav_validation_mc_generated will have reason code 241. • bypass_aav_on_merchant_risk will have reason code 242. These reason codes have now been added to the Developer Portal Reason Code guide here. |
| DEFECT-989 | Card Holder Report showing BIN as 0 |
|---|---|
| Defect Condition | For 8-digit BINs the Card Holder Report shows BIN as 0 |
| Defect Fix | Show up to 8 digits of the BIN in that column |
| DEFECT-1034 | Fix decimal point on performunblock3 function |
|---|---|
| Defect Condition | Transaction failed to unblock due to an exception |
| Defect Fix | The transaction should be successful in unblocking |
| DEFECT-399 | Rule based on a rolling 30-day period for monthly ATM withdrawal limit incorrectly considers declined transactions |
|---|---|
| Defect Condition | Monthly limit rule triggered despite the DE39 = 05 from MC |
| Defect Fix | Exclude declined transactions from spend history for limit type rules. |
| DEFECT-1104 | Client is not able to log in to PayControl |
|---|---|
| Defect Condition | Client not able to login to PayContro |
| Defect Fix | Hotfix deployed to enable login to PayControl. |
| DEFECT-1063 | ASI incorrectly declined when amount in DE4 is zero or non-zero |
|---|---|
| Defect Condition | For ASI transactions with processing code 28 and amount > 0 the response in DE39 and the reason code are incorrect. |
| Defect Fix | Do not decline transaction only if DE4 is zero or non-zero. |
| DEFECT-970 | Some cards are getting created without a PIN for a specific client |
|---|---|
| Defect Condition | Incorrect response for certain cards when calling v2_sc_get_pin API. NOTE: Only impacted one specific client. |
| Defect Fix | Ensure random pin generation is happening during card manufacturing. Token returns successfully when calling v2_sc_get_pin API.. |
| DEFECT-1005 | ATM withdrawal-reversal request is not posted for cancelled transaction |
|---|---|
| Defect Condition | FAST active message not generated for ATM withdrawal-reversal request for cancelled transactions. |
| Defect Fix | FAST message for ATM withdrawal-reversal request is posted for cancelled transactions by Increasing transaction processing time and queue time in the Rules Engine call parameter. |
| DEFECT-1044 | MADA Transaction declined with 909 |
|---|---|
| Defect Condition | MADA transaction declined with 909 due to DE47 data in the message. |
| Defect Fix | MADA DE47 parsed to Rules Engine and the transaction was approved as expected. |
| DEFECT-1065 | Divergence in Response code for MADA transactions |
|---|---|
| Defect Condition | DE47_07 = 18 parsed incorrectly in the FAST feed. |
| Defect Fix | Valid notes related to DE47_07_04 are excluded, if there is no relation with ARQC fail. If the transaction fails due to reason code 140, it is indicated clearly. |
| DEFECT-1061 | Error when parsing DE7 (txn time) for generating FAST lite JSON data |
|---|---|
| Defect Condition | DE7 (txn time) not parsed in the FAST lite feed. |
| Defect Fix | DE7 (txn time) correctly parsed in the FAST lite feed. |
ESQA-1151 | Mada Internal Ledger: Capture Transaction declined with excessive capture greater than the threshold (even though the amount is within the 10% threshold value) |
|---|---|
Defect Condition | Capture Transaction declined with excessive capture greater than the threshold (even though the amount is within the 10% threshold value). |
Defect Fix | hreshold limit logic fixed. |
| PECA-354 | pws_rule_list not returning all rules on shared UAT |
|---|---|
| Defect Condition | The card rule system on shared UAT is not working as expected. It does not set the limit rules and it removes the rule when changing the limit. |
| Defect Fix | Setting and changing limit type rules on shared UAT will now work as expected. |
DEFECT-1221 | Sends an approval decision to the client even when DE-3_1 = 99 (unregistered value) |
|---|---|
Defect Condition | Unregistered value of DE-3_1 (ex : 99) is approved where it should be declined. |
Defect Fix | Validate the value of DE-3_1, if it’s an unregistered one then decline. Technically no change, but since the processing logic is changed as previously described then it affects the output of the FAST request body sent to the client: |
| DEFECT-1154 | 3DS e-commerce transaction rejected with incorrect code |
|---|---|
| Defect Condition | Previously, there was an issue with the breaking of DE48_71_05 and DE48_71_06 field and causing issue during OBS checks ( i.e. DE48_71.1 contains 05V and matches criteria like DE48_71.2 = V and DE48_43 leading IN ('kD', 'kC', 'kE', 'kX', 'kY', 'kZ', 'kF') ). |
| Defect Fix | Fix contains proper breaking of those fields and setting on_behalf_service_mastercard_aav_verification flag to TRUE (there is still option to disable this, but by default this logic will be enabled i.e. flag set to TRUE as default). |