Could someone with a bit of knowledge of this pool explain to me a little about the API?
Im trying to monitor the generated BTC once an hour, and unlike most pools i'd use theres no total paid out value in there, and im struggling to understand which specific stats i want to be using to get an accurate measurement of income.

Currently im using 'confirmed rewards', and im running a check on the last db entry to see if that figure has decreased then it must have meant a payment has been sent, in which case i increase the db's total payout to += 'send_threshold'.

I thought that would be correct, however about 2hr ago my db stats went from:

16:00 UTC
Confirmed: 0.31413209
Total Payout: 0.00000000
Hourly update: 0.00000000 (no block solved)

17:00 UTC
Confirmed: 0.04204677
Total Payout: 0.25000000
Hourly update: -0.02208532

18:00 UTC
Confirmed: 0.13160902
Total Payout: 0.25000000
Hourly update: 0.08956225

Now, this has happened because rather than simply paying out based on the threshold, its paid more (0.31), however there doesnt appear to be anything in the API which tells me there has been any payment, and it means my attempt to code something in to respond to the fact that there isnt a total paid out statistic, is completely useless because if it sends 0.31btc i only know this by manually looking, and i have to go fumbling through the database to fix this.
Has anyone found a solution which allows for the funds to be properly monitored, i genuinely thought with the 'send_threshold' it'd work, but its not much use really, its just another snippet of information rather than being a valuable means of circumventing the lack of 'total_payout' on the account & API.

0.08-0.09 is not smaller than your usually 0.012-0.014.

uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this

Better connected/faster servers reduce it a lot.  3 orphans in 24 hours is seems extremely high given the size of the pool.  Orphan rates should be <1%.  Obviously a given sample may have much more than 1% just due to lack of # of rounds being evaluated.  Maybe organofcorti can shed some light on the probabilities.

EDIT:  2 of the 3 orphans were never even seen by Blockchain.info...that points to serious server issues.  These blocks were either never broadcast, or were broadcast well after the prior block (meaning no connected peers accepted it and rebroadcasted).  The timestamp on 265441 was more than 1 minute after the competing block was seen by Blockchain.info.  The timestamp on 265419 was almost 4 minutes after.  This may not be the real delay due to ntime rolling/slush's poold configuration/where the table get it's timestamp from.  But those are both blocks that were not even seen by the rest of the network apparently.

I would rather use a YubiKey than Google Authenticator, not that I don't trust Google but...

I saw that too just now....what's with the invalid blocks lately?