• Release date: 2026-03-09
• Release status: Deployed to UAT
• Version: AN_BALPH2_V5

Highlights

• Admin Portal Integration of Underwriting Evaluations (AN-32769) – Underwriting as a step in quick onboarding/edit workflows; display summary, timeline events, application versions.
• Account holder and Balance account Updates (AN-44059) – Account summary page updated with Application data.
• Enabling Application Acceptance (AN-44008 et al.) – Emulate Apply portal; create application from Sub-merchant; perform underwriting evaluations; approve with justifications.
• Technology Backlog items (AN-45215, AN-45211) – Dynatrace logs enabled in Balance Account Transaction and Payment Batching modules.

References

• AN-32769
• AN-44059
• AN-44008
• AN-44933
• AN-44934
• AN-45195
• AN-45211

The post UAT Release Notes – Balance Platform Phase II (AN_BALPH2_V5) appeared first on AndDone.

What’s New

The account listing view now surfaces the virtual account processor associated with each account. This gives administrators and internal users visibility into which payment processor backs a given virtual account directly from the listing, without needing to open individual account records.

Why It Matters

You can now identify the virtual account processor for any account at a glance from the listing page, reducing the need to drill into individual records during account review or support workflows.

Adds Multi-Status Filtering to the Applications Search API

What’s New

The Applications Search API now accepts multiple status values as filter parameters in a single request. Previously, queries could only filter by one status at a time, requiring multiple round trips to retrieve applications across different states.

Why It Matters

You can now retrieve applications in multiple statuses — such as pending and under review — in a single API call, simplifying dashboard queries, reporting logic, and any workflow that needs to operate across application lifecycle stages simultaneously.

Changes

Parameter: status filter on GET /applications

Change type: Modified — now accepts multiple values (previously limited to a single status value per request)

Handles Remediation Actions Triggered by Payment Processor Events

What’s New

The platform now listens for and processes remediation-related events from the payment processor and automatically triggers the corresponding remediation actions on the affected accounts or applications. This closes a gap where processor-side compliance or verification events had no automated handler on the platform side.

Why It Matters

Before this change, remediation actions flagged by the payment processor required manual intervention to apply on the platform. The platform now responds to these events automatically, reducing operational lag and the risk of accounts remaining in an unresolved remediation state.

Enforces a Single Individual Restriction for Sole Proprietorship and Individual Organization Subtypes

What’s New

When creating or updating an application for an organization with a subtype of Sole Proprietorship or Individual, the platform now enforces that only a single individual can be associated with that organization. Attempts to associate more than one individual with these subtypes are rejected with a validation error.

Why It Matters

Before this change, it was possible to associate multiple individuals with organization types that are legally defined as single-person entities, leading to data inconsistencies. You can now rely on the API to enforce this structural constraint automatically rather than managing it in application-layer validation.

Synchronizes Merchant Profile Data With Application Data

What’s New

Merchant profile records are now kept in sync with the data held in their associated application. When application data is updated — such as business details or contact information — those changes are reflected on the merchant record automatically, eliminating drift between the two data sources.

Why It Matters

Previously, merchant and application records could fall out of sync after an application update, requiring manual reconciliation. You can now treat the application as the authoritative source of merchant data and trust that the merchant record reflects the latest state automatically.

Fixes Balance Account Resolution Failures for Test Environments

What’s New

An issue that caused “balance account not found” errors in test Adyen environments has been resolved. The platform now correctly resolves balance accounts in test configurations, allowing end-to-end testing of balance account flows without encountering spurious lookup failures.

Why It Matters

Before this fix, balance account operations in test environments would intermittently fail with a not-found error even when the account existed, blocking integration testing and QA workflows. Test environment balance account flows now resolve reliably.

Adds Event Handling for Underwriting Evaluation Mappings

What’s New

The platform now includes an event handler that listens for underwriting evaluation events from the external underwriting service and maps them to the corresponding internal application states. This creates a real-time bridge between the underwriting service’s event stream and the platform’s application lifecycle.

Why It Matters

Before this change, underwriting evaluation outcomes were not automatically reflected in application state — status updates required polling or manual intervention. You can now rely on event-driven updates to keep application state current as underwriting evaluations complete.

Correlates Completed Evaluation Events With Application Artifacts

What’s New

When an underwriting evaluation completes, the platform now automatically correlates the resulting evaluation record with the relevant application artifacts — such as documents and submitted data — already on file. This linkage makes it possible to trace which application inputs contributed to a given underwriting outcome.

Why It Matters

