What’s new

A new API service is available in Premium Finance Lite that allows a manual sync to be triggered for updating IPFS GA (General Agent) data in the system for a specific merchant. This gives operators an on-demand alternative to waiting for the regularly scheduled cron job to run.

Why it matters

You can now trigger a GA sync programmatically at any time, making it easier to recover from data discrepancies or push updates immediately after a GA change in IPFS without waiting for the next scheduled run.

Adds manual GA sync button to the Admin Portal

What’s new

A new button has been added to the PF Lite feature page in the Admin Portal, allowing admins to trigger a manual GA sync directly from the UI at any time without waiting for the regular cron job.

Why it matters

Before this change, initiating a sync required either waiting for the scheduled job or triggering the API directly. Admins can now initiate a sync on demand from the portal without any technical intervention.

Introduces automated GA sync for Premium Finance Lite

What’s new

A new scheduled API service has been introduced that runs automatically at a configured time, retrieves all GAs from IPFS, and syncs them into the system for each relevant merchant. This replaces the need for manual intervention to keep GA data current on a routine basis.

Why it matters

GA data in the system now stays automatically up to date with IPFS on a scheduled basis, reducing the risk of stale GA records being used in quote creation and other downstream flows.

Adds GA search API by name

What’s new

A new API service allows callers to search for a General Agent by their unique name. This provides a targeted lookup mechanism for GA records without needing to retrieve the full list.

Why it matters

You can now look up a specific GA by name in a single API call, making it straightforward to integrate GA selection into quote creation flows or other workflows that require identifying a GA by name.

Integrates GA search into the quote creation UI

What’s new

A dropdown search field has been added to the quote creation flow in the UI, allowing users to find and select a General Agent to associate with a new quote. The field is powered by the GA search API and supports searching by GA name.

Why it matters

Before this change, there was no UI mechanism to associate a GA with a quote at creation time. Users can now search for and add a GA directly within the quote creation workflow without leaving the page.

Adds GA support to the Draft Quote JWT API

What’s new

The existing Draft Quote API has been updated to accept a GA object in the policy request body, enabling GA details to be included when creating a draft quote. The API for fetching quote details has also been updated to return the GA in the policy object.

Why it matters

Integrations that create draft quotes via the JWT API can now include GA information as part of the initial quote creation request, and retrieve it back when fetching quote details, without requiring a separate update step.

Changes

Maps GA object to quote creation UI fields

What’s new

The GA object returned from the API is now mapped to the corresponding UI text fields in the quote creation flow, enabling both adding and displaying a GA when creating or viewing a quote.

Why it matters

GA data entered or retrieved via the API is now consistently reflected in the quote creation UI, ensuring that what is stored in the system matches what the user sees and interacts with on screen.

Includes GA details in quote generation

What’s new

The existing quote creation flow has been updated to include GA details in the generated quote. When a GA is associated with a quote, that information is now carried through to the final quote output.

Why it matters

Before this change, GA information entered during quote creation was not reflected in the generated quote. GA details are now included end-to-end, from selection through to the final quote document.

Displays GA on saved policies in search results

What’s new

When a GA is added during quote creation, it is now mapped to the resulting policy and displayed when that policy is retrieved via the saved policy search. This ensures GA association is visible throughout the policy lifecycle, not just at quote time.

Why it matters

Before this change, a GA associated with a quote was not surfaced when searching saved policies, making it difficult to identify which GA was linked to a given policy. GA information is now consistently visible at both the quote and policy level.

UAT Release – GA Support to Premium Finance Lite (AN_GASPFL_V1)

Release Date: Mar 31, 2026

Release Status: Deployed to UAT

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

Create GA Manual Sync in Existing Premium Finance Lite [AN-46447]

An API service in premium finance lite to perform manual sync for updating IPFS GA in our system for a merchant.

Client Facing: No

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

Integrate Manual Sync API in Admin Portal [AN-46462]

UI to display a button on PF lite feature page to perform a manual sync at any time without waiting for regular Cron job.

Client Facing: Yes

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

Create Auto Sync for GA in Premium Finance Lite [AN-45696]

An API service which will execute on a given time and retrieve all GAs from IPFS and sync in our system for a specific merchant.

Client Facing: No

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

Create Get API for GA with Search by Name [AN-45749]

An API service which will be able to search a GA with its unique name.

Client Facing: No

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

Integrate Get GA Details to Fetch and Search GA [AN-46419]

UI to display a dropdown search option to find GA and add it in quote creation.

Client Facing: Yes

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

Add GA for Draft Quote in JWT API [AN-45768]

Update existing draft quote to support GA in the policy request for quote creation.

Client Facing: No

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

Return GA in the Draft JWT API [AN-46116]

Update existing API to fetch quote details for GA in policy object.

Client Facing: No

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

