Improvement
Choose which ABN business name to verify against
When an ABN has more than one active registered business name, auto-verify now shows the available names and lets you pick the one to use, instead of selecting one automatically. ABNs with a single active name still verify in one click.FeatureImprovement
Review identity checks instead of an outright fail
Identity (KYC) checks that need a closer look no longer simply fail. When the automated checks cannot reach a confident decision, the verification moves to a distinct in-review state, and the contact and verification pages prompt your team to review it in the portal.Reviewers see the evidence submitted by the person — identity documents, liveness video, and face-match results — and record an approve or reject decision with a reason. The decision is applied to the verification immediately and logged in the contact’s activity timeline, so a borderline identity check becomes a minute of review instead of a failed verification and a restarted process.Improvement
Find records faster with portal search
Portal searches now reliably find contacts and verifications by names and payment details, with search added across invoices, ABA checks, API keys, webhooks, users, and invites.Feature
7-day card-free trial for the Founder plan
The Founder plan now includes a 7-day free trial that requires no card details to start. Customers can explore the full portal experience and run live verifications without payment, making it easier to evaluate ezyshield before committing to a paid subscription.Feature
Upload invoices through the API
Supplier invoices can now be uploaded through the new Invoice endpoints. ezyshield reads each uploaded file and extracts the supplier’s business identity, bank account details, and invoice number — removing manual data entry from the path between receiving an invoice and verifying who gets paid.Progress is delivered over the newinvoice.reading, invoice.processed, invoice.failed, and invoice.invalid webhook events, and the new invoice:read and invoice:write API key abilities scope access. Invoices uploaded through the API never create or update contacts, so the extracted details stay under your integration’s control.See the Invoice extraction guide for the recommended upload-extract-verify workflow.Bug
Verification status displays correctly after reverting contacts to verified
Verification status now displays the correct check marks in the portal when contacts are reverted to verified status, instead of incorrectly showing cancelled verification attempt indicators.FeatureImprovement
Manage webhook subscriptions in the portal
API administrators can now create and manage webhook endpoints, choose which verification events each endpoint receives, copy signing secrets when subscriptions are created, and send test events directly from the portal.Webhook event pages show payloads, HTTP response statuses, delivery attempts, queued retries, and terminal failures, making it easier to validate and troubleshoot integrations without leaving the portal.Authorise individual email addresses
Organization settings now accept individual email addresses alongside authorised email domains. Emails from an authorised address are processed automatically even when the rest of its domain is not trusted — useful for accepting invoices from a specific contact at a shared provider such as Gmail without opening the door to the entire domain.Breaking Change
Verification delivery parameters renamed to send_individual_authentication_* Breaking Change
The send_individual_confirmation_sms and send_individual_confirmation_email parameters on the Verification API have been renamed to send_individual_authentication_sms and send_individual_authentication_email, matching the identity authentication step the contact person completes. Verification responses use the new names too, and the individual_confirmation_url response attribute is now individual_authentication_url.Update integrations to send and read the
send_individual_authentication_sms, send_individual_authentication_email, and individual_authentication_url attributes.Webhook event verification.confirmation_notification_sent renamed Breaking Change
The verification.confirmation_notification_sent webhook event has been renamed to verification.authentication_link_sent, matching the identity authentication link it reports on. The event payload is unchanged.Update any webhook handlers filtering on
verification.confirmation_notification_sent to listen for verification.authentication_link_sent.Rejected verification status removed Breaking Change
Therejected verification status and the verification.rejected webhook event have been removed. The status belonged to a retired flow in which the contact person could decline the payment details; no verification could reach it any longer. Verifications that cannot be verified always finish as failed.Remove any handling of the
rejected status or the verification.rejected webhook event; failed outcomes are delivered via verification.failed.Breaking ChangeFeature
Verification requests use a verify_identity boolean Breaking Change
The individual_confirmation_mode parameter on the Verification API has been replaced by a single verify_identity boolean. Set it to true to have the contact person verify their identity with a government-issued ID, or false to run sanctions screening only. The individual_portrait_image parameter and the biometric authentication mode have been removed, and verification responses no longer include individual_confirmation_mode.Update integrations to send
verify_identity alongside individual_name. Requests that still send individual_confirmation_mode or individual_portrait_image are rejected with a validation error.Verified identities are reused automatically
When a contact person has already verified their identity for the same contact (orattribution_id chain) and their details are unchanged, requesting a new verification no longer messages them again. The earlier identity verification is reused and the verification completes immediately — sanctions screening and payee correlation still run in full every time. Payees are no longer asked to re-verify details that haven’t changed, and repeat verifications finish without waiting on the payee.Breaking Change
Identity verification page moved to /authenticate Breaking Change
The page payees use to verify their identity has moved from /confirm/{code} to /authenticate/{code}. Verification links sent by SMS and email now point to the new address, and any existing /confirm/{code} link is permanently redirected (301) to the new path — so links already delivered to payees keep working without interruption.Update any hardcoded references to the
/confirm/{code} path to use /authenticate/{code}.Webhook event verification.confirmation_ready renamed Breaking Change
The verification.confirmation_ready webhook event has been renamed to verification.authentication_ready, reflecting that the payee completes an identity authentication step. The event payload is unchanged.Update any webhook handlers filtering on
verification.confirmation_ready to listen for verification.authentication_ready.Feature
Import your contacts in bulk
Bring your existing payees into ezyshield in one step. Upload a CSV of contacts during onboarding or at any time from the contacts list, and ezyshield creates and queues them for verification automatically — no manual entry, no row-by-row setup. New customers can be fully operational minutes after signing up.Invoices without a valid ABN are automatically blocked
Invoices that arrive without a valid ABN are now flagged as Invalid and stopped before any contact is created. Fraudulent and malformed invoices are caught at the door, keeping unverifiable payees out of your payment workflow rather than surfacing the risk only after the fact.Feature
Auto-correct recurring payee details
When an invoice arrives with a name that differs from a contact you’ve already verified, ezyshield offers to auto-correct it. Opt in with one click and future invoices for that contact are aligned to the verified details for you — so recurring suppliers stop tripping the same avoidable mismatch. Turn it off again whenever you like.Re-verify a failed contact in one click
When a contact fails verification, an Auto-verify option appears. One click updates the business and account name to the ABN’s registered entity and re-runs the check — clearing common name mismatches without editing anything by hand.Improvement
Choose when to contact a payee for identity verification
Adding or importing a contact no longer automatically texts the contact person to verify their identity. By default, only the account name check runs, confirming the bank account name matches the business or individual on the contact — without involving the contact person.A new Verify identity toggle on the contact person section puts you in control. When enabled, the contact person is asked to verify their identity with a government-issued ID and is notified by email and/or SMS to complete the process. This unlocks ongoing monitoring for AML, PEP screening, and sanction checks so you can confirm the individual is safe to pay and work with.Feature
Set how long verifications stay valid
Set a verification expiry period for your organization. Once a verification reaches that age it’s marked expired and your team is notified, so stale payee details surface for a fresh check instead of being trusted indefinitely.Feature
Account-only verifications (Confirmation of Payee)
Create verifications with only bank account details when business or individual identity verification and correlation is not required.This gives API integrations a lighter Confirmation of Payee path for checking an account name, BSB, and account number, while keeping business and individual verification flows available when stronger payee correlation is needed.Breaking Change
Renamed Verification checks to check_results Breaking Change
The checks attribute on the Verification object has been renamed to check_results to reduce naming ambiguity between automated check logs and user-initiated Check objects.Concept Clarification
verification.check_resultsis a historical record of the automated background checks run by the system during the initial verification process.- The Check object represents a separate, ongoing monitoring check that you trigger after completion to ensure details haven’t maliciously diverged.
Make sure to update references from
checks to check_results.Feature