Hi all,
While working on the omultisafepay component ( http://oem.ofbizci.net/oci-2/products/p_omultisafepay) I noticed that we have a very complex way of processing payments in OFBiz. When I look at CheckOutEvents and CheckOutHelper in the order mgt I found following: 1. getSelectedPaymentMethods (*Events.java) 2. checkExternalPayment (*Events.java) 3. checkPaymentMethods (*Events.java) 4. checkExternalPayment (*Helper.java) 5. checkGiftCard (*Helper.java) 6. makeBillingAccountMap (*Helper.java) 7. setCheckOutPayment (*Helper.java) 8. setCheckOutPaymentInternal (*Helper.java) 9. validatePaymentMethods (*Helper.java) And I might even be forgetting some. On top of this we have the various handlers/processors in accounting: 1. Bill acount 2. Gifcard 3. Authorize.Net 4. ClearCommerce 5. CyberSource 6. Eway 7. Gosoftware 8. iDeal 9. Orbital 10. Paypal 11. Sagepay 12. Securepay 13. Valuelink 14. Verisign 15. Worldpay (and I can't even determine whether these are still valid - as in used - and functioning options). It seems to me that we have created a feature set that has become more and more difficult to maintain/support. How do you solve the requirements of your customer when it comes to payment solution integration? Do you advice/implement the ootb functionalities as they are now? Do you improve the ootb solutions? Or do you build from scratch? What do you think? Should we rethink this? Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ |
The main problem is there are two different payment gateway execution
paths - the old style and the new style. That is why there seems to be so much processing code. [It has been a while since I worked on those, but if I recall correctly, the old style takes you to a provider's web page for payment, while the new style calls a provider API without leaving your site.] The new style uses configuration entities and such and those entities drive a payment gateway workflow. The idea being you add some entity values and a little bit of code to add a new payment gateway provider. It takes time to dig through the code, but once you figure it out, it is easy to set up. Adrian Crum Sandglass Software www.sandglass-software.com On 11/23/2015 1:27 AM, Pierre Smits wrote: > Hi all, > > While working on the omultisafepay component ( > http://oem.ofbizci.net/oci-2/products/p_omultisafepay) I noticed that we > have a very complex way of processing payments in OFBiz. > > When I look at CheckOutEvents and CheckOutHelper in the order mgt I found > following: > > 1. getSelectedPaymentMethods (*Events.java) > 2. checkExternalPayment (*Events.java) > 3. checkPaymentMethods (*Events.java) > 4. checkExternalPayment (*Helper.java) > 5. checkGiftCard (*Helper.java) > 6. makeBillingAccountMap (*Helper.java) > 7. setCheckOutPayment (*Helper.java) > 8. setCheckOutPaymentInternal (*Helper.java) > 9. validatePaymentMethods (*Helper.java) > > And I might even be forgetting some. > > On top of this we have the various handlers/processors in accounting: > > 1. Bill acount > 2. Gifcard > 3. Authorize.Net > 4. ClearCommerce > 5. CyberSource > 6. Eway > 7. Gosoftware > 8. iDeal > 9. Orbital > 10. Paypal > 11. Sagepay > 12. Securepay > 13. Valuelink > 14. Verisign > 15. Worldpay > > (and I can't even determine whether these are still valid - as in used - > and functioning options). > > It seems to me that we have created a feature set that has become more and > more difficult to maintain/support. > > How do you solve the requirements of your customer when it comes to payment > solution integration? Do you advice/implement the ootb functionalities as > they are now? Do you improve the ootb solutions? Or do you build from > scratch? > > What do you think? Should we rethink this? > > Best regards, > > > Pierre Smits > > *OFBiz Extensions Marketplace* > http://oem.ofbizci.net/oci-2/ > |
Thanks you, Adrian, for sharing your insights.
I guess that is why there is a lot of exception handling regarding the various payment methodologies in the two CheckOut*.java files. I also guess that the new style talked about uses the functions in PaymentGatewayServices.java. Whether the payment solution takes you to the providers web pages (call out), or integrates into the pages of our ecommerce component shouldn't be of concern to the project. I regard that as a business decision each adopter will have to address. I regard how that is handled (from an architectural viewpoint) to be something that needs to be handled within the realms of the payment solution. It shouldn't lead to (new) exception handling in the CheckOut*.java files. Neither should there be a difference in how internal and external payment handling functions are called in the Checkout*.java files. Those should be payment solution agnostic. Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Mon, Nov 23, 2015 at 5:35 PM, Adrian Crum < [hidden email]> wrote: > The main problem is there are two different payment gateway execution > paths - the old style and the new style. That is why there seems to be so > much processing code. > > [It has been a while since I worked on those, but if I recall correctly, > the old style takes you to a provider's web page for payment, while the new > style calls a provider API without leaving your site.] > > The new style uses configuration entities and such and those entities > drive a payment gateway workflow. The idea being you add some entity values > and a little bit of code to add a new payment gateway provider. It takes > time to dig through the code, but once you figure it out, it is easy to set > up. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 11/23/2015 1:27 AM, Pierre Smits wrote: > >> Hi all, >> >> While working on the omultisafepay component ( >> http://oem.ofbizci.net/oci-2/products/p_omultisafepay) I noticed that we >> have a very complex way of processing payments in OFBiz. >> >> When I look at CheckOutEvents and CheckOutHelper in the order mgt I found >> following: >> >> 1. getSelectedPaymentMethods (*Events.java) >> 2. checkExternalPayment (*Events.java) >> 3. checkPaymentMethods (*Events.java) >> 4. checkExternalPayment (*Helper.java) >> 5. checkGiftCard (*Helper.java) >> 6. makeBillingAccountMap (*Helper.java) >> 7. setCheckOutPayment (*Helper.java) >> 8. setCheckOutPaymentInternal (*Helper.java) >> 9. validatePaymentMethods (*Helper.java) >> >> And I might even be forgetting some. >> >> On top of this we have the various handlers/processors in accounting: >> >> 1. Bill acount >> 2. Gifcard >> 3. Authorize.Net >> 4. ClearCommerce >> 5. CyberSource >> 6. Eway >> 7. Gosoftware >> 8. iDeal >> 9. Orbital >> 10. Paypal >> 11. Sagepay >> 12. Securepay >> 13. Valuelink >> 14. Verisign >> 15. Worldpay >> >> (and I can't even determine whether these are still valid - as in used - >> and functioning options). >> >> It seems to me that we have created a feature set that has become more and >> more difficult to maintain/support. >> >> How do you solve the requirements of your customer when it comes to >> payment >> solution integration? Do you advice/implement the ootb functionalities as >> they are now? Do you improve the ootb solutions? Or do you build from >> scratch? >> >> What do you think? Should we rethink this? >> >> Best regards, >> >> >> Pierre Smits >> >> *OFBiz Extensions Marketplace* >> http://oem.ofbizci.net/oci-2/ >> >> |
Free forum by Nabble | Edit this page |