#mr-stinky-pants_api

1 messages Ā· Page 1 of 1 (latest)

supple galleonBOT
#

šŸ‘‹ Welcome to your new thread!

ā²ļø We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

ā±ļø We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

šŸ”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1478806919438139472

šŸ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

cosmic mesa
#

hello! looking at this now

woeful snow
#

copilot is saying because it classes as on session where the 3ds was made for off session

cosmic mesa
#

sorry i'm reading through your question and i'm not completely clear on what specifically you're looking for - are you wondering why 3Ds was triggered here? or how you should be handling it?

#

3Ds is used for on-session payments too so i don't think copilot's answer is accurate

woeful snow
#

i want to take the payment now when the user clicks activate because they have had a trial already

#

the 3ds isnot allowing this on the payment intent it then makes

#

but the si did succeed with 3ds seti_1T7HB0JKY8YXH2zhI9bi7DJl

cosmic mesa
#

ok, so i see you're

  1. creating the subscription in trial mode
  2. confirming the pending setup intent
  3. updating the subscription to end the trial

all in pretty quick succession. most of the time we recommend against doing anything that would trigger multiple auths in a row, and since you're effectively creating a setup intent and then creating a payment intent a few minutes later, that's why you're seeing 3Ds trigger multiple times. it's worth noting that 3Ds can trigger any time we do an authorization, so ideally your integration should be prepared to handle that by bringing the user back online and either collecting a new payment method or calling handleNextAction
https://docs.stripe.com/js/payment_intents/handle_next_action

#

can you tell me why you're creating the subscription in trial mode and changing it so quickly afterwards? is this a test subscription or is this what would actually happen if a customer was interacting with your integration?

woeful snow
#

i get a setup intent with 7 days trial for the normal flow. I save that finger print so i can check if they had a trial already. If they did then im telling them it looks like you had a trial do you want to pay now and activate the account

cosmic mesa
#

hmm ok, let me do some thinking to see if there's a better way to handle this

woeful snow
#

i did change it all to get a setup intent without a customer to avoid having a loat of customers you have to delete who dont complet sign up but i thought that was the problem that it wasnt attached to the customer

#

i was going to make a customer after if setup intent suceeded and put the default payment method on the customer from the si that is not attached to a customer

cosmic mesa
#

ok i'm chatting through this with some colleagues and i think i've got some ideas for how to handle it, just need to do a little bit of testing

#

it sounds like you collect Payment Methods every time someone creates a trial, right?

woeful snow
#

yes im just doing cards

#

const subscriptionId = stripeCustomer.subscriptions!.data[0].id;
await stripe.subscriptions.update(subscriptionId, {
trial_end: "now",
});

#

set this first await stripe.customers.update(customerId, {
invoice_settings: { default_payment_method: paymentMethodId },
});

supple galleonBOT
sage ice
#

I am doing a Stripe integration with Salesforce. I want a way to add a payment method to a customer without navigating to the Stripe Dashboard. I tried using the API but got a message saying that it's unsafe. Has anyone done this before?

timid lotus
#

@sage ice Can you please start your own thread and we'll be happy to help you

sage ice
woeful snow
#

click a button under the #help section on the left

timid lotus
#

Okay, taking over for solanum here - apologies about the delay

#

Let me just get caught up

#

and the crux of the issue is that you're using the card's fingerprint as the source of truth for whether they've had a trial before or not, and you want to avoid doing 3DS two times if they have not

woeful snow
#

well i check email too for if trial exists

#

but yes it would seem weird asking for the card again

timid lotus
#

gotcha

#

So you can create a Confirmation Token from the Payment Element on the frontend, then pass it to the backend and retrieve it from the API and you can inspect the card's fingerprint in the payment method preview (docs)

#

And then if you don't have a match for the fingerprint you can create/confirm a SetupIntent using the confirmation token on the server and create your Subscription with that payment method

woeful snow
#

isnt the si auto confirmed

timid lotus
#

I'm sorry?

#

I don't understand the question

woeful snow
#

doesnt the setup intent get confirmed before suceeded

#

do i need someehitng for the lyament intent thats creaed by the pay now update on the subscription?

timid lotus
#

So in this flow, you create a Confirmation Token on the frontend and that's essentially a placeholder for a Payment Method. You'll then create and confirm the SetupIntent in a single API call after you inspect it by hitting the /v1/setup_intents api endpoint with confirm: true and confirmation_token docs

woeful snow
#

is it safe to make a setup intent without a customer on the first page?

