Set up Party Bookings: payments and email

These instructions describe FECForge 1.32.35. If a control is missing, check your role and installed version before continuing.

1. Prepare your account and source information

   Read Party Bookings: start here first. Sign in as owner for payment and email setup. Managers cannot connect provider accounts or change sender secrets.

1. Read the environment shown in Payment setup

   Open Party Bookings → Settings → Payments & deposits. Test means rehearsal only: use fictional guest details and the provider’s test payment controls, never a real card. Live means real-money activity may be possible only when the service administrator has enabled it and all readiness checks pass.

2. Use your venue’s Stripe test account

   Prefer Connect Stripe and approve the venue account on Stripe’s website. If sign-in is unavailable, the service administrator needs to finish the Stripe application setup; the alternate restricted-key method remains available. Complete the full test booking rehearsal before relying on either route.

3. Match the service environment

   For a rehearsal, the service must show Test / Sandbox. Use keys or authorize a seller in the same mode. Account verification, signed webhook delivery and checkout readiness are separate checks. Connecting an account does not change the service environment or enable live charges. Square uses Connect Square OAuth; do not paste a personal access token.

4. Keep your FECForge password local

   The hosted connection page does not need your FECForge password. Provider sign-in uses the provider’s own website. For the alternate Stripe key method, create a one-time setup code from HTTPS or from a browser running on the FECForge server at localhost. Enter that code on the hosted page, then enter keys there only. Never send keys, setup codes or links to support.

5. Keep ownership with the venue

   Authorize the venue’s dedicated Sandbox or test seller, not the Stripe account used by the FECForge website for license sales, another venue’s account, or a staff member’s unrelated account. The website checkout and Party Bookings connection are separate systems.

1. Open the intended Sandbox seller first

   In Square Developer Console, choose Sandbox, open Sandbox test accounts, and open the Square Dashboard for the dedicated venue test seller. Square keeps Sandbox accounts, locations, tokens, and transactions separate from production.

2. Authorize Square

   As the venue owner, open Party Bookings → Settings → Payments & deposits, choose Square, then select Connect Square. Approve access for the intended venue seller in the provider tab. No Square token or webhook signing key is entered in the local app.

3. Return and check the saved account

   Return to FECForge and select Check readiness if the account has not updated yet. The service manages webhook delivery for OAuth connections. A return page alone is not proof of a saved connection; check the account shown in FECForge.

4. Select the receiving location

   Choose Check readiness. Set Provider used at checkout to Square, select the active USD Sandbox location, choose the guest-payment policy, and save payment setup. If only one active location exists, FECForge may place it in the draft; saving is still required.

5. Verify delivery and finish the rehearsal

   Save the policy and require the test-checkout gate to be ready. Complete a synthetic booking with Square’s test-payment controls, then choose Check readiness and confirm its signed event and expected paid amount in the ledger. Never use a real card.

1. Choose the recommended sign-in

   As the owner, open Party Bookings → Settings → Payments & deposits, choose Stripe and select Connect Stripe. Sign in on Stripe’s website and approve the correct venue account in the displayed environment. This route works from your local HTTP address and asks for no FECForge password or API keys.

2. Check the saved account and deposit policy

   Return to FECForge and select Check readiness. Verify the account identity and finish any Stripe onboarding requirements. Select Stripe as the checkout provider, choose the deposit policy and save. The service manages webhooks for provider-authorized connections. Complete a test booking and verify its signed event and payment ledger.

3. If sign-in is not available

   The FECForge service administrator must finish Stripe Connect configuration before this button can be used. An account controlled by another platform may also be ineligible for this authorization; follow Stripe’s instructions and do not disconnect another integration blindly. The alternate key method below does not require FECForge Connect approval.

1. Create a one-time setup code

   Expand Alternate connection: use API keys. Open FECForge through HTTPS, or use a browser on the computer running the FECForge server at its localhost address. Create a setup code, then continue to the hosted HTTPS page and enter that code. It expires after ten minutes and is not your FECForge password. On a different computer, localhost points to that computer, not your venue server. Ordinary HTTP LAN addresses cannot create manual setup codes; use the recommended provider sign-in instead.

2. Read the hosted page’s required permissions

   Use the venue’s Stripe account in the matching test/live environment. Follow the hosted setup page and Stripe’s current restricted-key instructions. Grant only the permissions that page requires. Never paste a publishable key or the FECForge license-sales account’s key. Ask the service administrator if the requirements are unclear.

3. Configure the endpoint shown on the hosted page

   Follow Stripe’s current webhook instructions using the exact hosted URL and event list displayed by FECForge. Do not use your local venue-network address. Keep the endpoint and signing secret in the same Stripe account and environment as the restricted key.

4. Save on the hosted page, then return

   On the hosted HTTPS setup page, paste the restricted API key beginning rk_test_ and the webhook signing secret beginning whsec_ into their labeled fields. Both are required; a publishable key is not needed. Saving checks the account without creating a charge. Return to FECForge and check the saved account. To rotate keys, create a fresh code and link from the alternate connection panel. This alternate method does not require FECForge’s Stripe account or Connect onboarding.

5. Complete a test booking, then verify delivery

   The read-only account test creates no charge and cannot verify the signing secret or checkout-write permissions. Save your deposit policy, check that the deployment’s test-checkout gate is ready, and complete a booking with Stripe test payment details. Verify its actual signed event and expected paid amount afterward. You can also resend an existing event from this Stripe Sandbox account; a fabricated Dashboard sample is not sufficient because the service verifies account ownership through Stripe’s Events API. A delivery timestamp is not required to start test checkout, and a success-page redirect alone is never payment proof.

