#breakfastbill-migration
placid schooner
Shoot.
obtuse shell
A Source (src_123) works as a PaymentMethod to make migrating to PaymentIntent easier but not the opposite
placid schooner
Ah, shoot.
obtuse shell
unfortunately you will either have to migrate to PI (strongly recommended) or re-collect card details entirely for all those customers
placid schooner
Oh wow.
We definitely do not have time to migrate to PI, we are so deeply integrated with Source/Charge paradigm and this customer needs their subscription orders to run tonight.
Trying to brainstorm what else might be possible.
obtuse shell
yep I understand. Just to make it clear: I work for Stripe
There is absolutely no solution beyond collecting card details again right now
if you want to stay on Source/Charge, you can not use any of the saved PaymentMethods
placid schooner
Okay I understand. Recollecting card details is not an option, so maybe we will have to manually charge customers one at a time tonight from the dashboard. Just trying to brainstorm. Scared about the move to PI given desire not to rock the boat.
Man this is a bummer, did not see this coming haha
Two questions:
-
Is it possible to use the Stripe Elements id we currently use to save a Source as a Source object, to instead save them as Payment Method's? (thinking about how painful this migration might be and what we can do for this large client of ours today)
-
Is it possible to pass a Source.id into a PaymentIntent object? Are there any gotchas there if we change our backend subscription logic to start sending out PaymentIntent's vs Charges?
obtuse shell
I don't follow what point #1 means. But #2 yes, that's what I explained earlier, we made the migration extremely easy. If you moved to PaymentIntent tonight all existing saved card (card_123 or src_123) would just work without having to collect anything
placid schooner
For #1: we currently use Stripe Elements to save card details, basically:
var stripe = Stripe(token);
var elements = stripe.elements();
stripe.createToken(card).then(function(result) {
stripeTokenHandler(result.token);
});
where then in stripeTokenHandler we submit the token.id to the backend, the backend saves the card as a Source ...
The hardest part of thinking about this migration is all of our frontend forms. Would we have to rip out this Stripe Elements flow in order to save cards as PaymentMethod's instead of Source's?
obtuse shell
just to clarify: you save the object as a Card right? Like you get a card_123 back?
obtuse shell
And no, you can keep most of this today and change the way you charge by using PaymentIntent instead of Charge. You can slowly migrate parts of your code
placid schooner
ok. will see how far we get today. is there a migration document? and is there a doc for "gotchas"? thanks for the info and sorry for all the q's, just on a very tight deadline and don't want to mess this up for what is a very large new merchant of ours
obtuse shell
placid schooner
okay one other question that i'm not immediately seeing in the docs: once a PaymentIntent flips to paid, it looks like it creates a Charge object as a child. Will this Charge object come in via webhook? Or does the webhook come back as a PaymentIntent, which just contains the Charge? (trying to manage webhook behavior)
obtuse shell
when you confirm a PaymentIntent it creates a Charge under the hood for you. It's true for a decline or a success.
And yes it creates a "Real charge object" so all events come through as expected
placid schooner
got it.