Integrate GA Object in Policy Details [AN-46394]

UI to map GA Object with UI text field for Add and get GA in quote creation.

Client Facing: Yes

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

Generate a Quote with GA Object [AN-46888]

Update existing quote creation to support GA details in the generated quote.

Client Facing: Yes

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

Search Saved Policies Should Show GA When Added [AN-47244]

The GA added while quote creation should be mapped to Policy and should be displayed when policy is searched.

Client Facing: Yes

The post UAT Release – GA Support to Premium Finance Lite (AN_GASPFL_V1) appeared first on AndDone.

Release date: March 26, 2026

Adds Email Notifications for Sub-Merchant Lifecycle Events

What’s New

Allies can now receive email notifications whenever key lifecycle events occur for the sub-merchants they manage. Covered events include onboarding, activation, deactivation, and other merchant status changes. This gives Allies a passive, real-time awareness of their portfolio without requiring them to actively check the portal.

Why It Matters

Before this change, Allies had no automated way to learn when a sub-merchant’s status changed — they had to log in and check manually. You can now rely on email alerts to stay informed about merchant lifecycle activity as it happens, reducing the risk of missing critical changes.

Sends Notifications When Webhook Configurations are Added or Removed

What’s New

Allies receive an email notification whenever a webhook is added to or deleted from their account. This ensures that any change to webhook configuration — whether intentional or unexpected — is surfaced to the Ally promptly.

Why It Matters

Webhook changes can silently break downstream integrations if they go unnoticed. You can now detect configuration changes immediately and investigate or respond before any integration impact escalates.

Restricts Merchant Management Webhook Module to IPFS Allies Only

What’s New

The Merchant Management webhook module in the Ally Portal is now only visible and accessible to Allies who are set up as IPFS Allies. Non-IPFS Allies no longer see this module in their webhook subscription interface.

Why It Matters

Previously, non-IPFS Allies could see webhook modules that were not applicable to their account type, leading to confusion. You can now expect the webhook subscription UI to reflect only the options relevant to your Ally configuration.

Fixes Recurring Scheduler Errors Caused by Special Characters in Merchant References

What’s New

The transaction correction scheduler previously failed every 30 minutes when processing records where the Merchant Reference field contained special characters, including single quotes. The underlying SQL update logic has been corrected to handle these characters safely.

Why It Matters

Transactions containing special characters in the Merchant Reference field were getting stuck and never advancing to the correct status. Those transactions now process reliably, and the scheduler no longer produces recurring errors.

Displays Split Reference Identifiers in the Payment Details UI

What’s New

When a payment is split into multiple portions, each split’s merchant-provided reference identifier is now stored and displayed in the UI. This appears in both the standard payment intent flow and the secure payments flow, within the split payment details view.

Why it Matters

You can now verify and cross-reference each portion of a split payment against the merchant-assigned reference — useful for reconciliation, auditing, and tracking individual splits through your own systems.

UAT Release: Ally Management V15 (AN_ALMGMT_V15) Release Ticket:

Release Date: Mar 26, 2026

Release Status: Done

Summary

Ally Sub‐merchant Activity Notifications – Ally notification capabilities are extended so Allies can receive email updates about key sub‐merchant activities (such as onboarding, activation, deactivation and other changes), helping them stay informed about merchant lifecycle events.

Ally Portal Webhooks & Admin UI Consistency – The Ally Portal webhook subscription experience is refined so IPFS‐specific modules are no longer shown to non‐IPFS Allies, and Admin portal Ally table visuals are aligned for a more consistent UI.

Transactions, Monitoring & Front‐end Hardening – Transaction correction handling is made robust for special characters, Additional UI support is added for displaying split references on split payments.

AN-45805: UAT Release – Ally Management (AN_ALMGMT_V15)

POST DEPLOYMENT MONITORING

Ally Notifications | Sub‐merchant related updates (Epic AN-41458) Enables Allies to receive email notifications for activity related to their sub‐merchants (such as activations, deactivations or other updates), so they are aware of important lifecycle changes for the merchants they manage.

Client Facing Impact: YES

Ally Notifications | Ally webhook Added/deleted (AN-36995) Sends Ally notifications when a webhook is added or deleted for an Ally, ensuring Allies are informed whenever webhook configurations they rely on are changed.

Client Facing Impact: YES

Ally Portal | Hide Merchant Management Webhook Module (Non‐IPFS Allies) (AN-46091) Restricts the Merchant Management webhook module

Client Facing Impact: YES

in Ally Portal so it is only listed and available for IPFS Allies, preventing non‐IPFS Allies from seeing or subscribing to IPFS‐specific webhook modules.
[PROD] – Console statement “Angular is running in development mode.” is visible on production environment (AN-46887)
Cleans up the UI console in production so the “Angular is running in development mode.” message and related development‐mode logs are no longer shown, aligning browser console behavior with production standards.