1. Enter each fixed package deposit

   Open Packages & add-ons. Set the Base price and Package deposit for each active package. A package deposit cannot exceed that package’s base price. Save and publish package changes before expecting the guest site to use them.

2. Choose the initial booking rule

   In the Test or Live payment setup shown for your deployment, choose No payment, Use each package’s deposit, Percentage across all packages, or Full amount for all packages. Percentage applies to the complete booking total; the fixed-package option uses the published package deposit.

3. Check the amount before a test booking

   Use the $300 example in settings, then review the actual guest checkout summary. The server calculates the amount from the published package, guest count, add-ons, and saved payment policy; changing an unsaved draft does not change an existing checkout.

4. Create a later private payment link from the reservation

   Open the reservation’s Payments tab and find Guest online payment. Review Maximum additional online before creating its private link. Creating a replacement invalidates the previous link. Copying it does not email it. This is an advance payment, not the final invoice settlement.

5. Let returning guests request their own private link

   On the guest site, choose Already booked? Get a payment link and enter the booking reference plus the adult contact’s booking email. The response does not reveal whether the details matched; a reference alone never opens a booking. An eligible request queues a private link that expires after one hour. Requests are limited to prevent abuse. Delivery still depends on sender readiness, the service’s delivery mode, and the permitted recipient.

6. Keep later payments within the saved package base

   The later Pay toward your party page accepts only an amount up to the reservation’s saved discounted package base after verified and in-progress payments. Extra guests, add-ons, room surcharges and extra-birthday-person fees are excluded from this later payment and remain due to the venue. Only future scheduled pending or confirmed reservations can accept another payment. Unresolved payment, refund or dispute records can block further payments until reconciled.

1. Prepare a dedicated sending account

   Use a venue-controlled mailbox and the SMTP hostname, username, and password supplied by its mail provider. Authorize the From address, monitor the Reply-to address, and finish the provider’s SPF, DKIM, and DMARC setup. Party Bookings does not read the mailbox or process replies.

2. Open the sender settings

   As the owner, open Party Bookings → Settings → Email. The Confirmation email panel contains the sender controls. Choose Existing email / SMTP.

3. Choose the encrypted transport

   Select your provider preset or enter its public SMTP hostname. Use SSL/TLS on port 465 or STARTTLS on port 587. Unencrypted SMTP, custom ports, IP literals, and private-network mail servers are rejected.

4. Save every field together

   Enter From name, From email, Reply-to, username, and the current SMTP password, then save. The password is write-only and is required again on every save, including when changing a different sender field. Do not send it to FECForge support.

5. Test the saved connection first

   Choose Test saved connection. This verifies the saved hostname, encryption, and credentials without sending email. Save or discard any draft changes before testing.

6. Send one permitted test email

   Enter a test recipient allowed by the displayed delivery mode, then choose Send test email. Restricted deployments may allow only an administrator-approved address. This is a real send, unlike Preview guest emails.

7. Check the test mailbox

   Look in the inbox, spam, and quarantine folders. SMTP acceptance does not prove inbox delivery. Ask the mail provider to check its logs if the message is absent; do not repeatedly send an uncertain job.

8. Distinguish the booking receipt from the questionnaire

   A successful booking request queues an initial receipt with its reference, party details, saved totals and verified payment amount. A checkout that has only started does not queue this receipt; paid bookings wait for verified payment. The receipt says staff approval is pending and is not final confirmation. Staff confirmation sends the package’s planning questionnaire, when configured; submitting that form creates a separate planning-response receipt. Check Email activity and the mailbox instead of assuming delivery from a booking success screen.

9. Follow your mail provider’s current authentication rules

   Ask the mailbox administrator for supported SMTP credentials and sender authorization. Some providers require an app password or disable password-based SMTP. FECForge does not offer Google or Microsoft mailbox OAuth; do not weaken mailbox security to make a connection test pass.

1. Hosted setup or Square authorization is unavailable

   Ask the service administrator to check hosted HTTPS setup and secure credential storage for Stripe, or the provider application for Square OAuth. No customer-side HTTPS configuration is required. Do not switch to live credentials to work around this state; share only the safe readiness message with support.

2. Connection link expired or the tab was blocked

   Choose Connect again for a fresh link. If the browser blocks the new tab, use the Continue to Square or Continue to Stripe link shown by FECForge. Do not reuse an old callback address.

3. Connected but checkout is not ready

   Confirm that the saved provider matches the connected test account, a payment mode other than No payment is selected, and Square has an active USD location. Then choose Check readiness. Test checkout may also be disabled by the operator.

4. Returned from checkout but payment is still waiting

   A provider redirect is not payment proof. Keep the same browser session, allow session storage, and choose Check status while the hold is active. Do not create repeated checkouts when the result is uncertain; staff must reconcile recovery-required or paid-needs-attention states.

5. SMTP test reports sign-in, TLS, or server errors

   For sign-in failure, verify the full username and provider-specific password, save all fields, then test again. For TLS failure, match 465 with SSL/TLS or 587 with STARTTLS. For server-not-found, copy the public hostname from the mail provider instead of entering an IP address.

6. Email was accepted but is not in the inbox

   Check spam or quarantine, the intended recipient permitted by the delivery mode, sender authorization, and provider logs. Do not label SMTP accepted as delivered or keep resending an ambiguous job; the first handoff may have succeeded.

1. Find your single fictional test booking in Reservations.

   Its saved amount, individual provider payment, and status should agree. Check the actual permitted test mailbox separately; a redirect and SMTP acceptance are not proof of payment or inbox delivery.

2. If the result is not what you expected

   Keep the reference, time, provider, and safe readiness error. Never include card details, private links, connection tokens, SMTP passwords, OAuth codes, or API keys in support messages.