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_ccy field 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_ccy field 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_lang field 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 passive FAST notification is sent to the client.
A pre-authorization of 100 SAR is performed successfully.	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.
• Improved Accuracy: By using a new property name oldPublicToken, the implementation is clearer and prevents similar issues in the future.

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
• valid_on_behalf_service_mastercard_aav_verification, skip_aav_validation_mc_generated, bypass_aav_on_merchant_risk),

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
• valid_on_behalf_service_mastercard_aav_verification

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. Capture Transaction will now be approved with excessive capture greater than the threshold when the amount is within the threshold value.

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:
• Processor_Decision_Code previously 00 now 30
• Processor_Reason_Code previously 000 now 899
• Processor_Decision_Desc previously “Approved” now "Decline - Request Field Format Error"

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).