Subscription Payments

Last year I created the member management system for Build Brighton, this was a system designed amongst other things to track members monthly subscription payments. I designed the system around the GoCardless direct debit processing but because of legacy members it also had to support PayPal and standing order payments.

When setting up the GoCardless processing I opted for their subscription payments as this seemed the most logical solution, afterall thats what I was doing. Their subscription system basically does everything for you, once setup it will bill members each month and let you know the outcome.

The Problems Begin

The system got built and implemented but over time I started to find the flaws in this setup, the first being changing the subscription amount. This isn't possible so if a member wants to pay more or less you need to cancel the direct debit and set up a new one. This isn't a problem but it does require the user to make a round trip to the GoCardless site, not a great experience for what should be a simple thing.

The other problem and the key one for me is keeping track of each payment, its status and what month it's for, especially in situations when payments get declined and need to be retried. With Gocardless if a payment fails you need to manually retry it and if you don't nothing happens, everything carries on as normal and the next month it takes the next payment. This has led to situations where some months payments never get collected. This isn't necessarily a GoCardless issue but one I feel should have been part of their subscription offering.

Making Changes

I am currently in the middle of making two changes to the direct debit subscription system at Build Brighton, one is switching away from subscription payments and the other is setting up what is effectively a monthly invoice to track the payments.

The alternative to subscription payments is getting the member to setup a variable direct debit, a pre auth, and then generating payments each month against this. The payment amounts can be arbitrary and don't require any subsequent user interaction, this means the member can very easily change their monthly subscription amount and additional ad hoc payments can be made quickly and easily.

Because these payments are now initiated at my end I need some way to know when to generate them and to solve this I created an entity called Subscription Charge. Every month, 3 days before the member payment date a sub charge record will get generated, if the member is paying by the new variable direct debit payment system this record will get picked up on the correct date and used to initiate a payment.

If the member is paying by any other means then when notification of that payment comes in the system searches for the members oldest sub charge record. This bit is key to keeping track of payments as by locating the oldest payment it means payments can't ever get missed. In addition, by generating the sub charge record 3 days early I can cater for discrepancies with the billing times of other payment systems as well as fulfilling direct debit notification period requirements. I don't want to risk a payment notification coming through before the sub charge has been created.

This upgrade is going well and one I am looking forward to getting in place as it will solve a lot of problems, for now my priority is making sure the existing payment methods, gocardless subscriptions, paypal subscriptions, and standing orders get correctly mapped to the subscription charge records being generated for members.