Client Facing Impact: NO

Regression Ally: Inconsistent UI on Allies table in Admin portal (AN- 46404)

Fixes a UI regression on the Allies table in the Admin Portal by restoring the missing divider line above the Actions menu, ensuring a consistent and polished table layout.

Client Facing Impact: NO

Encountered the scheduler error Transaction Entity Correction Handler for every 30 minute. (AN-45359)
Fixes an issue in Transaction Entity Correction Handler where SQL updates failed when the Merchant Reference field contained certain special characters (including single quotes), preventing recurring scheduler errors and ensuring affected transactions move to the correct status without failures.

Client Facing Impact: NO

Ability to display Split Reference in UI (AN-44749) Stores and displays each split’s merchant‐provided reference in the UI for split payment details (via existing payment intent and secure payments flows) so users can verify and track the reference associated with each split portion of a payment.

Client Facing Impact: YES

The post Production Release Notes – Ally Management V15(AN_ALMGMT_V15) appeared first on AndDone.

• Release date: 2026-03-26
• Release status: Deployed to UAT
• Version: AN_OUTPAY_V9

Highlights

• Outbound Payment Notifications – New Event Name ‘Outbound Payments’ under Notifications; event types: Vendor Approved, Vendor Denied, Vendor Approval Status Changed by Admin.
• Vendor Approval Notification Template – Email includes event timestamp, Merchant DBA, Company Name, Vendor Name, Vendor ID, and Legal Entity Type.
• Outbound Payment Status Notifications – Merchants receive notifications for status changes: Printed, Mailed, Transit, Delivered, Cancelled, Failed.
• Merchant Configuration – Merchants can enable/disable notifications, edit email templates, and update distribution lists via Merchant Portal.

The post UAT Release Notes – Outbound Payments (AN_OUTPAY_V9) appeared first on AndDone.

What’s New

You can now create, read, update, and delete Coverage entities through the API. Additional actions include status updates, as well as lock and unlock controls to manage editability. The system also supports both manual and scheduled synchronization with external data sources to keep coverage data current.

Why It Matters

You no longer need separate workflows or tools to manage coverage data. You can now fully manage Coverage entities programmatically and keep them in sync automatically, reducing manual overhead and data inconsistencies.

Adds Full CRUD Support for Policy Entities

What’s New

The API now supports full lifecycle management for Policy entities, including create, read, update, and delete operations. It also introduces manual and scheduled synchronization with external policy data sources to ensure records remain up to date.

Why It Matters

You can now manage policies entirely through the API without relying on external processes. Automated sync ensures your policy data stays consistent across systems with minimal effort.

Introduces Admin Portal Data Sync Framework

What’s New

A new data synchronization framework is implemented in the Admin Portal UI. This enables direct interaction with backend entity APIs such as Program, Carrier, Coverage, General Agent, and Broker management.

Why It Matters

You can now trigger and manage data sync operations directly from the UI instead of relying solely on backend processes. This improves visibility and control over how data flows between systems.

Updates OpenAPI Specification Across All Modules

What’s New

The OpenAPI (Swagger) documentation is updated across all modules. This includes standardized naming, consolidated program definitions, improved version metadata, and support for manual sync endpoints.

Why It Matters

You now have a more consistent and accurate API contract. This makes integration easier, reduces ambiguity, and ensures your client applications align with the latest API behavior.

Enforces Required and Unique Alias for QuoteConfig

What’s New

The alias field in QuoteConfig is now mandatory for both create and update operations. The system enforces case-insensitive uniqueness, and requests with missing or duplicate values will fail with validation errors.

Why It Matters

You can rely on alias as a stable and unique identifier across configurations. This prevents duplication issues and improves consistency when referencing QuoteConfig records.

Upgrade

1. Ensure all create and update requests include a non-empty alias field.
2. Validate that the alias is unique (case-insensitive) before sending requests.
3. Update any existing records that may not meet the new requirement.

Enforces Required and Unique Alias for CommsConfig

What’s New

The alias field in CommsConfig is now required for all create and update operations. The API enforces case-insensitive uniqueness and rejects invalid or duplicate values with clear error responses.

Why It Matters

You can now depend on a consistent and unique identifier for communication configurations. This reduces ambiguity and prevents conflicts across records.

Upgrade

1. Update all create and update requests to include the alias field.
2. Ensure alias values are unique across all existing configurations.
3. Handle validation errors for missing or duplicate aliases in your integration logic.

Release Date: UAT Mar 26, 2026

Release Status: Deployed to Production

This release bundle primarily consists of premium finance development for the coverage, policy, and data sync between IPFS and anddone system using the admin portal.

PFTAD | Coverage Management (Entity API) [AN- 28221]

