[meta] Recurring payments/Card on File support

I think we should be able to make this work very similar to how the authorize.net gateway works. Stripe has a very detailed customer storage and retrieval API, which includes secure storage of credit card details. I've been thinking about coding this up for a project, but I'm not going to commit to it just yet.

I will look in to this when my work situation has eased a bit.

To me, #1482776: Any ideas for webhooks integration? seems to be the way to go...but I don't know how the auth.net gateway works.

@wizonesolutions: http://drupal.org/node/1482776#comment-6581272

@iler, I'm going to be working on this at https://bitbucket.org/cweagans/commerce_stripe

Is it too presumptuous to mark this as critical so that a 1.0 release does not happen without this feature? The timeframe that I'm looking at on completion is 1-2 weeks, and that's a worst-case scenario.

Updated issue summary

Any progress on this yet? Even if it's not close to being done, I'd just like to know what the status is. This simple request (recurring billing) seems to be spread around too many issues, and there doesn't seem to be any updated code anywhere.

Recurring billing is not, by any stretch of the imagination, a "simple request".

There's some progress here: https://bitbucket.org/cweagans/commerce_stripe/src/6927b7294873ab921d29c...

Is there any update on this? A lot of progress has been made on Commerce Card on File and Commerce Recurring, so it may be a good time to revisit the issue. I may be to help move it forward.

Here is a patch against 7.x-1.x-dev that adds commerce card on file support.

Functionality:

- create (during checkout only), update (expiry month and date only) and delete operations support.
- commerce recurring integration through commerce card on file support.
- Stripe customer id creation and support for multiple cards per customer id.
- Stripe.js-created form token used on each checkout form submission (card data is not submitted in checkout form).

I have tested all new functionality succesfully, but it needs much more testing. If you test, be sure to fix your commerce_cardonfile first as per: https://drupal.org/node/1693588 (or use the patched dev branch).

TODOS:

- Add more complete javascript support to prevent fetching a Stripe token when a card on file is selected. Right now this is supported only for the card on file setting defaults (i.e. radio buttons), but it should support all combinations of those settings.
- Add a name to the stored card when saving a new card.

Besides Card On File supporting Recurring Payments, would this also support charging a card on file "later", as in some time after the purchase is made (really, in this case a promise to pay)?

My potential use-case is a Kickstarter-like deferred payment system where the cards on file are only charged once a certain number of users have "bought" a specific item.

I have applied the patch from 12 and receiving the following error when trying to create an order through the admin panel.

Notice: Undefined index: stripeToken in commerce_stripe_submit_form_submit() (line 198 of /home/manyhands/domains/client.manyhandscollective.com/public_html/sites/all/modules/commerce_stripe/commerce_stripe.module).
We received the following error processing your card. Please enter you information again or try a different card.
You must supply either a card or a customer id

Steps to reproduce...

go to admin/commerce/orders/add
create an order
then add a payment to the order using stripe.

Any ideas?

Updating with related issues

Re: #14, correct me if I'm wrong but I don't believe this module or commerce_cardonfile supports adding new payments via order administration

What version of commerce_stripe are you using?

See https://drupal.org/node/1875234

Re: #13, this patch does not include a "create callback", so a new card can only be created via the checkout process (whereby the card must be charged up front). I believe this should be possible though. From your custom create form, you could use the stripe token to create a customer, which will return the Stripe customer and card ids for storage. See the Stripe documentation here: https://stripe.com/docs/api#create_customer

The patch does something similar for new customers, but again, only during checkout.

Re #16, thanks for the follow-up. In this case I expect a user to go through checkout with a "deferred" product (for lack of a better term), so card on file would be saved, just not changed, until sometime in the (near) future.

Successfully tested #12 - some things need fixed.

After checking out successfully I navigated to the accounts 'stored cards'. It requested I set the Card Owner name again - as though it wasn't pre-filled.

When I logged into stripe I noticed that the customer account was created successfully - however the email of the account was saved to the stripe:description field, and the stripe:email field was blank.

Lastly - order status remains "Pending" even after a successful charge.

This may be my commerce install - but after trying to checkout again It skipped the confirm order page and went right to checkout complete page - with no opportunity to confirm.

I am testing this patch and will work on fixing some of the bugs.

After checking out successfully I navigated to the accounts 'stored cards'. It requested I set the Card Owner name again - as though it wasn't pre-filled.

When I logged into stripe I noticed that the customer account was created successfully - however the email of the account was saved to the stripe:description field, and the stripe:email field was blank.

I will fix these two.

Lastly - order status remains "Pending" even after a successful charge.

I was not able to reproduce this. order status was "completed" on all my tests.

after trying to checkout again It skipped the confirm order page and went right to checkout complete page - with no opportunity to confirm.

My commerce install is intentionally set up to suppress the confirmation page, so i can't test this at the moment. If someone else could confirm this issue, i would appreciate it.

here is a patch that fixes the storage of cardholder name and email in stripe as well as cardonfile. it is only a slight modification to the patch provided by MEsch in #12. The patch is against the HEAD of the 1.x branch.

Thanks to everyone who has tested this so far, and thanks to aviindub for providing an updated patch.

A few additional notes for those using this patch:
1. As per https://github.com/stripe/stripe-php/blob/master/CHANGELOG, you will need version 1.8.1 or higher. We could change the regex in hook_libraries_info() to reflect this, or just note it in the README file (since it's only required for the subset that require card on file support). Or maybe we could perform a check when the "Enable card on file support" button is checked.
2. Be aware of https://drupal.org/node/2000420. There are some partial fixes there.
3. Be aware of https://drupal.org/node/2118687. We could potentially deal with this by adding a mapping of Stripe card types to Drupal Commerce card names, but this wouldn't be ideal. I'd prefer it be fixed in cardonfile instead.

