Payment integration - external hosted UI

[mitfik]

I just start work on integration with payments system using ActiveMerchant (unfortunately this payment gateway which I want to use does not work, so I need to rewrite) but I see that there is one missing part in ror-e (correct me if I am wrong)

Right now there is assumption that store owner will host UI for payment (user need to fill credit card info on store webpage). But as I know this is related with PCI [1] and some special requirements (and of course security issue). As I can see ror-e of course do not store credit cards data so maybe this is not so big deal but any way.

In my case I do not want to host ui for credit card I prefer to send user to much more secure webpage and just get confirmation about status of this payment. So the question is: how can I do that and how this influence on payments flow?

[1] https://www.pcisecuritystandards.org/

[drhenner]

I'll be honest. I personally Like stripe.com and feefighers.com. I avoid all CreditCard security issues. Unfortunately, neither are available outside of US and I think Canada right now. Once support is added I'll be switching.

Storing creditcards with an active merchant gateway is a bit of a pain and a bit custom per the gateway. You can use a service like recurly or spreadlycore to make things easier. I should probably check into using spreadlycore by default.

If you want to use something like google wallet or paypal I'm a bit unsure of the details of those services. I'm guessing they have API calls so you can store all the shipping details and just get confirmation of payments. Unfortunately I don't know many details.

[mitfik]

So there are plans to abandon Active Merchant in the future ? It will be good to have something like active merchant to have some abstract class for handling payments. This is big advantage if there is possibility to implement/add different payment system (not all payments system are available in all countries as you notice and sometimes there are special requirements for payments system like handling different currency (not using currency ratings)).

I am not sure if storing creditcards is a good idea, This kind of behavior shouldn't ever take place. It's not secure and very risky to compromise the system.

I think that using active merchant (or something similar) is right now the best solution. I understand that each gateway has own requirements and this complicate implementation but this give user huge range of payments system to choose. Of course without some small modification will not work. But this is much better then implementing everything from scratch each time when user will want to use different payment system.

I think that aim is: provide easy and quite fast possibility to implement own payment system.

not dictate anything. Because in this case payment system is just module which you can use or not but something which is very strong related with your business and that where you make this business. So it should be chosen by customer.

[rubydesign]

Hey I just want to throw in my +1 . No cc details stored is essential (for law) and preferably somw standard api to get the local services implemented easier.

Eg in Finnland most people pay by direct bank transfer. There are gateways that implement that, but currently only php implementations for those gateways.

So if I were to do a ruby implementation, it would be easier (i could get help, possibly funding) if it were to some know standard.

just mho

[drhenner]

Storing credit card would never happen on your local servers. However storing CC's is not against the law or PCI. The only way I would implement this is using a 3rd party. Please don't assume I meant I would store CC details locally.

I prefer to never even have the CC hit your server. (that is why I always rip Active Merchant out and use stripe or feefighters in the US) The Active Merchant method of storing CC's the creditcard is never saved on your server.

As far as a plan to abandon Active Merchant... Yes I do want to get rid of Active Merchant. The problem is Stripe and FeeFighter does not allow banks outside the USA right now. Once they do I will glad switch.

Because Active Merchant is a pain and a bit different for each gateway I'm not sure the best way to store CC's via the gateway (not locally). It has been a while since I looked at this code. I'll plan to take a look again. I'm guessing Gateways and Active Merchant have changed a bit.

[drhenner]

BTW did you guys know 37signals stored credit card on their own servers for years. They were PCI compliant. They had to get a separate server used only for the credit cards. I assume that was a major pain! I would never recommend that solution... I guess they wanted 100% flexibility with their CC's / gateways.

[drhenner]

What is the thought on https://spreedlycore.com/ for outside the United States? I know some people use it in the US and like it.

[mitfik]

