Back to Room Booking Pro Support

Briddle
Briddle

No, right now the Room Booking plugin supports all popular payment methods (PayPal, Creditcard, iDeal, Bank transfers, Bitcoin, etc.). It does so using a single API from Mollie.com, an international Dutch Payment Service Provider (PSP).

From a functionality point of view Stripe does not offer any benefits other than being a better known brand. The Stripe API's that are famous for being well documented and simple to use actually are inferior to what Mollie has been doing thus far. Having said that I think it is always a good idea to offer customers different options so I am planning on integrating Stripe as well :)

However, at the moment I am still focussing on the core functionality of the Room Booking plugin:

  • writing (better) documentation,
  • making example-themes available,
  • testing & optimising core functionality in different user scenarios

For your convenience I have listed the PROS and CONS of various PSP's:

STRIPE

Stripe is a popular Payment Service Provider that focusses on creditcards and has recently added different payment methods (they call these "sources").

When Stripe first launched to the public, the Stripe API was a difference maker. It's clean, well documented, and extremely easy to use. Payment processor APIs of the past were buggy, inconsistent, and poorly documented. In fact, PayPal was one of the worst offenders.

PROS

  • Stripe supports different payment methods (but is focussed on creditcard)

CONS

  • Stripe may have a reputation for being a difference maker in payment API's, Mollies's API is actually FAR superior to Stripe.
PayPal

In a way, Stripe has forced PayPal to up its game. The documentation and organization of their new RESTful PayPal API is vastly improved and modeled after Stripe (coincidentally). This is an example of competition benefiting customers. Stripe has set a new standard for a clean and well documented API, and the rest of the industry (including PayPal) is rushing to catch up.

PROS

  • PayPal is widely used (in some parts of the world, not in Europe)

CONS

  • PayPal integration only supports 1 payment method: PayPal (creditcard)
MOLLIE

Mollie is a Payment Service Provider from the Netherlands (that's probably why you have not heard about it). Mollie offers a single API for creditcard, PayPal, iDeal, Money transfer, bitcoins, etc. Mollies's API is actually FAR superior to Stripe.

PROS

  • Mollie supports different payment methods
  • Mollies's API is actually FAR superior to Stripe

CONS

  • Not that well known :(
Eoler
Eoler

Interesting overview, thanks.

Mollie is not yet available down south in our region: https://help.mollie.com/hc/en-us/articles/115002116105-Can-I-create-a-Mollie-account-with-a-foreign-company-

PayPal "not widely used is Europe" is (according to my current knowledge) still only global payment processor that handles not just €uro but also other EU currencies... Braintree - a PayPal company, that is.

Briddle
Briddle

Hi Eoler,

Thank you for pointing out that Mollie is targeting the European market. That makes a big difference if you are.... not in it :)

PayPal will continue the grow globally (as will Apple pay since it is dominating mobile payments).

According to payment company Adyen (from a couple of years ago):

  • In Italy, Visa or Mastercard are the preferred online payment method (83%). Much more than PayPal (13%) or American Express (4%).
  • In Spain Visa or Mastercard are even more popular (91%) followed by PayPal (7%).
  • In Poland, the dominance of credit cards is much lower (45%). Online banking is a second best (35%), followed by cash based methods (15%) and PayPal (5%).
  • In Germany, the most preferred online payment method (38%) is ELV (short for Elektronisches Lastschriftverfahren), an electronic direct debit payment method that’s supported by banks in Germany. Followed by Visa er Mastercard (25%) and PayPal (16%).
  • In the Netherlands a similar method is the absolute number one. iDeal, also a payment method that’s supported by the majority of local banks, is the preferred payment method for 55% of online shoppers. PayPal accounts for 7%.
  • In Turkey credit and debit cards are very popular (87%), but Visa and Mastercard are nowhere to be seen. PayPal is the second most popular payment method (7%), followed by other wallets (6%).
  • In France credit and debit cards are very popular (82%) followed by PayPal (15%), followed by domestic Carte Bleu (3%)
  • In the United Kingdom Visa and Mastercard are popular (77%) followed by PayPal (10%).
  • In Sweden credit cards are pupular (37%) followed by online banking (35%) and open invoice (20%) and PayPal (8%).

In the U.S. PayPal is much bigger.

amdad
amdad

Hello, why not integrate Omnipay by default? Not just one gateway. But open gate way to multi-gateway. Mollie is also integrated with Omnipay too.

Briddle
Briddle

Amdad, excellent suggestion!

I have just openend up the Room Booking Plugin in two ways:

  1. The briddle.book.booking event (fired just after creating the booking and sending the mail but before handling online payment), the briddle.book.paid event (fired after marking the order as paid) and the briddle.book.imported event (fired after importing an event in the cronjob). These events can be used to add asynchronous functionality to the Room Booking Plugin (events are asynchronous and do not allow redirecting users or sending feedback to them).
  2. Callback functions

There are still a couple of things that I want to simplify and standardise but these two options will make integrating your own payment gateway easy.

I really like your idea to standardise the default gateway (now specific to mollie) and I will look into this the coming week.

Again, thank you for an excellent suggestion!

Last updated

Briddle
Briddle

Hello,

I have just released a new free plugin Briddle Omnipay that implements Mollie and PayPal Express components. Both can be used on my Room Booking plugin or on other projects.

Some Payment Service Providers like Stripe collect creditcard details on your site. Yes, I know these details do not have to be stored on your server and are send over SSL but I personally have a problem with this as there is no way for the visitors of your website to be sure that you do not store creditcard details anyway (for whatever reason).

The point being that as a visitor of your website I now do not only have to trust you to send me the items that I purchased on your site (creditcards are insurance against this scenario) but I also have to trust that you do not store or transmit my creditcard details in a manner that is potentially insecure (even if you do not need to store creditcard details yourself you could if you wanted to). 50% of those fears would instantly go away by only asking for creditcard details on the website of the PSP. Stripe currently does not offer this possibility.

I have included Stripe in this plugin but do not offer it in the components because I do not collect creditcard details in my Room Booking plugin or other projects.

amdad
amdad

+++ LEVEL UP! :) Thank you!

