Refactoring OrderPaymentPreference entity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Refactoring OrderPaymentPreference entity

Jacopo Cappellato-4
Hi all,

I would like to start talking about possible improvements in the way  
Orders are associated to Payments.
Currently the OrderPaymentPreference entity is associated to the  
PaymentGatewayResponse entity and also the status of the payment is  
tracked in the OrderPaymentPreference.statusId field.
IMO we should just store there the payment preferences selected by the  
user and then track all the other information related to the payment  
processing (auth, capture, etc..) thru a Payment record.

What I am suggesting is to create a Payment record asap (probably when  
the order is created), associate it to the OrderPaymentPreference (as  
it is currently happening) and then track all the other information  
from the Payment; for example:

* for cc payments: Order->OrderPaymentPreference->Payment->  
PaymentGatewayResponse(s): if a cc auth fails, we will set the Payment  
status as 'rejected'
* for offline payments: Order->OrderPaymentPreference->Payment and  
then initially set the status of the payment as 'not received'

No status will be kept for OrderPaymentPreferences.

What do you think?

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: Refactoring OrderPaymentPreference entity

BJ Freeman
Just make sure the Facetoface(POS) is considered.
in that one you want
1) immeadiate response to CC status
2) immeadiate payment of Cash.

Jacopo Cappellato sent the following on 7/15/2009 6:46 AM:

> Hi all,
>
> I would like to start talking about possible improvements in the way
> Orders are associated to Payments.
> Currently the OrderPaymentPreference entity is associated to the
> PaymentGatewayResponse entity and also the status of the payment is
> tracked in the OrderPaymentPreference.statusId field.
> IMO we should just store there the payment preferences selected by the
> user and then track all the other information related to the payment
> processing (auth, capture, etc..) thru a Payment record.
>
> What I am suggesting is to create a Payment record asap (probably when
> the order is created), associate it to the OrderPaymentPreference (as it
> is currently happening) and then track all the other information from
> the Payment; for example:
>
> * for cc payments: Order->OrderPaymentPreference->Payment->
> PaymentGatewayResponse(s): if a cc auth fails, we will set the Payment
> status as 'rejected'
> * for offline payments: Order->OrderPaymentPreference->Payment and then
> initially set the status of the payment as 'not received'
>
> No status will be kept for OrderPaymentPreferences.
>
> What do you think?
>
> Jacopo
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.