timid lotus
#

and then you pass the Payment Method id to the call to create the Subscription as the default_payment_method docs

#

and then your Subscription has a payment method explicitly defined as the one it should charge when needed

woeful snow
#

and attach that payment method to a new customer when sucessfull?

timid lotus
#

I'm sorry, could you elaborate a bit on your question?

woeful snow
#

is it ok to make a customer and subscription after getting a temp setup intent with no subscription and customer so you dont add customers to stripe who dont have a sucessfull card

timid lotus
#

I'm not following you - what do you mean by a "temp setup intent" - can you try fleshing your idea out with some more words? Your responses are pretty sparse

woeful snow
#

make a temporary setup intent on the sign up page to get the card details so that you dont add a customer to stripe

#

if the setup intent succeeds then create a customer and subscription with that payment method

timid lotus
#

This is kind of incongrous after the recommendation I made above - can you explain your thinking here?

The recommended approach is to (1) create a Confirmation Token on the client using the Payment Element on, I assume, your signup page. Once you have that, you (2) send it to the server, check its fingerprint, and then you can (3) create a Customer and (4) a SetupIntent with the confirmation token. Assuming that succeeds, then you can (5) create a Subscription.

Are you trying to avoid the proliferation of Customers at #3? If the call to create a SetupIntent fails/is declined and you can't rescue it by sending the client secret back to the client and having them confirm the SetupIntent on the payment element, you can add deleting the Customer to your error handling if you want

woeful snow
#

if thats the process as your steps suggest then thats the same sort of thing i was doing earlier

#

its just docs recommend having a customer first for a subscription setup intent.

timid lotus
#

It is different - when creating a confirmation token we don't reach out to the network and 3DS won't be triggered

woeful snow
#

will it still ask for 3ds on step 1?

timid lotus
#

No. What I'm recommend that you do allows you to avoid creating Customers and SetupIntents for cards that you've already seen because you get that information before you get to the step of creating a Customer and a SetupIntent.

woeful snow
#

so its the payment element still going to forward to a page, sorry i just cant see when it will do the 3ds

#

is the payment element just using those card details go generate a fingerprint by sort of of hash on those numbers?

timid lotus
#

If 3DS is required, it would be at step #4. You would show a spinner while Steps 2-4 are taking place or redirect to confirmation page. If authentication is required, you need to pass the SetupIntent's client secret back to the frontend, load the Payment Element, and call stripe.confirmSetup() to let the Payment Element handle authentication

woeful snow
#

sounds pretty messy

#

ill give it a go in test then

timid lotus
#

Its what every Stripe user that has a two-step confirmation process (a confirmation page in their checkout) and also has to handle 3DS goes through šŸ¤·ā€ā™‚ļø

woeful snow
#

so its this mthos in the docs?

timid lotus
#

In the former, the difference is that at Step #4 you diverge and create/confirm a SetupIntent after you run your business logic (looking for duplicate cards / emails)

#

in the later it is that you create a Subscription at step #7 and that you pass confirm: true and the confirmation token at #5

woeful snow
#

and you could make a new subscription with paynow if they had a trial already and agree to activate now?

supple galleonBOT
young gazelle
#

Yep, you can end the trial and have them just pay the first payment if that makes sense to you. Trying to think of whether there is a good way to do this without always halting the trial period

woeful snow
#

not right to make a new subscription either way? if had a trial already > no trial, pays now, otherwise > 7 day trial?

young gazelle
#

Ah you could do that. Just delete the trialing subscription if the second one succeeds or let the second one cancel itself if the first payment isn't made.

#

Ah wait my apologies, I think I misread one of your messages. Are you talking about PayNow the one-time payment method from Singapore? Or are you asking about how to interrupt the trial if the user wants to start paying immediately?

woeful snow
#

no i mean make an invoice but pay now

#

trying to look through these pages but still not sure

#

we need a setup intent before making a customer so why dont we just make that on the service side first var setupIntent = new SetupIntentService().Create(new SetupIntentCreateOptions());
ClientSecret = setupIntent.ClientSecret;

#

oh no the difference is you check the fingerprint first

#

yes i think the problem might actually be more simple

#

i thought you had to make a setup intent to render the payment element

young gazelle
#

Ah gotcha, yep the code in those guides shows how to do it without an intent. So you can render the element, create a token and examine the fingerprint, then confirm the SetupIntent or PaymentIntent related to your subscription based on whether it is trialing or not.

woeful snow
#

ill have to just give it a go im sure it will make sense, cheers