PayPal scheduling integration guide
Add another familiar checkout option for paid time. The intended connection would authorize the required charge before a paid appointment becomes a confirmed reservation.
PROVIDER SETUP GUIDE. Documented workflow, not a live PayPal connection.
PayPal 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 PayPal 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. Add another familiar checkout option for paid time. It sits beside the other payments connections and supports the paid appointment scheduling requirements.
PayPal-specific integration decisions
Rely on authoritative PayPal order or capture state—not browser return alone—and map pending review, currency, refund, and dispute behavior.
Check these against current PayPal documentation and your account edition; the verification standard explains how provider claims are reviewed.
PayPal provider review points
- Rely on authoritative paypal order or capture state—not browser return alone—
- Map pending review
- Dispute behavior
Scheduling data and actions in the workflow
For PayPal, 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 PayPal 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
PayPal 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 PayPal to confirm production status before building on it.
Map the PayPal workflow before connecting it.
Bring the trigger, required data, failure path, and desired guest outcome.
Discuss the connectionPayPal integration questions
Provider-specific answers for teams planning a PayPal scheduling connection.
Why offer PayPal alongside card payment?
In several markets a meaningful share of buyers will not enter card details but will pay through PayPal. It is a conversion decision more than a technical one.
How do PayPal disputes affect a booked meeting?
A dispute can arrive long after the meeting. Keep the booking record, the terms shown at checkout, and the attendance evidence together so a claim can be answered.
Does PayPal support the same refund window?
Refund rules and timing differ from card processors. Confirm the exact window before publishing a cancellation policy you cannot honor.
PayPal data and lifecycle decisions
1. Choose the identity model
PayPal orders move through created, approved, and captured states. Only a captured order means money moved. Never confirm a paid booking on the return-to-site redirect alone.
2. Protect business ownership
The PayPal business account owns refunds and disputes, and its currency settings decide what a guest is charged. Decide whether a refund cancels the booking.
3. Map the full lifecycle
Hold the slot on order creation, confirm on capture, release on expiry, and record refunds and disputes. Pending-review states need a visible holding message rather than a silent confirmation.
4. Keep traceable evidence
Store the order ID and capture ID with the booking. Test a pending review, a currency mismatch, a duplicate webhook, and a refund from the PayPal side.
