We have a situation where we need to create a customer object when sending over the charge data, even if we don't have the customer ID on hand (via the Card on File module). Considering that Stripe doesn't consider an email address a unique identifier, this makes it difficult (impossible?) to query Stripe for a customer record that may already exist.
I have some code written that I can submit as a patch that will allow the site admin to force the creation of the customer object for every charge. Obviously, this isn't great, we'd prefer to only create the customer if that customer doesn't exist.
A bit more background: We're building a donation system for an organization who has several other donation platforms, so we can't count on parity between the customers that are in Stripe and the customers that are in Drupal Commerce. It may very well be that a donor donated through an external donation page and then they use our system for another donation. We want all donations to show up as charges under one customer object.
Some advice, please? Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2775673-commerce_stripe_create-customers-no-cof-6.patch | 12.78 KB | torgospizza |
Comments
Comment #2
capellicI'm going to provide my patch because I have my code to the spot I discuss above.
Comment #3
torgospizzaWould you mind re-rolling this against 3.x? The patch you provided was quite large and included a bunch of changes around the billing profile, which I'm not sure were needed. Let me know if you'd like to discuss this on IRC since I may not be fully comprehending what it is you're trying to do.
Comment #4
bleg commentedI used this patch for card on file https://www.drupal.org/files/issues/commerce_cardonfile-allow_anonymous_...
Now my customer ddescription is "Customer for
<em class="placeholder"></em>"The above patch doesn't work on the current 7.x-3.x-dev or on 7.x-3.0-alpha1
Everything else works well with the card on file patch
Comment #5
torgospizzaComing back to this from #2881411: Customer Object not created in Stripe. I had forgotten that literally having Card on File enabled is the only way to create a Customer in Stripe, when Stripe expects a Customer for lots of other purposes besides just making charges. This was the impetus behind beginning work on #2816709: Require Stripe module - I wanted to put all non-Commerce stuff there, and allow the Commerce Stripe module to only care about the Drupal Commerce side of things.
Since Customers should actually exist outside of the Commerce workflow, I don't know that it makes a lot of sense to duplicate that effort. The interim solution, however, is to allow some flexibility between the two - for instance if the Stripe Customer module exists, we would want to use that module's customer retrieval before deferring to our own. The main issue being that until now Card on File handles the storage of customer_ids, and since Commerce customers can have multiple Stripe Customers due to this. (For example if a customer deletes all of her cards on file in Drupal, the function commerce_stripe_customer_id() will return an empty response, as it relies on that module for its results. That's a much narrower scope than what Stripe is really intended for.)
I have a lot of other thoughts on how we might better handle things. I'm tempted to start work in the 7.x-4.x version of this module to try and get all of that stuff in there, including requiring the Stripe modules, to make life easy on all of us.
@bleg: That should be an easy replacement of the token type to fix that metadata. However the majority of the patch seems to focus on metadata, and it makes applying it difficult. I'm going to work on a more focused patch to try and get Customers created before any payments, and store those customers in the {stripe_customers} table that I created for the Stripe Customers module. I'll make sure each module checks for that table existing before attempting to create it.
Comment #6
torgospizzaHere's my first run at a patch for this. It does the following:
- Implements
commerce_stripe_schema()to create a {commerce_stripe_customers} database table. Once I have Commerce Stripe requiring the Stripe suite, I will make sure those records simply get migrated over to Stripe's {stripe_customers} module so that Commerce Stripe no longer is storing them, as this should really be abstracted out. (For instance we may want to grab a Customer ID for a user if they want to add a bank account, etc.- Implements a hook_update() to create the table. Right now, no records are inserted from a {commerce_cardonfile} table, though they will be in the next patch. My focus with this initial patch is to get Customers created without Card on File being enabled, and then reusing that Customer ID for future operations. I
- However I did modify the function _commerce_stripe_create_card() to be a bit cleaner, since we can just retrieve the user's default source, rather than looping through the array of cards (with a count of 1) and returning a type-juggled object.
- Creates a new function
commerce_stripe_create_customer($account, $params = array())which accepts a customer and an array of parameters to pass to \Stripe\Customer::create($params). I have not yet implemented the metadata hook_alter yet, as that should be in a separate patch entirely.- New function
_commerce_stripe_customer_save($customer)which saves details of a \Stripe\Customer object to the database.- Modified signature of the function
commerce_stripe_customer_id($uid, $payment_method = NULL)to accept $payment_method as the 2nd argument, rather than simply the $instance_id. This allows us to dig into the settings of the payment method (which will change behavior depending on if we're leveraging Card on File for storing Customer IDs).- Added a settings field for the payment method to store Customers instead of Card on File. You will need to enable this checkbox for the new behavior to take effect.
Patch is attached, but could use some thorough testing. I don't expect Card on File functionality to break, but I haven't tested too much there yet. Like I said, main concern is getting Customers created without relying on CoF. Please let me know if it works for you or if you encounter any trouble.
Comment #7
tomtech commentedAutomatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.