You can now retrieve a completed evaluation alongside its associated application artifacts in a unified view, rather than manually cross-referencing separate records to reconstruct the full picture of an underwriting decision.

Adds Entity Filtering to the Underwriting Summary API

What’s New

The Underwriting Summary API now supports filtering by entity, allowing callers to retrieve underwriting summaries scoped to a specific legal entity within an application. Previously, the API returned underwriting data at the application level only, with no way to narrow results to a particular entity.

Why It Matters

You can now query underwriting summaries for a specific entity — such as a business owner or subsidiary — without retrieving and filtering the full application-level response in your own code.

Changes

Parameter: entity_id filter on the Underwriting Summary endpoint

Change type: Added — filters summary results to the specified entity

Adds Entity Filtering to the Underwriting Summary Events API

What’s New

The Underwriting Summary Events API now accepts an entity filter, enabling callers to retrieve the underwriting event history for a specific entity within an application. This mirrors the entity filtering capability added to the Underwriting Summary API in this release.

Why It Matters

You can now fetch the underwriting event timeline for a single entity directly from the API, making it easier to build audit views or investigate underwriting activity for a specific person or organization tied to an application.

Changes

Parameter: entity_id filter on the Underwriting Summary Events endpoint

Change type: Added — filters event results to the specified entity

Adds Owner, Grantor, and Role Assignment Management for Application Entities

What’s New

A new set of capabilities supports managing legal entity relationships within an application. Administrators can now assign an owner to a legal entity, retrieve all entity owners for a given application, assign grantors across all entities in an application, and manage role assignments for individual entities. Together, these operations cover the full lifecycle of entity relationship management needed to prepare an application for approval.

Why It Matters

Before this change, there was no supported way to programmatically assign or retrieve ownership and role structures for entities within an application, blocking the application acceptance workflow. You can now fully configure entity roles and ownership through the API as part of building an end-to-end application submission and approval flow.

Changes

The following endpoints are newly added to support entity relationship management on applications:

POST /applications/{id}/entities/{entityId}/owner — Added. Assigns an owner to a specific legal entity.

GET /applications/{id}/entity-owners — Added. Returns all entity owners associated with the application.

POST /applications/{id}/grantors — Added. Assigns grantors to all entities within the application.

PUT /applications/{id}/entities/{entityId}/roles — Added. Sets role assignments for a specific entity.

Release Date: Feb 26th, 2026

Release Status: Deployed to PROD

This release bundle primarily consists of Alloy underwriting Integration updates, Onboarding Enhancements and Enabling Application Acceptance on AndDone platform. This also includes some UX enhancements to admin portal and bug-fixes as identified during the development cycle.

Onboarding Enhancements

(AN-43267, AN-43031, AN-43285, AN-42551, AN-44569,AN-43228)

Virtual Account Processor on Account Listing
Search Applications API supporting multiple status filters
Handle Remediations actions from Adyen events
Restrict single Individual for Organization of subtypes “Sole Proprietorship” and “Individual”
Synchronize merchant data with Application data
Addressed Balance account not found issue for Test Adyen

Client Facing Impact: No

Alloy Underwriting Integration Updates

(AN-43709, AN-44223, AN-44298, AN-44299)

Event handler for Alloy evaluation event mappings
Correlate completed_evaluation events with application artifacts
Underwriting summary API enhancements with entity filters
Underwriting summary Events API enhancements withentity filters

Client Facing Impact: No

Enabling Application Acceptance

(AN-43138, AN-44007, AN-43139, AN-43135 )

Assign owner to a legal entity of an Application
Fetch all entity owners for an Application
Assign grantors to all entities of an AndDone application
Manage entity roles and role assignments for an AndDone Application

Client Facing Impact: No

The post PROD Release Notes – Balance Platform Phase II (AN_BALPH2_V4) appeared first on AndDone.

What’s new

A new Payments section is now available on the Ally Portal, giving Allies a dedicated view of payments received by their merchants. The section includes filtering and search options to help Allies analyze payment activity across their merchant portfolio.

Why it matters

You can now view and analyze merchant payment data directly from the Ally Portal without needing to rely on separate reporting tools or API calls. Allies have a single, purpose-built interface for monitoring payment activity across all their merchants.

Converts Ally Monthly Profitability Report to merchant-level summary

What’s new

The Ally Monthly Profitability Report CSV has been restructured from a transaction-level report to a merchant-level summary, broken down by payment method (ACH, Debit, Credit). The file is now significantly smaller and easier to open while retaining all profitability insights.

Why it matters

