The Future of InvoicePlane

Thanks for this post.

I’am one of the users come over from FusionInvoice. I did even use MyClientBase back in 2011 +/- 1 year. I loved all of it. As my requirements has grown, I started to implement AddOns and templates for myself and my clients… dozents…

I was really sad to see, that FusionInvoice disappeared. I downloaded InvoicePlane 2.0 Alpha 1 and started testing. I even set up 2 instances in december for clients as of I thought the disappearing of FusionInvoice was a final decission.

Since two weeks I mentioned, that they maybe come back and I was really interested in what’s going on here now. It’s sad to read that you plan to not migrate to FusionInvoice 2 but to start a new Codebase. I think this is not the right decission, you will lose a lot of time and potential users, but OK, it’s up to you.

Hint: FusionInvoice is already modular. There are devs out there (like me) who implement a lot of AddOns. Migrating to an OpenSource and maybe also donate to an OpenSource sounds like a good option to migrate all the existing AddOns/Templates…

Please answer one Question: Is the current database schema of 2.0 Alpha 1 compatible to the latest FusionInvoice, so I can migrate from 2.0 Alpha 1 to the next FusionInvoice version?

@lippoliv - as InvoicePlane v2.0 Alpha 1 undertook no database changes from the FusionInvoice 08-2018 release, we can only hope it will continue to work with any plans the developers may have.

There are other issues behind why we took this decision and I hope in time we can prevail in showing that this may be the harder path but the most rewarding for all.

Thanks for the reply. I really wish you all the best for this, no joke.

Damn that sounds so good.

Yes I hoped that so hard! For me this is 100% the right decision

Its like christmas and B-Day at the same day

Yes hopefully all with something where we can change Sass variables to customize it.
Love that, and CoreUI looks so good/professional!!

But I also have some questions:

Are some quicker BugFixes planned?
Like the fix to support PHP7.3?
Which already exists here in the Forum. --> LINK

Is there a ETA for a Pre-Alpha for IP2? Because I would really love to test IP2 and report back.

The hope is to get all the current fixes out by this weekend, time permitting, especially to ensure support of php7.3.

A Pre-Alpha for IP2 will be as soon as we can get the structure set up and the documentation up to standard to go alongside it. We are not slacking on the documentation and we want to ensure anyone can pick it up, work out where to go and get done what they want to do.

Interesting to see what’s happening guys. We would be willing to maintain the payments element going forward if that was of interest and a burden to you? We would look to switch out the current payment stack for our own and use our API, let me know if you want to discuss. Here’s more info. https://www.paywithbolt.com/saas-providers/invoicing-software-payments/

Nick what do you need exactly? A connection from invoiceplane to bolt? Then push invoice info to your api?

Yes, basically a connection from invoiceplane to Bolt is what we’d need. Then hit our end points with invoice data and we’ll fire webhooks on success, which can then be used to trigger receipts or whatever in invoiceplane. We maintain the payments infrastructure so you’d never need to recode the integration unless there were new end points or something, which we could amend for you. We’re also delivering new gateway integrations every month, which would then be available in invoiceplane. You’re welcome to do the integration yourself but I was offering resource.

It’s definitely an interesting proposal, I’d be interested to know if the API would be able to support subscriptions as well as one-off charges.

I’d ultimately have to see what the community votes on, my initial thoughts would be to give users the choice, either on install as a module (ie IP-Payments Module || or || Pay with Bolt Module)

Could you also suggest your competitors and why your solution would be the best or better option over the rest?

No problem, yes you can do recurring payments either via card or direct debit or ACH in the near future via the API.

We’re aiming to become the defacto standard for connecting payment providers. Lots of our clients phase out their existing payments module and replace it with ours so this could be a way to go. I just thought it would be a lot easier for invoiceplane to maintain, with no cost to you or the platform. Users can use our service for free or pay $16 to brand the payment popup.

Our competitors for payments integrations could be Spreedly or the open source project called Active Merchant. However neither of those are a turnkey solution like ours. And secondly we are the biggest third party provider to QuickBooks for online invoice payments and payment gateway integrations. We have proper partnerships with the payment providers, card issuers and industry. We also provide an SLA are PCI DSS Level 1 compliant. Happy for the community to vote. Let me know if you want to know anything else or if you guys want to do the integration yourselves - https://paywithbolt.com/1weekchallenge

I would not be in favour of a module being restricted to a single service, Implementations need to have a choice of payment providers. InvoicePlane should supply the hooks -service providers like yourself should be welcome to mould your offering to suit the requirements of the project, and to offer code enhancements to IP itself.

Thanks for the update, I have a question, I am a new user and I started with v2 already. Is there a way to migrate back to 1.5.9 ?

Sadly not, there are massive differences between IP v1 and the former Fi/IP v2 software.

Hi Crafter, we package up lots of payment providers: Stripe, PayPal etc. We release more providers every few months. I’m not sure you get what I was offering. Happy to talk about it further

Hi

I think it may be worth considering both, the current OmniPay as a module and PayWithBolt as a module, with agreement with the community. Would there be any discount that could be offered for your premium offering?

I think these Modules should not get shipped with the new IP2 Version by default, everyone who wants to have them should install them if he needs it.

For me it would be better if basic things like:

• fully PayPal integration
• AmazonPay integration
• Banktransfer
• etc

would be perfectly integrated out of the box and if its not enough for someone he can install some of the mentioned modules (OmniPay, PayWithBolt) etc.

I generally think that using things directly is much better and makes you independent and not depending on other services. Also services like these can change conditions and prices over night.

For me: I dont need PayWithBolt (also never heard about). So I personaly dont wanna have it in my IP2 but making IP2 support it (for other users then me) would make sense.

That’s fine, the point is that as the dev. team you’ll have to maintain all these integrations yourselves. We won’t change prices on you, and you can use our service for free. If this is too challenging to wrap your heads around that is fine, I was just following invoiceplane and trying to help you get IP2 going.

The only reason you’d want our premium offer is if you want to white label the payments. I can give you a discount on that, but you can use our service fully featured for free. OmniPay is effectively an open source type competitor to us based on Active Merchant - why are we better than OmniPay or Active Merchant, because we have partner agreements with the payment providers, we also do a lot more of the heavy lifting in terms of the merchant on-boarding and checkout.

From a personal POV, I appreciate the offer of introduction us to Pay With Bolt, and I can see the advantages of API over coded gateway access. I’m a firm believer of offering choice to give the end users what they are most comfortable with.

My personal opinion and unaffecting of the path of development would be to offer both and maybe more in the future, PayWithBolt may offer those in professional industries securities and peace of mind of a professional paid for supported system, but likewise, those whom are comfortable with open source developed gateways or developers will appreciate the flexibility and adjustability of the likes of OmniPay.

I’d personally like to see both includes and more, but I think this may be something put to a poll to register the true interest of offerings.

how about hide IP v2 from home page and in other pages so this don’t create confusion about v2 argument?