The ability to internally process charges was added to SD-RevenueBuilder (SDRB) inApril ’09. The general idea is, if you have a client that’s authorized you to run chargesagainst his credit card, you can do that process right within SDRB. Or, if you have aclient that’s authorized you to direct-withdraw funds from his checking account (eitheronce or periodically), you can also do that directly in SDRB.
For context, what we’ve now done in SDRB is to give you the ability to run charges onyour clients—using almost the same methods we use here at Rossware, for runningcharges on you.
Whether it’s charges involving credit card transactions or checking withdrawals, themethod to initiate is precisely the same.
While we’re using the term “credit card” here, we really mean either credit or debit cards. The systemis indifferent between the two.
Simply, click on SDRB’s ‘Manage Billings Due’ button, to display the BillingsManagement form:
With that form displayed, pick whatever categorization you’re interested in from theoptions at bottom (or, if preferred, leave set as per default). As you examine items inthe list, you can initiate a charge process (at least for any item on which a credit cardcharge or auto-check draft is applicable) in one of two ways:
If you use Method 1, the system will immediately take you to an appropriate context toprocess the transaction.
If you use Method 2, the system will do an instant, behind-the-scenes examination tofind (and select/highlight for your approval) all the charge items it reckons should beincluded, for this one-and-the-same-client and charge-method, in your currenttransaction. With your approval of same, it will then take you to the appropriatetransaction-performing interface.
In either case, if you complete the transaction, SDRB will immediately make appropriateentries in its data. Specifically, it will:
This subject is very simple. For the actual credit card processing machinery in SDRB,we simply equipped it with the same Virtual Terminal interface (and machinery) as waspreviously added to ServiceDesk and SD-Mobile.
Because of this, all the details you need, in regard to operation of Virtual Terminal, areavailable in our standard Virtual Terminal Handbook. Here’s a link:
You’ll note there are boxes in the SDRB Parties page where you should place accuratecredit card info for any client on whom you’ll be doing credit card charges. When it’stime to run a charge, this card info will auto-insert for you, into the Virtual Terminal.
We’ve presently programmed Virtual Terminal, when operating from within SDRB, touse the same merchant credentials as have been setup in ServiceDesk for the stationinvolved (didn’t want to make you have to separately enter those long credentials onceagain). If it turns out you need different credentials for SDRB, we’ll have to alter suchprogramming.
It’s confession time. Our prior language on this subject misled slightly (though it wasinnocent, for our only purpose was to keep the initial descriptions simple).
Truth is, we do not have a method that electronically pulls money, based on checkingaccount info (i.e., account number, routing number, etc.), directly from a client’saccount. We use a better method.
The reason our method is better is because, unless you’re an extremely large operation(i.e., hundreds of employees), the costs that are involved in electronic withdrawals areprohibitive. Our method involves zero banking fees, and works great.
Quite simply, our method is to print a paper check on the client’s account (this is whatSDRB actually does for you). We then deposit it, just like we would if our client hadprovided it.
Believe it or not, this is completely legal, and is thoroughly accepted as a commonbusiness practice.
Of course, you don’t want to do this unless your client has clearly authorized you to doso. At Rossware, when one of our clients wants to setup for this kind of paymentmethod, we fax them a simple form, as follows:
Usually, prior to faxing, we place a checkmark next the applicable line-item, and writeinwhat the amount is going to be. The client gets the fax, attaches a check (which weuse, simply, to pull appropriate account data from), signs and faxes back. We thenhave full authorization, and all the info we need.
As simple as such authorization is, to some extent it’s a formality. We’ve created anddeposited thousands of checks based on these forms, and yet have never once beenasked to present any such documentation to banking authorities. Still, it’s a good ideato have it—if only because it makes it clear, between you and your client, that you havesuch authority. Plus, it’s a good means of getting the underlying account info.
In regard to that latter, just as there’s place in each SDRB Parties datasheet for creditcard info, right below that same location there are boxes for checking account info.Quite obviously, if you’re going to be running check drafts for a particular client, you’llneed to accurately fill-in those boxes:
With such advance work completed (and, of course, appropriate billing events setup inSDRB), you’re all-but ready to run auto-check drafts. Only one element remains, andthat is having appropriate paper to print to.
In regard to this issue, the technical truth is that a check may be a legally validinstrument when printed on virtually anything (e.g., a rock). You could have SDRBprint client checks onto plain paper, and possibly succeed. However, our guess isemployees at your bank may give you some frustration if your deposited checks don’tlook like checks. SDRB will take care of all the contents that go on the paper, butyou’re going to have a better time at your bank if the background is colored and alsolooks check-like.
There are likely hundreds of sources from whence you can order blank check stock(again, we’re referring to paper that’s got all the background color and securityfeatures, but no actual content). Here’s one in particular (use this link if you don’t wantto bother with your own shopping):
http://www.netbankstore.com/p/87999/
As far as SDRB is concerned, it will print the applicable check contents in the top 3.5” ofan 8.5 x 11” sheet (the actual check portion). In the second 3.5” (approximately themiddle of the sheet) it will re-print identical imagery (this essentially becomes yourcheck stub). The result (one check per sheet) looks very much like the following:
So, the simple idea is, you’ll use SDRB to create these checks (and to auto-documenthaving done so, etc.), then deposit. You’ll find it’s incredibly easy—just like printingyour own money.? It’s what we do here, and we love it!
Dang, there is one more little detail. SDRB can’t print that cool check font at thebottom of each check (where the account number and routing number go) unless yourcomputer has the appropriate font installed. This font is called MICR (for Magnetic InkCharacter Reading), and is not easy to obtain. The best source we’ve found sells a fiveuserlicense for $99.95. Here’s a link:
http://www.micr-fonts.com/MICRfont/micr-fonts-windows.html
It may seem like a lot to pay for a silly font, but we shopped very hard to find it eventhis cheap (at many sites it goes for $1500 or more).
Please understand, if we could, we’d give you the font. We simply could not find asource that we can give away. We made the five-user-license purchase ourselves, forourselves.
You’ll need to install the font on each/every computer where you wish to have SDRBprint your checks. If you try to print without the font, you’ll get plain text where thespecial font is supposed to be, and your bank will likely not accept the check.
If you read the underlying literature, you’ll find that, in addition to the special font,banks are also expecting use of a special kind of magnetic ink. We have never foundthis to be necessary. As far as we know, without the magnetic ink the checks may failto be machine-read (depending on your bank’s machinery), but while that may be anuisance for the bank, it does not seem to be an impediment to the checks beingaccepted.
We do, however, highly recommend you do this printing via a good laser printer.