• Release date: 2026-02-26
• Release status: Post Deployment Monitoring
• Version: AN_ALMGMT_V14

Highlights

• Ally Payout capability status webhooks (AN-42836) – Allies receive payout status updates for their merchants via webhooks.
• Ally Portal | Reporting Section (AN-38481) – Dedicated Reporting section on Ally Portal for viewing and downloading reports.
• Ally Notifications | Submerchant Onboarded (AN-41462) – Ally notified when sub-merchant is fully onboarded.
• Ally Notifications | Submerchant Activated/Deactivated (AN-41460, AN-41461) – Lifecycle notifications for Ally merchants.
• Ally API Versioning | Secure APIs (AN-40411) – Baselines Ally secure APIs to version 2.3; mandatory x-version header.
• Ally Management | Admin Portal – View Ally Details (AN-41113) – Single-page view of Ally config, fees, features, and actions.
• [CR] Ally Submerchant IPFS Payments provision data (AN-44621) – Admins can add/edit IPFS provisioning data for Ally sub-merchants.
• Ally Management – Admin Portal | Unlock Ally (AN-36482) – Unlock locked-out Ally Admins directly from Admin Portal.
• Update Transaction Id link for down payment in quote timeline (AN-44826) – Transaction ID linked to ‘Downpayment Authorized’ event.

References

• AN-42836
• AN-38481
• AN-38639
• AN-41462
• AN-41460
• AN-41461
• AN-40411
• AN-41791
• AN-38998
• AN-41113
• AN-44003
• AN-44621
• AN-36482
• AN-44826
• AN-43310

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

• Release date: 2026-02-12
• Release status: Post Deployment Monitoring
• Version: AN_ALMGMT_V14

Highlights

• Ally Payout capability status webhooks (AN-42836) – Allies receive payout status updates for their merchants via webhooks.
• Ally Portal | Reporting Section (AN-38481) – Dedicated Reporting section on Ally Portal for viewing and downloading reports.
• Ally Notifications | Submerchant Onboarded/Activated/Deactivated/Created (AN-41462, AN-41460, AN-41461, AN-44003) – Full sub-merchant lifecycle notifications for Allies.
• Ally API Versioning | Secure APIs (AN-40411) – Baselines Ally secure merchant and payout APIs to version 2.3; mandatory x-version header.
• Ally Webhooks | Hide Merchant Management module for non-IPFS Allies (AN-41791) – IPFS-specific webhook module restricted to IPFS Allies only.
• Ally Fees | Partner Sell Rate – IPFS & AndDone Default scenarios (AN-38998) – Partner Sell Rate left NULL for AndDone Default accounts; profitability reports suppressed for IPFS Allies.
• Ally Management | Admin Portal – View Ally Details (AN-41113) – View Ally Details page with config, payment methods, fees, features, and actions.
• [CR] Ally Submerchant IPFS Payments provision data (AN-44621) – Admins can add/edit Agency ID, Branch ID for Ally sub-merchants in Admin Portal.
• Ally Management – Admin Portal | Unlock Ally (AN-36482) – Lock icon and Unlock Ally Admin action with confirmation dialog.
• Update Transaction Id link / Quote timeline for down payment (AN-44826, AN-43310) – Transaction ID correctly linked to ‘Downpayment Authorized’ event.
• Migrate Monitoring from Lumigo to Dynatrace (AN-38785, AN-38796) – Premium Finance and Infrastructure ECS projects migrated.
• Merchant portal Report GeneratedOn timestamp fix (AN-44667) – Correct date-time format when timezone is updated.

References

• AN-42836
• AN-38481
• AN-38639
• AN-41462
• AN-41460
• AN-41461
• AN-40411
• AN-41791
• AN-38998
• AN-41113
• AN-44003
• AN-44621
• AN-36482
• AN-44826
• AN-43310

The post UAT Release Notes – Ally Management V14 (AN_ALMGMT_V14) 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.

• Release date: 2026-01-19
• Release status: Post Deployment Monitoring
• Version: AN_ALMGMT_V13

Highlights

