Fix in civicrm_stripe.js that was causing "Stripe.js Not passed" because token was empty.
Fix error message about accessing static variable.
Large cleanup to code structure in stripe.php.

Update info to 1.9.2.
Update civix.
Generated Upgrader.php (may not be triggering yet).
Set queries and writes to civicrm_stripe_plans and _customers to use is_live flag.

* Fall back to looking up the contact ID, apparent issue on Wordpress backend contribs.
* Catch error & display clear message when no email was found, instead of trying to query empty value.

Lots of code cleanup.

* Handle proper stashing of token for "Go Back" action on Contrib and Event forms.

updated stripe to v2, make compatiable with webform_civicrm, code cleanup / generalization to work with civicrm + webform, prevent sensitive data transfer across the server to ensure PCI compliance, also notice and indentation fixes

Strict warning: Declaration of CRM_Core_Payment_Stripe::singleton() should be
compatible with & CRM_Core_Payment::singleton().

And:
Strict warning: Accessing static property CRM_Core_Payment_Stripe::$_mode as
non static in CRM_Core_Payment_Stripe->__construct().

Usually when we setup staging and test sites, we set the Stripe payment
processor keys to use the test keys for both test payments and "live"
payments. This lets us test things more realisticly. Unfortunately, because
we are doing a "live" test, but using the Stripe test keys, the Stripe API
fails with "Received unknown parameter: livemode".

I think the CiviCRM Stripe payment processor should behave like all the other
payment processors and work as expected if you use the test API keys as the
"live" keys.

Usually when we setup staging and test sites, we set the Stripe payment
processor keys to use the test keys for both test payments and "live"
payments. This lets us test things more realisticly. This caused a problem
with the Stripe extension where it was it was sending 'livemode' => true
along with the 'create_plan' API call. This was causing the API call to fail
with "Received unknown parameter: livemode", but because stripeCatchErrors
ignores most errors the code was actually failing later on.

To make problems with the Stripe API calls easier to debug in the future,
we added some code to log all the exceptions when making Stripe calls and
make sure that Civi crashes when these calls fail. That way the user knows
that something went wrong with his transaction and he can inform the website
owner.

Sometimes, though we do expect an error from Stripe (like in the case where a
subscription plan already exists, but it isn't in the local
civicrm_stripe_subscriptions table). For that I've added an ignores parameter
to the stripCatchErrors method that can be used to tell it to ignore very
specific error messages, but still crash if we get an unexpected error.

BillingBlock.tpl is gone!
JS For Stripe is now injected on appropriate pages.

Known fixes
-----------
GitHub Issue: https://github.com/drastik/civicrm_stripe/issues/28
Ability to submit backend/offline contributions for a contact w/ Stripe.

Previous fixes
--------------
The last commit also fixed GitHub Issue:
https://github.com/drastik/civicrm_stripe/issues/9
USD forced on recurring plans.

Fixed issue where you might see 'no such customer'.
---DO NOT UPDATE LIVE SITES YET---
Changes to plan names to utilize Stripe's new ability to do plan frequency intervals.

-Fix amount issue from github: https://github.com/drastik/civicrm_stripe/issues/18
-Fix BillingBlock.tpl issues (cvv image, credit cards image)
-New error message report if there was a silent error (can be found in stripe.com account logs)

Removed unecessary call to retrieve customer in doRecurPayment() - (carry customer through from building/verifying data previously)
Change reaction on customer_id mis-match to create new Stripe Customer