4 ms·

Care to share an opinion on who does it best? Or least worst?

by chaz 13y ago

skore 13y ago
Can't really pick a best. The reason why I write that recurring billing is hard is because the business cases vary so widely, so the answer is usually: It depends (on your location, userbase, what you're selling...). I started out writing a couple of integrations and you think "hey, why are there so many processors, that's unnecessary!". And then you do a couple dozen and you start to see the picture. I CAN definitely tell you how to spot the worst, though. In general, when you read the documentation and get the creeping feeling like the API was written for one big client (and their weird business logic) and then they just packaged it up and resold it, badly. Funnily enough, Google Checkout seemed to be like that to me - for instance, usually you have two things to specify: Time unit and amount of your billing cycle, like "recur every 4 days". Google Checkout didn't do that, no no, much too simple. They only had a time unit - one of: daily, weekly, semi_monthly, monthly, every_two_months, quarterly, yearly. And that's not the most complex "let us structure time awkwardly" example I have seen over the years. Other services only allow for "days" as time unit and you have to figure out a way to do monthly billing that doesn't just keep running away. My favorite so far was the one where it's basically "day, week, month, quarter, half-year and year". The values for that? D, W, M, Q, 6, Y. Can't make this stuff up. Other red flags: No English documentation, no public documentation, documentation that specifies variables without data types, unsafe notification functions (not even a shared secret) or downright exotic "security" (I have seen black-box .dll files distributed as security callbacks... oh the horror)... I could go on.
- chaz 13y ago
  Thanks for the insight.
- yardie 13y ago
  If it's any consolation my bank pays off my credit card every 30 days. When I signed up the credit card would get payed on the 1st of the month. Over the years that date has drifted to now be the 20th. So even the big players haven't solved this recurring payment problem.
  - Pxtl 13y ago
    I still think that offering "every N days" and "Nth day of the month" would cover 99% of use-cases. The big problem I ran into was when my credit-card expired, PayPal paid a recurring bill late as it had to do an "e-cheque" that had a long delay on it. So the payment happened late. The WTF happened the next month, after I fixed the credit card issue - every future bill had the same long delay on it. Somehow their "Pxtl pays on X day of the month" had gotten shifted. So I was getting late notifications every month.

Care to share an opinion on who does it best? Or least worst?

by chaz 13y ago

Care to share an opinion on who does it best? Or least worst?

skore 13y ago

Can't really pick a best. The reason why I write that recurring billing is hard is because the business cases vary so widely, so the answer is usually: It depends (on your location, userbase, what you're selling...). I started out writing a couple of integrations and you think "hey, why are there so many processors, that's unnecessary!". And then you do a couple dozen and you start to see the picture. I CAN definitely tell you how to spot the worst, though. In general, when you read the documentation and get the creeping feeling like the API was written for one big client (and their weird business logic) and then they just packaged it up and resold it, badly. Funnily enough, Google Checkout seemed to be like that to me - for instance, usually you have two things to specify: Time unit and amount of your billing cycle, like "recur every 4 days". Google Checkout didn't do that, no no, much too simple. They only had a time unit - one of: daily, weekly, semi_monthly, monthly, every_two_months, quarterly, yearly. And that's not the most complex "let us structure time awkwardly" example I have seen over the years. Other services only allow for "days" as time unit and you have to figure out a way to do monthly billing that doesn't just keep running away. My favorite so far was the one where it's basically "day, week, month, quarter, half-year and year". The values for that? D, W, M, Q, 6, Y. Can't make this stuff up. Other red flags: No English documentation, no public documentation, documentation that specifies variables without data types, unsafe notification functions (not even a shared secret) or downright exotic "security" (I have seen black-box .dll files distributed as security callbacks... oh the horror)... I could go on.

chaz 13y ago
Thanks for the insight.
yardie 13y ago
If it's any consolation my bank pays off my credit card every 30 days. When I signed up the credit card would get payed on the 1st of the month. Over the years that date has drifted to now be the 20th. So even the big players haven't solved this recurring payment problem.
- Pxtl 13y ago
  I still think that offering "every N days" and "Nth day of the month" would cover 99% of use-cases. The big problem I ran into was when my credit-card expired, PayPal paid a recurring bill late as it had to do an "e-cheque" that had a long delay on it. So the payment happened late. The WTF happened the next month, after I fixed the credit card issue - every future bill had the same long delay on it. Somehow their "Pxtl pays on X day of the month" had gotten shifted. So I was getting late notifications every month.