Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reuse Stripe profiles when customer adds a new credit card #26

Open
spaghetticode opened this issue Jan 30, 2020 · 5 comments
Open

Reuse Stripe profiles when customer adds a new credit card #26

spaghetticode opened this issue Jan 30, 2020 · 5 comments
Labels
v4.x Issues and PRs targeting the classic frontend (before v5)

Comments

@spaghetticode
Copy link
Member

When a Spree::User adds a new credit card and that user already has a saved credit card stored we should reuse their existing Stripe customer profile instead of creating a new one.

This is a screenshot from a Stripe test account that shows a single email address with 3 different customer accounts, each with one single credit card:

Schermata 2020-01-30 alle 17 54 59

This can be surely done when using the Stripe official gem, but we need to investigate if ActiveMerchant allows this.

@brchristian
Copy link
Contributor

We are looking at building out a subscription implementation on top of solidus_stripe, and persistent customer accounts are a critical first step, so adding a +1 to this. LMK if I can help with a PR...

@brchristian
Copy link
Contributor

It seems to me that in an ideal world, this extension would include a migration to add a stripe_gateway_customer_id to the Spree::Users table.

But, maybe there's another way to do it. When creating a new Spree::CreditCard object, we can attempt to populate the gateway_customer_id field like so:

gateway_customer_profile_id = source.user&.
payment_sources&.where&.not(gateway_customer_profile_id: nil)&.order(:updated_at)&.last&.
gateway_customer_profile_id

@spaghetticode What do you think about trying something like that?

@brchristian
Copy link
Contributor

brchristian commented Jul 24, 2020

Updating with two pieces of information. First is that I've created a (failing) spec at #77 to demonstrate this issue.

Second is that I have begun tracking down the cause. I believe the key lines are here:

response = gateway.store(creditcard, options)
if response.success?
if v3_intents?
payment.source.update!(
cc_type: payment.source.cc_type,
gateway_customer_profile_id: response.params['customer'],
gateway_payment_profile_id: response.params['id']
)
else
payment.source.update!(
cc_type: payment.source.cc_type,
gateway_customer_profile_id: response.params['id'],
gateway_payment_profile_id: response.params['default_source'] || response.params['default_card']
)
end
else
payment.send(:gateway_error, response.message)
end

Here you can see how we're setting the gateway_customer_profile_id. Of course, a trivial way to make the specs in #77 pass would be to change the lines that directly update the payment source, but this would not be sufficient because the data would look right to Solidus and in the database, but would not actually be correct in Stripe.

It seems that we need to link this to the customer either before or during the call to gateway.store. This method lives in ActiveMerchant. So, I'll keep digging and update this thread when I learn more.

@brchristian
Copy link
Contributor

Update: the specs are now green in #77, which should solve this issue.

brchristian added a commit to brchristian/solidus_stripe that referenced this issue Aug 7, 2020
These specs address the need in solidusio#26 for maintaining
a stable Stripe customer object across multiple credit
cards. Currently V2 and V3 Elements are supported, with
V3 Intents functionality remaining as a TODO for a later
PR.
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Aug 8, 2020
These specs address the need in solidusio#26 for maintaining
a stable Stripe customer object across multiple credit
cards. Currently V2 and V3 Elements are supported, with
V3 Intents functionality remaining as a TODO for a later
PR.
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Aug 20, 2020
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Aug 20, 2020
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Oct 14, 2020
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Oct 27, 2020
These specs address the need in solidusio#26 for maintaining
a stable Stripe customer object across multiple credit
cards. Currently V2 and V3 Elements are supported, with
V3 Intents functionality remaining as a TODO for a later
PR.
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Nov 26, 2020
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Jan 25, 2021
These specs address the need in solidusio#26 for maintaining
a stable Stripe customer object across multiple credit
cards. Currently V2 and V3 Elements are supported, with
V3 Intents functionality remaining as a TODO for a later
PR.
brchristian added a commit to brchristian/solidus_stripe that referenced this issue Feb 17, 2021
These specs address the need in solidusio#26 for maintaining
a stable Stripe customer object across multiple credit
cards. Currently V2 and V3 Elements are supported, with
V3 Intents functionality remaining as a TODO for a later
PR.
brchristian added a commit to brchristian/solidus_stripe that referenced this issue May 5, 2021
These specs address the need in solidusio#26 for maintaining
a stable Stripe customer object across multiple credit
cards. Currently V2 and V3 Elements are supported, with
V3 Intents functionality remaining as a TODO for a later
PR.
@stale
Copy link

stale bot commented Nov 11, 2022

This issue has been automatically marked as stale because it has not had recent activity. It might be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 11, 2022
@gsmendoza gsmendoza removed the stale label Nov 15, 2022
@elia elia added the v4.x Issues and PRs targeting the classic frontend (before v5) label Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v4.x Issues and PRs targeting the classic frontend (before v5)
Projects
None yet
Development

No branches or pull requests

4 participants