Purchase model

[John Leith]

The purchase model seems like something that could be highly variable
per site. I've worked on some sites that have had no need to have
shipping addresses. Some needed multiple shipping address. Others
still required that a payment be able to span accross multiple orders.
Purchasing a class needs vastly different information that a product.

I was thinking that if bursar's purpose is to allow sites to take
payments generically, then it would make sense not to have a purchase
model at all. I think that dependency should be removed. The payment
models is the only one that is actually needed, then the site could
determine on it's own how to make purchases.

[Bruce Kroeze]

I agree with you to some degree. However, it isn't quite that
straightforward. For one thing, a purchase system needs to have a
"point-in-time" record of the purchase. The counter-argument is that
this is an implementation detail which could be handled by the host
app, not Bursar.

Also, some of the payment gateways really do need a "normalized"
version of the billing/shipping information.

Note, however, that all the billing and shipping information in the
purchase default to an empty string. If the particular app/Gateway
which is using Bursar doesn't need to store it, then it is not
enforced. Also, the app is free to have any kind of extra information
(multiple addresses, etc.) it requires, stored in its own version of a
"Contact" record.

I am not completely convinced of this direction. If you could
possibly diagram a typical transaction, say for Authorize.net, where
we could provide all the required information without having to store
it in Bursar models, that would be a big step forward. I do think
making the requirements-for-use as small as possible is absolutely the
best direction, I'm just uncertain how we can do that in a way
generically useful for 99% of Payment Gateways.

--
Bruce Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.