Introduced full CRUD support for Coverage entities (create, update, status update, lock/unlock, delete).
Added manual and scheduled (cron) sync with Datalink Coverages to keep coverage data up-to-date.

Client facing impact: No

PFTAD | Policy Management (Entity API) [AN-28221] Introduced full CRUD support for policy entities (create, read, update, and delete). Added manual and scheduled (cron) sync with Datalink policy to keep data up-to-date.

Client facing impact: No

PFTAD | Admin Portal – Data Sync [AN-38556]
Implemented front-end data sync framework for the Admin Portal
Enables UI integration with new entity-based APIs (Program, Carrier, Coverage, GA, Broker Management).

Client facing impact: Yes

Required PFTAD swagger update for all modules
Updated PFTAD Open API/Swagger specs across all modules, including PF4 → PFTAD renaming, consolidated program definition, added Manual Sync

Client facing impact: No

API, corrected naming, and standardized missing x- version metadata.

[CR] Quote Config – make alias unique and required
Enforced that alias in quote Config is now mandatory for both Create and Update APIs.
Added case-insensitive uniqueness validation for alias ; requests with missing alias return
MISSING_REQUIRED_FIELD and duplicate aliases return DULPICATE_ALIAS .

Client facing impact: No

[CR] CommsConfig – Make alias field required and unique
Enforced that alias in communication Config is now mandatory for both Create and Update APIs; requests without it return MISSING_REQUIRED_FIELD .
Implemented case‐insensitive uniqueness validation on alias ; if the value matches any existing alias , the API returns DUPLICATE_ALIAS .

Client facing impact: No

The post Production Release Notes – PFTAD (AN_PFTADN_V4) appeared first on AndDone.

What’s New

The Admin Portal now supports underwriting as a step within merchant onboarding and merchant edit workflows. Administrators can view a full underwriting summary, a timeline of underwriting events, and all versions of a given application. It is also now possible to associate an existing application with a merchant and view underwriting results for any entity tied to that application.

Why It Matters

Before this change, underwriting data lived outside the Admin Portal, requiring context-switching between systems to assess a merchant’s status. You can now complete underwriting review entirely within the Admin Portal, with full visibility into history, decisions, and application versions in one place.

Updates Account Summary Pages With Application Data

What’s New

The account summary page for account holders and balance accounts now pulls in and displays relevant information sourced from the associated application. This keeps merchant profile data and application data aligned in a single view.

Why It Matters

Previously, account summary pages reflected only the core account data, leaving out context from the application record. You can now see a more complete picture of an account holder’s details without navigating away from the summary page.

Enables End-to-End Application Approval From the Admin Portal

What’s New

Administrators can now manage the full application approval lifecycle directly from the Admin Portal. This includes creating an application from the merchant underwriting view, running underwriting evaluations inline, reviewing an approval panel, approving applications with written justifications, and editing applications in ways that respect their current status.

Administrators can also emulate the applicant-facing portal from within the Admin Portal, making it easier to review and validate the applicant experience without switching interfaces.

Why It Matters

Before this change, approving an application required coordinating across multiple tools or views with no unified workflow. You can now take a merchant from application creation through underwriting evaluation to final approval — with justification on record — entirely within a single interface.

Release Date: Mar 26th, 2026

Release Status: Deployed to Production

This release bundle primarily consists of Alloy underwriting Integration on Admin Portal Onboarding Enhancements supporting Account holder and balance account updates and Enabling Application Approval on AndDone platform. This also includes some UX enhancements to admin portal and bug-fixes as identified during the development cycle.

Admin Portal Integration of Underwriting Evaluations

(AN-32769)

• Underwriting as a step in quick onboarding or edit merchant workflows
• Ability to display Underwriting summary information
• Ability to display Underwriting timeline events
• Ability to associate an application to an existing merchant
• Display underwriting results for an entity associated with an application

Client facing impact: No

Account holder and Balance account Updates

(AN-44059)

• Update account summary page with information from Application

Client facing impact: No

Enabling Application Acceptance

(AN-44008, AN-44933, AN-44934, AN-45444, AN-45445, AN-45195, AN-45196, AN-45739)

• Ability to emulate Apply portal from Admin Portal 
• Ability to create application from Sub-merchant Underwriting view 
• Perform underwriting evaluations from Underwriting view 
• Application approval panel and ability to approve 
  applications 
• Approve application with Justifications 
• Edit application with status based behavior
  

Technology Backlog items

(AN-45215, AN-45211)

• Enablement of dynatrace logs in Balance Account Transaction module
• Enablement of dynatrace logs onto Transaction Payment Batching module

Client facing impact: No

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

What’s New

Allies can now subscribe to webhook notifications that fire when payout capabilities are confirmed for one of their merchants. When a merchant’s payout capability status changes, the event is pushed directly to the Ally’s configured webhook endpoint.

Why It Matters

