#francesco_checkout-paymentmethods

1 messages · Page 1 of 1 (latest)

frank widgetBOT
#

👋 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/1245037687166205993

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

hard sluice
#

this is the error, both when we are triggering the recurring payment and when we are trying to attach customer and payment method: "400 -- [invalid_request_error] The provided PaymentMethod was previously used with a PaymentIntent without Customer attachment, shared with a connected account without Customer attachment, or was detached from a Customer. It may not be used again. To use a Payme"

#

this is mission critical

coarse river
#

Hi there 👋 if you don't want to let your customers choose whether they save their payment method, which you don't if you need that for future usage, you can set payment_method_save to disabled.

frank widgetBOT
hard sluice
#

Hi toby, this was not explained at all in the documentation

#

And now I have to manually attach the payment method to the customer object, but the API does not allow me to do it

coarse river
hard sluice
#

I cannot imagine asking my customers to log in to the website and doing again the "change method"

frank widgetBOT
late jacinthBOT
hard sluice
#

I really need thos methods to be reused

#

this was the mail I received, nowhere it was mentioned that it would override the off_session method

#

it only talks about filling the form

humble basin
#

francesco_checkout-paymentmethods

#

@hard sluice sorry do you have a clearer description of your issue? why do you expect things to "override" exactly?

hard sluice
#

So basically I have set up a payment component with payment_intent_data: {
setup_future_usage: 'off_session',
receipt_email: email,
},
saved_payment_method_options: {
allow_redisplay_filters: ['always'],
payment_method_save: 'enabled'
},

humble basin
#

okay so what's the issue?

hard sluice
#

if the user does not tick the box "allow this payment for future use" the off_session does not work because It does not connect the payment method with the customer

humble basin
#

Gotcha. That should be impossible. Can you share an exact example I can look at?

hard sluice
#

this does not make sense, because if I don't ask anything to the user (payment_method_save: disabled), the payment method IS CORRECLY SAVED

#

you can have a look at this request: req_VEfhbnWiRvCPk7

humble basin
#

That request id is just you trying to attach it with no context. I understand you are frustrated but there are 15 other people asking for help all at once.
Can you try and take a step back, write a clear and detailed summary all in one message that explains the issue end to end including all the relevant object id(s) for me to help you figure out what happened?

hard sluice
#

Sure can you read the subject of the ticket?

#

What did you expect to happen?
setup_future_use should override the new payment_method_save when using "off_session".

What actually happened?
Enabling the payment_method_save box in the managed checkout page of Stripe, if the user does not explicitly tick the "save payment for future use", we cannot attach the payment method to the customer, even if we specify the "off_session". This breaks our recurring payment since we are a subscription platform. deleting the "payment_method_save" solve the problem

Reproduction Steps
create a checkout component with future payment off_session and try to do a payment. the payment method is correctly attached to the customer.
Now create a checkout component but also add the payment_method_save option. now try to pay: if you don't check the box, the payment and customer are NOT attached, thus breaking the recurring payments

Question
What can we do now? We added payment_method_save after receiving your email that states that it's only for autofill feature, and now we are experiencing tons of failing in triggering the recurrent payments. the only option is to delete the payment_method_save option and manually attach customer to payment method but this does not work via API

What are you working on?
hotfix

#

What do you mean by an example? What do you want me to provide?

#

The issue is simple, if you create an intent with setup_future_usage: "off_session" and payment_method_save: 'enabled', if the user does not tick the box the payment method is not attached to the user. this seems a bug and needs to be fixed, meanwhile I'm turning the payment_method_save to 'disabled'.

#

Now my problem is that I have 150 transactions, made this month, that can't trigger because they don't have a payment attached, caused by this bug. How can I fix this? How can I manually attach them?

humble basin
#

I'm trying to ask you to help me help you. You copy-pasted a wall of text but what I need are exact example ids of the entire life cycle of what you tried: Checkout Session, resulting Customer and PaymentMethod, etc. so I can help you.
All in one message as I am helping 15 other people in real time and every message is lighting up my UI with no information

hard sluice
#

Ok I'll try to find evidence and post it to you

#

First of all I created a customer (cus_QBNfRotnJbAO7e). Then I created a payment intent using the checkout session specifying that customer in the payload, specifiyng the setup_future_usage: "off session" and saved_payment_method_options: {
allow_redisplay_filters: ['always'],
payment_method_save: 'enabled'
}. The user filled the form with the card and fullfilled the payment intent (pi_3PL0yfG0HkO3ZPnp1oZt1hwK) using this payment method: (pm_1PL0yeG0HkO3ZPnpyjZX2whX) . After a month, I tried to charge the same customer with the same payment method but the result was an error: 400 -- [invalid_request_error] The provided PaymentMethod was previously used with a PaymentIntent without Customer attachment, shared with a connected account without Customer attachment, or was detached from a Customer. It may not be used again.

#

After that I tried to manually attach the payment method to the customer, but the result was the same error: 400 -- [invalid_request_error] The provided PaymentMethod was previously used with a PaymentIntent without Customer attachment, shared with a connected account without Customer attachment, or was detached from a Customer. It may not be used again.

humble basin
#

What is the exact Checkout Session id please

hard sluice
#

cs_live_a1KJTOxsR27CYjzXIH44wYEwn7ngm9vJCMg1o6Ok97dWF55UjXuScUa2tK

humble basin
#

Thanks, give me some time to figure out what happened!

humble basin
#

(still digging into this)

hard sluice
#

thanks I'm waiting

humble basin
#

Okay right now it seems this is on purpose. If you use the payment_method_save you give the option to the end customer to decide whether to save their card details or not.
I do agree this is confusing. It should at least error if you pass setup_future_usage: 'off_session' in my eyes.

I think you should stop using payment_method_save in this case if you need that card attached no matter what. There unfortunately won't be a way to fix the previously collected/consumed cards on our end.

hard sluice
#

Thanks, but I litterally die if I cannot handle this situation

#

I created 106 checkout session for "off_session" use

#

There must be a way to solve the issue

#

I'll die of dunning

#

Can I bill a payment method that is not attached to a customer?

humble basin
hard sluice
#

removing payment_method_save is a PERMANENT solution?

humble basin
#

I don't really know why you added this or what the email you got told you so I'm not sure what you were trying to resolve.
But yes, if you remove that parameter, the card will be saved for future off session payments

hard sluice
#

I received a mail that said that from 1*st of may the checkout would change

#

and a link to this arcticle

#

talking about privacy and other stuff regarding saving payment for future use

humble basin
#

yep got it, so it looks like this feature will override your setup_future_usage because it is asking the end customer if they want to save their card details or not, so when they don't check that box, the card is not saved

hard sluice
#

yeah but this was not mentioned, so i'm in real trouble right now. Can you imagine any other way other than asking to the end user to have it done?

humble basin
#

Unfortunately no there is no other way I'm sorry

hard sluice
#

this is insane

#

thank you

humble basin
#

We're still investigating internally to see if we can improve the behaviour to be clearer (including the docs) and where passing setup_future_usage should still attach the card but it won't fix the previous ones unfortunately 😦

hard sluice
#

thank you

humble basin
#

@hard sluice is your colleague also here asking the same question maybe? I just realized when looking at the other thread with the same question taht it's from the same Stripe account

hard sluice
#

I think so

#

I'll update him

#

thanks

humble basin
#

gotcha