Release notes: Banking.Live 2.12

PECA-295: Outbound API to Retrieve Tokenisation Product Configuration ID (PCID) from Clients During Provisioning

This feature enables clients with proprietary logic to identify a single card's Product Configuration ID (PCID). Paymentology will contact the client to obtain the required PCID during the provisioning process, specifically when making the CheckEligibility call.

Clients can use their own logic to determine PCIDs, resulting in more precise and personalised provisioning. This, in turn, will lead to a smoother user experience for cardholders when tokenizing their cards across multiple wallets.

Impact on Clients

❕

Integration required

Clients need to integrate this feature into their systems, if they wish to use it.

This involves setting up the outbound API and ensuring their systems can handle the request and response format specified. Enhanced User Experience: Cardholders will experience an improved and seamless process when tokenizing their cards.

Clients will need to follow the below steps during integration:

• Implement the outbound API to receive token requests from Paymentology.
• Handling the required parameters (token and walletId) in the request.
• Returning the productConfigurationId in the response.

PECP-148: Allow refund for card statuses via PayControl

We have added a new setting on the Product Configuration page to enable clients to configure which card statuses are eligible to receive a refund on a perproduct basis. By default, refunds are always allowed for active cards. Users will be able to configure which other card statuses can receive a refund, such as stopped or voided cards.

Impact on Clients

Change to the PayControl User Interface on the Product Configuration Screen to provide clients with more flexibility in handling refund cases for their cardholders.

PECA-316: Increase Character Limit for Address Fields in Card Renewal API

We have increased the pur_addr1, pur_addr2, del_addr1, and del_addr2 fields from 50 to 100 characters in the v2_pws_card_renewal API. This update allows clients to order and renew cards with longer address fields, improving the card ordering process and resolving previous limitations

Impact on Clients

• Enhanced Address Handling: pur_addr1, pur_addr2, del_addr1, and del_addr2 fields now support up to 100 characters.
• Improved Card Renewal Process: Clients can renew cards without issues related to address length.

DEC-154: Inclusion of public tokens in rule alerts

We now provide the ability to display the public token in the “Send Alert“ action. This is useful for clients who wish to look up a card in their back-office system without having to do wildcard searches on the masked PAN as they previously
had to do.

Impact on Clients

This addition of the public token to the alert actions is purely visual

DEC-154: Availability of STIP Functionality for Visa and Mastercard card products

Paymentology now offers Stand-In Processing (STIP) to enhance transaction reliability during system outages. STIP allows an alternate entity to manage transactions when the primary system is down due to maintenance or technical issues. We offer STIP in two configurations: with shadow balance and without shadow balance. This ensures continuous and reliable transaction handling within financial networks. This feature is available for clients using the FAST V3 transaction feed.

Impact on Clients

Should a client wishes to leverage the STIP functionality offered by Paymentology, they may engage with their Client Executive.

PECA-283: Improvements to pws_mada_token_update Endpoint

The pws_mada_token_update endpoint now accepts card MetadataInfo as optional. If provided, it overrides the database value; if not, the database value is used. Code refactoring and bug fixes have improved reliability, and unnecessary steps have been removed. This update improves the flexibility and reliability of the pws_mada_token_update endpoint, ensuring that it handles optional fields correctly and operates more efficiently.

Impact on Clients

• Enhanced Flexibility: The cardMetadataInfo field can now be optionally included in requests.
• Improved Reliability: Fixes and refactoring enhance the overall reliability and maintainability of the endpoint.
• Streamlined Processing: Removal of unnecessary steps and incorrect assignments ensures smoother operation

AUTH-480: Issuers Can Only Submit Partial Authorization Responses When Acquirer Support is Present

We have added support to check if the acquirer supports Partial Auth by checking Field 60.10 position 12 has a value of 3 (Estimated amount and terminal accepts partial auth responses).

Impact on Clients

No client impact.

AUTH-492: Enhancing the Mastercard Identity Check Program

Paymentology implemented enhancements to the validation and rejection logic for the On-Behalf-Service (OBS) in the Mastercard Identity Check Program.

• Identify the Transactions with OBS Flag: We check the Data Element (DE) 48, subfield 71, position 1 (DE-48_71_1) for the values 05 or 06, which indicates an On-Behalf-Service (OBS) transaction.
• Validate MAC Key: Use the mac_key_validation_on_behalf_service_mastercard_aav_verification flag to mark transactions that meet these criteria for improved tracking and reporting.
• Reject the Transaction: The transaction is rejected if DE-48_71_2 equals F (MAC key validation fail) with
  mac_key_validation_on_behalf_service_mastercard_aav_verification Improvement flag

Impact on Clients

No client impacts. The default value of mac_key_validation_on_behalf_service_mastercard_aav_verification flag is FALSE. The new validation won’t take effect and no transaction will be declined. If a client decides to enable the flag, and Mastercard has implemented the F value (currently they have not) and the transaction meets the criteria then the
transaction will be rejected.