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
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
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?
I hope your new ver is as good at the v2 i have installed the current ver to have a look and its lacking the nice look and some of the add-ons that v2 had. v2 had a way of installing plugins and the one i use is the overdue account where it will add 10% or what ever i want to there invoice for late payments.
I am just finding out about this, as I didn’t come around for a while (nothing much was happening).
I am puzzled: what’s the reason to moving to Laravel and abandoning CodeIgniter ?
Why not continuing with the current version and just adding what’s missing ?
Not sure how come thinking to develop something from scratch instead of choosing a software that is already working, tested with many users, and 100% functional could be a good idea. Of course this is not a company, and provide as many services as possible with minimal effort is not a thing to consider. But… Would be that bad start from FI?
I’m saying this as a project manager (I’m not developer), but what you plan to do, even could look the right decision, it’s gonna take tons of effort (and users’ effort as well) that is not really necessary.
Remember what happened to Netscape and the reason…
Your points are good.
Ultimately, the decision of whether to start a version 2 from scratch versus or continue developing the current version is a toss up between the capabilities of the current framework and what alternatives offer.
Codeigniter is good, it is rooted in an MVC-centric history, while alternative frameworks like Symfony ad Laravel offer other development approaches more easily, like Domain-Driven Development.
There are many things that need addressing in IP, and some of those go back to the core design. An example of this is a more modular approach. with the ability to develop functionality independently of other modules. Sometimes the limitations of a start-from-scratch approach allows for a less painful path to re-building the design.