Resources | Blog |
Articles |
Booking Demo |
Forum |
Help Pages |
How-To Videos |
Releases |
||||||||||||||||
Resources: Blog | ||
I'm doing some testing and have a fake booking for 2 days away. I have it set up to pay Sec Dep with PP. The rest in check. Well, that works fine if the booking dates are 2 months out, but now I won't even get the check till after they arrive? It needs to be paid in full with Credit Card if that close to the booking....is there a way to set this up? Also is there a book it now feature available where we can approve a fully paid booking?
1 Responses:
Reply »
John Amato, December 6, 2014:
Hi Steve - there's a few things going on here, let me try to address in sections to keep us organized:
1) You are configured to take a refundable security deposit (RSD) as the "pre-payment". You are configured to then receive the full amount due for the booking 30 days prior to arrival.
2) If the booking is made (created) less than 30 days out, then the whole thing is due, and because of this, the whole amount (booking total + RSD) will be considered as the "pre-payment" to secure the booking.
3) For the convenience of the guests, Bookerville will combine these two payments (booking total + RSD) as a single payment. This way, the guest pays one invoice instead of two.
4) You've specified that you want to collect RSD's using PayPal only (I don't blame you, this is much easier/cheaper to refund). Since the combined payment includes an RSD, Bookerville is going to invoice the customer for a single payment, and require the whole thing to be paid via PayPal.
Does this make sense? For most property managers, this is how they want to do it, and I think in your case, it will work in your favor because for "close-in" bookings (those made less than 30-days out), the customers will be required to pay the full amount by PayPal. In a nutshell: I believe it will do what you want it to do, but if your testing shows otherwise, please let me know.
--
The last sentence I'm not sure I understand. If a booking is already paid in full, then it is already "approved", or in Bookerville terminology, it is no longer a Booking Request, but an actual booking (blocking dates on your calendar). Bookerville is structured this way because that's how most property managers want to do it: don't block dates on your calendar until at least a pre-payment has been made.
You are running in Bookerville's "Manager-Centric" mode, so bookings start out as Booking Requests (which do not block dates). Only you, the manager, can convert these into actual bookings, which block the dates.
Essentially, subsequent payments cannot be solicited for Booking Requests, only "pre-payments" can be. And this is usually done by the manager sending the guest a Quote email, which contains a link to take the guest through the "Confirm Quote" process. This Confirm Quote process typically converts the Booking Request into an actual booking (blocks the dates), and collects any "pre-payments" required, all in one step. If it happens to be a "close-in" booking (< 30 days out, in your case), then it will collect the full amount (booking total + RSD).
Does this help?
1) You are configured to take a refundable security deposit (RSD) as the "pre-payment". You are configured to then receive the full amount due for the booking 30 days prior to arrival.
2) If the booking is made (created) less than 30 days out, then the whole thing is due, and because of this, the whole amount (booking total + RSD) will be considered as the "pre-payment" to secure the booking.
3) For the convenience of the guests, Bookerville will combine these two payments (booking total + RSD) as a single payment. This way, the guest pays one invoice instead of two.
4) You've specified that you want to collect RSD's using PayPal only (I don't blame you, this is much easier/cheaper to refund). Since the combined payment includes an RSD, Bookerville is going to invoice the customer for a single payment, and require the whole thing to be paid via PayPal.
Does this make sense? For most property managers, this is how they want to do it, and I think in your case, it will work in your favor because for "close-in" bookings (those made less than 30-days out), the customers will be required to pay the full amount by PayPal. In a nutshell: I believe it will do what you want it to do, but if your testing shows otherwise, please let me know.
--
The last sentence I'm not sure I understand. If a booking is already paid in full, then it is already "approved", or in Bookerville terminology, it is no longer a Booking Request, but an actual booking (blocking dates on your calendar). Bookerville is structured this way because that's how most property managers want to do it: don't block dates on your calendar until at least a pre-payment has been made.
You are running in Bookerville's "Manager-Centric" mode, so bookings start out as Booking Requests (which do not block dates). Only you, the manager, can convert these into actual bookings, which block the dates.
Essentially, subsequent payments cannot be solicited for Booking Requests, only "pre-payments" can be. And this is usually done by the manager sending the guest a Quote email, which contains a link to take the guest through the "Confirm Quote" process. This Confirm Quote process typically converts the Booking Request into an actual booking (blocks the dates), and collects any "pre-payments" required, all in one step. If it happens to be a "close-in" booking (< 30 days out, in your case), then it will collect the full amount (booking total + RSD).
Does this help?
Recent Posts:
Monthly Archives:
Categories:
- Minimum Days Between Bookings
- Property Deletes No Longer Permitted
- Bookerville's New Maintenance App
- Automated Refunds Are Here!
- Send Your Scheduled Emails Hourly
- "From" Address and Bookerville Email Delivery
- Automatic Emails and Listing Sites
- Vacation Rental Channel Managers
- At-A-Glance Tab Updates
- Bookerville Reads Your VRBO iCal Feed
- Guest Services Mobile App!
Monthly Archives:
- February 2021 (1)
- May 2020 (1)
- January 2020 (2)
- December 2019 (1)
- August 2019 (1)
- November 2018 (1)
- February 2017 (1)
- November 2016 (1)
- May 2016 (1)
- April 2016 (1)
- January 2016 (1)
- August 2015 (1)
Categories: