Hi all,
I'm still trying to fix the last problems in the current billing account implementation. Before I go on, I'd like to be sure that what I have in mind is the right process: * during checkout, an order can be associated to a billing account * if there is enough credit available in the billing account there is no need, during checkout, to select a second payment method; if the credit in the billing account is not enough, then the user have to select a second payment method (e.g. a CC) * when invoices are created for the order, they are associated to the billing account too * all the payments applied to invoices associated to a billing account, are associated to the billing account too (using the PaymentApplication.billingAccountId field) * a payment application can be associated to a billing account, and it will increase the credit available in the billing account All the above points are already implemented and I'm fixing some bugs in them; however there is one issue I'm not sure how to manage. Right now (thanks to Si's work) when the amounts are captured and one of the OrderPaymentPreferences is EXT_BILLACT, a payment is created and a payment application is associated to the billing account (to decrease the credit available in the account); however, no authorization is done before this. This is a problem because if I select a billing account and a CC, no auth is associated to the billing account and the authorization is requested for the total order amount to the CC (even if later, during capturing, just the correct amount is captured). My question is: how should we handle this? Should we treat the OrderPaymentPreferences of type EXT_BILLACT in a similar way of the CC auth/capturing? (I mean by creating 'fake' PaymentGatewayResponses for them etc...). Please help! Jacopo PS: For more details have a look at: https://issues.apache.org/jira/browse/OFBIZ-93 |
Jacopo,
Your suggestion seems to make sense. I hope to upgrade my system to the latest after the end of the Christmas shopping period and can do some testing of the new implementation then. Cheers, Iain Jacopo Cappellato wrote: > Hi all, > > I'm still trying to fix the last problems in the current billing > account implementation. > Before I go on, I'd like to be sure that what I have in mind is the > right process: > > * during checkout, an order can be associated to a billing account > * if there is enough credit available in the billing account there is > no need, during checkout, to select a second payment method; if the > credit in the billing account is not enough, then the user have to > select a second payment method (e.g. a CC) > * when invoices are created for the order, they are associated to the > billing account too > * all the payments applied to invoices associated to a billing > account, are associated to the billing account too (using the > PaymentApplication.billingAccountId field) > * a payment application can be associated to a billing account, and it > will increase the credit available in the billing account > > All the above points are already implemented and I'm fixing some bugs > in them; however there is one issue I'm not sure how to manage. > Right now (thanks to Si's work) when the amounts are captured and one > of the OrderPaymentPreferences is EXT_BILLACT, a payment is created > and a payment application is associated to the billing account (to > decrease the credit available in the account); however, no > authorization is done before this. > This is a problem because if I select a billing account and a CC, no > auth is associated to the billing account and the authorization is > requested for the total order amount to the CC (even if later, during > capturing, just the correct amount is captured). > My question is: how should we handle this? > Should we treat the OrderPaymentPreferences of type EXT_BILLACT in a > similar way of the CC auth/capturing? (I mean by creating 'fake' > PaymentGatewayResponses for them etc...). > > Please help! > > Jacopo > > PS: For more details have a look at: > https://issues.apache.org/jira/browse/OFBIZ-93 > > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.26/598 - Release Date: 22/12/2006 |
Free forum by Nabble | Edit this page |