baruco-cardElement-confirmCard | Stripe Developers | Page 1

radiant plank Jun 23, 2022, 1:10 PM

#

Hello 👋
What cards have you tested so far?
Can you share those example SetupIntent IDs as well?

ancient meteor Jun 23, 2022, 1:10 PM

#

Sec

#

Setup Intent - seti_1LDpeNA155AgO8fTeoKdgafR

#

PM ID - pm_1LDpeOA155AgO8fTNk15Oa3B

#

Customer ID - cus_Lvh2a3mCUSYsNv

#

4000000000009979

#

Sorry

radiant plank Jun 23, 2022, 1:12 PM

#

The test card for this SetupIntent ends in 1280

ancient meteor Jun 23, 2022, 1:12 PM

#

I gave you wrong details

#

The correct ones are:
Setup Intent - seti_1LDpovA155AgO8fTjxHIHeUf

#

cus_LvhDhyxiD6hdL3

#

pm_1LDpowA155AgO8fTnY3tZpzT

#

And the card for the former details that was used is - 4000008400001280

#

Both of them are supposed to fail due to generic "decline" or "stolen", but they pass

radiant plank Jun 23, 2022, 1:15 PM

#

I'm not sure but it could be that these Setup fine right now but would error out when charging the payment method off_session

#

have you tried running a sample charge?

ancient meteor Jun 23, 2022, 1:15 PM

#

No I haven't

#

But even so, that's a problem for me

#

I would want to ensure the card is OK on-session

#

Obviously when I try to charge it again to ensure it's OK, but for the initial subscription creation it's important to ensure the card is working...

radiant plank Jun 23, 2022, 1:17 PM

#

let me see if there's a specific test card for this

ancient meteor Jun 23, 2022, 1:18 PM

#

OK, but even then, will that happen in a real scenario as well?

tribal crypt Jun 23, 2022, 1:26 PM

#

I think if you just use the standard decline card it should fail setup. Has the 4000000000000002 card been succeeding setups for you?

ancient meteor Jun 23, 2022, 1:26 PM

#

Let me check

#

btw, I spoke about this flow we several engineers already, just getting you up to speed:

Frontend sends Backend a request for checkout.
Backend creates a customer and a subscription without a payment method and returns a client secret from the subscription.pending_setup_intent entry
Frontend runs confirmCardSetup with the client secret and a payment method from the card element

#

The card you gave passes

tribal crypt Jun 23, 2022, 1:39 PM

#

I am still looking if there is a good test card to fail setup. I thought that those cards failed for me before.

#

Oh wait, can't you just put in a random card number for this? That kind of failure would be realistic to the actual card not going through in live mode

ancient meteor Jun 23, 2022, 1:41 PM

#

Well, I think the point here is that I do not try to immediately charge the customer since this is a setup intent and not a payment intent, perhaps this is the issue?

#

Is there a different way to authorize a customer in this case?

tribal crypt Jun 23, 2022, 1:44 PM

#

If you want to fail a setup intent, I think a random card number would work. If you want the card to succeed setup but fail on the first payment at a later date, we have a test card for that. I will find it now

#

Or is that not quite what you are looking for?

ancient meteor Jun 23, 2022, 1:47 PM

#

No

#

Again, my flow is this: https://discordapp.com/channels/841573134531821608/989517110684303401/989522383729721344

#

I want my Front End to fail during stripe.confirmCardSetup if the card should fail for any reason ("card declined", "stolen" whatever...)

#

But right now this function always passes, no matter the card we use

tribal crypt Jun 23, 2022, 1:51 PM

#

Right. Unfortunately I don't think we have cards for setup declines like that at the moment. I actually don't think you will get info beyond a generic decline at that point as banks are often not involved with setup intents. A failure from an invalid card number is about as close as you can get at the moment

ancient meteor Jun 23, 2022, 1:52 PM

#

Shit

#

