That would work, but I don't do order fulfillment. e-junkie does. They get to keep the IPN and Google payment notification interfaces, an email server to send out registration keys, bunches o' reporting code, and integration to the company that stamps CDs for me.
The cart posts directly to them, so hypothetically assuming I generated a secret and passed it over, they'd process the order anyhow and then tell me "By the way, your website passed this secret with the order -- do whatever with it", after which point a) the customer would have a registration key and b) if they ordered a CD, it would be scheduled to ship already.
Which is a long way of saying "There are ways to make this setup more secure but they'd involve me having to rewrite large portions of my business processes." Like I mentioned: it would cost me a lot of time at a very minor increase in security.
Probably illusory, actually. No amount of securing my cart will protect me from this attack: buy the software, write me an email saying "You offer an unconditional guarantee. I'd like a refund." And there is absolutely nothing that anyone could say or do which would make me stop offering that unconditional guarantee, because it is practically a license to print money. (To anyone who produces a low-marginal-cost product or service: if you do not have a guarantee, start A/B testing one. Its the closest thing in life to free money.)
I remember reading one of the "hacking exposed" books (the exact one I can't remember now), where there was an incident where an online store used values in the webpage itself to handle the prices of goods. In the example in the book, the hackers had replaced $45 list price with $1 giving huge discounts to the purchasers. And to make things even worse, some of the hackers would order dozens of shirts (at $1 each) and then return them for full price.
The cart posts directly to them, so hypothetically assuming I generated a secret and passed it over, they'd process the order anyhow and then tell me "By the way, your website passed this secret with the order -- do whatever with it", after which point a) the customer would have a registration key and b) if they ordered a CD, it would be scheduled to ship already.
Which is a long way of saying "There are ways to make this setup more secure but they'd involve me having to rewrite large portions of my business processes." Like I mentioned: it would cost me a lot of time at a very minor increase in security.
Probably illusory, actually. No amount of securing my cart will protect me from this attack: buy the software, write me an email saying "You offer an unconditional guarantee. I'd like a refund." And there is absolutely nothing that anyone could say or do which would make me stop offering that unconditional guarantee, because it is practically a license to print money. (To anyone who produces a low-marginal-cost product or service: if you do not have a guarantee, start A/B testing one. Its the closest thing in life to free money.)