Before this change, the report contained one row per transaction, making it unwieldy for allies with high transaction volumes. The new format condenses data to the merchant level, making the file practical to open and analyze in standard spreadsheet tools.

Exposes secure Payment Intent Timeline API to Ally users

What’s new

Allies can now access the existing secure Payment Intent Timeline API using an Ally user API key, with an optional app key. The API enforces proper authorization boundaries, returning appropriate errors when an Ally attempts to access payment intents outside their merchant portfolio.

Why it matters

You can now trace the full timeline of payment intents for your merchants directly via the Ally API, enabling deeper transaction analysis without requiring custom integrations or elevated access credentials.

Introduces Ally Portal notification APIs for listing and retrieving notifications

What’s new

Two new Ally Portal notification APIs are now available: one to list all notifications configured for an Ally, and one to retrieve the full details — including templates — for a specific notification by ID. These APIs mirror the existing Merchant notification API contract.

Why it matters

Allies can now programmatically inspect their notification configurations, making it easier to audit, debug, and integrate notification management into internal tooling or workflows.

Adds notification status management APIs for Ally Portal

What’s new

New Ally Portal APIs allow Allies to enable or disable individual notifications and pause or unpause all notifications in a single call. This gives Allies self-service control over notification delivery without requiring admin intervention.

Why it matters

Before this change, Allies had no programmatic way to manage the active state of their notifications. You can now build controls into your own tooling to pause notifications during maintenance windows or enable them as part of onboarding flows.

Adds API to list all template variables for Ally notification templates

What’s new

A new Ally Portal API returns all available template variables for a given notification template. This allows Allies to discover what variables are supported when customizing notification content, without needing to reference separate documentation.

Why it matters

You can now query available variables at runtime when building template customization UIs or automation, reducing guesswork and the risk of referencing unsupported variables in notification templates.

Introduces distribution list management APIs for Ally Portal notifications

What’s new

New Ally Portal APIs allow Allies to retrieve and update distribution lists (DLs) for notifications, including the email addresses within each list. The API contract matches the existing Merchant notification distribution list APIs for consistency.

Why it matters

You can now manage who receives Ally notifications programmatically, using the same patterns already established for Merchant notifications. This makes it straightforward to keep distribution lists in sync with your own contact management systems.

Adds template update and creation APIs for Ally Portal notifications

What’s new

New Ally Portal APIs support updating existing notification templates — both plain text and HTML — and creating new templates. These APIs are aligned with changes initiated from the TinyMCE editor and mirror the behavior of the existing Merchant-side template APIs.

Why it matters

Allies can now manage the full lifecycle of their notification templates via API, enabling programmatic template updates as part of onboarding flows or content management workflows.

Extends secure merchant onboarding API with optional shopper statement field

What’s new

The secure merchant onboarding API now accepts an optional shopperStatement field, allowing Allies to configure shopper statements for their merchants at the time of onboarding. The field applies the same validations as existing shopper statement configurations.

Changes

Why it matters

You can now include shopper statement configuration as part of a single onboarding API call, rather than requiring a separate follow-up update after the merchant is created.

Aligns Ally sub-merchant feature inheritance with Ally feature configuration

What’s new

Ally sub-merchant feature inheritance has been corrected so that features enabled or disabled at the Ally level are reflected consistently across all relevant Admin portal views — including the sub-merchant details page, the confirm edit screen, and the features access page.

Why it matters

Before this fix, enabling or disabling a feature at the Ally level could result in inconsistent states across portal views, making it difficult to verify what was actually configured for a sub-merchant. Feature state is now reliable and consistent wherever it is displayed.

Migrates Domain project monitoring from Lumigo to Dynatrace

What’s new

Monitoring for Domain project services — including MerchantKeyExpirationExecutor, MerchantSettingsCacheSyncService, and Domain.API — has been migrated from Lumigo to Dynatrace. The migration includes agent setup, traces, metrics, dashboards, alerts, and removal of existing Lumigo configuration.

Why it matters

Observability for Domain project services now runs through Dynatrace. Teams relying on Lumigo dashboards or alerts for these services should update their monitoring workflows accordingly.

Migrates Infrastructure project monitoring from Lumigo to Dynatrace

What’s new

Monitoring for key Infrastructure services — including InfrastructureAllyHandler, InfrastructureMerchantHandler, and Infrastructure.API — has been migrated from Lumigo to Dynatrace, standardizing observability across the platform.

Why it matters

Infrastructure service monitoring now runs through Dynatrace. Teams using Lumigo for alerts or dashboards on these services should transition their observability setup to Dynatrace.

Continues Transaction project monitoring migration to Dynatrace (Part 3)

