First Capital Cashflow Direct Debit Payment Plugin

<sarcasm>Arghh... nothing cheers me up more than the week we plan to launch the use of Membership Pro being told the club wants to add an additional payment processor.</sarcasm> Of course to make life simple, the processor isn't available in MemberhsipPro :sick:

So, I've just received the API documentation. This is a direct debit system rather than a card payment system (so similar to GoCardless). In some form I will be looking to make it a recurring payment. The system is designed to cope with that obviously.

I can see 3 possible models that may or may not work! Your thoughts would be welcome:

Option 1 The processor creates a recurring payment. That seems the obvious solution. But on my first skim read of the API it doesn't send a payment confirmation when the money actually moves. You can query the API and check the payment cleared, so I could create a plugin that runs every 24 hours say, and checks for any payments that were expected and didn't clear and then do something to the Subscription table.

Option 2 The processor can create a "permission to take money". Reading the OmniPay documentation I think this is similar to the token system. If we did that, If I understand correctly I'd then need a plugin that generates a payment request each time a recurring payment is coming due and a further plugin / function that checks for that clearing.

Option 3 The processor might offer a pay-by-link function. Not a fan but would be far simpler! Wouldn't close any accounts unpaid?

So my questions:

A. Of my options above - am I right that MembershipPro doesn't generate a request like Option 2 its self - it expects the payment processor to take the payment?
B. Do recurring payment processors all send a message to confirm payment was taken on the recurring payment? What happens when no notification is received? Is there any 'cushioning' in that to allow delays in payment etc. Direct Debits never happen on weekends for instance?
C. If someone wants to cancel - assuming I allow cancellation - do all the existing recurring payments handle that through the payment people's website?

I will of course share the code publically.

Hi Calum

I think you should contact the payment gateway provider and ask them to see whether they support the option #1. That would be the easiest way.

Basically, at the time people sign up, the system will register the recurring payment with the payment gateway and the payment gateway handles the payment itself

Each time the gateway handles the payment, it will send notification back to your website to inform about it (the URL which should receive payment is domain.com/index.php?option=com_osmember...ethod=os_plugin_name

The payment plugin will then validate the payment and extend the membership...

That's how all the existing payment plugins support recurring payment works. It will be quite hard if you go with Option #2. For option #3, to be honest, I still don't understand how it works and could not give any feedback about it. However, I think the option #1 is the easiest way (hopefully the payment gateway support it)

Tuan

Tuan Pham Ngoc wrote: Hi Calum
Each time the gateway handles the payment, it will send notification back to your website to inform about it (the URL which should receive payment is domain.com/index.php?option=com_osmember...ethod=os_plugin_name

You'd think!
But they definitely don't send an outbound message on payment. You can use SOAP at any point to query the payment status. So if this was the only part of membership I guess you could hold a fields in the joomla table against a user and just SOAP that payment reference each and every time a member logged in through a new authentication plugin! But I want to do all the integration stuff MembPro offers like adding to AcyMailing lists, sending welcome emails, cancellation emails etc.

So I will create a plugin that every 24 hours does a big SOAP request for all transactions since the previous request, then parses through each of those and creates a notification. Is there documentation for the valid 'task types'? is there a recurring_payment_fail? or something simillar? And should my plugin just cURL that URL or is it better to skip that stage and call the class/function that the cURL would have called.

That's how all the existing payment plugins support recurring payment works. It will be quite hard if you go with Option #2. For option #3, to be honest, I still don't understand how it works and could not give any feedback about it. However, I think the option #1 is the easiest way (hopefully the payment gateway support it)

Ta - option 2 would only work if there was some trigger in MembPro that occurred at or approaching expiry. In theory I could use the reminder email plugins to do something similar. But feeling like I'd end up with a very hacked MembPro!

option 3 is very simple. In effect they say provide a link to the customer along the lines of " www.firstcapital.com/paybylink?account="..."&reference="ABCDEFG " - when user clicks that they are taken to a payment form on firstcapital's payment gateway and they fill in their bank details etc. All very simple. I suspect they end up completing their address etc as I don't think I'd be happy passing it in the URL even if they allow it. That will frustrate users. Then it doesn't send any confirmation (so effectively we'd rename Offline Payment to Direct Debit and put the link in there and handle it all manually. Would be fasted to deploy and test but least functional! **BUT** Offline doesn't handle recurring does it? And I assume its not just needing a setting in the offline processor plugin to say "can be recurring"?? In theory I could manually enter the payment reference and then develop the SOAP plugin to check for payments later... it will still see the paybylink ones (I think!)