Charging cards fails if using Stripe API > 2015-02-18

this does sound like a bug, but the modules and use case you described sound quite standard, so i suspect there is something else about your drupal setup causing this. are you using a totally stock drupal setup to test this, or is this an ongoing project where you are adding this module?

Yes, I am also experiencing the issue when attempting to save a card and use stripe. Perhaps I should be posting to "card on file" thread as its says that this module is supported but it doesn't seem to work for anyone..

Any ideas would be most appreciated..

sorry for the hiatus, I am having this issue like @mdyorke said, fresh install and having issues, I have an older install that wasn't having issues about 4 months back, I will attempt to dig up the versions and test it with a current stripe account.

Then maybe we can pinpoint where the error is.

This also extends to previous version I was using that worked previously, maybe stripe has changed the way it stores it's information? This is a MASSIVE issue and renders the card on file functionality useless, and also means the modules like commerce_license_billing useless for this payment option...

Just updating the error log.

Fresh install again, with only the following:

commerce
commerce_cardonfile
commerce_stripe

with Card on File functionality disabled, sale goes through and is received in the test stripe account.

with Card on File functionality enabled, the following errors appear.

Notice: Trying to get property of non-object in _commerce_stripe_create_card() (line 318 of /home/commerce-billing/public_html/sites/all/modules/commerce_stripe/commerce_stripe.module).

Warning: Invalid argument supplied for foreach() in _commerce_stripe_create_card() (line 318 of /home/commerce-billing/public_html/sites/all/modules/commerce_stripe/commerce_stripe.module).

We received the following error processing your card. Please enter your information again or try a different card.
You cannot use a Stripe token more than once: tok_15yb8ZK0OMqXMpzrdhv0ujYA.

And this is the apache error log entry

[fcgid:warn] [pid 26169] [client 192.168.0.23:57698] mod_fcgid: stderr: Stripe Notice: Undefined property of Stripe_Customer instance: cards, referer: http://commerce-test.dev/checkout/11/review

Also to note:

• I couldn't add a "Stripe" Card to the user/%uid/cards/add page, it just kept refreshing the page with an empty form (no errors anywhere)
• I can use commerce_cardonfile test payment with no issues
• I can use Stripe WITHOUT card on file enable with no issues

I am going to attempt to use an earlier library and see if maybe something has changed with the way it sends user information. Still the same error after going all the way back to https://github.com/stripe/stripe-php/releases/tag/v1.17.4

I am not a PHP or API coder, I am only a front end Drupal developer, so please forgive me if I say anything wrong or don't give enough information, feel free to let me know what you want to check and I will do my best :)

I also do not know PHP I Just do drupal front-end, but the below sounds pretty similar to what @pjonckiere is saying well at least to me... My apologies if this thread is way passed knowing this info:

...with our API: You just need to attach the card details to a customer object. Once you’ve done that, you can charge the customer at any time.

https://support.stripe.com/questions/can-i-save-a-card-and-charge-it-later

Perhaps were trying to save the card instead of the customer?

@Capfive et all - Is anyone having errors after a card has already been saved?

Thanks!

i have a theory about what may be happening here. can someone who is experiencing this bug please tell me what version of stripe-php you are running? you can find that under sites/all/libraries/stripe-php/VERSION

I am using the recommended v1.18.0 but also tried v1.17.5 and v1.17.4 with errors still, I will try the patch this morning

well, that would seem to invalidate my theory. what i can't understand is how it once worked with $customer->cards but that no longer works, and we need to use $customer->sources instead. the only way i can explain that is if it changed in stripe-php, but i doubt they did that on a minor version release.

I am as perplexed as you @aviindub, this is why i went back to an older sit build that i did back in November 2014 which was 100% working, all of a sudden started throwing up the error, I'm not sure when it happened other than us trying it on the new site build 2 weeks ago.

I have not had time to test this yet, I convinced my client to not use recurring billing as it is a monthly charge, but I have another recurring charge site that I will be testing this on soon

I've checked our error logs and I don't see this happening for any of our users. I just tested myself in Test mode and couldn't reproduce this.

Does anyone have some definitive scenario for reproducing the bug? My versions:

- stripe-php v. 1.17.4
- Commerce Stripe 7.x-1.0-rc7+19-dev
- cardonfile 7.x-2.0-beta5+2-dev

Ah, I see. Perhaps it's the Stripe-PHP v.1.18 introducing the issue as discussed earlier (which I somehow missed). Thanks!

so i just tested this and it is working for checkout, but there are separate errors now with Card on file that seem to be related to stripe.

I will start a new issue but thanks so much for fixing this :) we are one step closer!

Thumbs up here! +1

Hi @capfive. It doesn't sound like we got to a resolution. Opening back up unless we can confirm that the error is fully gone using the 1.18 library.

I'm testing with Stripe v.1.18 and still unable to reproduce the issue. I tested both a NEW customer being created at Stripe (no cards stored in Drupal), and an existing customer being retrieved (because I had stored my card from the 1st test). Both charges succeeded.

I also inspected the response from Stripe, and it seems that $cards is in fact being returned on the $customer object, so I'm not quite sure the patch in #10 is necessary. It does seem like a good idea, however, because cards can be sources, but there are multiple types of sources including Invoices. In theory returning Sources instead of Cards could allow us to introduce Metered Billing and other advanced features into Commerce Stripe.

Also regarding that patch we'd want to make sure that $customer->sources->data[0]; does map to cards. I don't have alternative sources to try, so I can't verify whether this will always be the case.

One quick note: although I can't reproduce it right now, I have seen this behavior when in my initial testing, I had created a Test user and stored their card, and then tried to checkout with that same card after switching our keys over to Live. Because the function commerce_cardonfile_load_multiple_by_uid() tries to load a Card entity from Drupal first, it was finding the stored card in Drupal, and attempting to charge that card in Production - but it didn't exist there, only in Test Mode. This resulted in similar errors to what we're seeing here. The solution was to delete the user's stored cards from Drupal (in user/UID/cards).

@torgusPizza you may not be seeing this in your particular Stripe account. The change is not in the Stripe library but in the API version that your Stripe account uses.

See: https://stripe.com/docs/upgrades#2015-02-18

In that update, "cards" was changed to "sources". I'm attaching a patch that should work for either.

Ah ha! That makes perfect sense. Changing the title to be more relevant, since this issue appears to be a side effect of using a newer API version. I'm using one that's actually quite old, which would explain why I can't reproduce the issue!

@aviindub Does it make sense to lock this to not just a Stripe Library version but Stripe API version < 2015-02-18?

We may also want the OP to edit their Issue summary since it sounds like this is definitely the root cause.

There is a patch here so setting to Needs Review. I'm testing on our end as well.

We have deployed the patch in #21 and it works great.

Would love for others to test it as well. Perhaps if and when Commerce Stripe decides to require an API version we can remove the backwards compatibility (checking for properties first) but otherwise I think it's good to go.

the API change totally explains the mystery here, so that's good. thanks for tackling this, folks.

as far as locking in an API version, i think thats a good idea in case of future API changes.

Yeah or at the very least making a minimum standard. TBH I didn't even realize we had to "Upgrade" the API version in our Account settings - may be worth including in documentation somewhere.

I'll mark this as fixed since the patch was committed.