Stripe scheduling integration guide
Collect payment before confirming selected events. The intended connection would authorize the required charge before a paid appointment becomes a confirmed reservation.
PROVIDER SETUP GUIDE. Documented workflow, not a live Stripe connection.
Stripe at a glance
| Category | Payments |
|---|---|
| Status | Provider setup guide |
| Job | Authorize the required charge before a paid appointment becomes a confirmed reservation |
| Data exchanged | Price, currency, and payment description; checkout result and provider transaction identifier; booking, refund, and cancellation relationship |
| Related capability | Paid appointment scheduling |
What the Stripe connection is designed to do
For payments workflows, the important job is to authorize the required charge before a paid appointment becomes a confirmed reservation. Collect payment before confirming selected events. It sits beside the other payments connections and supports the paid appointment scheduling requirements.
Stripe-specific integration decisions
Use an authoritative Checkout or PaymentIntent state and stable transaction identifier to reconcile slot reservation, tax, refunds, disputes, and retries.
Check these against current Stripe documentation and your account edition; the verification standard explains how provider claims are reviewed.
Stripe provider review points
- Use an authoritative checkout or paymentintent state
- Stable transaction identifier to reconcile slot reservation
Scheduling data and actions in the workflow
For Stripe, these are the data groups the connection exchanges. Record the source, destination, and owner of each before granting access:
- Price, currency, and payment description
- Checkout result and provider transaction identifier
- Booking, refund, and cancellation relationship
Common Stripe scheduling use cases
- Reducing unpaid reservations for professional time
- Offering a deposit for a high-value appointment
- Linking the refund policy to the booking record
Stripe setup and verification checklist
- Test success, decline, abandonment, and duplicate submission.
- Publish cancellation, tax, and refund terms before checkout.
- Reconcile booking and provider records with a stable transaction ID.
Availability, permissions, and limits
Payment, tax, refund, and dispute obligations vary by business and location. Meetin.gs should not confirm the time until payment state is authoritative.
Retry and duplicate handling is covered in the API and webhook guide; ask about Stripe to confirm production status before building on it.
Map the Stripe workflow before connecting it.
Bring the trigger, required data, failure path, and desired guest outcome.
Discuss the connectionStripe integration questions
Provider-specific answers for teams planning a Stripe scheduling connection.
What happens if a Stripe payment succeeds but the booking fails?
This is the state that must never be left unresolved. Reconcile the Stripe payment intent against the meeting record and either issue the booking or refund automatically.
How are refunds handled when a meeting is cancelled?
Define the rule before you take money: full refund inside a stated window, partial or none outside it, and publish the terms beside the paid event rather than only in the confirmation.
Is Stripe Checkout or a custom payment flow better?
Checkout carries less compliance burden because card data never touches your systems. Choose a custom flow only when you have a requirement Checkout genuinely cannot meet.
Stripe data and lifecycle decisions
1. Choose the identity model
A paid booking has two identities: the Meetin.gs reservation and the Stripe Checkout Session or PaymentIntent. The Stripe object is the source of truth for whether money moved; the reservation must not confirm on a browser redirect alone.
2. Protect business ownership
The Stripe account that receives funds owns refund and dispute handling. Decide who can issue a refund and whether a refund also cancels the booking, or the two drift apart.
3. Map the full lifecycle
Hold the slot when checkout begins, confirm on the webhook that says payment succeeded, release the slot if checkout expires, and record refunds and disputes against the booking. A retry after a failed card must not create a second reservation.
4. Keep traceable evidence
Store the PaymentIntent ID and the Meetin.gs booking code together. Test an abandoned checkout, a declined card, a duplicate webhook delivery, and a refund issued from the Stripe dashboard.