• Ally Portal | Payments Section (AN-37771) – Dedicated Payments section for Allies to view merchant payments with filters and search.
• [CR] Ally Fees | Ally profitability report.csv changes (AN-33858) – Report changed from transaction-level to merchant-level summary per payment method.
• Ally Payments | Secure Payment Intent timeline (AN-36488) – Allies access Payment Intent Timeline API using Ally user API key.
• Ally Portal Notification APIs (AN-39507, AN-39509, AN-39511, AN-39512, AN-39513) – Full suite: list, update status, template variables, distribution lists, update templates.
• [CR] Ally Submerchant Onboarding | shopperStatement field (AN-33725) – Optional shopperStatement added to secure onboarding API.
• Ally Submerchant Feature Inheritance (AN-42726) – Aligns feature inheritance with Ally configuration across all Admin portal views.
• Migrate Monitoring from Lumigo to Dynatrace (AN-38782, AN-38781, AN-41672, AN-41717) – Domain, Infrastructure, and Transaction project migrations.
• Migrate Invoice Project Lambdas to ARM64 (AN-41760) – Graviton processor migration for cost and performance.
• NACHA notification email fix (AN-44537) – Stops repeated emails every 15 minutes for the same transaction batch.
• Notifications not triggering fix (AN-44539) – Resolves defect where subscribed users did not receive transaction event notifications on QAT.
• [UAT] Page unresponsive on Shift+Hyphen in Last Name field fix (AN-40941) – Prevents page freeze on Create Payment Link page.

References

• AN-37771
• AN-33858
• AN-36488
• AN-39507
• AN-39509
• AN-39511
• AN-39512
• AN-39513
• AN-33725
• AN-42726
• AN-38782
• AN-38781
• AN-41672
• AN-41717
• AN-41760
• AN-44537
• AN-44539
• AN-40941

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

What’s new

Merchants can now link their AMS360 bank accounts to the platform and designate a default bank under Business Settings. The available bank options are pulled directly from the accounts already configured in AMS360. When posting receipts, the system automatically suggests the default bank but allows merchants to override it on a per-transaction basis. Once posted, receipts appear in AMS360 under the bank name selected during the posting process.

Why it matters

Before this change, there was no way to associate payments made through the platform with specific AMS360 bank accounts. Merchants can now post receipts directly to the correct bank in AMS360, keeping their records organized and reconciliation straightforward.

Introduces individual and bulk receipt posting to AMS360

What’s new

A new “Post Receipts” tab is now available on the Payment Listing page, displaying AMS360-eligible transactions based on the merchant’s selected filters. Merchants can select one or multiple transactions and submit them for posting in a single action. Only transactions in an Authorized or Settled status are eligible — Failed, Refunded, and Chargeback transactions are excluded. The system requires full posting only; partial posting is not supported. Eligible transactions can also be re-posted individually from their Transaction Details page if needed.

Why it matters

You can now post receipts to AMS360 in bulk directly from the payment listing, eliminating the need to handle transactions one by one. The eligibility rules are enforced automatically, reducing the risk of posting transactions in invalid states.

Adds Invoice Count column to Authorization and Settlement reports

What’s new

The Authorization and Settlement reports now include a new “Invoice Count” column that displays the number of AMS360 invoices associated with each transaction.

Why it matters

You can now see at a glance how many AMS360 invoices are tied to a given transaction without needing to navigate to individual transaction records, making it faster to audit and reconcile payment data.

Updates CSV filename convention for AMS360 compatibility

What’s new

The naming convention for exported CSV files has been shortened to comply with AMS360’s 35-character filename limit, which was causing filenames to be truncated. Authorization reports are now named AMS360_auth_yyyy_mm_dd_D and Settlement reports are named AMS360_settled_yyyy_mm_dd_D, where D is a sequence counter (e.g. _01) to differentiate multiple files exported on the same day. Previously generated files retain their original names and must be manually re-exported if the new naming convention is required.

Why it matters

Before this change, long filenames were being cut off by AMS360’s character limit, which could cause files to be unreadable or misidentified on import. Exported files now import cleanly into AMS360 without truncation issues.

Production Release Notes – AMS360 (AN_AMS360_V7)

