1. Define PCI Scope and Ownership Across Systems and Vendors

PCI compliance for your insurance agency starts with clearly defining scope and ownership. Finance teams must understand every system, workflow, and vendor involved in accepting, processing, refunding, or adjusting card payments, especially when payment activity extends beyond internal systems.

Finance leaders should inventory every touchpoint where card data could appear, including:

• Customer-facing payment portals and hosted checkout experiences.
• Embedded payment links used in emails, invoices, or AMS workflows.
• Internal systems that process, reconcile, refund, or adjust transactions.
• Reprocessed or corrected payments handled outside the original workflow.
• Third-party vendors involved in payment acceptance, processing, tokenization, refunds, chargebacks, or reporting.

Just as important as defining ownership, PCI compliance in insurance depends on documented internal accountability and clearly outlined third-party vendor compliance responsibilities. While technical controls may live with IT teams or vendors, finance remains responsible for oversight.

Finance leaders should document:

• Who owns PCI oversight internally, including validation of scope, controls, and ongoing compliance.
• Which vendors are responsible for PCI controls related to payment acceptance, processing, and tokenization.
• How PCI evidence is collected, reviewed, and stored for audits.
• Where escalation occurs when compliance questions or control gaps arise.

2. Verify How Card Data Is Handled and Stored

Understanding how card data is handled is essential for limiting compliance burden.

Key areas to review include:

• Where card data is captured.
• Whether tokenization occurs immediately.
• Whether any system stores raw card data.
• How long payment data is retained.
• How data is removed or invalidated.

Platforms that rely on tokenization and limit data exposure help finance teams reduce audit scope while maintaining reporting visibility. Less exposure means fewer controls to manage and fewer questions to answer later.

Finance teams should confirm these controls are applied consistently across collections, refunds, and payment adjustments, not only initial transactions.

Look for platforms such as AndDone that tokenize payment data at capture and avoid storing raw card information to reduce audit scope and limit risk.

3. Restrict and Review Access to Payment

Access control is both compliance and financial security.

Finance teams should regularly review:

• Who can view payment details.
• Who can initiate refunds or adjustments.
• Who can export transaction data.
• How role changes are logged and approved.

Role-based permissions and access logs protect against internal risk and support clean audit trails in platforms like the AndDone Portal.

4. Validate Daily Reconciliation and Audit Trails

Reconciliation is where compliance becomes operational.

Strong payment workflows support:

• Transaction-level detail.
• Time-stamped audit logs.
• Clear linkage between payments, refunds, and accounting entries.
• Visibility into paid, pending, failed, and reversed transactions.

Manual reconciliation increases compliance risk. Finance teams benefit from systems that support daily reconciliation.

When payment records are tied to policies and customers with time-stamped logs, reconciliation becomes faster and more accurate. 

5. Make Exceptions Easy to See and Prove

Refunds, chargebacks, and adjustments are part of every payment operation. But when they aren’t documented or visible, they become compliance risks.

Finance teams should ensure:

• All exceptions are tracked with complete transaction history.
• Refunds follow standardized and documented workflows.
• Chargebacks remain visible in reporting.
• Exceptions do not bypass approval or logging controls.

Auditors focus on the moments when processes break. That’s why visibility matters.

Exception workflows should stay connected to the original transaction and remain visible to the full team. This makes it easier to demonstrate control, even when workflows don’t follow the standard path.

6. Confirm Third-Party and Vendor PCI Compliance

Third-party vendors are part of your compliance footprint. As industry coverage regularly highlights, payment complexity in insurance often increases when responsibility for data handling and reporting is spread across multiple platforms and partners. Finance leaders should verify each vendor’s PCI status and document third-party service provider responsibilities across data handling, reporting, and audit support.

Key areas to confirm include:

• Each vendor’s current PCI certification and scope.
• Which party captures, processes, tokenizes, or stores card data.
• How vendors support audits, including access to evidence and documentation.
• Where responsibility shifts between internal teams and external partners.