Before this change, Allies had no automated signal to confirm that a merchant was ready to receive payouts — they had to poll or check manually. You can now use these webhooks to gate payout initiation logic in your integration, ensuring payouts only go out once the capability is confirmed.

Introduces a Dedicated Reporting Section in the Ally Portal

What’s New

The Ally Portal now includes a standalone Reporting section where Allies can view and download their reports. Reports are accessible directly from the portal without requiring separate tooling or manual exports.

Why It Matters

You can now access and download Ally reports from a single, consistent location in the portal rather than relying on out-of-band delivery or external tools.

Delivers Remaining Notification Management APIs for the Ally Portal

What’s New

The full set of Ally notification management APIs is now available. These APIs allow the Ally Portal to manage notification templates, distribution lists, and notification statuses, bringing the Ally notification experience into parity with how merchant notifications are managed elsewhere in the platform.

Why It Matters

The final API endpoints needed to fully manage Ally notifications — including creating and updating templates and controlling distribution lists — are now available. You can now build or configure complete notification management workflows without hitting missing endpoints.

Sends Notifications When a Sub-Merchant Is Created

What’s New

Allies now receive a notification whenever a new sub-merchant is created under their account. The notification is delivered using the Ally’s existing distribution lists and subscription preferences.

Why It Matters

You can now react programmatically or operationally to new sub-merchant creation as it happens, rather than discovering new merchants only through manual portal checks.

Sends Notifications When a Sub-Merchant Completes Onboarding

What’s New

When a sub-merchant finishes the full onboarding process, Allies receive a notification that includes the merchant’s virtual account details. This notification is delivered to Allies who have subscribed to this event type.

Why It Matters

You can now use this notification as the trigger for initiating payouts to a newly onboarded merchant, eliminating the need to poll for onboarding completion or manually confirm virtual account availability.

Sends Notifications When a Sub-Merchant Is Activated

What’s New

Allies receive a notification when one of their sub-merchants is activated and becomes eligible to process payments. Delivery follows the Ally’s configured subscription and distribution list settings.

Why It Matters

You can now automate downstream workflows — such as enabling payment flows or updating merchant status in your own systems — immediately upon merchant activation, without manually monitoring the portal.

Sends Notifications When a Sub-Merchant Is Deactivated

What’s New

Allies receive a notification when one of their sub-merchants is deactivated. The notification gives Allies an immediate signal to follow up with the platform or communicate proactively with the affected merchant.

Why It Matters

You can now detect merchant deactivation events in real time and respond — whether that means investigating a potential error, pausing related workflows, or reaching out to the merchant — rather than discovering the change after the fact.

Enforces API Versioning on Ally Secure and Payout APIs

What’s New

Ally secure merchant and payout APIs are now baselined at version 2.3. The x-version header is mandatory for Ally merchant APIs. Payout APIs support versions 2.0 and 2.3, with 2.3 as the default. Requests that supply an unrecognized or unsupported version are rejected with an explicit error.

Why It Matters

Unversioned or incorrectly versioned requests to Ally merchant APIs will now be rejected rather than silently processed. Review your integration to ensure the x-version header is present and set to a supported value before this change affects your traffic.

Changes

Parameter: x-version header Change type: Now required (previously optional) Affects: Ally secure merchant APIs

Parameter: x-version header Change type: Modified — defaults to 2.3; valid values are 2.0 and 2.3; unsupported values return an error Affects: Ally payout APIs

Restricts Merchant Management Webhooks to IPFS Allies

What’s New

The Merchant Management webhook module in the Ally Portal is now only visible and subscribable for IPFS Allies. Non-IPFS Allies no longer see this module in their webhook configuration interface.

Why It Matters

Non-IPFS Allies were previously exposed to a webhook module that had no relevance to their account type, creating confusion. The webhook subscription UI now reflects only the modules applicable to your Ally configuration.

Enforces Correct Partner Sell Rate Behavior for Default Account Transactions

What’s New

When a transaction uses an AndDone Default account, the Partner Sell Rate is now explicitly set to NULL rather than inheriting an incorrect value. Additionally, Partner Profitability reports and statements are suppressed for IPFS Allies, ensuring profitability calculations follow the correct business rules for each scenario.

Why It Matters

Before this change, profitability data could reflect incorrect Partner Sell Rate values when default accounts were involved. You can now rely on Partner Profitability reports to accurately represent only the transactions and configurations they are designed to cover.

Adds a View Ally Details Page in the Admin Portal

What’s New

A new View Ally Details page is available in the Admin Portal. It surfaces a comprehensive view of an Ally’s configuration, including allowed payment methods, enabled fees, active features, and quick-action links such as viewing the Ally’s associated merchants.

Why It Matters

Previously, Ally configuration details were scattered or required navigating multiple screens. You can now inspect the full state of any Ally’s setup from a single page in the Admin Portal.

