Ubiquiti Employee
Posts: 4,055
Registered: ‎12-10-2015
Kudos: 1436
Solutions: 312

Re: UCRM Dealbreakers: Recurring Payments

Hi @markb540
you can use UCRM API https://ucrm.docs.apiary.io/
and soon (in v. 2.10) you can also create Plugins for UCRM based on API. You could also configure webhooks.

Follow the UCRM community section for more details, during this week.
Member
Posts: 122
Registered: ‎02-01-2014
Kudos: 16
Solutions: 1

Re: UCRM Dealbreakers: Recurring Payments

Petr, About a month ago, you said that an updated way to handle recurring payments could be released in "1 to 2 months". Since it has been a month, I'm just curious if any headway has been made on this.
Ubiquiti Employee
Posts: 4,055
Registered: ‎12-10-2015
Kudos: 1436
Solutions: 312

Re: UCRM Dealbreakers: Recurring Payments

In the next beta release (2.11.0-beta1 - ETA late March), you will be able to use Autopay for Stripe (besides the current Recurring payments).
The Autopay will take care of automatic charging of proper current price of client's service.

Any additional related features (like charging the client's account balance or Autopay for another paygate) may follow. It would be great to register new feature request for each so the community can upvote it. This will help to set the priorities for future development.

Thanks.
Veteran Member
Posts: 6,104
Registered: ‎07-03-2008
Kudos: 1937
Solutions: 142

Re: UCRM Autopay


@UBNT-Petrwrote:
The Autopay will take care of automatic charging of proper current price of client's service.

Any additional related features (like charging the client's account balance or Autopay for another paygate) may follow. It would be great to register new feature request for each so the community can upvote it.

Is Autopay supported on IPPay?

 

Ubiquiti Employee
Posts: 1,447
Registered: ‎03-21-2016
Kudos: 237
Solutions: 159

Re: UCRM Autopay

@MimCom  Not yet, first implementation will be for Stripe, for other providers we will decide based on upvotes and usage statistics.

Veteran Member
Posts: 6,104
Registered: ‎07-03-2008
Kudos: 1937
Solutions: 142

Re: UCRM Dealbreakers: Recurring Payments

Thank you.

 

I just created a request for Autopay on IPPay.

Emerging Member
Posts: 110
Registered: ‎03-05-2018
Kudos: 52

Re: UCRM Dealbreakers: Recurring Payments

I found a  few requests for some gateways but not for Authorize.net so i went ahead and created a new feature request here

 

This could actually put on hold our own integration, i hope we can get some sort of auto pay for invoices integrated soon for most payment gateways.  

New Member
Posts: 10
Registered: ‎02-13-2018
Kudos: 9

Re: UCRM Dealbreakers: Recurring Payments

this is exactly what I can help with. d have been pursuing this for only a little bit now and am ready to set a project plan in place to build an Integration or plugin that will

  • make auto pay an option 
  • combine with an invoice 
  • process on TI level Compliance 
  • provide a setup to users that is seamless
  • provide accompanying hardware to enable user totake face-to-face payments anywhere with an E M V chip, NFCpayments 
  • more options down the road. 

All need is to get connected to the right person togain direction on what to do first. 

 

Help, I'm ready to go. 

 

Mark 

(540) 693-0424 mobile 

 

Ubiquiti Employee
Posts: 4,055
Registered: ‎12-10-2015
Kudos: 1436
Solutions: 312

Re: UCRM Dealbreakers: Recurring Payments

Hi all,
we are now considering how to enable the community to implement their own payment gateway integration.

Approach 1: integrating new payment gateway directly into UCRM, (the UI and the triggering of the subscription will be powered by UCRM)

Approach 2: everything will be handled by a custom implementation independent of UCRM. (the UI and the triggering of the subscription will be powered by custom implementation). The only interface between UCRM and the custom implementation would be API and webhooks.
Emerging Member
Posts: 110
Registered: ‎03-05-2018
Kudos: 52

Re: UCRM Dealbreakers: Recurring Payments

Personally, i would be fine with option 2. If UCRM allowed us to create the recurring payment via the API using the inovice webhook creation. So when an invoice is created we have our own custom script that just creates the recurring payment on UCRM using a new API method for creating Recurring Payments.

Regular Member
Posts: 395
Registered: ‎01-18-2017
Kudos: 127
Solutions: 13

Re: UCRM Dealbreakers: Recurring Payments

I am not sure what the value of ucrm would be going forward with option 2. We implemented ucrm specifically for managing our financials.

Ubiquiti Employee
Posts: 4,055
Registered: ‎12-10-2015
Kudos: 1436
Solutions: 312

Re: UCRM Dealbreakers: Recurring Payments

@clarkraymond yes, UCRM will still contain all the information about invoices and received payments. The "option 2" just means that UCRM will not automatically charge the client, the custom Plugin will do that, which means the Plugin will be responsible for:
- creating and managing the subscriptions
- triggering all the payments
- pushing the payments to UCRM
Regular Member
Posts: 395
Registered: ‎01-18-2017
Kudos: 127
Solutions: 13

Re: UCRM Dealbreakers: Recurring Payments

Since several payment methods are already contained within UCRM, if you go with approach 2 will you make those available as plugins or will we be required to create them?

Ubiquiti Employee
Posts: 4,055
Registered: ‎12-10-2015
Kudos: 1436
Solutions: 312

Re: UCRM Dealbreakers: Recurring Payments

The Plugins are mostly designed for the community, they are open-sourced and the development can be shared. The main point is that our own resources can't handle implementation of all more than 20 requested payment gateways. So, both approaches 1,2 are intended to be used by the community.

If we decide to implement a new gateway support, we will hardcode it into UCRM most likely. However, it's also possible to cooperate and help to create a new Plugin, if someone asks us.

Regular Member
Posts: 395
Registered: ‎01-18-2017
Kudos: 127
Solutions: 13

Re: UCRM Dealbreakers: Recurring Payments

Absolutely understand the never ending scope increases. I just wanted to vote for not breaking what is already working.

 

Keep up the good work!

Ubiquiti Employee
Posts: 4,055
Registered: ‎12-10-2015
Kudos: 1436
Solutions: 312

Re: UCRM Dealbreakers: Recurring Payments

Sure, the current features and integrated tools won't be modified. What we are discussing here is the additional stuff only.
Regular Member
Posts: 719
Registered: ‎11-10-2012
Kudos: 86
Solutions: 16

Re: UCRM Dealbreakers: Recurring Payments

Just got this from Stripe:

 

Stripe.png

Highlighted
Member
Posts: 111
Registered: ‎01-07-2014
Kudos: 45
Solutions: 1

Re: UCRM Dealbreakers: Recurring Payments

[ Edited ]

@Blinc @UBNT-Petr I saw that yesterday. What was most interesting was the "usage-Based Billing" feature.

Wondering if that could be hooked into the UCRM / Stripe billing for usage based invoicing?

 

-Dan

Ubiquiti Employee
Posts: 4,055
Registered: ‎12-10-2015
Kudos: 1436
Solutions: 312

Re: UCRM Dealbreakers: Recurring Payments

I don't think this would be an advantage. UBB will be eventually comprised by UCRM and pushing usage-based data into Stripe could end up with different final values invoced by UCRM and Stripe.

Currently, your options are:
- one time Stripe payment
- recurring Stripe subscriptions (fixed price every month)
- linked recurring Stripe subscriptions (any service price changes are reflected and the proper service amount is charged every month)

and in our next development:
- Stripe autopay (client outstanding amount will be automatically charged every month) - This should be the easiest way everyone
Member
Posts: 222
Registered: ‎03-19-2018
Kudos: 51
Solutions: 7

Re: UCRM Dealbreakers: Recurring Payments

+1 for adding the ability for plugins to handle some of this. Currently payment plans aren't available for most of the gateways via the API. This is quite the hindrance to finalizing my stripe plugin for integrating a frontend signup.

 

The "linked subscriptions" in some of the new releases could potentially solve some of these problems but these also aren't available via the API, so plugins are confined.

 

 

I've also mentioned this in the API thread.. Does having more payment plan gateways available via the api need to be a feature request? Or is there current plans for implementation? What is the priority? 

HTML, SCSS, Javascript(Ember.js), Ruby(Ruby on Rails), PHP