Payment Processing in BastionGlass: Stripe Integration for Field Services

Payment Complexity in Auto Glass

Auto glass payment is not a simple one-time charge. Jobs can be paid through insurance, out of pocket, or a combination. Insurance claims involve deductibles that the customer pays directly while the insurance company pays the remainder separately. Some customers want to pay in full upfront, others want to pay on completion. Mobile technicians need to collect payments in the field, sometimes with unreliable cell service.

Before BastionGlass, Chris was using a separate Square terminal and manually reconciling payments with jobs in his spreadsheet. This worked but created accounting gaps — a payment collected in the field might not get recorded against the right job until the end of the day, and matching insurance reimbursements to specific jobs was a weekly reconciliation headache.

The goal for BastionGlass's payment system was simple: every payment is automatically associated with a job, every job's payment status is visible in real time, and the technician should be able to collect payment in two taps.

Stripe as the Payment Foundation

We chose Stripe for BastionGlass's payment processing for several reasons beyond the obvious ones. Yes, Stripe has excellent APIs and documentation. But more specifically, Stripe's payment intents model aligns well with the auto glass workflow, where a payment may be authorized at one point and captured at another.

When a customer approves a quote, BastionGlass creates a Stripe payment intent for the customer's portion of the job cost. For cash-pay customers, this is the full amount. For insurance customers, this is the deductible amount. The payment intent is created but not yet confirmed — it represents an obligation to pay, not a completed transaction.

When the technician completes the job and the customer signs the digital work order, the system confirms the payment intent. If the customer is paying with a card on file (captured during the intake process), confirmation happens automatically. If the customer is paying on-site, the technician's mobile interface presents a card input screen using Stripe's mobile elements, which handles the card reading and PCI compliance.

This authorization-then-capture pattern has a practical benefit: the customer's ability to pay is verified before the technician drives to the job. If a card is declined during authorization, the office can resolve the payment issue before dispatching the technician, saving a wasted trip.

Handling Insurance Payments

Insurance payments are the more complex half of auto glass billing. When a job is covered by insurance, the total cost is split between the customer's deductible and the insurance company's reimbursement. These two payments happen through completely different channels — the deductible is collected directly from the customer, while the insurance payment arrives days or weeks later via check or ACH from the insurance company.

BastionGlass models this as a split payment on the job record. The job has a total cost, a customer amount (the deductible), and an insurance amount. The Stripe integration handles the customer amount through the standard payment intent flow. The insurance amount is tracked separately as a receivable.

When the insurance reimbursement arrives, the office staff records it against the specific job. The system reconciles the total — if the insurance payment plus the customer payment equals the quoted amount, the job is marked as fully paid. If there is a discrepancy (insurance companies sometimes pay less than the quoted rate), the system flags the difference for review.

This reconciliation process replaced the manual spreadsheet matching that Chris was doing weekly. Instead of downloading bank statements and hunting for which deposit matches which job, the system presents unmatched insurance payments and suggests likely job matches based on the amount, date, and insurance company. Most matches can be confirmed with a single click.

Field Collection Challenges

Collecting payments in the field introduced technical challenges that do not exist in a traditional e-commerce integration. The biggest was connectivity. Mobile technicians work in parking lots, driveways, and commercial properties where cell signal is unreliable. A payment system that requires a constant connection to process a transaction would fail in exactly the situations where payment collection is needed.

We handled this with Stripe's offline-capable payment flow. The payment intent is created while the technician has connectivity — during the dispatch phase, not at the moment of collection. When the technician completes the job and collects payment, the card information is tokenized on the device using Stripe's SDK. If connectivity is available, the payment confirms immediately. If not, the tokenized payment is queued and confirmed when connectivity returns.

The risk of offline collection is that a card could be declined when the queued payment eventually processes. We mitigated this by requiring card pre-authorization during the scheduling phase. By the time the technician arrives, the customer's card has already been validated and a hold placed for the expected amount. The on-site collection is a confirmation of an already-authorized transaction, not a new charge.

Reporting and Financial Visibility

With payments flowing through Stripe and insurance receivables tracked in BastionGlass, the system provides financial visibility that was previously impossible. The dashboard shows daily, weekly, and monthly revenue broken down by payment type — credit card, cash, insurance. Outstanding insurance receivables are tracked separately, with aging reports that highlight claims that have not been paid within the expected timeframe.

This financial visibility connects to the broader ERP architecture. Revenue data feeds into profitability reporting per job, per technician, and per service area. Chris can see not just total revenue but which types of jobs are most profitable, which service areas generate the most business, and whether insurance-pay or cash-pay jobs contribute more to the bottom line.

The Stripe billing patterns we used in BastionGlass informed the approach we later took with subscription billing in Routiine.io, though the two use cases are different. Transaction-based payments for field services and recurring subscription billing for SaaS share the same payment infrastructure but require different models for authorization, timing, and reconciliation.