Paid meeting scheduling

Short answer: Connect checkout, cancellation policy, and booking confirmation. Begin with “Connect the payment account and choose price and currency.” and verify the result through the public participant path.

Before you change the setup

Identify the exact organizer, event type, public link, and time zone involved before editing anything. Save the current behavior or take a screenshot so the test has a reliable before-and-after comparison.

How to complete this task

Connect the payment account and choose price and currency.Start with the intended outcome and the record that controls it.
Publish refund and cancellation terms beside the paid event.Review every related setting before saving so one rule does not mask another.
Test approved, declined, abandoned, and duplicated checkout attempts.Keep private data and guest-facing information clearly separated.
Reconcile the provider transaction with the confirmed booking.Complete the same path an external participant will use.

Verify the participant result

Run one successful case and one edge case. Confirm the public title, local time, available choices, duration, location, confirmation, calendar file, and private management path as applicable. Then check the organizer view and any email delivery record. A saved setting is not proof that the scheduling lifecycle worked.

Troubleshoot paid meeting scheduling

These are the failures reported most often for this specific task, with the cause that explains each one.

A payment succeeded but no booking exists.

Never leave this state unresolved. Reconcile the provider transaction against the booking record and either issue the meeting or refund.

A guest disputes a cancellation charge.

Refund and cancellation terms must be visible beside the paid event before checkout, not only in the confirmation email.

Duplicate charges appeared.

Test the double-submit and browser-back cases specifically. Checkout must be idempotent for a single booking attempt.

Related Meetin.gs help

Return to the Meetin.gs Help Center for the adjacent configuration guide, or send the exact event code and expected result when the documented checks do not explain the behavior.

Paid meeting scheduling acceptance checklist

Use the following evidence map while completing this specific task. It ties each action to an observable result so another person can repeat the setup or diagnose it without guessing.

1. Connect the payment account and choose price and currency.

Write down the intended result, the organizer or account that owns it, and the exact event type or public link in scope. This prevents a correct change from being applied to the wrong record.

2. Publish refund and cancellation terms beside the paid event.

Inspect the related rules and dependencies before saving. Record the previous value and the new value, including the time zone, provider account, or team owner when one controls the outcome.

3. Test approved, declined, abandoned, and duplicated checkout attempts.

Review what an invitee can see and what remains private. Keep only the context needed to complete the meeting task, and make the fallback understandable when information is missing.

4. Reconcile the provider transaction with the confirmed booking.

Complete this step from a signed-out participant session. Preserve the resulting URL or event code, displayed state, message, calendar output, and any provider response needed to prove the task worked.

Evidence type	What to record
Controlling input	The account, event type, setting, public link, and time zone used in the test.
Participant result	The exact choices, context, confirmation, or error visible while signed out.
Lifecycle result	What changes after confirmation, finalization, cancellation, reschedule, or retry.
Failure boundary	The missing permission, unavailable dependency, invalid input, or conflicting rule that prevents success.
Owner	The person responsible for correcting the setting, provider connection, content, or customer communication.

Evidence type

What to record

Controlling input

The account, event type, setting, public link, and time zone used in the test.

Participant result

The exact choices, context, confirmation, or error visible while signed out.

Lifecycle result

What changes after confirmation, finalization, cancellation, reschedule, or retry.

Failure boundary

The missing permission, unavailable dependency, invalid input, or conflicting rule that prevents success.

Owner

The person responsible for correcting the setting, provider connection, content, or customer communication.

RELATED CAPABILITY

Payments for booked time

Add a payment requirement to selected event types and connect confirmation to successful checkout. This page explains payments for booked time requirements. Confirm production availability before depending on this capability.

Review scope

Paid meeting scheduling: frequently asked questions

Short answers to the questions organizers ask most about paid meeting scheduling.

Can Meetin.gs collect payment at booking?

Payment collection is documented as a requirement rather than a shipped feature. Confirm availability before designing a paid workflow around it.

Where should refund terms appear?

Beside the paid event, before checkout. Terms that only appear in the confirmation email are discovered after the dispute has already started.

What payment cases must be tested?

Approved, declined, abandoned, duplicated, and refunded. The dangerous state is a successful payment with no booking, so reconcile the provider transaction against the meeting record.

Should deposits or full payment be taken?

A deposit reduces no-shows with less refund friction; full payment suits fixed-scope sessions. State the cancellation window either way.