Every time I see a stupid and provocative title, I am hoping that it's something interesting and title was chosen only to attract attention.
Yet again, it was just that - stupid: if you're afraid to deal with usernames/passwords in a secure fashion, how would you deal with credit card numbers for recurring billing? Or how would you approach a task of writing a billing system for someone like AT&T?
Most recurring billing providers handle the credit card numbers for you. So after you pass them along to their API you never need them again.
Isn't it more secure not to reinvent every wheel yourself? I'm much rather let others deal with their core competencies than spend all my new feature cycles making yet another create/confirm/forgot authentication boiler plate.
"Billing and Shipping Addresses: Billing records are kept at the payment processor, and shipping is likely kept in a waybill somewhere - both accessible by your application when needed. You don't need this in your database."
I don't need to maintain the user's maintenance of it in my database, but the data that goes onto the waybill needs to be stored somewhere during the ordering process (and most likely needs to be stored for future shipment records processing/reporting), so you actually have not gained much security.
Yet again, it was just that - stupid: if you're afraid to deal with usernames/passwords in a secure fashion, how would you deal with credit card numbers for recurring billing? Or how would you approach a task of writing a billing system for someone like AT&T?