Use version 3.x of Stripe php libraries

Early on (in the Stripe 1.x timeframe) there were no particular instructions specifying what version of the Stripe PHP library to use, and of course all hell broke loose when 2.x came out with a complete and total rewrite. That's why a specific version of the Stripe library is required.

I don't see why a patch to use the Stripe PHP library 3.x would not be accepted, especially if it didn't break using 2.2.0. If it *did* break using 2.2.0 more work would be required.

As I think about it, I imagine that their change of a key class name in 3.x will break things for existing users, and we'll be forced to go to 7.x-3.x, and that's not the end of the world. But if it doesn't have to be that's OK too.

Here's a patch which adds support for both Stripe PHP library 2.2.0 and 3.13.0, the latest as of this patch. The great thing about this patch is that it doesn't require existing users to upgrade the Stripe PHP library, but if someone wants to use a newer version, they can.

I'm also the maintainer of the Webform Stripe module, and I was running into conflicts having two versions of the Stripe PHP library installed. With this patch applied to Ubercart Stripe, plus a patch I'm working on for Webform Stripe, the two should be able to play nicely.

I haven't tested yet, but just reading the patch had a couple of questions:

1. +++ b/uc_stripe.module
   @@ -24,61 +19,70 @@ function uc_stripe_libraries_info() {
   -      'lines' => 500,
   

   Is the removal of 'lines => 500' intentional?

2. +++ b/uc_stripe.module
   @@ -447,7 +451,7 @@ function uc_stripe_charge($order_id, $amount, $data) {
          $customer = \Stripe\Customer::create(array(
   -          "card" => $stripe_token,
   +          "source" => $stripe_token,
              'description' => "OrderID: {$order->order_id}",
   

   Could you comment on why the change from 'card' to 'source'? Is it compatible with both versions?

1) Well, the VERSION file included with the Stripe PHP library is only one line long, so I figured it wasn't needed.

2) Some time ago, Stripe changed their API to expect a 'source' attribute rather than 'card', since they now accept non-credit card payments (like Bitcoin). But I tested this setting with both versions of the Stripe PHP library and it worked. Also, in their changelog it shows that the use of the 'source' attribute predates the version of the Stripe API currently used by Ubercart Stripe.

Thanks, excellent.

I tested and had just one problem, the caching of the stripe library item, which caused failure trying

    \Stripe\Stripe::setApiVersion($library['stripe_api_version']);

So in this patch I added a hook_update_N() to clear that cache item, and updated the README.txt slightly to specify appropriate versions of the PHP library.

I did not test recurring transactions...

Thanks! I tested recurring transactions and the API hasn't changed in this regard.

Committed #9, thanks.

There are still 2 problems remaining with this. The 'versions' key is inexplicably deleted in libraries_detect(), so it's not always available.

1. That means that uc_stripe_requirements() runs into a failure to load *sometimes* in if (!array_key_exists($php_api_version, $info['versions'])) {

2. _uc_stripe_prepare_api() may run into trouble trying to get $library['stripe_api_version']

3. libraries_detect() accepts any version higher than the specified version. So our uc_stripe_requirements() *does* do its job to make sure that one of the two required versions i there. But it must be noted that the libraries module does *not* handle this for us.

Normally these situations are resolved by a couple of cache clears and reloads. But they're annoying.

Basically, the fact that we're stashing information in the 'versions' key and expecting to get it (and expecting to find the acceptable library version in there) is a #fail.

One fairly ugly way to handle this is to call uc_stripe_libraries_info() directly and get the specified info that way. It seems ugly, like we're just storing the information in the wrong place.

Well, here's the approach suggested in #14. Would sure like something prettier.

I can't understand why libraries module deletes the 'versions' key.

Here's a simpler version which accomplishes more with less effort. It turns out that the stripe_api_version key does get copied from the 'versions' key over to the main array based on the version selected. We still have to be more rigid than libraries module about the explicit api required, so have to call our function directly, but this one is a lot less code.

That would mean the dev was wrong all this time. Would appreciate a patch to fix, since sounds like it needs it.

Actually, it looks like #16 just needs to be reviewed and committed.

@JamesOakley if you could review it we can get it in. Now that I remember this, it seems that it was resolved by some cache clears and stuff, but could annoy people.

Just testing #16with both versions of Stripe PHP API would be adequate, IMO.

Pretty sure this would be a reasonable approach:

* Install one version of the Stripe PHP library, then visit the admin/reports/status page & see if it shows right version, then try a transaction, see if it succeeds
* Install the other, same approach
* Install an unsupported version, see if it gets detected correctly

You may need drush cc in there, and the instructions still say that loudly.

THANKS!

Committed #16 - Thanks so much for the review and for all your involvement here @JamesOakley.