Clarify readme.

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().

Don't use livemode parameter.

Log all stripe errors.

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.

No $charge->fee field returned by Stripe

Stripe was not returning the fee with recurring payments, so this was causing 500 error.

-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)

From: https://github.com/drastik/civicrm_stripe/issues/18
Remove all non-numeric characters from amount.
by DaveBagler

Fix error when number of installments not filled out.
Cancel previous subscription when user starts new recurring contribution and already had one.

This happens if a contact already has an active Stripe subscription due to a
previous recurring contribution that is not completed yet and if they create
a new recurring contribution and change only the amount, without changing the
frequency/installments, then Stripe will wait to charge the card until the
next installment is due. CiviCRM, expects the charge to be immediate, so the
first contribution does not get marked as Completed, and more importantly,
never appears in Stripe, since the card didn't actually get charged.

To correct this, we have to first cancel any existing active subscriptions
for that contact. Then, everything works correctly.

Fix "One of parameters (value: ) is not of the type Integer" error when submitting a recurring contribution using the Stripe payment  processor.

The Stripe payment processor extension was not handling the case where a user
submits a recurring contribution without setting the number of installments.
This commit fixes that and also modifies the code that uses the recurring
contribution's end date to take ongoing recurring contributions into a
account.

laryn-update-4.3-add-scroll-to-top

Need to do further testing but this is the Stripe section pasted into the BillingBlock.tpl from 4.3.

Fix 2 instances of #stripe-token under certain circumstances.
Adapt new BillingBlock.tpl format (used Civi 4.2.8)
Handle changes in CiviCRM 4.3 that would otherwise break submission.
Now more properly handle multiple payment options.
(Stripe, back off they want to send a check!)