Support for more Payment Gateways

  • I think one of the blocking issues for the uptake on an ecommerce platform is what payment gateways are supported, especially for those switching from other platforms where they’ve got the merchant accounts already set up.

    I know you’ve got a PayPal and Stripe gateway module on the go but here in the UK a lot of companies use the likes of WorldPay and SagePay. Sure Stripe may offer better facilities and costs but you’ve also got to look at the point that some companies don’t want to switch what they’ve been with for years, especially when what they’ve got has just worked without problems.

    I myself have gone round the whole gateway issue many times with my company and previous companies I’ve worked for and as it stands now I’m probably going to have to make our PrestaShop SagePay module work with TB if we go TB because PrestaShop certainly won’t provide any support in making their module work with TB!

    It might be worth surveying users as to what gateways they use on their current systems to see if this is a wider issue and also what could be blocking them from their uptake of TB because there seems to be a lot of interested people but not as many uptakes from those with established platforms.

    From the reported 10,000 users of TB (you mentioned it in a blog) I get the impression from these forums that there’s maybe 3 or 4 people who are actually running a live TB store that sells stuff. If that’s the case why are those other 9,996 people not running TB for their shop?

  • @DavidP have you testet out the PS SagePay on TB? in most cases PS modules will work right out of the box on TB.

    Stuff like Mollie, QuickPay, Epay, and so on actually works straight out of the box with out a single modification.

  • But there is way more with active TB stores then 3-4 ppl 🙂

  • @bzndk yup I’ve tried the module out in test mode and it has some issue with the form submission. TBH I’ve not tried thorough debugging to find out what’s wrong but it does work on my PS stores. I don’t know where I stand though on licencing, given I paid for the module under PS whether trying to use it under TB would void that.

    With regards to those other modules, maybe we should have a section under supported modules to show supported Payment Gateways or even on the front features page - something like that boosts confidence in the product.

    I’m guessing all those with active shops then aren’t forum users lol.

  • Here i Denmark there is actually 10-15 shops on TB so fare but they use Facebook groups insted, so that might be why.

    Hmm the issue is when it’s under a license and you payed for the module there is not a whole lot any one can do ofc you can get modification on the module, but the module cant be shared.

    But is it PS own module or the one created by Presto Changeo you use ?

  • @bzndk unfortunately I use the PS own module on 3 stores, have paid for it 3 times. I don’t expect my licences to cover TB support and I don’t know where I’d stand legally on trying to use them on TB, part of the reason I didn’t dig more into debugging them as I wasn’t sure if I was allowed to.

    I’ve had bad experience with third-party devs on PS so went with PS made ones as that seemed a more trusted source lol.

    Maybe I’ll just have to investigate in writing a SagePay interface to get round the issue. However, showing more supported gateways would be handy as I didn’t know about those you mentioned until you brought them up.

  • Hmm since you payed for the module for all 3 stores, you should be fine if you still use the module on the same domains i dont think you do anything illigal.

    Haha ye most modules developed by PS is shit sadly 😞

    What is the reason you use SagePay? Cant figure out there pricing structure, they got a forced amount monthly but card fees is not mentioned any where.

  • @bzndk seems PS all round from my experience is crap modules - of the few we’ve bought we’ve had to ask for refunds on a couple as they didn’t do what they claimed they would.

    My company has used SagePay since about 2007 apparently, going back to old Salesforce days, and so don’t want to change that especially given that Stripe takes 7 - 10 days to get your money from them. I’d looked at CloudSwipe but they don’t want to pay a monthly fee for it. Also the fact SagePay is a UK based company they’re happier dealing with it than a US based one, partly due to the fact if they get problems they can ring them during office hours. The fees are fine though the cost is higher than Stripe due to the monthly fees. It does though have the added benefit of taking PayPal from within the system so you don’t need to install two modules for it and PayPal.

    SagePay is old school that for the most part just works (except the Black Friday 2017 blip lol) and has good customer support; if you get a failed payment you can find out within minutes what went wrong, even whilst you’ve got the customer on the phone.

    I could probably fix the SagePay issues myself but it’d be handy for TB to provide a list of the supported gateways as for the uninitiated it does seem it’s Stripe and PayPal are the only ones supported.

  • We are currently looking at using Mollie, even tho we are based in Denmark, the Dutch company Mollie seems to make a lot of sence using.

    But ye some comapnys dont want to wait 7 days between payments, here in Denmark it’s the standart that there is payout’s once a week, we will stick with that if we use Mollie since it would not make sence to change it Danish banks takes ex 2,5 Euro pr bank transfer from outside of Denmark, so keeping it once a week is the best option for us i think.

    Like i said in most cases all the payment modules that works in PS works in TB, there can be minor issues ofc there can, since there are code changes.

    Is you problem with SagePay purly CSS based do you got an idea about that ?

    Making a list like the one you would like requires that everyone using TB, add’s what module they use and if it works and so on, since team TB can’t test them all rly.

  • Presto-Changeo’s sagepay module works with thirty bees, we have a few clients using it.

  • @lesley that’s good to know. I think I also get a discount from them from my contribution to the Elastic Search module 🙂

  • @bzndk My SagePay issue is reported from SagePay so I have to debug error logs and form submissions.

    Yup the list would require people using TB to list what they use but a survey of TB users would be good for that.

  • Hmmz, we started the Omnipay project for this purpose about half a year ago. It somehow stranded after we found out that we couldn’t add the Omnipay libraries to the modules because of conflicting dependencies.
    Now, that issue has been solved late 2017 thanks to a script called PHP-scoper. It scopes the Omnipay stuff away from the thirty bees dependencies so there’s no longer a conflict. After the first tests I managed to make the Mollie integration work via Omnipay:
    Note that this page is dynamically generated, depending on the payment methods that Mollie returns (credit card was not among them).
    Best of all, this only took 30 minutes to make, so this surely can be used to create integrations for other payment methods in an instant.

    So, what shall we do first? Start with SagePay? 🙂

    @DavidP could you help me with integrating SagePay Direct and/or Server via Omnipay? I noticed that there are integration packages for both and they are well-maintained. If everything goes well we can have this up and running within days.

  • @mdekker Would this apply to the FAC integration that we did as well?

  • We already made an integration for FAC, but I think FAC could work with Omnipay, too. Even though there is no official package, there seems to be a working one:
    Even token based billing seems to be supported with FAC, so this could support the upcoming one click payment module in the future:
    (token based requires the authorization, capture, createCard and updateCard methods to be available)

  • @mdekker Ahh ok so when we did that you didn’t use the Omnipay libraries to build it.

  • No, it was done natively.

  • @mdekker that sounds a fantastic idea with the OmniPay! When I last looked at it it seemed unsupported and I think you mentioned there were issues with it.

    I’ve looked at the OmniPay Github and it seems there is a SagePay implementation for both direct and server but there’s no reference to ‘form’. Given the PCI requirements for handling bank card details I suspect nearly everyone would use the form method with SagePay performing the card processing. Even the server method is risky as it entails communication to/from the website and a SagePay server.

    This page has the stuff for SagePay on github:

    but it needs composer on the system to install it, which I don’t currently have. It seems that branch was last updated in September 2017, like you say, there’s been recent updates.

    This is the page on SagePay for all 3 methods:

    This is from SagePay explaining the form method:

    For the form method you pass over to SagePay the users name, address, currency and amount and it does all the processing / validation then returns the user back to the website - there’s no interaction back and forth like there would be with the server method. This makes it clear now why we can’t do refunds from the website. Our module is very basic in that it doesn’t allow entry of a success & fail url, it just returns the user to the last page they were on regardless of status.

    From looking at the PS module code my issue could be related to PS_VERSION though I’m not 100% sure. Does Thirty Bees update this to a new value? I found something in header.tpl about re-assignment of var PS_VERSION = ‘{$smarty.const.TB_VERSION|@addcslashes:’’’}’; but I don’t know what this is doing. I notice there’s also some hard-coding in there of http that needs to be changed to https.

  • In the core we return a ps_version to make prestashop modules work with thirty bees.

  • Does SagePay Form return a token at the end?

    I noticed that omnipay didn’t pack frontend stuff for Stripe as well and it makes sense. You can often use those hosted forms/iframes to grab a token that later has to be sent with omnipay to the payment gateway and you can then further process everything as usual. This makes sure you don’t have to be PCI compliant in order to process CCs, because the sensitive data does not touch your server.

    Seen this line:

    Sage Pay Server captures any credit card details in forms hosted by the Sage Pay gateway,

    I think that you will have to/can combine Server and Form. Am I right?


Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.