Also be aware of #1836870: card number shouldn't go to drupal, which completely blocks progress on this issue right now.

cweagans, in the patch I didn't alter the javascript that removes the "name" attribute from the stripe form fields. So those form elements, including the full card number, should not be submitted to the server as per https://stripe.com/docs/tutorials/forms.

The server sees and stores some of this (Stripe card id, last four digits of card, and expiry/name/etc. - no security code or full card):
https://stripe.com/docs/api?lang=php#create_charge

One of my coworkers is working on a patch to improve the prevention of sending card data to drupal. Just to be a little more certain that it will never get posted accidentally, rather than removing the name attributes client-side, it strips out the name attributes in a drupal pre-render callback so that the name attributes are never present in the form in the first place.

patch to strip the name attributes server-side, so that there is never even a remote possibility of the card data being accidentally posted to drupal. this one applies on top of the patch from #20.

PS: i am maintaining a sandbox version of this module that incorporates these patches as well as some other stuff i am working on:

https://drupal.org/sandbox/aviindub/2168115

......aaaaand the actual patch.

Rather than manipulating a new DomDocument with an #after_build callback, a #post_render callback that unsets the #name property should suffice.

This works:

$credit_card_field['#after_build'][] = '_commerce_stripe_credit_card_field_remove_name';

...

function _commerce_stripe_credit_card_field_remove_name($element, &$form_state) {
  unset($element['#name']);
  return $element;
}

Also, this sub-issue should probably be cont'd in https://drupal.org/node/1836870.

I am still on the patch from #12 - however this issue has not been previously discussed.

I have successfully processed an order and see the order, as well as customer, reflected in Stripe.

Ok - sweet!

Now, that was a recurring payment product. So, when the due date laps & cron runs I see a new order is created, as expected, with the status "Pending (Recurring order)".

Great. Run Cron one more time to trigger recurring payments to charge the card on file...

And we have a bug. When I look at the order I see the status is "payment error". And if I go to the order > payment page I see "No payment methods available to add payments."

To be sure the card was saved on file - I process another order (both recurring and normal products) and the payment is successful using card on file.

Therefore the card is saved on file - however when the recurring framework goes to use it - something breaks. Is this a commerce_stripe issue, a recurring framework, or a card-on-file issue?

[UPDATE]
From what I can tell - the "payment error" is set by this rule "Unsuccessful recurring order card charge — hard decline". Here is the rules log export... but not much help. http://snag.gy/HkpTi.jpg

stopshinal, please see if anything in comment #21 fixes your issue.

Hum - no dice. But - to be honest - i'm a bit confused by the various patches at various stages in various issue threads. MESCH - are you currently able to process recurring payments using stripe? If so, could you share which version of the module you are using, as well as which patches you have applied?

I'm currently using...
Patch from #12 in this thread

Patch #1 from
https://drupal.org/node/2118687

and Patch #6 from
https://drupal.org/node/2000420

Yes, this is working with the patch from #12. But we encountered some issues subsequent to that patch, which is why I posted #21. If you have an appropriate Stripe PHP library (>1.8.1), then make sure the account you're testing this on has a Stripe card stored as default. Without a default card, the recurring payment will fail. You can manually set a card as default via the "Stored cards" tab on the user account. Note the patch you're using for this won't set set an existing card on file to default, which is perhaps why this still isn't working for you.

The patch should be applied to the -dev branch of this module, and it's being used in conjunction with the -dev branch of commerce_cardonfile because of this issue: https://drupal.org/node/1693588. However, the patch to that issue should be present in the latest beta version, so you could try it with the beta.

fear not, the patch confusion is at an end!

i have rolled all the accepted patches in to the main repo. all further patches should be against the head of the current 7.x-1.x branch. See release candidate 6.

As per #12 TODOS, I'm attaching a patch that adds Stripe token support to the checkout form when the card on file form element is a select list. Right now only radio buttons are supported.

Basically we need to ensure that a Stripe token is only used when a new card is inputted. Otherwise we don't need it.

As per https://drupal.org/node/2000420, I am attaching a small module that others may find useful until the issue is fixed in commerce_cardonfile. It's only a partial fix, but it makes sure there is a default card to work with (a default card is required for recurring payments to work). It applies to commerce_stripe only, but you can modify it easily by modifying the if clauses.

For those looking to implement/test this functionality, here is the most recent combination I have worked with:

commerce_stripe - rc6
commerce_cardonfile - beta2
commerce_recurring - dev
interval - dev
attached ccof_default module
Stripe PHP library 1.11.0

Per #2051331-31: Add card on file outside of the checkout process, there is a new callback that provides payment methods a way for users to add a Card on File outside of the checkout process (for instance, under a user's Stored Cards area, clicking an "Add Credit Card" button for a card they can use later).

If no one else gets to it, I will attempt a patch that adds this new feature.

Here is a patch that implements the remaining cardonfile features, including adding a card outside of the checkout process, as described in #36. Its a pretty hefty patch, but it should apply against the current dev. It also contains a bit of refactoring, and a fix that will allow cards to be set as default. Testing/feedback are appreciated.

I am using a new payment gateway called chase orbital . I wanted the functionality of card_on_file. How can I extend the funtionality of card_on_file module to accommodate the new payment gateway also.

zeoxe - this thread is not the right place to ask that question. this is for discussing card on file integration with Commerce Stripe.

an additional update to the patch from #37.

note: this is meant to apply against cc16b0099836724b037c5d01bef47705c145f679. it will not work against any current tag or branch. I am going to include this in a larger patch for rc7.

Has this 'fix' been committed? There is nothing in the project's description, under "Features", for the recurring capabilities so I'm just curious if the "fixed" status is accomplished only by the patches in this issue or if the recurring features are now committed into the release or dev.