> Why was the decision made to NOT associate a credit card with a user. In
> other words, why no credit card table with a link to the user table. As it
> stands (I believe) the user must enter CC info each time. This is very
> unusual.
>
> I have come to realize that Leon had good reasons for most of his
decisions.
> So, Leon, if you are reading this...what were you thinking here? Also, is
> there any way in FT 1.3 to have more than one credit card charge
associated
> with one order?
>
> For instance: We can have one order of three items sent to 3 different
> addresses. What if only two of them ship on Tue? We can't bill their card
> for all three. We must bill the third item separately. Is there a work
> around for this?
Actually, it's not hard to pull out previous credit card info. Invoices are
associated
with a user, so you can dig the data out with a join (Invoice to Billing).
Why aren't
the credit cards organized into their own tables? No one needed it, so it
wasn't
added to the project. Related to this are address books for users. I
should say
that the ideal (and perhaps unrealistic) solution is for the user to
maintain this
information in a wallet application. Mastercard has one for free, I think.
That was
the idea behind ECML compliance.
Regarding multiple payments...I think the schema will support it with no
problems.
Obviously, the code doesn't allow for it, but it should be possible to get
it working.
I can also imagine the situation where you want to pay for an order with a
gift certificate
and them make up the difference with a credit card.
The issue of partial orders is a bit tricky. First you have to think about
whether you're
charging the card immediately, or if you're charging when the order ships.
The billing
record is keeping info about how to bill the customer, not necessarily that
the customer
was billed. I'd consider adding a new table to keep this information. Then
you can
add as many record per invoice as you need. You are going down the path of
integrating
FreeTrade with the fulfillment process more deeply than was intended
originally. (But I'll
stress that there's nothing wrong with that!)
Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
