Payment Methods URLs

Hi,

Not a bug per say but mostly an annoyance from a deployment perspective.
The Payment processors are all nice in their own little projects with one or two files in each project, admin folder and main folder plus one or two files spread in the root folder (return urls for payment processors)
1. Having so many very small (mostly empty) projects is not a good thing for performance as it adds time to the assembly loading during the warmup of the app.
2. It makes VS (+ReSharper) much slower than having a slightly larger project with all the payment methods in separate namespaces (that's why namespaces were invented)
3. It makes it hard to "chase" all the dependencies of a specific payment processor (1 project, two folders, few random files in the root).

What I would like to see changed (I don't mind doing it myself if I get write rights to codeplex project)
1. Merge all payment processors in one assembly. It will greatly improve app bootstrap time.
2. Move all the files "owned" by a payment processor inside a single folder.
e.g:

.\Payments\eWay\
    eWayMerchantReturn.aspx
    PaymentModule.ascx
    ConfigurePaymentMethod.ascx

This would allow me to easy delete all the payment methods that I don't want published on my site. Following the "Secure-by-default" and "if it's not required it should not be there" principles I don't like to deploy _any_ file (especially payment related files) that are not in use. I do mind those payment return files to be present as they might allow someone to poke at them until they get some responses.

Regards,
Corneliu.

PS>> I would do the same for the shipping methods as well :)

If you're following a "don't include if not required" principle and are concerned about bootstrap time, why not just remove the references to the Payment Processor assemblies that you do not require. To me this is far more manageable than having to delete directories from within your solution.

Having the payment processors as separate assemblies is better for third party components / extensions since you do not need to modify / recompile the core assemblies. This is typically how we ship all our aftermarket extensions.

Also from a developers perspective, you can copy and paste your VS solution file and remove the projects that you don't require in Visual Studio - making things more manageable.

retroviz,

I did remove all the other projects from the solution :)
However then I had to chase all the Admin\Payment\[payment processor name]\ConfigurePaymentMethod.ascx and Templates\[payment processor name]\PaymentModule.ascx folders and delete them as well and then figure out all the return url [payment processor name].aspx page(s) spread through the root folder as they reference the removed payment processors so they don't compile anymore :)

I didn't mind but it would be nice to at least group processor dependent files into a single folder instead of (admin, templates and root folder) so it's easy if I want to delete them.

Having the payment processors as separate assemblies is better for third party components / extensions since you do not need to modify / recompile the core assemblies. This is typically how we ship all our aftermarket extensions.

Yes, it's good if people extend and add new stuff but those processors are published by you and I don't really expect anyone to change them (without that code making it back to you and back into the trunk one day).
For the ones that you publish and more or less control there is no reason for all of them not to be in the same project.
The custom ones that we make, yes, I'd expect them to be in different projects.

Corneliu.

Regarding the extra return pages that contained in the web project, my personal view is that we should replace these with HttpHandlers.

I have done this for a number of aftermarket payment gateway integrations and it means that you can define the http handler in the separate assembly so the only thing you have to do in the web project is add the handler to web.config.

Of course this still means you have the configure and user payment templates. One way round this would be to create the templates in the payment gateway assemblies and use post build events to copy them into the web project.

This would keep each payment processor, any return handler / pages and configuration modules in a self contained assembly. Up to now we have to ship a modified web assembly if we add any new templates (a bit of a pain - especially if the client has made code changes in the storefront project).

So I agree with you regarding the existing payment modules, perhaps these could be packaged up into a single assembly but I also think we could tidy things up a little.

If you want to go down the "good design" route then "HttpHandlers" should be without the "s" :)
There should be a _single payment return handler_ that acts as a router to just forward the requests back to the payment processor for which the request is done. Even more it could check if that payment processor is even activated.
Right now I can hit /eWayReturnPage.aspx or /PaymentExpressReturn.aspx and they will get executed and _try_ to mark an order a paid (yes, subject to a bunch of checks) even if that payment processor was not even activated.

An interesting example
(modify the AssistHostedPaymentReturn to drop the first Response.Redirect as per the comment in the file to make it work)
Hit /AssistHostedPaymentReturn.aspx?Order_IDP=<enter a valid order id placed by you> and you just marked your order paid even if AssistHostedPaymentReturn was never enabled as a payment gateway.
Do the same for BeanstreamHostedPaymentReturn, MonerisHostedPaymentReturn and all the other ones that don't include any security to allow you to confirm the source of the call in their response.

Oh, and BTW, almost none of the payment return pages log errors on failures to process return messages making a potential attack very easy to hide. It's just a matter of time until someone succeeds as there is no way for the owner to even know they are attacked. (sorry for changing the topic, maybe I should paste this as a separate bug).

Corneliu.

corneliu wrote:

Sorry forgot to debug my text before posting... :)

I disagree regarding a single return handler as many payment gateways differ in their implementation and how they perform the transaction notification. For example I just completed a payment gateway integration that required 3 different return urls, each with very different response formats/data.

corneliu wrote:

Yes you should add this to the bug / suggestions at Codeplex. Generally this is why more and more payment gateways are adopting ITN as it much more secure.

First of all, thanks for suggestions
corneliu wrote:
That's why it's there (validation workflow is not implemented for some of the payment modules). Just don't comment the first "Response.Redirect" line.