Addresses and constrained addresses (Long-term wish-list items...)
Last update on .
When you run a cable company, it makes sense to have the ability to explicitly and exhaustively define the streets and street-ranges in the town so that you can never have an invalid address entered for service. I've just finished the basic implementation of that for the better billing project, along with the other major contact types (phones, email, shipping address). It's all inheritance heavy, so that you can reference a "location", be it a constrained address or a free-form one from a mailing address.
Also did the basic credit-card storage tables (planning on using public-key encryption for that storage so that only the payment-processing machine will be able to access the plaintext information).
Beginning work on the billing process itself. Probably tomorrow I'll work on the tabular cost setup system and mocking up discount systems and tokens to move a customer to alternate billing tables. Should likely also work on the "bundle" support. I'm meeting a client tomorrow to discuss what they need in their new billing system.
Comments are closed.
Pingbacks are closed.
Rene Dudfield on 06/29/2006 7:10 p.m. #
Note that for possibly better security you probably want to do the encyption of the CC on a separate machine too.<br />
Since you have a machine with other services and users on it. Reading the CC details before you encypt them is easier on that machine since there are more attack vectors.<br />
You may not want one set of admins being able to touch CC details. With root, or local access they can much more easily intercept CC details. So keeping the encryption machine separate allows you to enforce this policy.<br />
Then again... there is now one more machine to admin and pay for... so you may not want to do that.<br />
I know at some places this is what is done with billing. They keep certain parts of it separated from different people.<br />
Mike Fletcher on 06/29/2006 9:39 p.m. #
Having a whole separate server just to do the entry of the CC information is probably too much to ask of users wanting to install a billing system.<br />
I expect many people will run the CC processing systems on a separate highly isolated box (likely in a locked room somewhere), but having yet another server (three total) just to enter and encrypt the CC information doesn't seem likely for the kind of small companies I'm targetting (and putting that server on the processing server would just make it ever so much more likely that the server would get compromised).<br />
Regarding the sysadmins, yes, that's the point of having the separate payment processing system. The sysadmin could, of course, install their own script in place of the one I've put up, and it is a risk.<br />
What the approach I'm taking guards against is having large collections of credit card information lying around to tempt anyone to break in. Assuming the integrity of the application and the public key is, of course, an assumption, but you have to make some assumptions at some point and I think this is probably fine for my target audience.
Rene Dudfield on 06/30/2006 12:31 a.m. #
Yeah, fair enough.<br />
In that case you might want to allow for integration of external 3rd party CC processing systems? eg worldpay/paypal etc. Then you don't need to worry about storing the information at all.<br />
They have much cheaper setup costs compared to other CC processing options too.<br />
I'm guessing you might want it to scale from one machine, no connection to bank up to multiple redundant servers. There's not many billing systems that can scale from that low end up to high requirements when needed.<br />