Description: ------------ The AuthorizeNet processor doesn't set the address and other transaction information. Without address information sent to the payment gateway, AVS cannot be completed. The problem arises from the lack of class members to be set by Payment_Process::getFields(), setFrom(), fieldExists() and set() Reproduce code: --------------- Solution: Add members to Payment_Process_AuthorizeNet <?php /** * List of supported "generic" fields (in addition to the base ones) */ var $postalCode; var $company; var $address; var $city; var $state; var $country; var $phone; var $email; var $ip; ?> This is not a definitive list though... -Philippe

You should be setting this in your Payment_Process_Type class and not in your $process instance. Check out Payment_Process_Type for more information. Possibly we should add a setFrom() to the _Type class with _handle*() as well. At any rate, set these in your $payment before you you pass $payment to setPayment, which then process these variables into $_data. Please close this bug if this was just a mixup. If there's a bug after reviewing this comment please post clarification. Thanks!

Mixup? yes and no... the line is blurred between the setup of the processor, the payment and the "order". I think a couple of things need to be clarified as the current implementation is leading to this kind of misinterpretation. Example in point is the "description" member being part of the Payment_Process class. There are actually 3 things required: a payment processor, a payment method and something to be paid for. The later is missing from the OOP abstraction. I don't have much a problem merging the payment type with the thing being paid for, but the current implementation is blurring the edges... which lead me to not knowing what to set where... IMHO the good way to go would be to set only information relavent to the processor on the $processor. For instance, login, password, connection parameters and so on... But description, amount and action shouldn't go there... Maybe a 3rd type of objects should be introduced, but that would definitely BC break. However since the package is beta, or even alpha. I think the benefits for clarity outweigh the BC break... Something named, for instance, Payment_Process_Invoice would be clearer. You set the invoice information, you setup your payment gateway and you gather information about the payment method. Shake it, don't stir ;-)... it's clear and clean.. -Philippe

Philippe, You want to start working on a "Order" or something like that object? Ian and I agree that we need some *VERY* generic order object (the something being paid for) maybe Item? Not exactly sure.