Release Date: Jan 8, 2026

Release Status: Deployed to Production

This release bundle includes functionality related to AMS360 receipt posting through APIs.

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

AMS360 Bank Configuration for Receipt Posting

This update allows merchants to integrate AMS360 bank accounts with the AndDone platform for accurate recording of payments and receipts.

• Set a Default Bank: Merchants can choose a preferred bank name under Business Settings. The available options are based on the bank accounts already set up in AMS360. This will act as the “Default Bank,” and the system will automatically suggest it for all receipt postings.
• Flexible Posting Options: While a default bank is set, the merchant is not locked into it. When posting receipts to AMS360, the merchant can manually override the default and select a different bank for specific transactions if needed.
• Seamless Integration: Once posted, all receipts will appear in the AMS360 system under the specific bank name selected during the process, ensuring the merchant’s records remain organized and easy to reconcile.

Client Facing: Yes

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

Individual and Bulk Posting of Receipts to AMS360

A new “Post Receipts” tab is now available on the Payment Listing page, displaying AMS360 transactions based on the merchant’s selected filters. The merchant can select one or multiple transactions and submit them by clicking the “Post Receipts” button.

Important Rules for Posting:

• Eligible Statuses: Only transactions marked as Authorized or Settled can be selected for bulk posting.
• Exclusions: Transactions that are Failed, Refunded, or Chargeback cannot be posted.
• Full Posting Only: The system does not allow partial posting of transactions.
• Re-posting: If necessary, eligible transactions can be re-posted through their individual Transaction Details page.

Client Facing: Yes

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

New “Invoice Count” Column in Reports

The Authorization and Settlement reports now include an “Invoice Count” column, which displays how many AMS360 invoices are associated with each transaction.

Client Facing: Yes

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

Updated CSV Filename Convention for AMS360 Compatibility

To prevent filenames from being truncated (cut off) due to AMS360’s 35-character limit, the naming convention for CSV files has been shortened. Merchants will now see files named in the following formats:

• Authorization Reports: AMS360_auth_yyyy_mm_dd_D
• Settlement Reports: AMS360_settled_yyyy_mm_dd_D

(Note: “D” represents a sequence counter, such as _01, to distinguish between multiple files on the same day.)

Important: Previously generated files will retain their original names. The merchant must re-generate any older files if the new naming convention is required for those records.

Client Facing: Yes

The post Production Release Notes – AMS360 (AN_AMS360_V7) appeared first on AndDone.

What’s new

A new Merchant module webhook is now available for Allies. When an AndDone Admin makes changes to a merchant — such as activating, deactivating, or updating configuration — the Ally receives a webhook notification in real time. This brings merchant activity visibility directly into Ally systems without requiring polling.

Why it matters

You can now build event-driven workflows that react to merchant state changes as they happen. Allies no longer need to manually check for updates or poll the API to detect when a merchant has been activated, deactivated, or reconfigured by an admin.

Synchronizes Ally account details across Admin and Ally portals

What’s new

A synchronization mechanism has been added to ensure that Ally account details stay consistent regardless of where an update originates. Changes made from either the Ally Portal or the Admin Portal are now automatically reflected in both systems.

Why it matters

Before this change, updates made in one portal were not guaranteed to propagate to the other, which could result in stale or inconsistent Ally account data depending on where it was viewed. Account details are now always in sync across both portals.

Updates feature lists for Allies and Ally merchants

What’s new

The feature lists available to Allies and Ally merchants have been updated to reflect the current set of supported capabilities. This ensures that feature access configuration in the Admin Portal accurately represents what is available to each party.

Why it matters

Admins configuring feature access for Allies and Ally merchants can now work from an accurate and up-to-date feature list, reducing the risk of enabling or expecting features that are no longer applicable.

Revokes merchant portal access for Ally merchants via migration

What’s new

A migration script has been run to revoke merchant portal access for Ally merchants across existing accounts. This is a one-time data migration to enforce the correct access boundaries for this merchant type going forward.

Why it matters

Ally merchants should not have direct merchant portal access — that access is managed through the Ally. This migration brings existing accounts into compliance with that access model without requiring manual intervention per merchant.

