itsqwerty

[fading vessel]

Hi there!

Yes that sound correct. However we recently launched a new way to create subscription, that allow you to use the Payment Element without a client_secret upfront: https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription

[white cove]

oh awesome! is there also a such thing with LinkAuthElement? because my issue was I was thinking (im guessing i got this wrong) i need to have a normal input to get the users email, create secret to show the LinkElement which lets the user type an email

and also are their any security concers sending the customerId to the fe without verifying an account belows to the user? The company wants to remove many flow as possibe from the cart system and wants the user to verify their email after a successfull payment

[white cove]

also I see here, in the e.g it enters the amount we want to charge to the customer in the FE, is there way to avoid that so it cannot be messed with from the FE by possibly malcius users

or ways to handle around it

[fading vessel]

oh awesome! is there also a such thing with LinkAuthElement? because my issue was I was thinking (im guessing i got this wrong) i need to have a normal input to get the users email, create secret to show the LinkElement which lets the user type an email
Technically you could create the customer object without an email. So only collect the email in the LinkAuthElement.

and also are their any security concers sending the customerId to the fe without verifying an account belows to the user? The company wants to remove many flow as possibe from the cart system and wants the user to verify their email after a successfull payment
I'm not sure I understand. What' the security concern exactly? Using LinkAuthElement?

also I see here, in the e.g it enters the amount we want to charge to the customer in the FE, is there way to avoid that so it cannot be messed with from the FE by possibly malcius users
You set it on the frontend only for display puproses. What the customer will pay depend on the amount you set when creating the PayementIntent on the backend.

[white cove]

I appreciate it.

I see the BE on the /create-subscription route expecting a priceId in the body, but I do not see in the e.g it being passed to the BE when making the API request. Is that a mistake or have I gotten that wrong again. Also, where does the FE get the priceId from?

I'm not sure I understand. What' the security concern exactly? Using LinkAuthElement? - Can I send the customerId to the FE even thought I have not verified a customerId belongs to that specific customer (for e.g if they are not logged in)

Technically you could create the customer object without an email. So only collect the email in the - can all the customer values be null when creating the customer object? or are some required

[white cove]

this is on the e.g page: https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription

[fading vessel]

I see the BE on the /create-subscription route expecting a priceId in the body, but I do not see in the e.g it being passed to the BE when making the API request. Is that a mistake or have I gotten that wrong again.
Indeed it looks like a mistake.

can all the customer values be null when creating the customer object?
Yes

Can I send the customerId to the FE even thought I have not verified a customerId belongs to that specific customer
Either it's a new customer, so you create a new customer ID. Or it's a returning customer, so you can pass the existing customer ID.

[white cove]

Would you be able to prove some gudience on the priceId if you wouldnt mind

when saving the paymentmethod on a subscription, (I think i know the answer to this however would just like to confirm), is the payment actually linked to the customer object which is linked to the subscription object

[fading vessel]

Would you be able to prove some gudience on the priceId if you wouldnt mind
Sure, what's your question exactly?

when saving the paymentmethod on a subscription, (I think i know the answer to this however would just like to confirm), is the payment actually linked to the customer object which is linked to the subscription object
You can either save the payment method on the subscription object (https://stripe.com/docs/api/customers/object#customer_object-invoice_settings-default_payment_method) or on the customer object (https://stripe.com/docs/api/subscriptions/object#subscription_object-default_payment_method). and yes the subscripiton is linked to the customer object.

[white cove]

In the example you provided - how is it actually meant to work with the priceId, is the FE meant to send the priceId to the BE at this stage if so how does the FE get that?

[fading vessel]

That's completely up to you. Maybe the priceID is hardcoded in the frontend. Maybe the priceID is directly available in the backend and the frontend doesn't know it at all.

[white cove]

Because the FE doesn’t pass anything to the BE, is the payment method automatically attached when confirming the payment in the FE

[fading vessel]

is the payment method automatically attached when confirming the payment in the FE
When creating the subscription, if you set payment_settings: { save_default_payment_method: 'on_subscription' }, then the PaymentMethod will be attached on the subscription.

[white cove]

And will it be attached to the subscription or also the customer object too in this case?

[fading vessel]

the payment method will be attached to the customer (but not set as default), and set as the default payment method for that subscription.