Technical Case Study
A mediation can involve one appointment but two separate payment responsibilities. For TexMediator, I connected scheduling, structured intake data, server-side automation, and Stripe so the second party's payment request could be generated without the mediator recreating it by hand.
A two-party mediation payment workflow keeps the mediation organized as one scheduled matter while allowing each responsible party to handle its own payment. In the TexMediator implementation, the booking form collects the second party's billing email, a scheduling webhook sends the appointment data to server-side automation, and the integration creates and sends the appropriate Stripe invoice for Party B.
The Business Problem
A conventional checkout flow assumes one customer is paying for one transaction. Mediation can be different: two law firms or parties may be responsible for separate shares of the same scheduled service.
The mediation itself still needed one date, one time, one matter, one intake process, and one set of scheduling details. Creating a second appointment just to collect another payment would fragment the operational record.
The workflow needed a reliable way to identify the second party's billing contact and issue the correct payment request without asking the first party to cover the entire mediation fee.
Re-entering names, email addresses, appointment details, and payment amounts after every qualifying booking would create repetitive work and another opportunity for information to be copied incorrectly.
System Architecture
The workflow uses the information already collected during scheduling to decide when a second-party invoice should be created and where it should be sent.
An attorney selects the mediation service, date, and time through the scheduling experience. The appointment becomes the central record for the workflow.
The scheduling form collects the case information needed for the appointment, including the second party's email address used by the payment automation.
When a qualifying appointment is scheduled, Acuity sends a signed webhook to the server-side integration. The endpoint verifies the request before processing the booking data.
The function reads the appointment and intake data, finds the Party B billing email, and applies the workflow rules for the selected mediation type.
The server-side integration uses Stripe to create the second-party invoice for the appropriate mediation share instead of requiring the mediator to build that invoice manually.
Stripe sends the invoice to the second party's billing email. The appointment remains the operational center of the mediation while the payment responsibility is handled separately.
Data Flow
Mediation booking → Acuity Scheduling → structured intake data → signed webhook → server-side function → Stripe → separate Party B invoice.
| Component | Role in the workflow |
|---|---|
| Custom website | Gives the client a branded path into the mediation information, pricing, policies, and booking experience. |
| Acuity Scheduling | Holds the appointment and structured intake information used by the automation. |
| Webhook | Notifies the server-side integration when the relevant scheduling event occurs. |
| Server-side function | Verifies the event, reads the appointment data, applies the business rules, and calls the payment system without exposing private API credentials in browser code. |
| Stripe | Creates and sends the separate invoice used for the second party's payment responsibility. |
The Important Part
The useful part of workflow automation is translating a real business process into explicit rules: when something should happen, which data it should use, and what should happen when required information is missing.
The automation should respond to the intended scheduling event rather than creating invoices from unrelated page views, form visits, or browser-side actions.
The second party's billing information is collected as part of the appointment flow, so the automation can work from structured booking data instead of relying on a later manual handoff.
Payment credentials and webhook validation belong in server-side code. The public website can start the customer journey without exposing private integration secrets to the browser.
Why Automate It
The purpose was not automation for its own sake. It was to remove a repetitive handoff from a real professional-service workflow.
Information already supplied during scheduling can be reused by the billing workflow instead of being typed into another system again.
Each party can receive the payment request intended for that party without turning one law firm into the default payer for the entire mediation.
Scheduling, case intake, confirmation, video-meeting information, and payment steps operate as parts of one designed process rather than as unrelated tools the mediator has to coordinate manually.
See the broader website, intake, scheduling, Zoom, and payment work in the TexMediator case study .
Reusable Architecture
The same architecture can be adapted when one booking or service creates follow-up work for multiple people, departments, customers, or payers. The exact implementation depends on the business rules and the systems being connected.
One engagement can involve multiple responsible parties who need separate invoices, confirmations, or document requests.
A scheduled service can trigger internal tasks, customer follow-up, deposits, balance requests, or participant-specific communication.
Webhooks and APIs can connect forms, calendars, payments, email, databases, and internal systems around a defined business process.
Learn more about custom software development and workflow automation from Renatus .
Frequently Asked Questions
Yes. One mediation can remain a single scheduled matter while the workflow sends separate payment requests to the parties responsible for their own shares.
The booking captures Party B's billing email. A scheduling webhook triggers server-side logic, which reads the appointment data and uses Stripe to create and send the appropriate invoice.
Not for the automated flow. Once the required booking information is present, the integration can create and send the second-party invoice without rebuilding it by hand.
The implementation combines a custom website, Acuity Scheduling intake data, a signed scheduling webhook, a server-side function, and Stripe invoicing.
The server-side function can validate the incoming event, apply the business rules, and communicate with Stripe without placing private payment credentials in public browser code.
Yes. The same event-driven pattern can support other businesses where a booking or form submission needs to trigger participant-specific billing, notifications, records, or internal actions.
Renatus builds focused integrations and custom software around real business processes, including scheduling, forms, payments, databases, portals, and operational automation.