Allows Admins to Add and Edit IPFS Provisioning Data for Sub-Merchants

What’s New

Admin users can now enter and update IPFS Payments provisioning fields — such as Agency ID and Branch ID — for Ally sub-merchants directly from the Admin Portal. This covers cases where the data was not supplied during the secure onboarding flow.

Why It Matters

When provisioning data is missing after onboarding, IPFS payment features cannot be activated. You can now unblock those merchants by supplying the missing identifiers through the Admin Portal without requiring a re-onboarding flow.

Adds Ally Admin Lockout Visibility and Unlock Action in Admin Portal

What’s New

When an Ally Admin account is locked out, the Admin Portal now shows a lock icon and a tooltip indicating the locked state. Admins can trigger an Unlock Ally Admin action with a confirmation step to restore access immediately, without waiting for automatic unlock.

Why It Matters

Previously, there was no visual indicator of a locked Ally Admin, and restoring access required waiting for an automatic timeout. You can now identify and resolve lockouts proactively, reducing disruption for Ally Admins who need immediate access.

Corrects Transaction ID Linking in the Quote Timeline

What’s New

The quote timeline now correctly links the transaction ID to the “Downpayment Authorized” event. Previously, the link was incorrectly attached to the “Sent for Booking” event, which did not reflect the actual sequence of backend operations.

Why It Matters

The transaction ID link in the timeline now points to the correct event, making it straightforward to trace a downpayment transaction from authorization through to booking without being directed to the wrong step.

Updates Quote Timeline State Sequence for Down Payment Flows

What’s New

The quote timeline has been updated for both standard and Autopay flows to consistently record “Downpayment Authorized” — with the transaction ID attached — before progressing to “Sent for Booking,” “Quote Booked,” and “Loan Account Created” where applicable. This aligns the displayed timeline with the actual backend processing order.

Why It Matters

Before this fix, the timeline sequence could be inconsistent or out of order for down payment events, making it difficult to track payment progress accurately. The timeline now provides a reliable, ordered view of each stage in the quote lifecycle.

UAT Release: Ally Management V14(AN_ALMGMT_V14)

Release Ticket: AN-43591 – UAT Release – Ally Management (AN_ALMGMT_V14)

Release Date: Feb 26, 2026

Release Status: Post Deployment Monitoring

Summary

Ally Merchant Notifications & Webhooks – New Ally notifications inform Allies whensub‐merchants are created, onboarded, activated or deactivated, and Admins can now seelocked‐out Ally Admins and unlock them directly from the Admin Portal. Merchant Management webhooks are restricted to IPFS Allies only.

Ally Portal Configuration, Fees & Reporting – Ally APIs are versioned and standardized at2.3 for secure Ally and payout APIs; IPFS‐specific behavior for AndDone default accounts inPartner share and profitability reporting is now enforced; Al Admins can view detailed Allyconfiguration (features, fees etc ) through view ally details page on Admin portal.

IPFS & Provisioning Improvements – Admins can capture and edit mandatory IPFSPayments provisioning data (like agency/branch identifiers) for Ally sub‐merchants directlyfrom the UI when it’s not provided via secure onboarding.

Quote Timeline & UI Fixes – The quote timeline around downpayments is corrected so thetransaction ID is linked to “Down Payment Authorized”, and the UI now correctly shows theupdated timeline states.

Features Deployed to UAT

Ally Payout capability status webhooks

(Epic AN-42836)

Enables Allies to receive payout status updates for their merchantsvia webhooks so they can confirm that payout capabilities are inplace before initiating payouts.

Client facing impact: YES

Ally Portal | Reporting Section

(Epic AN-38481)

Introduces a dedicated Reporting section on the Ally Portal so Allies can quicklyview and download their reports for further analysis.

Client facing impact: YES

Ally Notifications | AllyPortal APIs

(Epic AN-38639)

Delivers the remaining Ally notification APIs from V13 release needed by AllyNO Portal to manage Ally notifications (templates, distribution lists,statuses) in alignment with the Merchant notification experience.

Client facing impact: NO

Ally Notifications | Submerchant Onboarded

(AN-41462)

Sends an Ally notification when a sub‐merchant is fully onboarded,including virtual account details so Allies can initiate payouts to thatmerchant when subscribed to this notification.

Client facing impact: YES

Ally Notifications | Submerchant Activated

(AN-41460)

Notifies Allies when one of their sub‐merchants is activated, allowing themto start processing payments for that merchant once they aresubscribed and distribution lists are configured.

Client facing impact: YES

Ally Notifications | Submerchant Deactivated

(AN-41461)

Notifies Allies when a sub‐merchant is deactivated so they can reach out to AndDone in case of errors or proactively communicate with the merchant.

Client facing impact: YES

Ally API Versioning | Secure APIs