What’s new

Additional Transaction project services — including TransactionAllyHandler and related components — have been migrated from Lumigo to Dynatrace, ensuring consistent tracing and metric coverage across the Transaction project.

Why it matters

This continues the incremental migration of Transaction project monitoring to Dynatrace. Teams should verify that alerting and dashboard coverage for TransactionAllyHandler is now configured in Dynatrace.

Completes Transaction project monitoring migration to Dynatrace (Part 5)

What’s new

This release completes additional migration steps for Transaction project monitoring in Dynatrace, including dashboard and alert parity with the previous Lumigo setup.

Why it matters

The Transaction project monitoring migration to Dynatrace is now at full parity with the previous Lumigo configuration. Any remaining Lumigo references for this project can be decommissioned.

Migrates Invoice project Lambdas to ARM64 (Graviton) processor

What’s new

Invoice project Lambda functions — including PaymentLinkHandler, ReceivableHandler, and MerchantHandler — have been migrated from x86 to ARM64/Graviton processors. This is an infrastructure-level change with no impact on API behavior or response contracts.

Why it matters

The migration to Graviton reduces compute costs and improves performance for Invoice project functions. No changes to integration code are required.

Fixes repeated NACHA notification emails after scheduler run

What’s new

A bug was causing NACHA notification emails to be sent repeatedly every 15 minutes for the same transaction batch after the 4:30 AM IST scheduler run. This has been resolved so that only the expected single notification is sent per transaction batch.

Why it matters

Before this fix, merchants and recipients were receiving duplicate NACHA emails in rapid succession, creating confusion and potential compliance concerns. Notification delivery is now consistent with expected behavior.

Fixes notifications not triggering for transaction events on QAT

What’s new

A defect was preventing subscribed users on QAT from receiving notifications for transaction events — including Failed and Authorization event types. This has been resolved and expected notification delivery has been restored.

Why it matters

Before this fix, transaction event notifications were silently failing on QAT, making it impossible to validate notification behavior during testing. Notifications now fire correctly for all subscribed event types.

Fixes page becoming unresponsive when entering Shift + Hyphen in Last Name field

What’s new

A UI bug on the Create Payment Link page caused the page to become unresponsive when a long numeric string followed by Shift + Hyphen was entered in the Last Name field. This has been resolved and the field now handles all input combinations without freezing.

Why it matters

Before this fix, specific keyboard input sequences on the Create Payment Link page could lock up the UI entirely, blocking the user from completing the payment link creation flow. The page now remains responsive under all input conditions.

Production Release Notes – Ally Management V13 (AN_ALMGMT_V13)UAT Release: Ally Management V13 (AN_ALMGMT_V13) Release Date: Feb 9, 2026 Release Status: Production

Summary

Ally Portal Payments & Reporting – Allies can now use a dedicated Payments section on the Ally Portal to view merchant payments. Payment intent timelines are also exposed via secure Ally APIs for deeper transaction analysis.

Ally Notification Self-Service – A full set of Ally Portal notification APIs is introduced, which will help in enabling Ally Portal to list notifications, manage statuses (including pause/unpause all), work with template variables, maintain distribution lists, and update/create templates, aligned with existing Merchant notification behavior.

Configuration, Inheritance & Observability – Ally sub-merchant onboarding and feature inheritance are improved to align configurations across portals, while monitoring is standardized by migrating multiple projects from Lumigo to Dynatrace. Additional UAT/production defects around notifications, NACHA emails and UI responsiveness are also addressed.

────────────────────────────────────────────

Ally Portal | Payments Section (AN-37771)

Provides a dedicated Payments section on the Ally Portal so Allies can view payments received by their merchants and analyze them using filters and search options.

Client Facing: Yes

────────────────────────────────────────────

[CR] Ally Fees | Changes to Ally profitability report.csv (AN-33858)

Changes the Ally Monthly Profitability Report from a transaction-level report to a merchant-level summary per payment method (ACH, Debit, Credit), making the file smaller and easier to open while preserving profitability insights.

Client Facing: Yes

────────────────────────────────────────────

Ally Payments | Secure Payment Intent Timeline (AN-36488)

Enables Allies to access the existing secure Payment Intent Timeline API using an Ally user API key (app key optional) so that they can trace payment intents for their own merchants and receive appropriate authorization errors otherwise.

Client Facing: No

────────────────────────────────────────────

Ally Portal Notification APIs | Get Notifications & Notification by Id (AN-39507)

Introduces Ally Portal notification APIs to list all notifications configured for an Ally and retrieve the details (including templates) for a specific notification, aligned with the Merchant notification APIs.