When vendors manage payment data correctly, finance teams stay in control without taking on extra compliance work. The right platform provides visibility, reporting, and audit support without adding PCI scope to your internal systems. 

The right partner keeps finance in control without adding technical PCI risk. In this short video, Chase Courtney from AndDone shares how their team helps reduce audit complexity by managing tokenization, routing, and reconciliation in one system.

7. Maintain PCI Evidence and Audit Readiness

Audit readiness depends on evidence that reflects how your business actually operates.

Finance teams should centralize:

• PCI policies and procedures.
• Access logs and activity records.
• Transaction and reconciliation reports.
• Vendor compliance documentation.

Evidence should remain current and aligned with live workflows, because faulty or outdated records can directly lead to compliance problems and audit obstacles. When documentation matches real operating conditions, audits move faster. 

8. Schedule Ongoing PCI Reviews for the Year

PCI compliance in your insurance agency must remain current as systems, vendors, and workflows change.

Finance leaders should:

• Align PCI reviews with monthly close cycles.
• Reassess PCI scope whenever payment systems, vendors, or workflows change.
• Review vendor compliance on a regular cadence.
• Update documentation proactively as processes evolve.

Routine reviews prevent compliance drift and reduce last-minute remediation. Keeping PCI oversight tied to financial operations supports consistent audit readiness throughout the year.

The post The CFO’s Compliance Checklist: Key Insurance Requirements and Where PCI Fits appeared first on AndDone.

What Is Insurance Payment Processing?

Insurance payment processing includes the systems used to collect, route, track, and reconcile premium payments. It goes beyond simply accepting a payment. It covers everything from how funds are submitted to how they’re matched and confirmed.

A complete payment process answers several essential questions:

• How does the customer submit payment?
• Where do funds go after submission?
• How is the payment matched to the correct policy?
• When do teams receive confirmation?

Insurance payment processing includes:

• Payment methods, such as ACH and credit cards.
• Fund movement through banking or card networks.
• Payment matching tied to the correct customer and policy.
• Payment status visibility, including paid, pending, or failed.
• Accurate records for service, finance, and reporting.

Because insurance payments often involve binding deadlines, installments, and premium financing, this process carries more complexity than standard ecommerce transactions.

Why Insurance Payment Processing Matters for Service Teams and Owners

Payment processing affects every team in an insurance operation. Friction usually appears first in service interactions, then creates cash flow gaps and operational strain across the business.

Impact on Service Teams

Clear payment processes shape the daily workload for service teams.

When payment handling works well:

• Fewer steps make it easier to send payment links quickly.
• Clear confirmation reduces customer back and forth.
• Visible payment status prevents unnecessary follow ups.
• Faster payments help policies move forward without last minute pressure.

When payment status remains unclear, service teams spend time tracking, checking, and explaining instead of supporting customers.

Impact on Owners and Leadership

For business owners, payment processing influences both stability and reputation.

Reliable payment operations support:

• Better visibility into cash flow.
• Lower operational strain on staff.
• Consistent customer experiences that reflect professionalism.
• Modern payment options that meet customer expectations without disrupting familiar processes.

Delayed payments reduce visibility into cash flow, manual steps increase strain on staff, and inconsistent experiences can erode trust over time. As insurance operations become more data-driven and interconnected, operational efficiency plays a growing role in sustaining performance across billing, servicing, and financial oversight.

How Insurance Payment Processing Works

While specific tools may vary, insurance payment processing follows a predictable flow. Understanding each step helps teams identify where delays and confusion often begin.

Payment processing often operates behind the scenes, but it serves as the connective layer between payment collection, premium finance, and accounting. This foundational layer helps manage fund availability and ensures money moves in a way that supports both current operations and future growth.

What Slows Insurance Payments Down

Even small gaps in the payment process can create friction. These issues often appear repeatedly across service and finance teams.

Why do payments get delayed or returned?

Payment delays often stem from incorrect customer information, bank verification holds, or manual review that slows settlement. ACH returns from incorrect account details are one of the most common issues across the industry and frequently require additional follow up before funds can be posted correctly.