(AN-40411)

Baselines Ally secure merchant and payout APIs to version 2.3, making x-version mandatory for Ally merchant APIs and supporting 2.0/2.3 (with defaulting) for payouts, while rejecting invalid versionswith explicit errors.

Client facing impact: YES

Ally Webhooks | Hide Merchant Management module fornon‐IPFS Allies

(AN-41791)

Restricts the Merchant Management webhook module in Ally Portal so it is only visible and subscribablefor IPFS Allies, preventing other Allies from receiving IPFS‐specific boarding events.

Client facing impact: NO

Ally Fees | Partner Sell Rate – IPFS & AndDone Default scenarios

(AN-38998)

Ensures Partner Sell Rate is left NULL when an AndDone Default account is used on a transaction and suppresses Partner Profitability reports/statements for IPFS Allies, so profitability calculations reflect the correct business rules.

Client facing impact: YES

Ally Management | Admin Portal – View Ally Details

(AN-41113)

Adds a View Ally Details page in Admin Portal showing Ally details, allowed payment methods, enabled fees/features and actions (e.g.,View merchants), giving Admins a single place to inspect Ally onfiguration.

Client facing impact: YES

Ally Notifications | Submerchant Created

(AN-44003)

Sends a notification to Allies whenever a new sub‐merchant is created under them, acknowledging creation and using Ally‐managed distribution lists and subscriptions.

Client facing impact: YES

[CR] – Ally Submerchant feature – IPFS Payments – provisiondata

(AN-44621)

Allows Admin users to add and edit IPFS Payments provisioning data (e.g., Agency ID, Branch ID) for Ally sub‐merchants in the Admin Portal when it is not provided as part of secure onboarding, enabling feature activation.

Client facing impact: YES

Ally Management – Admin Portal | Unlock Ally

(Admin user) (AN-36482)

Shows a lock icon and tooltip when an Ally Admin is locked out, and provides an Unlock Ally Admin action with confirmation soAdmins can quickly restore access without waiting for automatic unlock.

Client facing impact: YES

Update Transaction Id link to down payment in quote timeline

(AN-44826)

Corrects the quote timeline so the transaction ID is linked to the “Downpayment Authorized” event instead of “Sent for booking”, aligning the UI with backend behavior.

Client facing impact: YES

Update Quote timeline when Down payment is processed

(AN-43310)

Updates quote timeline flows (with and without Autopay) so “Downpayment Authorized” is always recorded with the transaction ID, followed by “Sent for booking”, “Quote Booked” and “Loan Account Created” as applicable.

Client facing impact: YES

Migrate Monitoring from Lumigo to Dynatrace – PremiumFinance Project

(AN-38785)

Client facing impact: NO

Migrate Monitoring from Lumigo to Dynatrace -InfrastructureECS Project

(AN-38796)

Client facing impact: NO

Merchant portal – Report – GeneratedOn timestamp does not change when the timezone is updated

(AN-44667)

Bug fix for the correct date time format

Client facing impact: NO

The post PROD Release Notes – Ally Management V14(AN_ALMGMT_V14) appeared first on AndDone.

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

• Release date: 2026-03-04
• Release status: Deployed to UAT
• Version: AN_PFTADN_V4

Highlights

• PFTAD | Coverage Management (Entity API) [AN-28221] – Full CRUD support for Coverage entities; manual and scheduled cron sync with Datalink Coverages.
• PFTAD | Policy Management (Entity API) [AN-28221] – Full CRUD support for policy entities; manual and scheduled sync with Datalink policy.
• PFTAD | Admin Portal – Data Sync [AN-38556] – Front-end data sync framework; UI integration with entity-based APIs (Program, Carrier, Coverage, GA, Broker Management).
• Required PFTAD swagger update for all modules – Updated OpenAPI/Swagger specs; PF4 → PFTAD renaming; standardized x-version metadata.
• [CR] Quote Config – make alias unique and required – alias in quoteConfig is now mandatory; case-insensitive uniqueness validation; MISSING_REQUIRED_FIELD and DUPLICATE_ALIAS error codes.
• [CR] CommsConfig – Make alias field required and unique – alias in communicationConfig is now mandatory; DUPLICATE_ALIAS returned on conflict.

References

• AN-28221
• AN-38556

The post UAT Release Notes – PFTAD (AN_PFTADN_V4) appeared first on AndDone.

What’s New

The Anytime Payment Portal has been upgraded from Angular version 15 to version 20. This brings the portal in line with the current Angular release, incorporating the framework improvements, performance enhancements, and security patches introduced across the v16–v20 range.

Why It Matters

Before this upgrade, the portal was running on an Angular version that no longer receives active support. You can now build against and integrate with a portal that runs on a current, actively maintained Angular version, reducing compatibility friction and exposure to unpatched vulnerabilities.

Upgrade