1 is not free. 2 normally owner of store will not want to use many gateways (2-3 the most popular I think is standard, even in case when store will be global, probably it will be few gateways in use because for example currency requirements) so it should be possibility to choose and use only those which he want to do that (and that will be made by some developer who will prepare store for him) not add them all. 3 extra cell in chain between user and our store, and we know that chain should be short as possible (longer chain = more expensive) 4 I do not see any differences between this and ActiveMerchant (I know that AM is not perfect but I do not see why this should be better, especial if they will implement very different gateways not only those from US and very popular, and of course AM we can improve if we want here we rely on their mercy) 5 Please do not understand me wrong but I also know lot of people who use AM and they like it (I think we can't use that as argument) 6 As i understand if their system will go down store can't use any gateways even if there is 32 right now, is that correct ? (to compare with AM one getaway go down you use another one in the same time)

For me the most important is to have simple solution which will be accessible for everyone (= Open Source). Things which we should consider: 1) open source code 2) possibility to choose which gateway user want to use 3) direct communication between store and payment system 4) easy to implement new gateway 5) transparent solution

I am open to your thought about that.

[drhenner]

The only thing I have found is that everyone has an opinion on the gateway / solution they will use. I have talked with many people about what gateway they are using for ror-e and pretty much everyone does something different.

That said the #1 thing ror-e can do is be very flexible and plug-and-play as far as ripping out one solution and adding another. When I started this project everyone I knew used authorize.net. It appears that is far from the case now.

It might be best to make an interface between ror-e and AM. If the interface can be swapped out easily then in theory many interfaces can be created to work with any solution.

I start my trip from NY to California in a couple days. I won't have much access to the internet for the next couple weeks but I will do some coding along the way.

[mitfik]

I think create interface for ror-e is the best solution, especial that it does not matter what gateway(s) (or tool like AM or spreedlycore for it) user will want to use. Store will act always the same: collect information about order, check if is paid or not, create invoice and so on ...

And some arguments to last my post: Why open source

[deanpcmad]

Just looking through the issues and thought I'd give my opinion on this. I think adding plugins or Rails engines for the billing side of things would be a good idea. Again, like you said, there are loads of payment gateways and it would be hard trying to implement with them all. It depends on the amount of work required, but I think Rails Engines would be a good way to go.

What are your thoughts?

[mitfik]

I do not know if I understand your idea clear but if this is the same as:

Implement interface in ror-e to handle payments information internal and then provide plugin(s) for each payment gateway.

then I totally agree. The idea behind that is just the same as behind ActiveMerchant (https://github.com/Shopify/active_merchant) simple library which allow everybody implement own payment gateway. Just abstract class to handle that.

This gives us:

• easier to maintain core code
• allow to implement any payment gateway

I think we just need to clear a little bit this what exist right now (we should stay with AM) and will be great.

Why AM ?

• very popular
• lots already existing payment gateways
• huge community
• not so bad code

It not make sens to invent wheel from beginning, always we can just send pull request to AM to improve it.

[mitfik]

Hi,

I already prepare proposition how it could looks like, I tested it with existing code and looks like that everything is compatible.

Description of my idea you can find here: https://github.com/mitfik/ror_ecommerce/wiki/Payments

branch: https://github.com/mitfik/ror_ecommerce/commits/payments

Thanks to use new Setttings class (rails_conf) it will be easier to configure payment system is just question of adding proper credential into settings.yml

I want to add few more features like UI hosted by payment system and

P.S. I already reuse rails_config support to make it much more clean and easy to configure.

[mitfik]

I just wanted to give you know, that there is new version in my branch: https://github.com/mitfik/ror_ecommerce/commits/payments

I rewrite a little bit payment system which is right now more flexible:

• possibility to use more then one payment method in the same time
• possibility to host terminal or redirect user to external terminal in secure payment system.
• abstract payment system class/module which allow to easily integrate any payment system, without necessary to use ActiveMerchant. You can use AM as well as other libraries which are available.
• and some small improvements around that.

Next step is to do some more tests with different payment system and prepare stable version.

Please take a look and give me know what do you think.

[drhenner]

I'll take a look by the end of the week. Do you think it is ready to pull into the main repo?

[mitfik]

Not yet, but it is very close to it. I need to make few more tests with other payment systems but anyway is hard to predict all configuration right now. But I think this level of abstraction allow us to be independent from libraries like ActiveMerchant which I think is good approach. I will keep posting you about progress.

[drhenner]

Very Cool!!!

[drhenner]

BTW I did create a stripe_commerce project.