Insurance prior-authorization, how does the checkout that pauses, requests payer auth, and resumes actually work?

The pattern is an order-state machine, not a checkout hack.

SKUs that require prior auth are flagged with a product attribute (requires_prior_auth = 1) and tagged with the payer-matrix segment (Medicare DME MAC Jurisdiction A/B/C/D, Medicaid by state, commercial by payer ID). At checkout, if any cart line item has the flag and the customer’s insurance is in the matrix:

• Place order → order created in state pending_prior_auth, payment authorized but not captured, inventory reserved.
• Prior-auth request fires → via your clearinghouse (Availity, Change Healthcare, Waystar) using X12 278 transactions, or via the payer’s portal API (UHC PreCheck, Aetna eviCore, Anthem AIM, BCBS ProPAT).
• Patient + clinician notified via email/SMS with the auth-request number and expected turnaround (typical: 3-15 business days depending on payer + service code).
• Auth approved → order auto-transitions to ready_to_fulfill, payment captures, EDI 850 fires to distributor.
• Auth denied → order auto-cancels, payment auth releases, customer-service handoff with the denial reason + appeal path.

The hardest part isn’t the code, it’s the payer matrix. Each payer has different prior-auth rules per HCPCS code, and the rules change quarterly. We refresh the matrix via the clearinghouse and Optum’s payer-policy library; the retainer covers this.