Pinetop-Studios

I think there are two parts - customer use and staff use.

Customer use: ability to submit CC and get immediate feedback as to whether or not successful. Imagine for now, will need to be a manual process to then assigned them a room, update HK with the successful payment entry, generate a lock code. Be great if there was some type of HK integration to where we could update payment information. Of course, HK has direct integration with converge, but the issue is that you need a credit card machine to add CC information AND remote workers cannot charge credit cards on file - only someone on an ipad can do that. But even with iPAd, new cards, currently, can't be added.

Staff use- of lesser importance:
Converge has ability to save customer info for repeat billing - at a cost of $10 plus a small transaction fee each time feature used. Can the API tap into that? And if not, and seeing how we are only keeping a small database (which we are somewhat doing (responsibly) on a very small scale), how comfortable do we feel about having that database of multiple cards per person? Although we have a handful of guest who ask that we auto charge them weekly, would feel a lot better if this was still done manually.

Per conversations 4/11
Waiting on HK API information
Need to be able to accept payments
Set up recurring billing (I believe the converge API allows that)

Once payment received on a new reservation for HK can we mark it as paid by outside CC

Add more info as received

There is no HK API ... just as I am sure there is no TC integration .. as payments are made, email confirmation should be sent to pss@dweb.us so that the entire staff gets confirmation that it was successful. Angelie and I will record the payment in the proper system - whether that be TC, HK or Google sheets. We can also text the customer confirming payment, so the phone number and name on the confirmation would be very useful. Be great if we can automate the text feature as well.

Want a link the customer can fill out .. using converge API .. we already have an account under MH .. will soon create one for DC. For KP/CC and PSS, will continue charge under MH's converge ID. This site has to look official or folks will be scared to use it. Perhaps have the page say something like "servicing the White Mountain Area which includes XXX.... where we list the names of the various hotels, with pictures, etc, etc.

The customer will input CC info .. I would suggest we also have a place for the customer to load their DL - but that might be asking for too much. Instead, staff should always have a copy of the DL, and phone number before we even give them the link to submit CC info. The customer types in their phone #, last 4 digits of their DL number, and it displays image of their DL where they can then submit their CC info .. perhaps even with the verbiage "name on id must match with driver's license" .. that way, when they submit cc, their image will confirm we are not sending them to some bogus website. And I think folks are more inclined to type on a website as opposed to giving that info over phone and certainly better than text which is against PCI. That would certainly add legitimacy .. And as Angelie knows, to obtain that DL,we simply say "we need your DL to confirm name and age" - so normally not a big deal. And technically, there would be 2 name fields.. one from the DL and one for each credit card ..both names must show up on the payment confirmation email so that we can question if there is suspected fraud.

For re-occurring charges, this will all be done MANUALLY. We will remind the customer it is time to pay - the portal will list all of the credit cards previously used (of course, only displaying the last 4 digits) .. they have to put in the CVV code to complete the payment. Of course, this means it adds the complexity of identifying the customer - perhaps we use their phone number and last name as the identifier. Not like a stranger could do much other than view the last 4 digits of a CC. AS tempted as I am about showing all past successful charges, I don't think it is currently needed.

Having this page would allow "repeat" customers to submit payments on their own and allow our staff to charge on behalf oof the customer as long as we know how to get the CVV info .. or we do a 7 digit PIN that only the 4 of us knows.

Our current process is for us to alert the customer via text, confirm they are okay with us to charge for another week, we process payment manually using data we've stored manually. Of course, I am worried about PCI standards, so if there is a way to segment the data on the off chance the tables are compromised, let's be sure and discuss.

All this stuff is so unnecessary .. wish we could just Zelle, Cashapp and Cash ... darn fees, etc. As we get folks with larger deposits and known to be long term stays, we should push for just regular Checks.

Mike - Thanks for the screenshot ... as usual, I have a lot of feedback, lol..

Since the DL is the unique identifier, thoughts on making that first? Once inputted, we can tell if the guest already exist in our DB b4 wasting time collecting the rest of the info? And once looked up, be nice for our staff to put notes about the guest - if they are a DNR, their past behavior, etc - obviously, this is just a nice to have and can worry about that down the road - but just a large comment area so that we know if we should even take on the person. Esp good if they have a past balance with us, lol.

The hotel drop down is handy (assume staff, like myself, remembers to select the right one, lol). Since it is staff using it - originally , i had pictured different link per hotel - like dcpay.dweb.us and psspay.dweb.us ... But i am fine w/ the direction you have - can see the advantages, but fyi, in the case of Amanda, she will almost always just input for DC .. right now, we only have DC/D9 and MH ..