What happens when systems do not connect?

When systems don’t connect, teams face duplicate work and inconsistent updates. Disconnected tools lead to duplicate data entry, missed updates between service and finance, and unclear ownership of follow ups. Approaches that balance automation with human oversight help reduce these gaps by keeping processes aligned and communication clear.

Why do customers struggle to complete payments?

Customer friction often comes from unclear or complex steps. Too many screens, confusing instructions, and the lack of immediate confirmation can cause customers to assume something went wrong. This uncertainty increases inbound calls and slows payment completion.

How Modern Payment Platforms Support Insurance Payment Processing

Modern payment platforms designed for insurance focus on supporting existing processes while reducing manual effort.

With the right platform in place, teams can:

• Centralize payment collection.
• View payment status without switching tools.
• Reduce manual follow-ups tied to unclear or delayed payments.
• Provide service teams with intuitive tools.
• Give owners clearer visibility into payment activity.

Coverage from Digital Insurance highlights how insurance specific technology supports modernization without disrupting established operations.

Why Insurance Payment Processing Is Worth Getting Right

Insurance payment processing shapes service speed, staff workload, and customer confidence, and broader industry shifts toward technology that streamlines core operations reinforce why clarity and efficiency in payment workflows matter.

When payments move clearly and predictably:

• Teams stay focused on customer needs.
• Leadership gains stronger insight into cash flow.
• Customers feel supported throughout the process.

The right setup supports familiar processes while reducing friction across the business.

The post What is Insurance Payment Processing and Why Does it Matter? 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.

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

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

Highlights

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

References

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

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

What’s New

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

Why It Matters

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

Adds Multi-Status Filtering to the Applications Search API

What’s New

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

Why It Matters

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

Changes

Parameter: status filter on GET /applications

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

Handles Remediation Actions Triggered by Payment Processor Events

What’s New

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

Why It Matters

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

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

What’s New

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

Why It Matters

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

Synchronizes Merchant Profile Data With Application Data

What’s New

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

Why It Matters

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

Fixes Balance Account Resolution Failures for Test Environments

What’s New

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

Why It Matters

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

Adds Event Handling for Underwriting Evaluation Mappings

What’s New

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

Why It Matters

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

Correlates Completed Evaluation Events With Application Artifacts

What’s New

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

Why It Matters

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

Adds Entity Filtering to the Underwriting Summary API

What’s New

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

Why It Matters

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

Changes

Parameter: entity_id filter on the Underwriting Summary endpoint

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

Adds Entity Filtering to the Underwriting Summary Events API

What’s New

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

Why It Matters

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

Changes

Parameter: entity_id filter on the Underwriting Summary Events endpoint

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

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

What’s New

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

Why It Matters

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

Changes

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

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

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

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

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

Release Date: Feb 26th, 2026

Release Status: Deployed to PROD

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

Onboarding Enhancements

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

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

Client Facing Impact: No

Alloy Underwriting Integration Updates

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

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

Client Facing Impact: No

Enabling Application Acceptance

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

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

Client Facing Impact: No

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

What’s New

The settlement processing pipeline has been rearchitected to handle large volumes of authorization events simultaneously rather than sequentially. The underlying data layer has been updated to support bulk settlement operations, and a scheduler now publishes groups of settlement events in bulk through the event routing infrastructure. Incoming settlement events are processed and evaluated to determine whether a processing schedule needs to be created.

Why It Matters

Before this change, high-volume settlement scenarios — such as end-of-day batches or simultaneous authorization bursts — could create processing bottlenecks because events were handled one at a time. The pipeline can now ingest and route large numbers of settlement events concurrently, reducing settlement latency during peak periods.

Extends Downstream Handlers to Process Bulk Settlement Events

What’s New

The transaction, transaction event log, transaction status, and payment link status handlers have each been updated to correctly process bulk settlement success events. Previously, these handlers were designed around single-event processing and could not interpret or act on the batch-formatted events introduced by the new bulk pipeline.

Why It Matters

