#salim_paymentelement-save

1 messages · Page 1 of 1 (latest)

tranquil elmBOT
#

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

📝 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 tide
#

Hi 👋

How are you creating the Subscriptions?

signal jolt
#

Both we have subscriptions and onetime

cosmic tide
#

Sorry but that is not an answer to my question

#

What is the exact API call you are making to create a Subscription?

#

Can you share the code?

signal jolt
#

ah sorry, i thought you said if i am integrating subscription

#

sec

swift gulch
#

hello

#

i am trying to use payment element.

paymentElement.value = elements2.value.create('payment')
paymentElement.value.mount('#payment-element')

Q, is it possible get credit card details? What i want to do: get credit card details to attach credit card to user

cosmic tide
#

Okay that is an entirely different question.

Can you explain in clear steps, what the user flow is? Are you charging the user as part of this action? Are you just collecting the payment method information?

swift gulch
#

Only collecting the payment method information

#

before payment element I was trying to use express checkout to create sub. Flow with express checkout was like that:

  1. insert stripe script, initializing stripe instance using publish key
  2. render express checkout
  3. creating payment method, getting pm id to pass it to backend and attach payment card
  4. creating sub
#

but to create payment method manually, need set paymentMethodCreation: 'manual' where amazon pay not works

#

support said, there is a way to not create payment method manually, and to not attach payment method before subscription creation. But this way not suits for us for now.

#

so i am trying use payment element, to create payment method and attach pm id to user

#

one moment i will record video

tranquil elmBOT
cosmic tide
#

Let's stop right here

#

There is a simple and straightforward way to save a payment method to a Customer using the Payment Element

carmine slate
#

salim_paymentelement-save

swift gulch
#

what if CUSTOMER_ID not exists yet?

carmine slate
#

the easiest is create the Customer upfront in that case. But otherwise you can remove that parameter and later attach the PaymentMethod

swift gulch
#

this way will work correcly with google pay and amazon pay and with subscriptions?

carmine slate
#

If you are doing Subscriptions, you should follow a guide focused on Subscriptions instead

swift gulch
#

this solution involves using a separated window - checkout, right?

carmine slate
#

That guide has multiple tabs that shows various options.
There are dozens of ways to integrate our products and APIs. The first step is to pick what product(s) you want to use and then pick the right type of integration for it

swift gulch
#

unfortunately checkout as separated page or window doesn't suit us

carmine slate
#

Step 1: what product do you want to use

=> you are now saying you want Subscriptions. That changes the entire integration path. So is that correct?

swift gulch
#

we are using subscriptions

#

we used payment request button component before

#

now because, suggested migrate from payment request button component, we are trying migrate to express checkout

#

but we faced problem with it, so now i trying use payment element

carmine slate
#

What problem did you face with it? ExpressCheckoutElement works totally fine with Subscriptions

swift gulch
#

one moment, i will describe

#

can you read this chat please?

carmine slate
#

No sorry

swift gulch
#

first issues with express checkout are:

  • not found way how get selected credit card data from express checkout

i need get selected credit card to check, if this card was already attached to user or not.

  • If card has been attached, i need just run request to backend to set this card as default
  • If card has NOT been attached, i need get card data from express checkout, pass it to backend, to create and attach this card. But i have not found way how to get selected credit card data from express checkout. So i creating payment method from frontend using stripe.createPaymentMethod(). Then i am getting pm id and passing it to backend, so backend attach this card.
carmine slate
#

You should be able to summarize the problem in a couple sentences.
Overall using PaymentElement is fine too. But right now I don't get where you are confused

#

Gotcha, that's a good summary. It's really uncommon to show ExpressCheckoutElement to get a PaymentMEthod and then check if it's the same as before

#

Sorry it does look like you went down multiple rabbit holes and are trying to force your integration to something else

signal jolt
#

we need to pass the card data from express checkout to the backend to create and attach the card.
Since I couldn’t retrieve the card data from express checkout, I’m currently creating the payment method on the frontend using stripe.createPaymentMethod(). After obtaining the payment method ID, I pass it to the backend to attach the card.
Stripe Payment Method Creation Issue: Unfortunately, I encountered a second issue: stripe.createPaymentMethod() does not work unless the paymentMethodCreation: 'manual' setting is applied. However, when this setting is enabled, the Amazon Pay button fails to render.

swift gulch
#

we found out, that with paymentMethodCreation: 'manual' amazon pay not works

carmine slate
#

Since I couldn’t retrieve the card data from express checkout, I’m currently creating the payment method on the frontend
that's not a "hack" though. That is exactly what you are supposed/expected to do.

#

However, when this setting is enabled, the Amazon Pay button fails to render.
Correct, AmazonPay doesn't support this

swift gulch
#

because of that, i am tring payment element

carmine slate
#

Gotcha, so what isn't working with PaymentElement?

swift gulch
#

main goal is to attach payment method to user, before subscription creation

carmine slate
#

Yeah that is not a good flow, that's a really bad idea/approach. That's what I am trying to explain.

#

Why do you absolutely want to attach the PaymentMethod first? Is it a misunderstanding of our API? Or is it a hard requirement of your integration? Or something else?

swift gulch
#

it a hard requirement of backend logic, because most of logic located at backend. From frontend i only attaches payment method, and run subscription creation request to backend

carmine slate
#

Okay, so even though it is a really poor integration approach you absolutely want to use it?

swift gulch
#

we found out that there is a way to create sub without attaching pm before sub creation

#

but seems like we can't create subscription without attached payment method

swift gulch
carmine slate
#

yes if you can change your backend logic it'd be much better

#

