RecChat: NoVal Credit Cards and Payment Device - 06/03/2021
Episode Summary
In this episode of RecChat our host Bret Alarcon is joined by EDU Manager, Zach Malloch and Director of Municipal Support Services, Cullen Barber to discuss no valid credit cards, the payment profile, and how they all linked together.
Recording
Transcript
Bret Alarcon 0:08
All right, well, that music means it's time for this week's edition of RecChat. I'm your host, Brett Alarcon. So for today's RecChat are going to be talking about no valid credit cards, the payment profile, and how they all linked together. And who better to show you that then Zack. Hello, Zack
Zach Malloch 0:26
how's it going Bret? You know, I don't know that there. There might be people better to show you it. But you have me today to show it to you.
Bret Alarcon 0:33
You're the best.
Zach Malloch 0:36
Your raise is on the way.
Bret Alarcon 0:38
Excellent.
Zach Malloch 0:39
And Cullen is of course joining us to help out with some of those questions.
Bret Alarcon 0:43
Yes. And speaking of questions, if you click that little q&a button in the bottom, you can bring up our little question tab, you can ask your questions, we should have answers. And if you want to make any comments, we also have that little chat button where you can make comments during the presentation to
Zach Malloch 1:00
absolutely. So assuming you can see my RecTrac,
Bret Alarcon 1:05
we can
Zach Malloch 1:06
go ahead and start this RecChat. And so first, let's talk about what a Noval credit card actually is. So we're getting these from profiles. And the no val is no validation, it means that if you have this particular type of credit card profile linked, and if you don't see it in your list, you know, I do have one right here, but if you create a new credit card profile, you choose the credit card profile as the type and then the subtype is going to be no validate. So once you do that, and we'll just do just to show the whole thing, we'll call this Novell two. And when we create this, you'll notice that there's really barely anything if there's no setup required for this profile. So it's a special profile that once it exists. If we link, either this one or the one that I just created, there it is no value to your user or to wherever you link it in your profile assignments, then you can take a credit card, and it will not ask you to swipe a credit card, it won't go out and check with any issuing banks or issuing institutions, it won't check with any gateways. It doesn't use any of our other credit card logic, it kind of momentarily says treat all credit cards as though they were cash transactions or check transactions, meaning we're just trusting you to tell us how much should be associated with the credit card pay code. And because it's associated with the Pay Code. That's why I wanted to just really briefly talk about pay codes and the payment profile. So if we take a look at pay code management, this is something that probably doesn't need to be specified too much. But in the interest of information, when we have a payment type that is the type of credit card that means when you select that particular pay code in global sales, that you will be presented with all of the credit card logic based on whatever your provider is ETS, PlugnPay, Verifone, or PayTrac. And so it's always going to go out, it's going to use your credit card scanners, it's going to go out and try to talk to the institution, it's going to talk to the originating bank, it's going to get that authorization and approval for you. So then the money is actually transferred. But when there is a problem with those sorts of trans transactions, if maybe the customer created a dispute, and they got their card chargeback so that they didn't actually pay you that money, you didn't actually receive it. So you can go in and basically do a payment reversal or back out that transaction using the Noval credit card, because if you didn't switch to the Noval, then it would use your credit card logic and and try to give that credit back to the customers card. And of course, if they already got it back as a chargeback, then you're giving them twice as much of their money back. So there are certainly situations where it becomes very useful to be able to correct transactions, particularly in the case of a communication issue, using the Noval credit card profile. So I'm in here as my system administrator, ZZZ user, so I'm going to link this Noval to my user ID. Now of course, in my situation, because I am a no, we're we're not actually processing things. We're testing all sorts of different stuff, for the most part. So I'm just going to link that to all three of those situations here. And so now if I go to global sales,
I think I have a $10 balance on my main test household right here, and $10 will just pay for that. So this could also be something where maybe there was a communication drop between RecTrac and the processor. So you got the authorization you check in your terminal with your credit card provider, be that ETS or card connector or whoever. And you check out and you see that it was about about authorization and that you did get paid for it. But RecTrac didn't see that the transaction was finalized, there was a disconnect somewhere in there doesn't happen as much as it used to. But it definitely used to be something that we ran into fairly often. So if I pay my old balance, let's say that I had tried to do this transaction, I got the authorization for the $10, I got the the post off on the credit card terminal. So I know I'm going to get this $10. But RecTrac didn't record it getting paid. So now that I have that Noval profile linked to my user ID, if I choose to pay for this with a credit card, it is just going to accept this payment, it's not opening up any other logic, it's not telling me to use the pin pad, I don't even have a pin pad attached to my computer, it's not trying to go out and talk to any issuing organizations, it is just acting as a cash based transaction. So very useful for once again, for doing those corrections anytime you need to reference the credit card payment code. But for whatever reason, you don't want it to actually go out and get that authorization. And once again, it's usually correcting for something that's happened on the credit card side that RecTrac didn't know about credit or charge. That's when we would do that. Now, of course, the big Asterix on this is once you're done with any of those corrections, you absolutely want to make sure that you then remove all of the credit card links that you just did with that Noval credit card and replace them with whatever your your regular credit card processor is, certainly happened a few times that people called in, they processed a correction, they lengthen it well they linked to Noval credit cards so that they could process a correction, finished it up felt great when tullinge came back, didn't realize that they weren't linked to it in process three or four transactions with that Noval meaning that you're taking those credit cards, but you're not being asked to swipe the card, you're not being asked to go talk to the bank, all that sort of stuff. So you're just showing that they're getting paid without actually going in and getting the payment. So it's definitely an issue, it's definitely a problem. If you leave it linked for too long, you never want to take a new transaction with the no Val linked, it's just for those corrections. Actually, I'd say it's just for those corrections. It historically, we used to use it for people who had completely separate credit card terminals. So it was just something you type in the numbers, you type in the amount it doesn't talk to RecTrac, then we would sometimes use the no Val to represent those transactions and RecTrac when it wasn't actually originating from RecTrac, although I don't think that's happening anymore. So that's basically no Val. I take any questions about that. But I'm going to get into the payment profile. So the payment profile is one of our main places where people want to start playing permissions. So when we talk about permissions in general, it's who has access to what screens who can do what overrides, who can see what records, and who can, you know, delete, or add or create new stuff or delete existing things. But a big part of it is also who can take what payments who can do what sorts of refunds who can take various types of transactions. So when we look at the payment profile, and I update that from here, this has basically everything to do with in I mean, this is probably the most important part as far as our day to day things. Which types of payments. Are your customers allowed? Are your your paid, your clerks allowed to take? What refund refunds are they allowed to issue back out. And then this is kind of just a nice little thing where if you are going to do a cancellation, it'll let you know how that transaction was originally paid for. So that that could then be a nice convenient way of deciding how you actually do your cancellations or how you're going to issue the refund in this particular situation. In this just as if you're canceling something, the original transaction was paid for using credit card or paid for using check. So it's just a little simple way. So you don't have to look up that original transaction or reprint the receipt. It'll tell you how it was originally paid for.
Bret Alarcon 9:03
Hey Zach?
Zach Malloch 9:06
Yes, yeah,
Bret Alarcon 9:06
Do you have time for a question?
Zach Malloch 9:08
Absolutely. I've got time for a question.
Bret Alarcon 9:09
Awesome. This is actually something that's going to talk about when I was going to talk about how Army uses the no valid but Laurie has a question. She asks, I have a special user ID just for no valid transactions, will that still be a possibility in 3.1?
Zach Malloch 9:25
Absolutely. So the difference, Laurie, between 10.3. And 3.1 is really just that we're calling them profiles rather than in 10.3. They were called devices. So if we had a user, and actually I can do this just real quick to show what we'd be doing. So we go to User Management, and then I would create a correction user or a finance user or an audit user or something like that. Or specifically, no Val. So we get very, very clear as far as why this user exists in the system. And let's just use password, you guys are on the honor system not to hack my database, since you know my password now for this user. And you know, we'd probably want the corrections user to have some pretty high permissions. So we're linking them to the ZZ group. But if we're doing this as the user, then if I come in here, and I refresh this list, now I have my corrections user, I can link that no of our credit card up there, I can link my admin payment profile at that level. So I have access to all of my admin pay codes. And so you know, just as a little review, or refresher here, of course, when you link something to the user ID, it doesn't matter what's linked to your Menu Group, it doesn't matter what's linked to your workstation, or your user group or workstation, it will override because we're linking the profiles directly here. So then when I need to make a correction like that, like Laurie does, you just log in using your corrections user ID, it's already linked and configured for that Novell credit card profile. And then you're saving so yourself the need of linking something and then remembering to go in and unlink it, you're just logging in as this user, and all you have to do is remember to log out before you're actually doing your real transactions again. So a very good way of doing it. And absolutely, Laurie, it is still a possibility in 3.1, just by doing it like that. And in fact, it should transfer over when you do your migration, you shouldn't even need to do any configuration because those Profiles or Device links are translated into profile links.
Bret Alarcon 11:40
Just wanna add...
Zach Malloch 11:42
Yeah, Brett?
Bret Alarcon 11:42
Yeah, I want to add that the army does, indeed shift along with credit cards. So if they ever have to fix something, they have to both void the batch and make the correction, which I know it's much easier and three, one, and they need to use the no valid credit card device. So what they did was they created one special user that can only is the only one that voids is and is the one they logged into to make the credit card transaction fixes with the no valid device. So something to keep in mind if you're also doing end of shift as well.
Zach Malloch 12:17
Yeah, very good point. And actually kind of extending through that, based on how we're linking things to this user. Whether they have a different permission profile, if they have an individual drawer number, then we're getting their user ID, we're getting their drawer number. And it just stands out very immediately to us what transactions were done by this user, because there's a couple of things that are very unique about them. It allows you to run reports separate from this user. Also, if you're looking, you know, if you're only using this person for corrections, and you don't want them to be included in other things, it gives you a really easy way to filter that. Do you know if that's part of how they do it for the military, also, Brett, do they have their own uses? Or they'd have to for avoid your user the way that used to happen?
Bret Alarcon 12:58
Yes, yep, they have their ranges. And the way it works is they have the ranges that exact same for every single location, every single Garrison so all the golf course to start with a range of one, zero, and then two more drawer numbers. So 1000 Oh, one 1002. And then like the ODR Center, which outdoor rec would have 3501 3502. So they use ranges for all their locations that every Garrison,
Zach Malloch 13:23
yeah, makes that kind of shift stuff easier to do. And for an end of shift overview, I believe that we do have a virtual symposium of that. I think we've talked about it in RecChat, although if not, maybe we'll do that as an upcoming topic. All right. So we're talking about the payment profile, and also kind of the benefit of this. And so just once again, to give a little refresher to this, it's always very important information to have. But the way profiles work are based on this little hierarchy that we've got so defaults as the lowest level, these are the things that apply to everybody in the system unless we link something higher. And so when we're saying higher, it's literally like a top down hierarchy. This is the highest position default is the lowest position. So anything linked at a higher level will override anything linked at a lower level. So if I have my default set as my default payment profile, or is it, yeah, so Default Payment profiles right there. If I link something at the site at the workstation, or the user group or user that affects my login, it's all going to override that. And that's why, even though my default, that's limited to only have check and cash as my allowed pay codes, I as my system administrator user, logged into the system here with the admin payment Profile link to it. That's what this is overriding it. And that's why I'm getting all of these options. So just always like that opportunity to reiterate some of those basic logics based in RecTrac. So we have our core settings up here. So this is I'll just kind of go through these settings pretty quickly. Once again, if you guys have any questions, please Add those in as interjections or anything to add to it, I think that probably the fields here will go till basically the end of the session, because I'll talk about some of the examples that we use them for as well. So your gift certificate pin, this is a piece that actually allows you to take your gift certificates and allow your customers to use them on the web. So if you didn't know, you could do that, you can, you just have to have them print a PIN number. So that's a unique number to add to the transaction, just to prove that they actually have the card, oftentimes, kind times the pin will be printed on the receipt and not the card. So if you lose your card that will make sure that you know, nobody can use it unless it's actually yours. So kind of a nice thing right there require a household match and house links, gift certificates. So if you're selling gift certificates, if you're linking them to the household, they have to be linked to a house so they can't be tied to anything else. Or they can't be attached to somebody else, or they can't be just used as a as a method of tender, asked me on a household transaction who has that gift certificate linked to them already. Payment punch pass is one of my personal I don't know, it's a very limited use case sort of situation. But you can actually redeem punches from your punch cards as monetary value. The difficulty here is a lot of people cause charge different amounts for like a 10 punch card versus a 20 punch card versus a 30 punch card. So that actually changes the individual value of your punches. But when using punches as payments, they have to all equal basically the same payment amount. So it's a bit of an issue with balancing for finance stuff. But for some people it does work. Whether or not you give people access to the coupon button on the payment screen is controlled by this toggle. You do of course then have to have coupon codes created which is done through coupon management. So you can just use your menu and type in coupon and get to that point, allow scholarship use across family members. So if you assign scholarship to a household, then any family member can use it. Or you can assign them specifically to one to each individual family member in the household. Prompt add credit on overpayment? So do you always just give change back if somebody pays more than his do? Or do you ask? Well, you're paying $20 on a $10 transaction, do you want to leave $10 on the household as a credit in the system, prompt user we're not paying in full if your default is to pay in full, this is just a little warning that says hey, you're not paying in full Are you sure you wish to continue. So if that's a frequent issue, where you have people going too quickly through that screen, one of the other things, especially for new users, they sometimes just accept the default. So it has a cash as a pay code, they just hit process. And then the customer hands them a check. And of course, then there's issues. So this would be if you're not paying in full. The other thing is that actually when we get down to the module, the default payment settings, if we say it not selected, then that makes them slow down on that screen, it makes them pick up a code and then it like they're they're having to be a little bit more conscious, they can't just get into the muscle memory of hitting and process makes it a little bit more complicated. So for beginning making people pay attention to things, I definitely recommend a combination of that toggle and then possibly the default changes. If you guys do a lot of facility reservations, there's the option of doing your
firm, tentative or hold. So those are different reservation statuses for your facilities. And this is a way that says as soon as somebody has paid the balance in full, you can change the status to be firm. So those three statuses are really just filters for you to run different reports in the system so that you can get an idea of what you're actually can rely on happening or maybe have like a two week cancellation policy for people who haven't paid in full, and you get in touch with them and see if they do want to make it and if they do, then it automatically changes the condition. So nice thing if you're doing that change due pause. So how long do you want it to show up on your screen, how much change is due to the customer. Obviously, having it there long enough makes it easy for the clerk to actually make change. Having it there for too long, could be a little bit frustrating if you're just waiting for that screen to clear and the next customer is already up in front of you and asking you to serve them. And then we have this demographics prompt setting this is really for point of sale sorts of things. So point of sale, service items and point of sale inventory for daily sales. So the first ones are for daily sales, meaning it's not linked to household, then we have all sales meaning daily and those linked to households. And it's just getting a little bit of extra information from the customers at the time of the transaction. So even though you're not linking it to a household, you can still get an idea of where your customers are coming from what zip code are they residents of. All right. There's a core settings and I think I saw a question pop up.
Unknown Speaker 19:55
Yeah. Yes, Lisa wants to know Looks like a real world problem. The credit card went through and RecTrac but didn't get charged. Staff zeroed out the fee so that they can do he can use this membership over the weekend. How do I add the fee back into RecTrac? To acknowledge the the membership? If I go into Noval, I can purchase again since I'm sorry, I can't purchase again since they already have one.
Zach Malloch 20:20
Yeah, so that would be a situation where I'll come back to the payment profile, assuming we have time for it. But this is a good question. So if we're going into proof, or if we're going into that situation, so basically, you have the item in their purchase history with zero fees, and you're trying to sell a new one to get those fees to charge, but it's saying that they already have one, so it doesn't let you do the new piece. So the easiest thing I think in your situation, to undo that clerk zeroing out the fees, go to purchase history, find the item in your case, it's a pass, so do something like this. So I'm filtering my list, I'm only finding my passes. And I find a particular pass the one that has the zeroed out fee. And then my update fees are we click this reset fees, buttons. And so what that'll do is it'll discard the zeroed out fees, it'll go to the past, grab all of the fees that are attached to it in the file management side of it, and then reassess those fees for the same paths that they already own. So if it was zero, and it shows that they paid zero, and you reset the fees, then it says this is how much you charge a resident versus how much this is charged a non resident, it figures out this is a resident or non resident, whatever, and that puts the appropriate fees back onto that pass, and then it let you pay for it. So the reset fees button would be the case there. And the event would be pretty easy to do a real quick demonstration of that. But it will also take a little bit of time, I think that that is hopefully enough. Go ahead and just try going purchase history, find that zero dot pass, hit that reset fees button and then pay for it with a no val assuming that the credit card transaction did go through. If a credit card transaction didn't actually go through, then you'd want to do that process but actually swipe the card while you're linked to your real credit card profile. But I think that that will get you to the right place.
Cullen Barber 22:19
That was I think David had kind of a follow up question to that. He just He asked how do you do this? If the revenue codes are not in Rectrac? I think the revenue codes would be in RecTrac. They just weren't hit on the initial sale. Right?
Zach Malloch 22:39
Right. Yeah. So if you zeroed out the fees, then that would mean that you're not collecting anything for any of the revenue attached any of those fees. Then when you do the reset fees, and we doesn't even have to actually be reset, I mean, you could just click Update fees. And you probably will see the line that was zeroed out by your customer or by your clerks. And then you can just make it whatever the appropriate number was. And then when you process this transaction on Noval, or whatever it is, it will hit the balances, we'll just hit update fees from cart, it will hit the revenue codes attached to this fee.
Cullen Barber 23:21
You can't make a payment in RecTrac without a GL code attached to the fee. Right,
Zach Malloch 23:27
Right. Well, assuming that the the half of the transaction goes through rec track. So like David's situation, if you did charge the or if you if you didn't have the money go or if you charge the card, and it went through on the credit card processor, but it didn't go through and RecTrac, then it's basically that transaction didn't happen at all. And that's the perfect situation to use the no Val because if it did go through on the credit card side, you don't want to charge their card a second time, you just want to show RecTrac that the money did actually get attached to those revenue codes you're talking about. And so Lisa said that the credit card did go through. So that's why they zeroed out the fees. So linking the Novell credit card profile, going in resetting the fees, getting all the proper fees set up and then going through that payment process will not charge the card a second time it will show that the RecTrac took that money and it will associate the money with the with the revenue codes. For David, what you're talking so basically what you're saying is the transaction gets swiped, it gets declined through card connect and no transaction actually occurs in RecTrac. Because you're not seeing the money go through revenue in RecTrac, that would be my assumption there. And you're saying it's declined in CardConnect. So that's actually kind of the proper situation to be in. In that case. If it got declined on on CardConnect, you don't want to show the transaction hitting any revenue in RecTrac. So just basically payment hits our bank the refund is declined. So you're getting the original charge. Cullen is that making any more sense to you?
Cullen Barber 25:13
Doesn't doesn't make any sense. I think I'm gonna Dave I'm gonna look, look up your account to see who you're tied to, because we should give you a call on the support side because you if you're using if it's WebTrac, we want to find out which credit CardConnect interface you're using. They're using the iframe, you really shouldn't see a situation where the card is charged, but it's not in RecTrac. If you're using the old HPP v2, or HPP v1, then you could have a session issue where yeah, the card gets charged. It's not in RecTrac, but we'd want to kind of talk through that. Because there's definitely delegate some easier ways for you guys to get that fixed, I think.
Zach Malloch 26:00
Yeah, and I mean, I think just tying it back to the main topic of this wreck chat, that once we figured out what is going on, we will use the Noval credit card to make our profile just to make sure that RecTrac is in balance with what rec with what CardConnect says you should have matching the credits and any debits or declines or refunds or whatever. But yeah, I think that what? Yeah, what Cullen is saying is that we'll we'll get in touch with you because I think this is ending up there's probably going to be a fairly specific issue. And as Cullen mentioned with the iframe thing, once switching over to the iframe, if you are a card connect user. I mean, Cullen, you can speak better to like the the night and day difference of what that actually does in a real life situation, I think,
Cullen Barber 26:43
yeah, for sure. If if you're using the HPP v2 to but it was still doing a full redirect. There was a bunch of other kind of steps in between the other little, little clunky for sure. And you can get the session mismatch. The iframe, it shouldn't it shouldn't happen, because it's keeps this the session integrity. You don't actually need to need to fully redirect back and forth. We can use the iframe so you shouldn't see those situations or they should? I'm not sure we've seen one yet, you know, over the past year. So yeah, let me take a look and see if we can give David some direct help on this one.
Zach Malloch 27:21
Perfect. And I see Phillip has a question also. And I think that so basically is asking is would a location use this function if they had what you define as a side card or side credit card terminal. So something is not actually connected to RecTrac. So like taking a credit card and RecTrac doesn't tell the terminal to hey, we're going to swipe a card here, it's just completely separate, then yes, you would use your no Val. And I would go the extra degree of if you're doing that. Say that you are requiring a payment reference and then say that this is your auth code. So then that way, you will most likely get an auth code or a confirmation code from your credit card profile, and won't let your clerk process through a credit card transaction even with the Noval if they don't put something into this auth code field on that screen or on the payment screen. So it will just kind of slow them down and hopefully make sure they're actually using that terminal. And then the second part of your question, you're saying that you're looking at integrating indirect track using something that has a card, a credit card device, that's PCI compliance also uses p2p E encryption? Yes, absolutely. RecTrac 10.3 and 3.1 are actually, Cullen you can double check me I think 10.3 has solution options for that. 3.1 absolutely does. And we could potentially get you in touch with sales to discuss what some of those solutions would look like for you.
Cullen Barber 28:47
That's correct. Yep.
Zach Malloch 28:48
Okay, awesome. Thanks for the confirmation. All right, well, we've got about two minutes left. And I can go through very quickly some of the other payment settings here. And that'll probably wrap us up I think, of course, keep having questions coming in. So of core settings 2 not many people do this, but you could potentially withhold credits from the activity module so that you can only use those to pay for activity transactions and hold credits from passes, they can only be used for other passes. Generally speaking, people don't like having a lot of liability in their database, meaning owing their customers a lot of money. So by defaulting to allow the credits across modules means that the credits are more likely to be used up faster, you're less likely to have customers with outstanding credits on their accounts and it just reduces that liability to a degree. It same deal here with auto use new credits or use existing credits as much as possible. I recommend that people have all modules turned on for all of those unless you specifically need to restrict credits between modules. So if you don't specifically know you need to do that. I would definitely recommend having it on for everybody. Are you allowed to override the minimum amount due for particular modules? Are you out override to allowed to require the payment reference for particular modules? Are you requiring a refund reference? What types of refunds are you allowing, and what is the default gift certificate payment value. So if you are using a gift certificate to pay, are you paying the full balance of the gift card Are you paying the full balance of the transaction up to the limit that the gift card has. So there are a couple of different options we can use. This will show you that the this will look for gift certificates attached to the household. This will just let you scan any gift certificate number. So it's kind of related to this require no require household match on household linked gift certificates related to settings, Pay Code restrictions, we talked about that. So which pay codes do you have access to for taking transactions as well as processing refunds. And then our default payment code settings when I get to that payment screen by going through global sales, what will previous what will pre populate. So if 99% of my transactions are all credit cards, just leave it there. And it's going to assume that I'm sorry, swiping a credit card, if the clerk goes too fast, it's going to ask them to swipe a card, and they won't have a card to swipe. So this is another one that's kind of safe, especially for new users. Like I said, like having it not selected slows them down on that payment screen makes them pay a little bit more attention. Defaulting the credit card is also a functional one, sometimes it will speed up the process. If they are actually taking credit cards, it's one less selection to make, and it will still slow them down. If it's not actually a credit card that's being taken. Default refund settings. Same basic idea. This is only of course refund. Now, if you make that selection, that's still your payment, I clicked on that there's a refund. Yeah, so what refund apply refund finance or all of your refund options or refund now options. So once again, if you always do something a certain way for a particular module, these can save a lot of time. Pay old balance settings. So we saw when I did that example, I had to go into my transaction, it was an inventory item, I had to go to my purchase history, click pay all balances or find the item in my list and then manually select it to put it into my shopping cart to allow me to pay for it. If I had it set to auto add to cart for every module, as soon as I went to global sales, it would already have that $10 balance in my cart and available to pay for it. So if you generally don't have people that carry household balances, it's a really useful thing to say, auto Add to Cart, it's just going to save you that step of having to go to purchase history, look for any outstanding balances, add them to the cart if they're there.
And we can also just say you're not allowed to do that, or you have to do this or you give the clerk the option to do so or not. So various options, and you get to choose that by module. And then our default payment amount settings. So do we assume that they're paying the full amount do the minimum amount do or you just leave it at $0. And once again, kind of slow the clerk down on that screen, make them enter the actual number that the customer is giving them. And sometimes that can help us save on errors on those basic transactions. Then our last one is our minimum or maximum refund now slash void amount. So refund now is we're assuming that we're getting money back from the register, or crediting the card back. And of course, if we have a limit for how much money we actually have in the cash register, if I know I never have more than $100, then I could do something like that. And if I get to a situation where somebody is due a refund of more than $100, then it basically says you can't do this as refund. Now you have to do this as a refund finance or refund apply, leave it as household credit, or get a check back later, because we just don't trust that we're gonna have enough money in the cash register to cover that. So that is my fairly brief review of the payment profile and the settings that you can find there. And also the logic and how you know the payment profile in the specified specific ways that that works for different people. And linking it to different levels in our profile hierarchy is one of the most common ways that people start customizing the system. So I am going to check with Bret and Cullen see if there are any final thoughts if there's any areas of the payment profile are no vowel that you particularly find important that I didn't happen to cover in this quick half hour?
Bret Alarcon 34:37
Yeah, I can actually think of one so if you're getting a little ambitious and want to go through your payment profile and start locking some things down that you didn't know existed. Be careful with those system pay codes. When I say system pay codes, they're most likely in the 90s range. So like the 99 The 98 I'm not sure I can't remember how much three one and safeguards some of those Pay codes. But you want to make sure not to restrict those.
Zach Malloch 35:07
Yeah, so in three, one, it's actually not. If you're not converting, then it's not going to be numbers. For those Pay codes, it's going to be, they're going to all start with system. All right. So the VSI, they're all system pay codes. And they all start with VS or VSI. So accrual receivables, refund finance, refund RecTrac and the VSI system. If we didn't allow the system paycode, then you wouldn't actually be able to use household credits to pay for balances. So usually, it's okay to include the system pay codes for everybody to make sure that you're not limited as exactly as Bret Bret was saying there. But in but then on the refund side of things, that's really where you want to be a little bit more cautious. So if you don't want people to be able to create household credits, then you would keep the VSI system pay code off of the allowed refund pay codes. But you know, that's most of the time, you're going to allow people just to have those system pay codes because they're there's some things that are used by RecTrac to make sure that everything is working properly. But good point Bret. Cullen anything for you to add in the last couple of minutes.
Cullen Barber 36:25
Now you hit on the big one, if you link a no Val, make sure you unlink it,
Zach Malloch 36:30
or it's a very purpose oriented user that yeah, he's
Cullen Barber 36:35
already mentioned or somebody mentioned, having a very purpose built one. Handy. No, I think I think you've covered it.
Zach Malloch 36:43
All right, well, last thing before people start bailing out. Next RecChat. So June 17, is going to be all about the new Vic and the new executable installer. It's been out for a little bit. But if you haven't moved over to that this will be a really great session for your IT staff to attend. Jason Verdo is going to be joining Bret and Cullen unfortunately, I'm going to be out. But they're going to be talking all about the new Vic profile, the new installation, why it's better, and how much easier it is to do. So things to get excited about that will be coming out earlier on the week of the 17th. So expect the invitation either on the 14th or the 15th. And once again, that'd be a really great one to make sure it guys or IT staff guys, girls persons get that information if they want to attend. If they don't then as always, it'll be recorded, just like this one is. I think that's basically all I have to talk about as far as our profiles and no vals and miscellaneous other stuff. So I'll say goodbye to Brett and goodbye to Cullen and say thank you to both you and to everybody that participated. And
Cullen Barber 37:52
Thanks, Zach. Thanks, everybody for joining.
Zach Malloch 37:56
See everybody soon. Thanks. Bye
Delete