Closed (fixed)
Project:
Commerce Stripe
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 Jun 2015 at 23:55 UTC
Updated:
13 Dec 2016 at 21:45 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mesch commentedDidn't mean to assign to me! (but can help as time allows).
Comment #2
aviindub commentedyes, it should be. aside from the PCI issue, stripe checkout provides its own facility for storing cards.
Comment #3
mxwitkowski commentedThe feature for managing existing cards and adding new cards to an account is important for recurring payments and subscriptions. Is there a way to continue to have this functionality and still be compliant?
Comment #4
mesch commentedHere is my first go at this. Originally I was planning to handle the two integration methods (checkout and stripejs) differently in the respective callbacks, but then I realized that
hook_commerce_payment_method_infois called in all the needed places. As far as I know there's nothing in contrib that caches payment method info, so getting things done in this hook should be fine.While doing this I identified a separate bug in commerce_cardonfile whereby cards can be added/edited/deleted even when the payment method settings (configured via rules action) disable cardonfile. I added a fix for this as well, but really this should be fixed in commerce_cardonfile; I'll open an issue and link to it here.
Comment #5
mesch commented@mxwitkowski, my understanding is that the added security of Stripe checkout comes from Stripe building the form rather than the host e-commerce site. I would assume to maintain that level of security we'd have to do the same for the add/edit card forms, and I'm not aware of Stripe providing that ability at the moment.
This could all be for naught though if it turns out that stripejs and Stripe Checkout do have the same level of PCI compliance. AFAIK this question hasn't been resolved as yet.
Comment #6
mesch commented@aviindub re: #2, are you referring to the "Remember Me" functionality?
Comment #7
mesch commentedComment #8
aviindub commentedyes.
Comment #10
aviindub commentedpatched, but didnt have time to give it a proper review. hopefully someone else can take a closer look.
Comment #11
torgospizzaWorks for me and this approach seems workable enough (and doesn't seem to interfere with the change made in #2447527: You must supply either a source or a customer id, but I would posit that "updating" a card is fine to do even with Checkout integration. I say this because updating a card doesn't allow you to actually enter the card info, you're only able to update the expiration and the zip code, which are not considered "sensitive".
So personally I would disallow creation of cards, but still allow updating, if the integration method is Checkout.
Comment #12
mxwitkowski commentedThe feature for managing existing cards and adding new cards to an account is important for recurring payments and subscriptions -- specific example is for when a card needs to be changed on a recurring subscription and no new item purchase will take place. Is there a way to continue to have this functionality and still be compliant?
Perhaps can we use the same iFrame methodology here to add new cards and set them as the default payment method? Then we can use the existing form as @torgosPizza suggests to modify the non-sensitive data?
Comment #13
aviindub commentedagreed. it should be fine to update cards in the old form as long as it is restricted to the same fields you could update in the old version.
This is certainly possible, we just need someone to actually write it. in the meantime, we need to disable this feature as it would disqualify your site from using SAQ A. if you want to see that get developed, i recommend putting it in a separate feature request.
Comment #14
torgospizzaSince this was committed I'll set to Fixed. Any further fixes/features need to go into a new Issue.
Comment #16
wizonesolutionsComment #17
torgospizza