Before this change, downstream systems that update transaction records, status fields, and payment link states would not respond correctly when bulk settlement events arrived. All downstream handlers now process bulk success events accurately, ensuring that transaction and payment link states reflect settlement outcomes without manual intervention or reprocessing.

Adds a Dead Letter Queue for Automatic Retry of Failed Settlement Events

What’s New

A dead letter queue has been introduced into the settlement processing pipeline. When a settlement event fails to process — for example, due to a transient error during a high-volume period — it is routed to the dead letter queue and automatically retried rather than being dropped or requiring manual recovery.

Why It Matters

Before this change, settlement events that failed during processing had no automatic recovery path, meaning failed events could result in unresolved transaction states that required manual investigation and reprocessing. You can now rely on the pipeline to automatically retry and resume processing of failed settlement events, maintaining settlement integrity even when simultaneous high-volume events cause transient failures.

Release Date: Feb 26th, 2026

Release Status: Deployed to PROD

This release bundle primarily consists of modules required to support settlement processing based on the authorization events which contain information about the value date or settlement date-time. This version has the implementation to support change in approach for handling bulk events simultaneously. Also includes an ability to retry and resume of settlement processing incase of voluminous settlement occurrences happening at the same time.

Design changes to support bulk processing of events

(AN-42017, AN-42018, AN-42019)

Data source changes to support bulk settlement processing
Publishing of Bulk settlement events through event-bridgescheduler
Processing of incoming settlement event and createschedule if required

Client Facing Impact: No

Processing Enhancements for downstream processing

(AN-42020, AN-42545, AN-42546, AN-42547, AN-44108)

Transaction entity handler enhancements to support Bulk OnSuccess events
Transaction event log handler enhancements to support Bulk OnSuccess events
Transaction status handler enhancements to support Bulk OnSuccess events
Payment Link status handler enhancements to support Bulk OnSuccess events
Implement Dead letter queue for Retry of settlement event processing

Client Facing Impact: No

The post PROD Release Notes – Event Based Settlement Processing Upgrade (AN_EVTSPU_V2) appeared first on AndDone.

What’s New

The phone number field is now optional when creating or updating a vendor. This change applies consistently across both the user interface and backend APIs. Existing validation rules have been updated to allow vendor records without a phone number.

Why It Matters

You can now create and manage vendor records without requiring a phone number. This simplifies onboarding for vendors where contact numbers are unavailable or unnecessary, reducing friction in data entry.

Changes

• Parameter: phoneNumber
• Change Type: Modified (now optional)
• Affects: Vendor create and update endpoints

Allows Cancellation Of Checks In Print Queued Status

What’s New

Checks that are in a “Print Queued” state can now be canceled before they are printed. This introduces additional control over the check processing lifecycle and prevents unwanted check issuance.

Why It Matters

You can now stop checks before they are printed, reducing errors and avoiding the need for manual reversals or corrections after printing.

Omits Duplicate DBA Name On Printed Checks

What’s New

When the Merchant DBA (Doing Business As) name matches the Merchant name, the system no longer prints the DBA name on checks. This removes redundant information from printed output.

Why It Matters

You get cleaner, more readable checks without duplicate business names. This improves the presentation and avoids confusion for recipients.

Excludes Bundle Address For USPS First Class Shipping

What’s New

The system no longer includes the bundle address when USPS First Class is selected as the shipping method. This avoids requiring unnecessary fields such as phone numbers for this shipping type.

Why It Matters

You can process shipments with fewer required fields when using USPS First Class. This streamlines the workflow and reduces validation errors tied to unnecessary address data.

Suppresses Transit Status After Delivered Webhook

What’s New

If a “Delivered” webhook is received, the system stops sending or displaying subsequent “In Transit” status updates. This ensures that delivery status is not overwritten by outdated tracking events.

Why It Matters

You now see accurate and consistent delivery statuses. This prevents confusion caused by conflicting tracking updates after a package has already been marked as delivered.

Implements Secure Webhook Validation For Checkeeper

What’s New