Not to complicate things, but what happens when a customer MOVES to another hotel? I can totally see that happening. If need be, i am totally fine ignoring this issue - if they move from MH converge account to DC, I think we can explain that their statement will still show MH. Accounting/general ledger is not effected since we are tagging payments in TC. Jill - this does screw up our tax forms (end of year 1099's are from the credit card companies - and income might show up at the wrong place). And I am okay with that too. I guess if they move from hotel to hotel, it can just be a back end edit so that any new charges will go to the "right" hotel.

The label on this page, I think, should be "Name (First Last)" - that way we have a bit of consistency - not to mention that once u get to the page were we are collecting the CC info, the label should be the web standard of "Name on Credit Card" - which is typically first/last.

Since these payments are noted in TC and you are planning to generate an email every time a payment is successful, if u don't want to waste your time on tracking payment history, that is fine as well - it is more of a nice to have instead of a necessity.

1. DL first - got it - with look up for past guests - all properties with notes
2. Name label - will do - first, last
3. Hotel drop down can be check buttons instead so one has to be selected - and if the guest changes hotels, since I will have a page to pull up existing records I can make it so you can edit things like property and notes -

still a lot to do - finally feeling like I can get things done - will update end of week

Angelie -

This might end up being a good place for us to keep track of our good from our bad guest .. can u check HK and see if we can export name, DL number, DNR status and Guest Remarks? I am certain our LTR's float from place to place

So I have made progress - I am communicating with the Converge API and can get a token which is required to be able to send the charge - next is to make sure the charge goes thru then clean up and finish the web pages.

I do have to split the name on the upload page to First Name and Last Name because that is what Converge requires - separate fields - so might as well do that from the start.

I will be using the same encryption methods I'm using for the images on the other sensitive fields on the CC page - Good thing about using the XML version is we can even add custom fields to the account that we can upload with the charge - so if there are any you might want to include, let me know -

I hope to be able to give you a release next week - mid to late -

Question For Sieu/Angelie -

Do you ever need the Zip code of the billing address to process a charge?

I know that is asked sometimes online so didn't know if you needed that too - thanks

Site is up and still in Demo mode.

Meeting with CC providers on Tuesday regarding the percentage of use thru the website.

It can be accessed by https:/cc.dweb.us now

Site is in Demo mode -
Demo visa - 4000000000000002

https://cc.dweb.us will take you to the main front desk page where information is saved - there is a hamburger menu on the left that can take the user to a page to review all guest records or process CC.

https://pay.dweb.us is the url for the CC payment page

Passcode is 2390

Angelie is following up with our internet processing setting.

I am reviewing the PCI Third party certification that Elavon sent us to. More info to come -

• 2023_04_06_MainCustPage.mp4 - covers the main customer page (cc.dweb.us) - saving and retrieving information
• 2023_04_06_CCPage.mp4 - Covers the Credit Card page - can get to it from the main page or go directly to pay.dweb.us - Shows saving and retrieving information
• 2023_04_06_DataReview.mp4 - shows retrieving guest information - CC info not included

SVN Test: Ph: 1495 / DL 1234

A. so step 1, get a site that will charge a card
Working on that - gave FD the website url they wanted - hopefully will hear soon.

1. Working on PCI-DSS compliance - but that seems more focused on Elavon hopefully. Laveen IP scan passed - doing PSS hotel IP tonight.
DSS IP even though it will will change is fine to submit as well. But up to you.

2. I am also answering networking questions - all designed for big network configs - answering yes to most questions to get past - all easy enough to produce if needed since there really is not much of a network.

Will condense both pages into one that should work - can be modified as we move forward.

step 2, a way to quickly enter person, know if they were past customer, pull up old notes .. need to be able to search by DL, ph number, name....and a way to enter new notes on folks who misbehave. might very well need multiple fields to track damages
as for the saved CC info, your thoughts about the "label" doing a copy paste so that we don't ever display .. and to be safe, perhaps we don't put the cvv at all and make them have to ask customer or ask angelie and i?

Phase 1 - pay.dweb.us

Just a page that will take the user to the charge page after entering a few fields -

All fields are required - mostly because they are being fed into the charge page and would be needed anyway or are required for the account.

See recording - on Google Drive - https://drive.google.com/file/d/1Nm55VzS_1zap1UcO8K1TMk7eEYrvsPAS/view?usp=share_link

There is no saving or pulling up prior guest info right now - I am working on that -