keithm

[cosmic sparrow]

The way that we would recommend preventing this is to re-use the original subscription or to at least cancel it before creating a new one. Creating a new subscription while the old subscription is attempting to charge is what allows for the double payment here

Unfortunately hard to say how to look for this. Are users only supposed to have one subscription with you at a time or can they have multiple? It may be feasible to just iterate through your customers and see how many subscriptions they have

[elder torrent]

so what makes it tricky for us is that this is just an open payment link

the customer isn't registered / we don't have a way to identify them concretely

so say for example they attempt a subscription and it fails, if they refresh the page to us its as if they are completely new person

[cosmic sparrow]

I may have misunderstood the question. Checking in to those IDs. So was that first subscription ever active before the second subscription started?

[elder torrent]

to our system it wasnt as the payment intent on first invoice failed, I'm not sure what stripe's status on the subscription was

[cosmic sparrow]

Looking in to this. I think I confused myself a bit initially. I don't think we should be retrying payments like that if that first invoice payment fails. Will get back to you on what I can find for what happened here

[elder torrent]

No problem, thanks

[cosmic sparrow]

Okay I am seeing more of why this happened and think I need a better idea of why your integration is making some of these calls

So the steps I see at the moment are:

1. Payment method is saved to platform account
2. Payment method is cloned to connect account and attached to a customer there
3. Subscription schedule is created for the customer on the connected account

So you have an open page, and the customer is inputting details to create an account with your platform so that they can pay other merchants without entering their details agian?

I think what may need to happen is you don't set the payment method as the default for the customer until after a payment has succeeded with the customer on session. I don't think we will retry the payment unless the payment method is set as the default for either the subscription or customer. Will double check that and get back to you

[elder torrent]

So the reason for the global customers was I believe for us to have apple pay

the customer only ever actually pays the one connected account (we dont actually re use) but to make apple pay easier we had to implement this way I believe

[elder torrent]

This seems straight forward enough, I'm just wondering here, it's enough for us to attach the payment method then?

the subscription schedule / invoice will now to use that payment method or do we have to specify this elsewhere?

[cosmic sparrow]

Are all of these connected accounts still selling from your site or do they host and manage their own website here?

Yes, if you attach the payment method but don't set it as the default it shouldn't do this as far as I know

[elder torrent]

They sell from our site with vanity urls/custom domains in some cases

[cosmic sparrow]

Though I would personally recommend cutting out the extra cloning steps and just register the domain on each connected account. Would be more complicated up front but would likely be simpler overall

[elder torrent]

as we use stripe standard they can though connect / sell from their own site if they've implemented but I'm not aware of any that do

[elder torrent]

I think the problem we came across was enabling apple pay, we host the domain verification files regardless but there was some issue we came across that was easier to resolve by using shared customers

I dont actually remember as it was over 3 years ago this was done

we'll try remove the setting of the default payment method and see

just wondering then, do we even need to set this if they successfully complete?

we can just leave it unset?

[cosmic sparrow]

After it succeeds you will probably want to set it as the default for the subscription or customer. Otherwise Stripe will not know to automatically charge them when the subscription renews

[elder torrent]

ah ok, I assumed the payment method would become default for subscription if it went through

would you know of any query we could do to find subscriptions that have been retried like this?

basically we want to find all of these so we can deal with them as needed, they dont appear on our system so we're just trying to figure out a script we can write to query stripe for them

[cosmic sparrow]

Gotcha. Still trying to think of how to do this.

One thing that I think would be helpful here is that cards have a fingerprint property which will be the same for every card object that represents the same credit card on the same account (I think it may work for you across connected accounts but would have to double check) https://stripe.com/docs/api/payment_methods/object#payment_method_object-card-fingerprint

Unfortunately it looks like you can't just list all saved payment methods on an account. So I think you might have to do something like list each customer on an account, list each customer's payment methods, and see which fingerprints match

[elder torrent]

ah ok this makes sense

we may though have people genuinely paying twice but once we can get a list of potential duplicates we can manage from there

thinking about it actually, easiest way is for us to jsut go through all subscriptions and see which dont exist on our system

as this is what alerted us to this issue in the first place

thanks for all your help with this, we'll try the default payment method suggestion, my worry would be it causes a regression somewhere else but we'll test and see