Discontinues generation and display of Private API keys for submerchants

What’s new

The platform no longer generates Private API keys for submerchants, and existing Private API keys are no longer displayed in the UI. This change removes a potential security exposure by limiting Private API key visibility and issuance to the appropriate account level.

Why it matters

Before this change, Private API keys were being generated and shown for submerchants, which represented an unnecessary security surface. Any workflows that relied on submerchant Private API keys will need to be updated to use the appropriate key type at the correct account level.

Activates webhook notifications for the Ally report module

What’s new

Webhook notifications for the report module are now active for Allies. When a new report is generated, Allies receive a webhook notification automatically, keeping them informed of new report availability without requiring manual checks.

Why it matters

You can now trigger downstream workflows — such as automated report retrieval or processing — as soon as a new report is generated, rather than polling for availability.

Removes redundant report subscriptions for Ally merchants via migration

What’s new

A data cleanup migration has been run to identify and remove redundant report subscriptions for Ally merchants. This is a one-time migration to clean up stale subscription data that was no longer valid.

Why it matters

Redundant report subscriptions could result in unnecessary notifications or processing overhead. This migration ensures that only valid, active subscriptions remain for Ally merchants.

Adds Payments section to the Ally Portal with transaction history, refunds, and search

What’s new

A new Payments section is now available in the Ally Portal, featuring a full payment table with comprehensive transaction history and refund transactions. The table includes robust filtering and search tools, giving Allies a single place to look up and analyze payment activity across their merchants.

Why it matters

Before this change, Allies had no dedicated view of payment activity within the Ally Portal. You can now browse, search, and filter the complete transaction and refund history for your merchants directly from the portal without needing separate reporting tools or API calls.

Production Release Notes – Ally Management V12 (AN_ALMGMT_V12)PROD Release: Ally Management V12 (AN_ALMGMT_V12)

Release Date: Jan 8, 2026

Release Status: Post Deployment Monitoring

Summary

This release delivers a new webhook module for allies to get notifications on their merchant related activity by AndDone Admin. Additionally, this release includes updates to Ally Management and Ally Merchant management including enhancements to feature list, API key display, portal access revocation, report subscription revocations for Ally merchants and ally reporting module webhook updates. Payments section will be available on the Ally Portal to conveniently look up Allies payments.

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

Ally Webhooks | Merchant Module (AN-38060)

The Merchant module webhooks allows allies to receive updates regarding their merchant activity by AndDone Admins like activation, deactivation or any configuration change.

Client Facing: Yes

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

Ally User Management | Update Ally Details When Admin User is Updated (AN-39309)

Added synchronization logic to ensure Ally account details are automatically updated whether its updated from Ally portal or Admin portal.

Client Facing: Yes

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

Ally Management | Ally Feature List, Ally Merchant Feature List (AN-33935)

Updated feature list for Allies and Ally merchants according to the current supported capabilities.

Client Facing: Yes

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

[CR] Ally Merchant Management | Merchant Portal Access to be Removed (Migration) (AN-34999)

Merchant portal access to be revoked for any ally merchants through migration script.

Client Facing: Yes

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

Ally Merchant | Submerchant Private API Keys (Stop Generation and Display) (AN-32568)

Enhanced security by discontinuing the generation and UI display of Private API keys for submerchants.

Client Facing: Yes

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

Ally Webhooks | Webhook Notifications for Report Module (AN-37817)

Webhook notifications for report module are active for allies and will receive notifications for any new report generations.

Client Facing: Yes

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

Ally Report Management | Check if Report Subscription Exists for Ally Merchants and Remove (Migration) (AN-37818)

Data cleanup migration to identify and remove redundant report subscriptions for Ally merchants.

Client Facing: Yes

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

Ally Portal Payments | Payment Table Listing, Refund Transactions & Filter and Search (AN-38252, AN-38253, AN-38258)

New Payment Table within the Ally Portal to provide a comprehensive view of transaction history, refunds along with robust search and filtering tools.

Client Facing: Yes

The post Production Release Notes – Ally Management V12 (AN_ALMGMT_V12) appeared first on AndDone.