Release notes: Banking.Live 3.0

PECA-797: Introduction of Secure API for Fetching Personalisation Data

Paymentology will be deprecating Personalisation Data API (https://developer.paymentology.com/reference/pws_perso_data). A new, secure replacement API will be introduced under the PaySecure API suite, aligned with our standard security and access protocols.

This update ensures that sensitive card personalisation data is handled securely and in accordance with best practices, reducing the risk of data exposure or misuse

Applicability

Enablement

Migration Required: Any planned or ongoing integrations using the deprecated API must be reconfigured to use the new API endpoint once released.

Technical Info

The existing /pws_perso_data / API is deprecated and should no longer be used for any integration.

A new, secure API /sc/v2/sc_get_perso_data/ will be made available under the PaySecure service umbrella for fetching personalisation data.

The new API will follow the same secure access model as other PaySecure APIs, including token-based authentication and stricter access controls.

Header details

Generate 32 bytes random value and encode as base64 string termed as the session key.

The base64 encoded string should be encrypted with rsa public key.

The encrypted value will be passed in the header request under Session-Id

Later, this session key will be used to encrypt the sensitive data in the response

PECR-718: Quarterly Mastercard Report (QMR): Restricted Accounts/Cards Now Counted as “Open”

We have updated how the “accounts/cards at the beginning of quarter” metric are calculated in the Quarterly Mastercard Report. Previously, restricted accounts/cards used to be considered as “Temporarily blocked”. From this quarter (Q3 2025) onward, restricted accounts/cards are now considered under “Open” for a more precise reporting.

This change ensures precise reporting of the Quarterly Mastercard Report values uploaded to Mastercard’s portal.

Applicability

Enablement

No enablement required

Technical Info

NA.

PECR-760: Quarterly Visa Report (QVR): Total Number of Cards Metric Now Excludes Terminated Cards

We have refined how the “total number of cards” metric is calculated in the Quarterly Visa Report. In the past, the count excluded only expired cards. From this quarter (Q3 2025) onward, the count will exclude both expired and terminated cards for a more precise reporting.

This change ensures precise reporting of the quarterly visa report values uploaded to the portal.

Applicability

Enablement

No enablement required.

Technical Info

NA.

DEC-924: Non-Triggered Rules Restored on the Transaction Detail Screen

We improved rule processing speed by changing how non-triggered rules were logged. While this delivered significant performance benefits, it meant that non-triggered rules were no longer shown in PayControl. After receiving feedback that visibility of these rules is important, we have updated the UI to once again display non-triggered rules. This update sources them in a new way, ensuring you have the information needed while the performance improvements remain in place.

Applicability

Enablement

No enablement required.

Technical Info

Previous functionality has been restored.

PECP-777: PayControl API Documentation Upgrade for OpenAPI 3.0.0 Compatibility

The PayControl API documentation page has been updated to support and correctly render OpenAPI 3.0.0 specifications. This change was required following the upgrade to Java 21 and Apache Camel 4.10, which replaced the deprecated camel-swagger-java module with camel-openapi-java. The PayAPI endpoint now generates OpenAPI 3.0.0 JSON, and PayControl has been adapted to display this documentation format properly.

This update ensures that clients and integrators have access to accurate, up-to-date API documentation in the industry-standard OpenAPI 3.0.0 format. It improves developer experience, reduces confusion, and supports ongoing integration and compliance needs.

Applicability

Enablement

NA.

Technical Info

The API documentation page in PayControl now displays OpenAPI 3.0.0 specifications, replacing the previous Swagger 2.0 format.

PECA-822: PayApi, SecureAPI v1 and v2: misleading generic error message if PKS responds with 'weak pin detected'

This update improves error handling by ensuring that specific errors (for example, weak PINs) are now shown clearly instead of being replaced with generic messages. This gives more accurate information and makes issues easier to understand and resolve.

Applicability

Enablement

NA.

Technical Info

By using the specified endpoints for setting the PIN, we previously returned an invalid generic error ID along with the generic description. With this change, the proper error ID is now returned for all weak PIN scenarios.

All weak PIN scenarios in sc_set_pin (v1 and v2) will now consistently return error “Please use a strong pin” (Error ID 1301).

CLR-1005: Improved Handling of Dispute Re-Presentments for Internal Ledger Clients

To prevent negative account balances during dispute cycles, we have enhanced how second presentments (re-presentments) are processed for clients using internal ledger configurations.

For dispute-related re-presentments the system now logs the re-presentment without posting a deduction, ensuring account balances remain unaffected.

Applicability

Enablement

NA.

Technical Info

NA.

PECA-765: Track Format Updated to support for 8-Digit BIN

This release ensures that card data generated via the GenerateManufacturerCard job for client’s with 8 digit BIN adheres to the track formats defined for their 8-digit BIN. The system will now validate and enforce the specified Track 1 and Track 2 formats during card manufacturing.

Applicability

Enablement

Clients need to review their embossing/personalization workflows to confirm alignment with the enforced format.

Technical Info

Before: Cards were generated in a different format than defined (e.g., unexpected output in Track 1, Track 2, and Chip Track 2).

Now: The system enforces the following track structure for all cards:

Track 1 = KPPPPZZCCCZZZZZZ

Track 2 = KPPPPZZZZZCCC

Any deviations are prevented at the generation stage, ensuring correct embossing and personalization file output.

DEFECT-3838: Use dynamic mapping of ISO8583 standard response code (DE39) for MAMBU error reason code

In the existing version, Mambu error reason codes were mapped hardcoded and only limited to two ISO 8583 standard response code.

Current mapping details

With this feature we can configure and map to suitable DE39 that corresponds with the MAMBU error reason code.

Applicability

Enablement

When using the new feature for dynamic response code mapping, a new DE39 (response code) will be included in the FAST message. Please note that this response code must be agreed with you in advance.

If no new mapping is configured, there will be no impact. The system will continue to use the existing response code mapping by default

Technical Info

NA.