Although, I'm not already user of Room Booking it's just because I don't have project like this around. But as soon I get one, I will get it immediately. It's very good to see this plugin here, and growing strong.

New plugin for Omnipay is very cool thing. You saw this one before, right?https://octobercms.com/plugin/responsiv-pay

Last updated

Briddle
Briddle

Hello again and thank you.

I actually missed the Pay plugin. It's great to see such a diverse plugin landscape come into existence on the marketplace but I still find it difficult at times to decide where October CMS should begin and where it should end. Partly because these boundaries are not technological in nature.

What really sets October CMS apart is it's ability to create webapps that are available from a single environment: the CMS you are already using for your website, webshop or blog. From a developers perspective this makes a lot of sense but I do not think that end-users will install a CMS just to be able to use one of it's plugins (October is marketed as a CMS and the website is called octobercms.com). So any plugins for October CMS will target end-users who are already using October CMS for their website. Therefore these plugins should have some sort of relation with your website. Invoicing does not. A CRM does not. A helpdesk does not. A webshop does. A blog or a forum does and... room booking does :)

I have worked with InvoicePlane (open-source and self-hosted), my own solutions, Espo (invoicing as part of an open-source CRM), Moneybird (SaaS) and many others. An integration with the API of an existing SaaS or open-source solution makes more sense to me if you want to bring invoicing to October CMS. The market for such a product will always be much greater than any plugin that is specific to October CMS. As a result a plugin will always have less customers and thus less revenue and thus less growing potential. The biggest advantages of SaaS is that it is easy and relatively cheap, the biggest drawbacks are that you are limited to the functionality that is offered and that you put your financial and customer data in the hands of another (large) company. But that's just my two cents....

Afterthought

If October wants to market itself as something other than a CMS (like a "PHP platform") it should (in my opinion): 1) start by dropping cms from it's domain name 2) allow a plugin to not just be installed from October (after first installing October if you do not already use it) but to also be able to install the plugin directly from its own product website (and silently include October in the background).

In fact, it should be possible to modify October's installer for your own product to do just that. You could have a product website with it's own installer (branded for your product) that installs October and your plugin (October's installer already supports this). This way your plugin appears to be a stand-alone product to users who are not already using October CMS for their website (or do not want to combine their website and your plugin in a single installation).

Last updated

amdad
amdad

I thought, about Pay because it has integrated Omnipay. Just a good rule for future. Before go own way check existing plugins. We both, luv about October it's ecostystem and how plugins can complement each other and works native as a whole. Rainlab and Responsiv = Sam's plugins. So it comes from heart of October. So they are even more special ones.

I'm not telling this specific case, but general rule. The best way is to have super plugins that can be reused in as many projects as it's possible. So better to commit to ideas to existing good plugin to make it great (if possible) than always start from scratch. Start separate plugin if it's needed, not because of lack of reconnaissance what's around.

I hope that your Omnipay plugin can becomes standard one. Omnipay alone is great. But we don't need 20+ plugins to integrate with it. Just one that do this best. Second, if there are different set of needs, and only then.

To see many different approach to same issue is also good thing from learning perspective. But we have some goals here too: https://octobercms.com/help/guidelines/quality#common-requirements

Invoicing is a different set of boots here. I didn't even mention it. But I agree with you solely.

Last updated

Briddle
Briddle

Hello Amdad,

You have made some good points (again).

Unfortunately a search for "Omnipay" did not yield any results for me except for "Omnipay for Shopaholic". This was actually what made me think "Why just for Shopaholic? Why not a generic plugin?". So we agree fully on this point :) Unfortunately the Pay plugin does not offer a generic plugin for Omnipay either (it is marketed towards invoicing - not something that I want).

As you say, "we don't need 20+ plugins for everything". Just the one that does best. However, to get the best you need competition and you need to attract new developers and allow them to grow. This will, in time, create the 20+ plugins for everything that you fear BUT I think that the ratings, reviews and downloads will help people find the best one.

I would be very open to some sort of system that periodically cleans up the marketplace and hides (functionality is already there) plugins that:

  • have not been installed > x year AND
  • did not receive update > x year AND
  • have had a rating of < 2 for over x year
  • or some other sort of better criteria.... :)

Another option would be to use a sort of "Report as SPAM" equivalent: "Report as obsolete", maybe with a link to better alternatives? I agree with you that some sort of quality control for existing plugins will become more and more important to ensure the quality of the marketplace as October moves forward. In fact, it could remain something that sets October apart. Quality over quantity.

Last updated

Briddle
Briddle

Okay,

Thanks to some inspiration that was clearly triggered by Amdad in the posts above, I have changed my mind about October being just a CMS and decided to create the Custom installer for October projects.

With this plugin you can download a custom installer for your October project to use on a product website.

  • A custom installer allows people who are not already using October to install your project from your own product website (and install October in the background).
  • The installer can be branded to fit your own product and prevents confusing people who are not already using October by requiring them to first install October CMS from the October CMS website.
  • This is great for October plugins that offer plugins that do not necessarily have a relation with your website like Invoicing, Helpdesk, etc. in order to market these kind of generic products to a larger audience than users of October CMS.

And of course... it is free :)

Last updated

1-11 of 11