So how can I authorize a card during Setup Intent?
The flow I shared with you was suggested by some other engineer earlier today.
But the previous flow I had included creating the customer with a "payment method ID" which I received from the frontend.
That flow actually did validate the card itself during customer creation and failed if the card declined for any reason...

#

But I was told this is a not recommended way to work when onboarding new customers so we changed it accordingly

#

But now we are having this issue, so I'm kind wondering with you what are my other options?

#

BTW, this was that previous conversation - https://discordapp.com/channels/841573134531821608/841573134531821616/989445679506161684

tribal crypt Jun 23, 2022, 2:04 PM

#

Thanks for the link. Reading up on that conversation. I am surprised that setup failed one way here but not the other

tribal crypt Jun 23, 2022, 2:23 PM

#

Still trying to take a bunch of this in. On a slightly positive note, I overlooked a card that we have for testing this decline, it just isn't in the main doc 4000 0000 0000 9995 https://stripe.com/docs/payments/save-and-reuse?platform=web#web-test-the-integration

#

So the three shapes of your failure will be:

The validation failure from an invalid number
Decline during setup (with 4000000000009995 or by choosing to fail 3DS)
Setup succeeds but eventual payment fails (via our test card for that)

ancient meteor Jun 23, 2022, 2:27 PM

#

Yes

#

But, the card you sent also passes

#

The one with 95 at the end

#

I want to fail on the second shape you sent with all "failing" cards

#

Both in order to test several scenarios, and to fail in a live environment while the user is "on-session"

tribal crypt Jun 23, 2022, 2:31 PM

#

I am surprised by that. I cannot get that 95 card to succeed now

#

Can you try that again quickly and send me the request ID for it?

ancient meteor Jun 23, 2022, 2:32 PM

#

Sec

tribal crypt Jun 23, 2022, 2:32 PM

#

Apologies I know you have already been on this for a while now

ancient meteor Jun 23, 2022, 2:36 PM

#

hey

#

sorry, discord problems

#

Anyway, pm_1LDr7KA155AgO8fTJsNMAAMo

#

Successfully added payment method with the 95 card

tribal crypt Jun 23, 2022, 2:42 PM

#

This is weird. We passed in almost the exact same parameters. I am trying to find the difference in what we did there. Trying to reproduce this for a bit.

#

Also just wanted to note that we can also move this to a ticket whenever if this is towards/after the end of the day for you.

ancient meteor Jun 23, 2022, 2:45 PM

#

Yes that would be great, I would prefer we continue this tomorrow morning if possible?

tribal crypt Jun 23, 2022, 2:46 PM

#

If you write in to our email support here and DM me your email I can pick up the ticket. I am US hours though, you can bring this up again in Discord in your morning https://support.stripe.com/?contact=true

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

#

I'll update this thread if I figure out what is going on here and can make sure to summarize before I close so it would be easier to pick up tomorrow.

ancient meteor Jun 23, 2022, 2:51 PM

#

Honestly, I just want to know I'm following the best practice

tribal crypt Jun 23, 2022, 3:00 PM

#

Yes, it looks like you are setting up things fine here as far as I can see. I think we have a bug somewhere that is causing this test card to not fail when it should. Creating the subscription as you are now and using its setup intent to collect/attach the card is in line with what we typically recommend.

Reading your previous thread again, I don't think what you were doing before was particularly wrong. Creating the payment method client side and passing the ID server side can definitely work, I think the main difference here is that that has more moving parts and more places to fail (client-server connection, backend API calls, etc). With this, the payment method should attach as soon as you confirm the setup intent.

uneven knollBOT Jun 23, 2022, 3:49 PM

#

This thread has been archived. If you need help with anything else please ask in #dev-help or contact Stripe Support: https://support.stripe.com/contact

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

high hawk Jun 24, 2022, 11:22 AM

#

hey @ancient meteor, how can I help you out

ancient meteor Jun 24, 2022, 11:22 AM

#

Hey @high hawk good to hear from you again

high hawk Jun 24, 2022, 11:22 AM

#