1. Ensure any custom Angular components or libraries embedded in or alongside the portal are compatible with Angular v20.
2. Review any peer dependencies in your integration that declared a constraint on Angular v15 and update them accordingly.
3. Re-test any portal customizations or overrides that interact with Angular lifecycle hooks, routing, or change detection, as behavior in these areas evolved between v15 and v20.

Introduces a Centralized Shared NPM Package for Angular Micro-Frontends

What’s New

A new shared NPM package centralizes common Angular code — including services, interceptors, components, pipes, constants, and enums — that was previously duplicated across multiple micro-frontend applications. All Angular 19+ micro-frontends now consume this single package instead of maintaining their own copies of shared logic.

Why It Matters

Before this change, the same code existed in multiple places, meaning a bug fix or enhancement had to be applied and tested in every application separately. You can now rely on a single source of truth for shared functionality, making updates faster and reducing the risk of inconsistencies across applications.

Upgrade

1. Remove any locally duplicated copies of shared services, interceptors, components, pipes, constants, or enums from your micro-frontend application.
2. Add the new shared package as a dependency in your package.json.
3. Update import paths in your application to reference the shared package rather than local copies.
4. Run your test suite to confirm no regressions from the import path changes.

Updates the Shared NPM Package to Support Consumer Application Requirements

What’s New

The centralized shared NPM package has been extended to include additional common functionality required by the consumer-facing Angular application. These additions ensure the package covers the full breadth of shared logic needed across the application suite, not just the initial set of micro-frontends.

Why It Matters

You can now use the shared package as the single dependency for common Angular code across both existing micro-frontends and the consumer application, without needing to maintain parallel implementations.

Adds Client-Side Payload Encryption for Payment Submission

What’s New

The payment submission API now supports full client-side payload encryption. Before a payment request is sent, the entire request body is encrypted on the client using a public key. The payload is only decrypted by backend services upon receipt. This behavior is controlled by a feature flag named cryptography — when the flag is on, all payment request payloads are encrypted in transit; when off, payloads are sent as plain text matching the existing behavior.

Why It Matters

Before this change, payment request payloads were transmitted without client-side encryption, relying solely on transport-layer security. You can now enable end-to-end payload encryption for payment submissions, significantly reducing the risk of sensitive payment data being exposed at any intermediate layer.

Changes

Parameter: Request body of POST /payment Change type: Modified — when the cryptography feature flag is enabled, the entire request payload is encrypted before transmission and must be decryptable by the backend using the corresponding private key. When the flag is disabled, existing behavior is preserved.

Fixes Stale Inline Validation Errors When Switching Payment Method Tabs

What’s New

On the payment method selection page, inline validation error messages for Banking Type and Account Type fields were not cleared when a user navigated from the Card tab to the ACH tab. The form now correctly resets these error states on tab switch, so only errors relevant to the currently active tab are shown.

Why It Matters

Before this fix, users switching from the Card tab to the ACH tab would see leftover error messages from the Card form, creating a confusing and misleading experience. Validation errors now only appear in the context of the tab the user is actively filling out.

Release Date: Feb 26th, 2026

Release Status: Deployed to PROD

This release contains the technical upgrades such as angular version upgrade (v15 to v20), NPMPackage for common code from UI, NPM package update, Client-Side Payload Encryption.

[AN-38395] – Anytime Payments Angular Upgrade

Upgraded the Anytime Payment Portal from Angular v15 tov20.

No

[AN-30796] – NPM Package – for common code from UI

Introduced a centralized shared package for all Angular 19MFEs to eliminate duplicate common code (services,interceptors, components, pipes, constants, enums).

This change ensures:

Single source of truth
Improved consistency across MFEs
Simplified maintenance and bug fixes
Easier version upgrades for all applications

No

[AN-35616]- Update NPM Package to accommodate other application changes

Changes to the NPM package to support new commonfunctionality required for the consumer Angular application.

No

[AN-41602]- Client-Side Payload Encryption for PaymentSubmission

Changes made in {{BaseURL}}/payment API to ensure that entire payload is encrypted on the client using a secure public key before being transmitted and decrypted only bybackend services.

NoFeatures Deployed to UAT ClientFacingImpact

Launch darkly Flag “cryptography’ is created. If Flag is ON, then the payment API entire request payload will be encrypted to secure the requested details.

If flag is OFF, then the payment API request payload willbe shown as is as per existing.

This change is implemented on anytime portal as of now.

[AN-46112] – Bug fixes on anytime portal payment method page.

Existing Behavior: The Inline error of Banking Type andAccount Type remains as is if user navigate from Card tabto ACH tab.

Yes

Fixed Behavior: No error will be displayed if user navigatefrom CARD tab to ACH Tab.

The post PROD Release – Angular Version Upgrade (AN_ANGUPD_V1) 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.