This actually solves a problem for me. For a long time, "finish Google Checkout recurring billing integration" was on my todo list. Just didn't get to it due to limited time and confusing documentation. Now I can simply close that ticket.
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.
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.