Closed (fixed)
Project:
Commerce Core
Version:
8.x-2.x-dev
Component:
Payment
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
12 Mar 2018 at 11:41 UTC
Updated:
23 May 2018 at 22:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
czigor commentedThe patch
- Fixes the "Add payment method" form by allowing adding payment methods for all possible gateways, not just one.
- Also changes the "Add payment method" form from being a 2 step form to an AJAX one, copying logic from the Payment information pane.
- Implements the edit functionality inside payment module
- Updates the payment_example Onsite payment gateway to implement SupportsUpdatingStoredPaymentMethodsInterface
- Adds a test for payment method edits.
Comment #4
czigor commentedMy local test env is broken atm, so I just hope this is going to fix the tests.
Comment #6
czigor commentedLocal env fixed, and so are the tests.
Comment #7
czigor commentedComment #8
czigor commentedTo avoid code duplication, the attached patch creates a commerce_payment_method_form form element that is used on the PaymentInformation checkout pane and on the "Add payment method" form. However, because of the form element everything got one level deeper in the form structure which breaks tests. They are easy to fix, but i'm not sure we want to go this way and break selectors on existing sites.
Comment #10
czigor commentedRerolling patch to apply it to latest dev.
There's another issue: PaymentMethodForm::ajaxRefresh() returns an element one level higher than it should.
Comment #11
czigor commentedComment #13
czigor commentedSince https://developer.cardinalcommerce.com/try-it-now.shtml provides only a test visa number, I'm not sure about the mastercard responses regarding the cavv/eci numbers (afaik they have different names there).Wrong issue.
Comment #14
bojanz commentedThe patch here will need to be reworked, since we've decided that PaymentMethodEditForm should not share code with any other forms.
The sprit of the patch in #10 was completed in #2858599: Move a portion of the PaymentInformation pane logic to a PaymentOptionsBuilder
We just need a simple form that edits the billing profile, and a matching gateway method to call.
Comment #15
bojanz commentedHere is a rebuilt, minimal patch, allowing only billing profile updates.
It might make sense to also support modifying the expiration date, either in the main form or at least in the one for the Onsite example gateway.
Comment #16
czigor commentedCan't we pass $payment_details to updatePaymentMethod() too, just like to createPaymentMethod()? That way we could update the remote payment method with non-persistent data from the form.
Comment #17
czigor commentedFor some gateways not allowing submitting masked credit card numbers for payment method updates this might even be required.
Comment #18
bojanz commentedWell, I assumed we wouldn't want to support retokenization, people would add a new payment method for that.
The use cases here are 1) Update the billing info 2) Update the expiration date, when supported (usually supported without PCI implications)
Comment #19
czigor commentedAllowing retokenization would simplify card expiration handling for recurring payments. Doesn't seem to be a big deal to support it, should we open another issue for it?
Comment #20
czigor commentedAttached patch adds the gateway js library to the user add and edit payment method forms, just like we do it for the payment pane. I understand we add the js libraries there only to work around a drupal core js bug, but the gateway annotation suggests that commerce core takes care of attaching the library to the form, so I think we should do that.
Patch also removes a needless variable re-initialization.
Comment #21
czigor commentedComment #22
mglamanDiscussed with bojanz. We identified the following reasons for needing to update a payment method instead of replacing the payment method (retokenizing.)
After reviewing the various payment gateway APIs, it is possible to pass a new expiration date along with a remote payment method ID to update a payment method without full retokenization of the card.
That means we can render the masked credit card number that we already have and just prompt the customer for the expiration date information. I'm resetting the patches back to #15 and we will work from there.
Relevant links for payment gateway APIs:
Comment #23
mglamanAlso want to update title and issue summary because this feature will be 💯💯💯💯💯💯
Comment #24
mglamanUpdate issue summary.
Comment #25
mglamanHere is my update. Allows editing the expiration information. Displays the card type image, updates the payment method's expiring time as well. Then passes it to the payment gateway.
Comment #26
mglamanI forgot to update the test.
Comment #28
mglaman.. of course it failed.
Comment #29
mglamanHere is the updated patch and test.
Comment #30
bojanz commentedThis isn't translatable, no? Can we just use $payment_method->label()? That would give us "Visa ending in 1111"
Comment #31
mglamanYeah, dumb. Too long in client land. That makes more sense.
Comment #33
mglaman\o/ Committed!