That lets you do this

  1. Collect PaymentMethod client-side
  2. Go to your server, create the Customer and then create the Subscription with that PaymentMethod
  3. If needed, handle any next action such as 3D Secure, client-side
swift gulch
#

can you describe please, why our approach is not good?

#

i mean creating sub without attached payment method

carmine slate
#

Try to follow my doc end to end

swift gulch
#

so in this step we need create subscription only with payment_behavior: 'default_incomplete' parameter, right?

carmine slate
#

yes!

swift gulch
#

it means payment method will be attached to customer automically, right?

carmine slate
#

yep

#

it's a different way/flow of requests. I recommend just trying it

swift gulch
#

as i understood, he wants to reduce the number of requests

image.png
carmine slate
#

that sentence doesn't make sense to me

#

what does "auto-confirmation" mean?

signal jolt
carmine slate
#

Sorry that's still super cryptic. The PaymentIntent has to come from somewhere, which means you already created the Subscription in the first place right?
This is quite subtle and there are literally 20+ ways of integrating Subscriptions and PaymentElement. Can I ask you to be as clear and crisp as possible about the exact sequence of API requests?
Really what I shared is the right canonical way to do this, it's the best one

signal jolt
carmine slate
#

Yeah that flow is if you do not use Subscriptions though. I asked earlier and you said you absolutely use them.

signal jolt
#

we use them both subscriptions and onetime

signal jolt
#

payment intent for onetime only

carmine slate
#

Okay, and we were talking about Subscriptions. But you then talked about "auto-confirmation" and then creating a PaymentIntent and now say it's for one-time payment only

#

So if we focus on recurring payments and you use Subscriptions, then what I said above is the right flow

signal jolt
#

ok what about onetime?

carmine slate
#

One-time works completely differently though the idea is similar. But we can't really talk about every single part all at once while you;re confused. We should solely focus on one specific flow first.

signal jolt
#

ok thanks got it

carmine slate
#

I can definitely explain both as we go. But I want to make sure we do one at a time as you're two people in the thread and asking different questions

signal jolt
#

@swift gulch you can write.

carmine slate
#

The official flow is what I wrote earlier

  1. Collect PaymentMethod client-side
  2. Go to your server, create the Customer and then create the Subscription with that PaymentMethod
  3. If needed, handle any next action such as 3D Secure, client-side
swift gulch
#

if we go to suggested way of using subscriptions, we need also take care about onetime purchase. Sorry, i didn't mentioned onetime before.

carmine slate
#

It's fine, and it all will work. But it's tricky as you ask questions and then you ask them to Salim I think.

#

I can't really answer every questions all at once. There are dozens of ways to integrate. And some of the things you do definitely seem completely wrong right now. But I barely understand your expected flow. Can one of you clearly outline the sequence of exact API Requests you do in one clear message?

swift gulch
#

we are both with Salim trying figure out what approach we need use to not break current subscriptions and onetime, to convince lead developer change backend logic, if it is wrong

swift gulch
carmine slate
#

Sorry, you're giving me half answers each time

#

It's really hard to help you with vague answers unfortunately 😦
Can the lead developer just come and ask their questions instead? 😅

signal jolt
#

ok then another time

#

thank you for your support

#

👍

carmine slate
swift gulch
#

so, in both cases we don't need attach payment method before subscription creation, right?

carmine slate
#

correct.

#

This flow is newer (launched last year) and much better and definitely what I would recommend.
In both cases you end up with a PaymentIntent. Either one you created (one-time) or one Stripe created (through a Subscription) and then you confirm it with the PaymentMethod id pm_123 and if the payment succeeds it can attach the PaymentMethod to the Customer for future use

swift gulch
#

got it, thank you very much!

carmine slate
#

sure thing!

swift gulch
#

ah, another Q

tranquil elmBOT
swift gulch
#

we definetly need use payment elements, instead of express checkout?

carmine slate
#

If you want AmazonPay then I'd say yes.

swift gulch
#

amazon pay will not work with express checkout?

carmine slate
#

We already went through this earlier and you're the one who said it doesn't work specifically when you pass paymentMethodCreation

swift gulch
#

What way should we use, if we want use express checkout, but without manual payment method creation?

gleaming inlet
#

It doesn't appear that flow is supported for amazon pay

#

However, it looks like you're using createPaymentMethod -- its possible that this requires using createConfirmationToken. Have you tried that?

swift gulch
#

we used createPaymentMethod to get pm id and attach payment method, before subscription creation

gleaming inlet
#

Yea, you can't do that, you need to use confirmation tokens to carry the confirmation intent forward

swift gulch
#

but @carmine slate suggested to no attach pm before subscription creation

gleaming inlet
#

Right, you can either do that (simpler, but no ability to inspect payment details before confirmation) or you can switch to confirmation tokens to keep that interim step if required, and use the confirmation token to confirm the payment (one time or on the subscription).

#

If you don't explicitly need that in between step, i woul recommend eliminating it and confirming from the client directly, using the deferred patterns shared

swift gulch
#

in general the best way for us is:

  1. don't attach pm before subscription creation
  2. use express checkout without manuall payment creation using confirmation tokens

in this way, we will have working gpay, apple pay, amazon pay, am i right?

gleaming inlet
#

That is my understanding, yes, but you should try it out and let us know what works or doesnt!

#

Do you explicitly require the interim step to inspect the PM details?

#

If not, i would reocmmend option 1

swift gulch
#

using express checkout flow, payment method will be attached to user automatically?

gleaming inlet
#

If you use it to start a subscription, or your payment intent uses setup_future_usage yes

#

(customer, specifically, i assume you mean user=customer)

swift gulch
#

what better to use, payment elements with suggested @koopajah way, or using express checkout

gleaming inlet
#

I expect both should work, so its really up to your preference.