Attached is a patch to add a card on file update callback method. This allows updating the expiration date. Is there a reason the update callback only provides expiration date? As far as I can tell this method is completely useless (new credit cards are not issued with the same number, and haven't been for many years, so the only reason a user would want to update the expiration date is if they entered it wrong to start with, I guess?). Now that I see what it does, I plan to disable it, as it's just confusing. But, well, many other payment method modules have it, so I'm submitting the patch, since I've implemented it.

So, is the only way for a customer to change their billing information to create a new payment method and then delete the old one? Is there some way to make "update" actually functional (by collecting address and card number changes), maybe with the "update form" callback? I can't find any documentation for that method or any examples of usage in other payment methods, so I can't tell.

Anyway, this works in the same way as other payment method update methods, so it'd be great to see it merged. Along with the delete method I've already submitted a patch for, and a couple of others (a corrected charge method and a new create method) that I hope to submit in a day or two, it'll bring the commerce_braintree_dropin payment method up to parity (or close to it) with some of the other payment methods that are more complete.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

swelljoe created an issue. See original summary.

swelljoe’s picture

Oops. That patch had debugging statements in it...fixed in the patch labeled -fixed.

andyg5000’s picture

Status: Active » Needs review
FileSize
11.15 KB

Hey @swelljoe thanks for the patch to get this started. I've been working on adding card on file support for CRUD operations agains the Braintree API using the Drop-in user interface. Here's a patch that adds all of those options to the card on file forms. I'd love any feedback or testing you can provide so we can get this committed!

I would go ahead and commit this since it's new functionality, but it did require a minor rewrite of commerce_braintree_dropin_submit_form_elements() which is used to load the Braintree form elements. I don't expect any issues with the rewrite and I've tested it, but good to get some more eyes on this.

andyg5000’s picture

Create and update callbacks have to be valid functions even though we're using our own form. Updated the patch to set those to the submit handlers for the forms.

andyg5000’s picture

Few more changes to improve UX including:
* Getting rid of the "default" checkbox. We make the selected payment that's submitted by the Drop In UI the default payment method. I did this because you can select which card is loaded when you invoke the drop-in ui form which lead to a confusing user experience.
* Setting the next card on file to be the instance default when deleting one.
* Adding a success message when saving card on file entities

mglaman’s picture

Status: Needs review » Needs work

Patch did not apply

mglaman’s picture

Status: Needs work » Needs review
FileSize
12.69 KB

Re-rolled because I caused conflict.

mglaman’s picture

FileSize
515.35 KB

Here's what I saw. Looks good / weird to me. Mostly because in "create" it loads that same form. Let me know if +1 still.

andyg5000’s picture

I think this is just how the drop-in ui works. We don't have the ability to load a separate form or just 1 card. Drop-in has it's own "card on file" management and user interface, and we're just syncing that data (as much as possible) to commerce_cardonfile schema.

  • mglaman committed f491982 on 7.x-2.x authored by andyg5000
    Issue #2810277 by andyg5000, swelljoe, mglaman: Patch to add Card on...
mglaman’s picture

Status: Needs review » Fixed

Woo! It's in.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.