I wouldn't be able to read the whole thread could you please summarize

ancient meteor Jun 24, 2022, 11:23 AM

#

Sure

high hawk Jun 24, 2022, 11:23 AM

#

ancient meteor Hey <@937656056576888842> good to hear from you again

I'm happy to help again 🙂

ancient meteor Jun 24, 2022, 11:23 AM

#

Just getting you up to speed:

Frontend sends Backend a request for checkout.
Backend creates a customer and a subscription without a payment method and returns a client secret from the subscription.pending_setup_intent entry
Frontend runs confirmCardSetup with the client secret and a payment method from the card element

#

So we implemented this flow after your suggestion, and it works

#

However, the previous flow (where we pass the payment method ID to the backend and create the customer with it) used to fail when the cards that were used to create the payment method were supposed to fail ("general decline", "card stolen", etc...)

#

But with this flow, when running confirmCardSetup from the frontend, all the cards pass

#

And yesterday, the other engineer suggested using a special card that fails on "setup intent" - 4000000000009995 - which also passed.
But regardless, I don't want a "special card" to fail, I want all cards that are supposed to fail - to fail.

#

During initial "on-session" of course, off-session is a different story...

high hawk Jun 24, 2022, 11:30 AM

#

sorry didn't read the message through 😦

ancient meteor Jun 24, 2022, 11:30 AM

#

no worries ❤️

high hawk Jun 24, 2022, 11:31 AM

#

this is why I suggested using the latest_invoice.payment_intent instead of the pending_setup_intent

#

I have another suggestion for you

#

but you need to take it up to business decision makers

#

because it's a bit of a hack

#

but ultimately it's the best guarantee for your case to have a card that will not be declined

ancient meteor Jun 24, 2022, 11:32 AM

#

OK

#

BTW, this - latest_invoice.payment_intent is always empty with my flow

#

Even after expanding it

high hawk Jun 24, 2022, 11:33 AM

#

yes I know because it's a post-paid invoice

#

so there's no invoice at that stage

#

this is why I said it's going to be a business decision because my suggestion is changing the business model

#

but hear me out

#

what if you take a down-payment

#

a one-time payment at the start of the subscription

#

either you'd want it as a non-refundable payment or maybe you could deduce it from upcoming invoices?

#

that would solve your issue

#

if that's ok with you I could guide you through implementing this

ancient meteor Jun 24, 2022, 11:38 AM

#

I see what you're getting at, and I think I heard this suggestion from support before.
However the subscription is usage-based, and my option here would be to take the down-payment and then send a reimbursement, correct?
I agree it's a hack and I'd prefer to avoid that.
Even if it means going back to my previous flow and making it work properly (I know you said it works, but it has more moving parts).

I would say I want to hear this option out, but I know management would be against it...

high hawk Jun 24, 2022, 11:40 AM

#

then send a reimbursement, correct?
not really, you could set the amount as a balance for the customer and we would use that to pay the upcoming invoices

#