Incoming webhooks from Checkeeper are now validated using a signature-based verification process. This ensures that only trusted webhook events are accepted by the system.

Why It Matters

You can trust that webhook events are authentic and have not been tampered with. This improves the security of your payment workflows and reduces the risk of processing malicious or invalid requests.

Release Date: Feb 26, 2026

Release Status: Deployed to PROD

This release bundle contains Outbound payments API’s

Features Deployed to UAT

Merchant Portal Enhancements

Vendor Management:

Phone number made optional in Add/Edit Vendor, implemented across UI and Backend (Secure & Open APIs)

Client Facing Impact: Yes

Check Printing and Formatting:

Allow Cancellation of Checks in Print Queued Status
Merchants can now cancel Checks that are still in Print Queued status

Do Not print Merchant DBA Name when same as Merchant Name
If Merchant DBA name matches Merchant Name, the DBA name is omittedon the printed check to avoid redundancy.

Client Facing Impact: Yes

Exclude Bundle Address for USPS First Class Shipping Methods

Bundle address is now excluded when USPS first class shipping method is selected [only shipping method for now], to avoid phone number being mandate

Client Facing Impact: Yes

Omit Transit Status if Delivered webhook is received prior

Transit status updates are now omitted when a delivered webhook is already received, preventing wrong display of status

Client Facing Impact: Yes

Secure Webhook Validation for Checkeeper

Added Signature-based webhook validation to securely verify incoming Checkeeper webhook requests

Client Facing Impact: Yes

The post PROD Release Notes – Outbound Payments (AN_OUTPAY_V8) appeared first on AndDone.

• Release date: February 25, 2026
• Release status: Deployed to UAT
• Source pages: ANDDONE-ALL RELEASE NOTES.pdf pp. 318–320

Highlights

• Internal Invoicing Merchant Interaction (AN-13678) ves

References

• AN-13678
• AN_FEEINV_V2

Original release notes excerpt

UAT Release Notes – Merchant Invoicing & Notifications (AN_FEEINV_V2)
UAT Release: Merchant Invoicing & Notifications (AN_FEEINV_V2)
Release Date: UAT Feb 25,2025
Release Status: Deployed to UAT
With this version of release, Merchant Interaction of the Invoice feature along with changes to
Notifications feature is delivered. Platform notifications is a new notification type introduced to
manage the templates for notifications sent by platform to the Sub-Merchants (ex: Invoicing,
Fee updates). Along with these features change requests that accounts for Invoice feature and
technological updates to improve the performance are included in this release.
Features Deployed to Production Client Facing Impact
Internal Invoicing Merchant Interaction (AN-13678) ves
After this release, The Sub-merchants who has the Invoicing
feature enabled can view the invoice details and pay the
invoice for processing fee ete depending on their

Source: Compiled internal release notes PDF (ANDDONE-ALL RELEASE NOTES.pdf), pages 318–320.

The post UAT Release Notes – Merchant Invoicing & Notifications (AN_FEEINV_V2) appeared first on AndDone.

• Release date: 2026-02-11
• Release status: Deployed to UAT
• Version: AN_BALPH2_V4

Highlights

• Onboarding Enhancements (AN-43267, AN-43031, AN-43285, AN-42551, AN-44569, AN-43228) – Virtual Account Processor on Account Listing; multi-status application search; Adyen remediation handling; sole proprietorship restriction; merchant-application data sync.
• Alloy Underwriting Integration Updates (AN-43709, AN-44223, AN-44298, AN-44299) – Event handler for Alloy evaluation mappings; correlate completed_evaluation events; underwriting summary and events API enhancements with entity filters.
• Enabling Application Acceptance (AN-43138, AN-44007, AN-43139, AN-43135) – Assign owner, fetch entity owners, assign grantors, manage entity roles for AndDone applications.

References

• AN-43267
• AN-43031
• AN-43285
• AN-42551
• AN-44569
• AN-43228
• AN-43709
• AN-44223
• AN-44298
• AN-44299
• AN-43138
• AN-44007
• AN-43139
• AN-43135

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