Release notes: Banking.Live 3.3
PECA-848: Reset ATC on Card Renewal/Replacement
This feature ensures that the Application Transaction Counter (ATC) is reset whenever a card is renewed or replaced through our Card Issuance APIs. Resetting the ATC aligns with EMV standards and is critical for maintaining transaction integrity, fraud prevention, and cryptographic consistency during the card lifecycle. When a card is renewed or replaced via our Card Issuance APIs (v1 & v2), the ATC is now automatically reset to the starting value (0). This feature: Prevents false declines & noise in fraud rules: Many issuer auth systems expect the ATC to start over for newly issued cards; this fix avoids mismatches. Stronger replay protection & traceability: A fresh, sequential ATC per reissued card supports EMV cryptogram integrity. Operational clarity: Removes the need for workarounds introduced after defects (e.g., temporary ATC checks disabled for tokenized transactions).
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Core-API |
Enablement
No changes required to client payloads, response handling, or workflows. Behavior is automatic post-renewal/replacement.
Technical info
Works with both renewal endpoints below; no request/response contract changes. Card Renewal Card Renewal V2 The reset is executed automatically after a successful renewal/replacement operation.
PECA-857: VTS: Configurable Decrypted AdditionalMessageData field in VTS Notifications
This enhancement introduces the ability to receive decrypted tokenization payloads in notifications for selected VTS-related APIs. When encryptedData is present and the feature is enabled for a client, the platform will automatically decrypt eligible non-PCI fields and include them as decryptedData within the notification’s {{AdditionalMessageData}} block. Clients who choose to opt in will gain access to richer tokenization data, which can significantly improve fraud detection, investigation workflows, and overall insight into token events. This means all relevant data exchanged between VTS and Paymentology can now be surfaced directly to the client. Clients who do not wish to receive decrypted data can simply keep the configuration flag disabled, and their current integration and notification behaviour will remain unchanged.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | Visa | NA | Core- API |
Enablement
If you wish to have this feature enabled, please contact our customer support at https://support.paymentology.com/.
Technical info
Decryption support and inclusion of decryptedData in notifications is implemented for these VTS-related APIs: pws_vts_approve_provisioning pws_vts_check_eligibility pws_vts_retrieve_stepup_methods pws_vts_send_passcode pws_vts_token_changed
