Key takeaways
- To configure booking deposits on WordPress with Javis Booking Pro Worrdpress Plugin, define the business rule first, then set the guest threshold and fixed deposit amount, decide when the payment step appears, enable a fully configured gateway or bank transfer, publish the cancellation terms, and test successful, failed, abandoned, replayed, and refunded transactions before accepting live bookings.
Booking deposit start with a deposit policy, not a gateway
A deposit is a risk-control rule. It may protect scarce staff time, equipment, rooms, tables, group capacity, or advance preparation. It also adds checkout friction, reconciliation, refunds, chargeback exposure, and customer questions. State the specific problem and baseline no-show or cancellation cost before choosing an amount.
Write the policy in plain language: who pays, how much, when it is collected, whether it is refundable, the cancellation deadline, what happens to the remaining balance, and how a customer requests a change. Review local consumer, tax, privacy, and payment rules with the appropriate adviser. Plugin configuration implements the policy; it does not make the policy lawful or fair.
Understand JavisTab’s deposit model
The supplied Javis Booking Pro 6.7.8 code exposes these core controls:
- deposit_threshold: a guest-count trigger for the conditional large-party rule.
- deposit_amount: a fixed amount in the site’s base currency.
- payment_on_form: whether the ordinary booking flow shows payment choices.
- payment_off_require_deposit: an opt-in exception that requires a deposit for parties at or above the threshold when ordinary payment is hidden.
- Payment paths for at venue, deposit required, and prepaid.
Below the threshold, a payment-free form can stay payment-free. At or above it, the conditional rule changes the journey to a mandatory deposit. This is particularly useful for restaurants and group bookings, but the general principle applies whenever party size predicts risk. Other multi-service price logic in the build should be tested separately; do not assume every flow uses the same fixed-deposit presentation.
Prerequisites
- Javis Booking Pro installed on a staging copy and a complete test booking page.
- Correct business timezone, base currency, tax, service charge, package, and price data.
- Written deposit, cancellation, refund, no-show, and remaining-balance policies.
- Sandbox credentials and webhook access for the selected gateway, or verified bank-transfer instructions.
- Authenticated transactional email and a staff owner for pending or disputed payments.
- A backup and rollback path before changing an existing live payment workflow.
Step 1: choose one of three operating rules
| Rule | When it fits | Configuration intent |
|---|---|---|
| Payment choices for every booking | Customers may pay later, secure with a deposit, or prepay | Keep the payment step visible and expose only approved choices |
| Deposit only above a threshold | Small bookings have low risk; large groups require commitment | Hide ordinary payment, enable conditional deposit, set threshold and fixed amount |
| Manual pending collection | Bank transfer or staff collection is deliberate | Show instructions and keep status pending until receipt is reconciled |
Do not expose mutually confusing choices. If full prepayment receives no discount, set any prepaid discount to zero and label it clearly. If a deposit is mandatory, do not display pay at venue as though it were equivalent.
Step 2: set the threshold and fixed amount
Open the booking settings in the installed build and enter the guest count that triggers the rule. Set the standard deposit in the base currency. Test one booking below the threshold, one exactly at it, and one above it. The boundary case catches off-by-one assumptions that ordinary previewing misses.
Choose an amount proportionate to expected loss and simple to explain. A fixed amount is predictable for staff and guests, but it represents a different share of a low-value and high-value booking. If the business needs percentage deposits by service, package, or total, prove the exact selected flow supports that calculation or select a tool whose pricing model does. Do not describe a fixed threshold as percentage functionality.
Step 3: decide when payment appears
When payment_on_form is enabled, guests can see the payment cards permitted by the visibility settings. Use this for optional pay-later, deposit, or prepaid journeys. When it is disabled, the ordinary form skips payment. Enabling payment_off_require_deposit adds the payment step back only for qualifying large parties.
Preview the complete summary. It should distinguish total price, amount due now, amount already paid, and balance due later. The confirmation page and email must use the same terms. “Pay $50” is incomplete if the guest cannot see whether $50 is the full price or a non-refundable deposit.
Step 4: configure a collectable payment method
Version 6.7.8 registers PayPal, Stripe Payment, Square, Razorpay, OnePay, and bank transfer. A registered logo is not automatically usable. The frontend should offer a method only when required server-side credentials or manual instructions are ready. Secret keys and signature material must remain server-side.
| Method | Essential setup | Acceptance evidence |
|---|---|---|
| Stripe | Publishable/secret keys and webhook secret for the correct mode | Signed success event maps once to the expected booking and amount |
| PayPal | Sandbox/live client credentials and callback/webhook configuration | Created and captured order agrees with booking, currency, and email |
| Square | Application, token, location, environment, and signature settings | Captured payment and replayed event remain consistent and idempotent |
| Razorpay | Key ID/secret and webhook secret | Captured amount uses correct minor units and verified signature |
| OnePay | Merchant/access/hash credentials, test/live mode, return and IPN | Secure hash validates and closing the browser does not lose final state |
| Bank transfer | Bank details, booking-reference instruction, review owner and SLA | Booking remains pending until staff matches reference and amount |
Provider availability, onboarding, currencies, fees, reserves, and prohibited-business rules are separate from the plugin. Confirm them with the provider before launch.
Step 5: display material terms before confirmation
Place a short payment summary beside the final action: deposit amount, balance, cancellation deadline, refund treatment, and a link to the complete policy. Include tax or service charge treatment where relevant. Require acknowledgement only when legally and operationally justified; a hidden post-payment email is not informed notice.
Use consistent nouns. If the interface calls the money a “deposit,” the receipt should not call it “full payment.” If a bank transfer is only a request awaiting staff review, the page should say “pending” rather than “confirmed.”
Step 6: test totals and boundaries
Build a matrix that combines party size, service or package, extras, coupon, tax, service charge, currency, and payment choice. Include zero-decimal currencies such as VND or JPY where used. Compare the form, booking record, gateway minor units, invoice, email, refund, and accounting export.
If price changes after a deposit—for example, party size increases—define whether the additional deposit is collected, the balance changes, or staff approves manually. The plugin cannot choose that policy on behalf of the business.
Step 7: test the payment lifecycle
- Submit below, exactly at, and above the threshold.
- Complete each enabled method in its sandbox or test environment.
- Trigger a card decline, invalid callback, expired session, and user abandonment.
- Close the browser after provider success but before the return page loads.
- Deliver the same signed webhook twice; no duplicate payment, confirmation, invoice, or loyalty side effect should appear.
- Retry a failed payment against the same booking and verify references remain traceable.
- Issue a full and, if supported by the workflow, partial refund; confirm all records and messages.
- Change and cancel bookings before and after the refund deadline.
- Reconcile a manual bank transfer with an incorrect reference or amount.
Never infer payment solely from a browser success URL. Server-to-server verification and an auditable payment record protect against closed tabs and forged returns.
Step 8: launch with operational controls
Switch every credential and endpoint deliberately from test to live. Complete one low-value controlled transaction, then reconcile it in WordPress and the provider dashboard. Restrict access to payment settings, enable logs without storing secrets or full card data, and document escalation for pending, duplicate, disputed, and refunded cases.
Monitor conversion, payment failures, gateway latency, pending age, refunds, chargebacks, no-shows, and customer questions. Compare the no-show benefit with checkout abandonment and administration cost. A deposit rule should be adjusted with evidence, not left unchanged because it was difficult to configure.
Troubleshooting
The deposit step does not appear
Check whether the booking is below the guest threshold, whether ordinary payment is hidden, whether the conditional switch is enabled, and whether a collectable method is ready. Test the exact threshold rather than only a very small and very large party.
Payment succeeded but the booking is pending
Compare environment, booking reference, amount, currency, callback URL, signature secret, gateway event, and plugin log. A return page is not proof. Reconcile the signed provider event and use an intentional manual review process while investigating.
The deposit total is wrong
Verify base currency, zero-decimal handling, party size, package, extras, coupon, tax, service charge, and fixed amount. Compare values before and after gateway minor-unit conversion. Do not patch the display alone if the stored or charged amount differs.
Customers receive duplicate emails
Look for duplicate form submission, repeated provider events, manual status changes, or non-idempotent automation. Replaying a legitimate webhook should converge on the same state rather than repeat side effects.
Frequently asked questions
Can JavisTab charge a deposit only for large bookings?
Yes. In version 6.7.8, an opt-in rule can require the fixed deposit when guest count reaches the configured threshold even if the ordinary payment step is off. Test below, exactly at, and above the threshold and ensure a payment or deliberate manual route is available.
Is the standard deposit fixed or percentage based?
The core restaurant-style controls described here use a fixed base-currency deposit_amount and a guest-count trigger. Do not market that rule as percentage based. If a different multi-service flow exposes percentage behavior, validate its calculation, scope, and selected version independently.
What if no gateway is enabled?
The workflow should not falsely mark the reservation paid. Use a documented manual-pending process or enable a properly configured gateway/bank-transfer method before requiring deposits. Staff must know how and when a pending booking becomes confirmed.
Should deposits be refundable?
That is a business and legal decision, not a plugin default. Make the rule proportionate, state it before payment, and define exceptions and staff authority. Track disputes, refunds, no-shows, and conversion so the policy can be evaluated rather than assumed effective.
How often should gateway settings be tested?
Run a controlled live transaction after initial setup and after credential rotation, webhook change, domain or firewall change, significant plugin/WordPress/PHP update, or payment-provider notice. Review failed and pending transactions continuously and keep a repeatable reconciliation checklist.
NEXT STEP Review JavisTab’s online-payment guide and current pricing, configure the rule on staging, and do not enable mandatory deposits until every lifecycle test reconciles.
