Release notes: Banking.Live 2.16

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