Case study

Dental payment integration

The operating question

How can a practice move recurring payments to lower-cost ACH without manually reconciling every payment?

01 · Case studyDental payment integrationPayment fees from ≈2.9% to ≈0.7%02 · Case studyWedding venue proposal automation34 minutes to 6 minutes per quote03 · Case studyAI enabling a semi-private airlineSeparate instruction, practice, and weekly guides
ClientDental practice
Traditional fees≈2.9%
Our fees≈0.7%
EnvironmentDentrix Classic
StatusRunning in production
What the team needed to solve

Lower the fee without replacing the ledger.

Traditional card processing cost the practice ≈2.9% per payment. The Dentrix-compatible ACH path costs ≈0.7%. The harder problem was preserving the practice’s existing ledger workflow without creating a second administrative system.

Q1

Can ACH work without replacing Dentrix?

The practice needed a bridge around the existing system, not a migration project disguised as savings.

Q2

How does each payment reach the right patient account?

Patient matching and posting had to happen safely on the clinic workstation.

Q3

How does the system stop safely?

Ambiguous matches and reversals enter an exception state. A posting completes only after Dentrix read-back confirms the expected ledger state.

Before · traditional processing

Payment fees were ≈2.9%, and every cleared payment created another front-desk task.

  1. Watch the processor
  2. Find the patient and ledger
  3. Re-key the payment details
  4. Reconcile outside the posting action
After · ACH plus controlled posting

Fees are ≈0.7%. The common posting path is automated, and uncertain states stop for review.

  1. Retrieve an opaque payment event
  2. Match the local account or stop
  3. Post into Dentrix
  4. Read back and record proof or failure
The system boundary

Move the payment event. Keep patient identity inside the clinic.

The cloud service carries opaque payment information. Patient linkage, posting logic, exception detail, and Dentrix interaction remain on the clinic workstation.

Cloud boundary · No patient identity
Clinic boundary · Patient identity remains local
Cleared event
Stripe

Records a cleared ACH payment.

Opaque transport
Cloud service

Holds only the payment information needed for retrieval.

Clinic pull
Clinic-side service

Runs on the clinic’s Windows computer.

Local decision
Patient match

Resolves the local account or stops for staff.

Ledger action
Dentrix post

Enters the payment through the existing interface.

Completion proof
Read-back

Confirms the ledger or records failure.

What crosses: opaque payment information needed to retrieve work.

What stays: patient linkage, account context, posting detail, and exception evidence.

Human control

The important decisions are the ones the system refuses to make.

The normal path can move quickly because ambiguous or high-risk states stop, remain visible, and return to staff.

No patient identity in the cloud

Patient linkage remains in the clinic environment.

No guess under ambiguity

An uncertain patient match enters an exception state.

No duplicate posting

Idempotency and deduplication controls protect the ledger.

No silent success

The system reads the ledger back and records confirmation or a structured failure.

Result

Payment fees moved from ≈2.9% to ≈0.7%. The integration is running in production, with patient matching, exception handling, posting controls, and ledger read-back inside the clinic.

See the product

CHOMP is designed around this payment path.

Explore the product built around lower-cost ACH and clinic-side payment posting.

Explore CHOMP