Client Facing: No

────────────────────────────────────────────

Ally Portal Notification APIs | Update status of a notification (AN-39509)

Adds Ally Portal notification APIs that allow Allies to enable or disable individual notifications and pause or unpause all notifications, giving them self-service control over notification delivery.

Client Facing: No

────────────────────────────────────────────

Ally Portal Notification APIs | List all Template Variables (AN-39511)

Provides an Ally Portal API to list all template variables for a given notification template so Allies can understand what variables are available when customizing notification content.

Client Facing: No

────────────────────────────────────────────

Ally Portal Notification APIs | Distribution List (Get & Put) (AN-39512)

Introduces Ally Portal APIs to create and manage distribution lists (DLs) for notifications, allowing Allies to retrieve and update email addresses within a DL using the same contract as Merchant notification APIs.

Client Facing: No

────────────────────────────────────────────

Ally Portal Notification APIs | Update template (AN-39513)

Adds Ally Portal APIs for updating existing templates (plain text and HTML) and creating new templates for Ally notifications, supporting changes initiated from the TinyMCE editor and mirroring Merchant-side behavior.

Client Facing: No

────────────────────────────────────────────

[CR] – Ally Submerchant Onboarding | Secure Onboarding API (Create) – Shopper Statement (AN-33725)

Extends the secure merchant onboarding API with an optional shopperStatement field so Allies can configure shopper statements for their merchants via API, with the same validations as existing shopper statements.

Client Facing: Yes

────────────────────────────────────────────

Ally Submerchant Feature Inheritance (AN-42726)

Aligns Ally sub-merchant feature inheritance with Ally feature configuration so that enabled features appear consistently across Admin portal views (sub-merchant details, confirm edit screen, and features access page) when Ally features are enabled or disabled.

Client Facing: Yes

────────────────────────────────────────────

Migrate Monitoring from Lumigo to Dynatrace – Domain Project (AN-38782)

Migrates monitoring for Domain project services (such as MerchantKeyExpirationExecutor, MerchantSettingsCacheSyncService and Domain.API) from Lumigo to Dynatrace, including agent setup, traces, metrics, dashboards, alerts and removal of existing Lumigo configuration.

Client Facing: No

────────────────────────────────────────────

Migrate Monitoring from Lumigo to Dynatrace – Infrastructure Project (AN-38781)

Migrates monitoring for key Infrastructure services (InfrastructureAllyHandler, InfrastructureMerchantHandler, Infrastructure.API, etc.) from Lumigo to Dynatrace, standardizing observability across the platform.

Client Facing: No

────────────────────────────────────────────

Migrate Monitoring from Lumigo to Dynatrace – Transaction Project – Part 3 (AN-41672)

Continues migration of Transaction project services to Dynatrace (including TransactionAllyHandler and related components), ensuring consistent tracing and metric coverage.

Client Facing: No

────────────────────────────────────────────

Migrate Monitoring from Lumigo to Dynatrace – Transaction Project – Part 5 (AN-41717)

Completes additional migration steps for Transaction project monitoring in Dynatrace, including dashboards and alert parity with the previous Lumigo setup.

Client Facing: No

────────────────────────────────────────────

Migrate Invoice Project Lambdas to ARM64 (Graviton) Processor (AN-41760)

Migrates Invoice project Lambdas (such as PaymentLinkHandler, ReceivableHandler and MerchantHandler) to ARM64/Graviton to improve performance and cost efficiency.

Client Facing: No

────────────────────────────────────────────

NACHA notification emails triggered every 15 minutes after scheduler run at 4:30 AM IST for the same transaction (AN-44537)

Fixes an issue where NACHA notification emails were repeatedly sent every 15 minutes for the same transaction batch after the scheduler run, ensuring only the expected notification is sent.

Client Facing: No

────────────────────────────────────────────

Notifications Not Triggering for Failed, Authorization or any Transactions event type on QAT (AN-44539)

Resolves a defect where subscribed users on QAT were not receiving notifications for transaction events (such as Failed or Authorization), restoring expected notification behavior.

Client Facing: No

────────────────────────────────────────────

[UAT] – Page Becomes Unresponsive When Entering Shift + Hyphen in Last Name Field (AN-40941)

Fixes a UI issue on the Create Payment Link page where entering a long numeric string followed by Shift + Hyphen in the Last Name field caused the page to become unresponsive.

Client Facing: Yes

The post Production Release Notes – Ally Management V13 (AN_ALMGMT_V13) appeared first on AndDone.