Card-on-file feature for Ubercart?

[alanmels]

This is more of "support request" kind of issue, if it's allowed here at all.

I couldn't find any substantive discussion on the subject, but here are just couple, more or less relevant ones:

https://drupal.stackexchange.com/questions/50721/drupal-ubercart-says-its-not-saving-cc-data-then-whats-save-cc-data-to https://drupal.stackexchange.com/questions/60605/storing-credit-card-information-for-later-use

So my question is - does Ubercart need something like https://www.drupal.org/project/commerce_cardonfile? How you, guys, deal with providing end-user customers an ability to change their credit card data?

Maybe this issue should be filed on https://github.com/backdrop-contrib/uc_recurring as that's actually where credit cards are charged at regular basis without customer attendance, and logically customers have to be able to edit/replace/update/delete their credit card information. But I thought maybe there are other use cases for Ubercart when card-on-file feature is needed.

[bugfolder]

This is more of "support request" kind of issue, if it's allowed here at all.

Support or feature requests are always allowed! But our time or skills might make it hard to fulfill. No harm in asking, though.

A few comments.

The first link you gave was a question about Ubercart on D6. Since then, as Ubercart has evolved through D6->D7->Backdrop, it dropped even the debug setting that saved full credit cards; _uc_credit_save_cc_data_to_order() now immediately drops all but the last 4 digits (and encrypts even that), so there is no possibility of storing the full credit card info in the order.

This is, in general, a good thing. Storing actual CC data is hugely risky and there are major regulations governing how you do it (that fall under the umbrella of PCI Compliance).

The uc_recurring module doesn't store CC information (or at least, it shouldn't!); instead, it works with payment processors that support recurring charges, and then they have the burden of safely storing the CC info. (I know that Authorize.net supports recurring charges, but I don't see uc_authorizenet implementing hook_recurring_info(), so the module doesn't support it—yet).

So, I think implementing a solution where UC actually stores CC info on file is out of the scope of what UC should try to do. Working with a payment processor that supports recurring charges does seem feasible, but then that should probably be done via the uc_recurring module (which i see you are a maintainer of).

I am of course open to wiser minds correcting or augmenting any of what I said above. 😉

[argiepiano]

As far as I know, and with the little experience I have with credit card processing, I concur with @bugfolder a 100%. Many cc providers like PayPal and Stripe (two which I have used) offer safe and easy to implement API to safely handle payments AND to avoid storing cc info in your site (which as @bugfolder said, is hugely risky and requires a lot of safeguards and approvals). So the cc and other info (3 digit security code and expiration) never touches your server - it's transmitted from the customer's browser directly to their servers. These provider APIs have sophisticated ways (through webhooks) to transmit information to your site, so that you know, for example, when a payment was rejected, etc.

In particular, I know that Stripe and PayPal both offer the option (through their API) to set up recurring payments. Additionally, (I think) the uc_recurring module has a way to keep track and manage those.

[alanmels]

I understand all the security implications and why this feature was dropped altogether. At the same time, there are solid reason why Drupal Commerce came to implement https://www.drupal.org/project/commerce_cardonfile. For example, if a user CC gets expired,it becomes problematic to make the end user to interact with the payment processor without UI options (if the idea was to make the whole process seamless without exposing the processor to users).

[argiepiano]

Reading a bit about commerce_cardonfile:

The module does not retain full card numbers locally but instead stores the remote ID of the full card data from the payment gateway used to validate and process your credit card transactions. This means card on file data will only be good for a single payment gateway

So, the card is never stored in full. It uses the provider's API. It may be a good idea to create something like this for Ubercart as well.

[alanmels]

So, the card is never stored in full. It uses the provider's API. It may be a good idea to create something like this for Ubercart as well.

Right, the idea is not to store data, but to give an end-user a UI option to keep their CC updated. With the current state I have no idea how they manage cases with expired cards.