another thing you could do is try to attach the payment method to the customer (since in my suggestion it's just attached to the subscription)

#

when attaching the PM to the customer, we do a check

#

that would replicate the same thing you had in your previous flow

ancient meteor Jun 24, 2022, 11:46 AM

#

Interesting, so you're saying this type of error ("card declined") happens when a PM is attached to a "customer" object?
That sounds good, but that would mean, if I want it "on-session" I need the frontend to send the PM ID to the backend again after the setup intent was confirmed using confirmCardSetup?
Otherwise I would have to listen for a webhook and attach the PM then?

high hawk Jun 24, 2022, 11:47 AM

#

That sounds good, but that would mean, if I want it "on-session" I need the frontend to send the PM ID to the backend again after the setup intent was confirmed using confirmCardSetup?
Otherwise I would have to listen for a webhook and attach the PM then?
yes

ancient meteor Jun 24, 2022, 11:51 AM

#

So to sum up:

Frontend sends request to backend.
Backend creates Customer (with no PM) & Subscription (with no PM) and returns subscription.pending_setup_intent.client_secret
Frontend runs stripe.confirmCardSetup with the card element as the PM and the returned client_secret
Frontend sends request to backend to "update PM details" with the payment method ID
Backend updates customer with PM and succeeds/fails accordingly

Correct?

#

Interesting, so you're saying this type of error ("card declined") happens when a PM is attached to a "customer" object?
Is my assumption here correct BTW?

high hawk Jun 24, 2022, 11:52 AM

#

ancient meteor > Interesting, so you're saying this type of error ("card declined") happens whe...

yes

#

I'm thinking about something here

#

could you please share a pending_setup_intent Id I could look at?

ancient meteor Jun 24, 2022, 11:54 AM

#

Sure one sec

#

seti_1LDr7IA155AgO8fT9Ph4N5a5

high hawk Jun 24, 2022, 11:55 AM

#

maybe we could do something simpler and more efficient

ancient meteor Jun 24, 2022, 11:55 AM

#

req_XszrwIAJi89uZy

high hawk Jun 24, 2022, 11:56 AM

#

could you try to do a subscription and use a declined card?

ancient meteor Jun 24, 2022, 11:56 AM

#

The one I gave is exactly that

high hawk Jun 24, 2022, 11:56 AM

#

https://stripe.com/docs/testing#declined-payments

Testing

Simulate payments to test your integration.

ancient meteor Jun 24, 2022, 11:56 AM

#

I'll run it again but it may take a few minutes

high hawk Jun 24, 2022, 11:59 AM

#

ok so the authentication didn't happen on that setup intent

ancient meteor Jun 24, 2022, 11:59 AM

#

That is - card authentication?

#

And how do you see it? Can I see it too?

high hawk Jun 24, 2022, 11:59 AM

#

ancient meteor That is - card authentication?

yes

high hawk Jun 24, 2022, 11:59 AM

#

ancient meteor And how do you see it? Can I see it too?

I'm not sure you can

ancient meteor Jun 24, 2022, 12:00 PM

#

Is there a way to force card authentication all the time?

high hawk Jun 24, 2022, 12:01 PM

#

no not really AFAIK

#

could we please try something?

#

could you please generate a subscription the way you are doing right now and before passing submitting the payment information, could you please send me the setup intent id?

#

I want to check something

ancient meteor Jun 24, 2022, 12:05 PM

#

You mean, before confirming the card from the frontend?

#

seti_1LEBHUA155AgO8fTD8iUfm6W

high hawk Jun 24, 2022, 12:09 PM

#

yes

#

do you have the subscription id?

ancient meteor Jun 24, 2022, 12:10 PM

#

Sec, I'll give you a different one then:

seti_1LEBJYA155AgO8fT8Zg74g2R
sub_1LEBJYA155AgO8fTApHfdhgN

#

Used this card - 4000000000000002

high hawk Jun 24, 2022, 12:12 PM

#

I need both the ids before you confirm the card on the frontend

ancient meteor Jun 24, 2022, 12:12 PM

#

I gave you and didn't confirm the card

#

https://discordapp.com/channels/841573134531821608/989517110684303401/989865021259534356

#

I didn't even return the request to the Frontend, just created the subscription and gave you the IDs

high hawk Jun 24, 2022, 12:15 PM

#

you said Used this card - 4000000000000002 I assumed you confirmed my bad

ancient meteor Jun 24, 2022, 12:15 PM

#

Oh right, sorry

high hawk Jun 24, 2022, 12:21 PM

#

honestly I didn't find anything that could help

#

the payment method is attached to the customer as well, but it's using a different route than when you use the Attach PM to Customer API

#

🤦

ancient meteor Jun 24, 2022, 12:22 PM

#

😄

#

As a vendor, I find it amusing that you are frustrated with your own API

high hawk Jun 24, 2022, 12:23 PM

#

I think the only option is to do what I suggested earlier

ancient meteor Jun 24, 2022, 12:23 PM

#

I see

high hawk Jun 24, 2022, 12:23 PM

#

ancient meteor As a vendor, I find it amusing that you are frustrated with your own API

it's really complicated to design an API that suits all the users' different needs and scenario

#

we(my team) help design the API but at the end of the day there are decision that are made in the team that owns the products

ancient meteor Jun 24, 2022, 12:24 PM

#

Totally understand

#

So, following up the earlier suggestion.
What if a payment method different than the one attached to the subscription is attached to the customer?

high hawk Jun 24, 2022, 12:26 PM

#

by default we look at the subscription PM

#

if it's not present then we look somewhere else

#

https://stripe.com/docs/api/subscriptions/create#create_subscription-default_payment_method

Stripe API reference – Create a subscription – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

ancient meteor Jun 24, 2022, 12:27 PM

#

OK, so part of the "attach payment method" to the customer, I should set it as the default payment method in the subscription?

#

Wouldn't that cause the same error we had with the first flow?

high hawk Jun 24, 2022, 12:29 PM

#

I should set it as the default payment method in the subscription?
no need

#

default_payment_method
optional
ID of the default payment method for the subscription. It must belong to the customer associated with the subscription. This takes precedence over default_source. If neither are set, invoices will use the customer’s invoice_settings.default_payment_method or default_source.

ancient meteor Jun 24, 2022, 12:33 PM

#

OK, I'm trying this out now

high hawk Jun 24, 2022, 12:34 PM

#

I'd have to leave you with my colleague @marsh barn

#

if you need any more help please let them know

ancient meteor Jun 24, 2022, 12:38 PM

#

Thanks again @high hawk

marsh barn Jun 24, 2022, 12:38 PM

#

Hey, taking over here. Let me know if there's any follow-up Qs I can answer!

ancient meteor Jun 24, 2022, 1:08 PM

#

Hey

#

I have a question regarding the suggested method earlier

#

Although I didn't do it exactly the same way, but I think it's alright, you tell me

#

So the suggested flow was:

- Frontend sends request to backend.
 - Backend creates Customer (with no PM) & Subscription (with no PM) and returns subscription.pending_setup_intent.client_secret
 - Frontend runs stripe.confirmCardSetup with the card element as the PM and the returned client_secret
 - Frontend sends request to backend to "update PM details" with the payment method ID
 - Backend updates customer with PM and succeeds/fails accordingly

#

What I did was basically the same, but my Frontend was a go client running a test function
So when I needed to run confirmCardSetup I ran the go's setupintent.Confirm function

#

So I created a payment method, and confirmed the setupintent

#

It was a success

#

But later, I tried to update the customer with the payment method that was also used when confirming the setupintent, and it also worked.
But as @high hawk suggested earlier, it should've failed since the card I used is a bad card 4000000000000002

#

Any idea @marsh barn ?

marsh barn Jun 24, 2022, 1:15 PM

#

My guess is that card doesn't actually decline with Setup Intents – I don't know

#

What is it you're actually trying to test?

ancient meteor Jun 24, 2022, 1:16 PM

#

I want to make sure a card that is supposed to fail, fails during on-session when using setup intents

#

So the flow I wrote here - https://discordapp.com/channels/841573134531821608/989517110684303401/989880394889445417 should fail when using a bad card

#

But it doesn't...

marsh barn Jun 24, 2022, 1:17 PM

#

Right, but there's no actually any charges there in that scenario so my assumption is that card only declines in those circumstances

ancient meteor Jun 24, 2022, 1:19 PM

#

I mean, it used to decline when I had my previous flow.
Where I first create the payment method in the frontend, send the ID to the backend, create the customer with the payment method, and it fails due to a card declined error

#

Even though the subscription is usage-based and there are no charges

marsh barn Jun 24, 2022, 1:19 PM

#

If you want a decline when trying to confirm a Setup Intent then use this: 4000008260003178

#

create the customer with the payment method, and it fails due to a card declined error
Via the attach endpoint?

ancient meteor Jun 24, 2022, 1:20 PM

#

I create the customer with the payment method, as I understand it it was "attaching" behind the scenes

marsh barn Jun 24, 2022, 1:22 PM

#

Yep, you shouldn't do that as that flow will likely trigger a 3DS/auth request from the bank (and that endpoint has no way to facilitate that flow). Setup Intents is the correct way to do that now

#

you shouldn't do that as that flow will likely trigger a 3DS/auth request from the bank (and that endpoint has no way to facilitate that flow)
That will be the decline you saw. If we can't do 3DS, then it'll just decline

#

So in your current flow, which I think looks right, use the card: 4000008260003178

#

And you'll get a decline when confirming the Setup Intent

ancient meteor Jun 24, 2022, 1:24 PM

#

Well, it passed

#

Regardless, I don't want a special card to test on

#

I want to fail on all possible failing cards

marsh barn Jun 24, 2022, 1:27 PM

#

Our test card suite just doesn't really account for that. We create cards to cater for most scenarios, but there isn't really a blanket 'always fail' card

marsh barn Jun 24, 2022, 1:27 PM

#

ancient meteor Well, it passed

What did?

ancient meteor Jun 24, 2022, 1:28 PM

#

marsh barn What did?

Trying to confirm a setup intent with the card you gave me - 4000008260003178

#

I didn't mean always fail, my point was, when I had the previous flow and I tried to create a customer with a card that was meant to fail (e.g - 4000000000000002), the request to create the customer would fail on card declined.
But, with the new flow that you guys suggested and recommend, this doesn't happen.

#

I want to make sure a card is declined on-session and not only off-session

marsh barn Jun 24, 2022, 1:31 PM

#

I tried to create a customer with a card that was meant to fail (e.g - 4000000000000002), the request to create the customer would fail on card declined.
And I explained why – that wasn't because of the nature of the card you used

#

So you're almost trying tor replicate a test scenario that should never have happened

ancient meteor Jun 24, 2022, 1:35 PM

#

I don't understand, why is this a bad test scenario?
A user tries to use a "declined card" or a "stolen card", that shouldn't pass, the confirm setup intent shouldn't pass

radiant plank Jun 24, 2022, 1:46 PM

#

Hi there
Stepping in here as ynnoj needs to head out
Give me a moment to catch up and I'll respond as soon as I can

ancient meteor Jun 24, 2022, 1:47 PM

#

Thanks Hanzo

#

Shimada

#

BTW, I have this in my office 😄

radiant plank Jun 24, 2022, 1:54 PM

#

do you mind catching me up to your recent question with a quick summary as this is a long running thread? 🙂

ancient meteor Jun 24, 2022, 1:55 PM

#

Sure, give me a minute

#

Actually

#

I opened a ticket a few minutes ago

#

About that exaclty

#

Do you have access to it?

#

My mail is ohad@akeyless.io

#

So to sum up, this is basically it:

Frontend sends Backend a request for checkout.
Backend creates a customer and a subscription without a payment method and returns a client secret from the subscription.pending_setup_intent entry
Frontend runs confirmCardSetup with the client secret and a payment method from the card element
So we implemented this flow after your suggestion, and it works
However, the previous flow (where we pass the payment method ID to the backend and create the customer with it) used to fail when the cards that were used to create the payment method were supposed to fail ("general decline", "card stolen", etc...)
But with this flow, when running confirmCardSetup from the frontend, all the cards pass
And yesterday, the other engineer suggested using a special card that fails on "setup intent" - 4000000000009995 - which also passed.
But regardless, I don't want a "special card" to fail, I want all cards that are supposed to fail - to fail.
During initial "on-session" of course, off-session is a different story...

radiant plank Jun 24, 2022, 2:14 PM

#

I see. I think we'd need more time to dig into it and since you've already written into our support, we should be able to take it from there and continue this over email

ancient meteor Jun 24, 2022, 2:15 PM

#

OK, thanks man

#baruco-cardElement-confirmCard