You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Pierre Smits <pi...@gmail.com> on 2015/11/23 10:27:24 UTC
Payment solutions & process
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/
Re: Payment solutions & process
Posted by Pierre Smits <pi...@gmail.com>.
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 <
adrian.crum@sandglass-software.com> 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/
>>
>>
Re: Payment solutions & process
Posted by Adrian Crum <ad...@sandglass-software.com>.
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/
>