WordPress IntegrationGravity FormsPlugin DevelopmentWordPress

Insurance verification that behaves like native form data

GF VerifyTX Addon

A Gravity Forms add-on that turns VerifyTX responses into configurable validation, conditional logic, exports, and downstream workflows.

Role

WordPress Plugin Developer

Timeline

September 2025–present

Status

Released

Client

Healthcare form workflow

Diagram showing real-time, AJAX, and background verification paths converging on a VerifyTX service and normalized Gravity Forms result fields.

01 / The problem

A workflow that needed stronger engineering boundaries

A form can collect insurance details, but an external eligibility result is only useful when it arrives at the right point in the submission lifecycle and can be reused by confirmations, conditional logic, exports, CRM feeds, and administrators. Building that behavior separately into every form would create duplicated mappings, brittle response parsing, and inconsistent failure handling.

Blocking valid submissions when an external API is unavailable
Duplicating verification logic across forms and downstream integrations
Expired OAuth tokens interrupting form workflows
Sensitive request and response data appearing in unsafe contexts
Different timing modes producing inconsistent stored results

02 / The approach

Design the workflow around explicit invariants

Build on the Gravity Forms Add-On Framework, isolate external communication and verification logic in services, and translate API responses into native Gravity Forms fields and entry metadata. This makes the integration configurable per form while keeping downstream workflows independent of the raw API shape.

Lifecycle-aware verification: Real-time validation, explicit AJAX verification, and post-submission processing share one normalization and storage model.
Native form composition: Field mapping and seven custom result fields let administrators use verified values in conditional logic, notifications, confirmations, and exports.
Connection resilience: OAuth authorization, expiry checks, refresh-token handling, API timeouts, errors, and connection status are centralized.
Operational traceability: Verification history, cache records, configurable retention, logging, and normalized display output provide an auditable workflow surface.

03 / Architecture

Gravity Forms add-on with controller-style orchestration and dedicated API and verification services

The implementation separates WordPress integration points from the domain services and operational controls that carry the workflow.

WordPress bootstrap and activation-time database setup
Gravity Forms Add-On Framework settings and hooks
VerifyTX API client and OAuth token lifecycle
Verification validation, caching, history, and presentation service
Seven Gravity Forms field classes
Frontend AJAX, payer search, and verification-state UI

04 / System surface

Capabilities organized around the operator journey

The case study focuses on the verified engineering surface rather than unmeasured business claims.

Form configuration: Global API settings and OAuth connection state
Form configuration: Per-form enablement, verification timing, payer/facility context, and field mapping
Verification lifecycle: Real-time verification during Gravity Forms validation
Verification lifecycle: AJAX verification before submission with visible success/error state
Reusable result fields: Verification status and success flag
Reusable result fields: Payer name and normalized error code
Reliability and operations: Automatic OAuth token refresh
Reliability and operations: Validation, API timeout handling, caching, history, retention, and logging controls

05 / Engineering decisions

Tradeoffs made explicit

The design choices below address compatibility, identity, safety, and maintainability constraints found in the audited implementation.

Expose normalized results as Gravity Forms fields: Downstream conditional logic and integrations can consume stable field values instead of parsing a provider-specific response repeatedly.
Support three verification timings: Different forms can prioritize strict pre-submit eligibility, explicit user feedback, or a non-blocking submission experience.
Use one global OAuth connection with automatic refresh: Centralized connection management avoids per-form credential duplication and hourly manual reauthorization.
Separate API communication from verification workflow logic: Response parsing, transport errors, caching, validation, storage, and display remain independently maintainable.
Ship a tag-built plugin artifact: The release workflow installs production dependencies, removes development files, and attaches a versioned ZIP to the GitHub release.

06 / Verified outcome

A defensible result grounded in inspected evidence

Repository and interface evidence establish the engineering outcome. Production volume, time savings, and business impact remain unclaimed unless separately confirmed.

Release v2.0.0 and the default branch resolve to commit 15b01999022c2aeae4f8818af7c546705fc3e8ff.
The inspected history contains 82 commits, all attributed to Adrian T. Saycon.
The release contains 20 PHP, 6 JavaScript, and 6 CSS files, with 6,022 application PHP lines and 1,456 test-support PHP lines.
The repository contains 38 test methods across unit and integration suites.
GitHub Actions completed the v2.0.0 test matrix successfully on PHP 7.4, 8.0, 8.1, 8.2, and 8.3, and completed the release workflow successfully.
Verification results become reusable form data rather than an isolated API response.
Administrators can choose a verification experience without changing integration code.
Connection, validation, caching, history, and display concerns are centralized.