#ironbeard_api

1 messages · Page 1 of 1 (latest)

willow marlinBOT
#

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

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

gloomy fjord
glacial python
#

Gotcha, awesome. And PaymentElement will handle e.g. ACH Credit / bank transfers?

gloomy fjord
#

Yeah

glacial python
#

I guess I'll set that up then. Thanks 🙂

gloomy fjord
#

No problem. Yeah the Payment Element is the move if you want to accept more than just card payments

glacial python
#

Is there a way to pass e.g. a customer id to the PaymentElement so they can see e.g. their default payment method instead of entering a card?

gloomy fjord
glacial python
#

So actually, I just remembered (it's been awhile since I wrote this code), I'm actually potentially processing two separate payments with possibly two separate subscription client secrets. The reason being is that we have two main types of products: a newsletter (email pdf) and SaaS (which can be upgraded/downgraded etc).

If I recall correctly, the reason I split it into two separate payments was that upgrading and downgrading became a real mess when both the newsletter and the SaaS were on the same Subscription.

Based on a quick glance of the code you linked, it looks like I need to specify the subscription client secret when initializing the PaymentElement? (e.g., in the const options = {clientSecret: '{{CLIENT_SECRET}}', appearance: {[...]}})

gloomy fjord
#

Correct

#

So how are you managing this w/ the card element?

glacial python
#

So I create the card element using const stripe = Stripe('{{ STRIPE_API_KEY}}') and const cardInstance = stripe.elements().create('card', {style: {base: {fontSize: '16px'}}}); cardInstance.mount('#card-element');

Then my hidden form has possibly 2 client secrets, so I just loop through them and if they have a value I call stripe.confirmCardPayment(clientSecretValue, {payment_method: {card: cardInstance}})

gloomy fjord
#

Yeah this is going to be difficult to do with the payment element. We have a flow to initialize the payment element without a client secret, but the return_url on the confirmPayment call is going to be an issue since there will have to be a redirect after the first confirmPayment call

glacial python
#

Right, I just thought the same thing.

#

I'm trying to remember the specifics of why I needed to separate them into two separate subscriptions. I think it was because idealsly the newsletter subscription start/end dates shouldn't change even if the user upgrades/downgrades their SaaS package, but I think that was happening?

gloomy fjord
#

That shouldn't change the start/end dates

glacial python
#

Hmm 🤔 It would if proration_behavior: 'always_invoice' and billing_cycle_anchor: 'now', right?

gloomy fjord
#

yeah billing_cycle_anchor controls that

glacial python
#

I wonder why I set it to 'now' 🙄

gloomy fjord
#

If you don't specify it, it shouldn't change

glacial python
#

I remember now (had to search your discord for a post of mine from Sept 2022!).

  1. To simplify things, we offer two levels of SaaS subscription: data for a single region and data for all regions. Everything is an annual subscription, both the SaaS and the newsletter.
  2. If someone subscribes to a single region on Jan 1st, theoretically if we didn't have billing_cycle_anchor: 'now', then on Dec 31st at 11pm they could "upgrade" to the "All Regions" package and access the data for 1hr at a vastly reduced price, then cancel their subscription before midnight.
  3. To combat this, we set billing_cycle_anchor to now. However, a byproduct of this situation was, if someone subscribed to both the SaaS (single region) and the Newsletter on Jan1st, and then on July1st they upgrade the SaaS to all regions, they wouldn't only be paying the full price for the SaaS (which is good), but they would also be asked to pay for 6 months of the newsletter, since it it's billing cycle would be adjusted to line up with the SaaS.

So, felt weird to ask them to pay more for their newsletter subscription even though it wasn't finished yet. Hence doing these as separate Subscription objects.

gloomy fjord
#

I see. So, things will definitely be much simpler if you stick with card element given this

#

However, I can suggest some workarounds if you really want to move to payment element

glacial python
#

Hmm, the redirect_url, and the handling of default payment methods, as well as being able to take bank payments, are all very enticing.

gloomy fjord
#

Hmm, the redirect_url
This piece becomes a complication in your flow actually

glacial python
#

In reality, we're a small-ish company: 21 people subscribed to newsletter only, 4 people subscribed to both Newsletter+SaaS, 4 people subscribed to the "All Regions" package and 10 people subscribed to the single region stuff.

It's possible that I'm giving more weight to the edge cases than they deserve.

gloomy fjord
#

Up to you

willow marlinBOT
glacial python
#

Yeah, the redirect url being the issue bc if I'm processing two separate subscription objects, then there's no clear way to say "don't redirect until both of these payments are processed"?

compact cedar
#

Hello
Taking over

#

I'm trying to read through previous messages but can you give me a short summary of what you're trying to do?

glacial python
#

Sure. I'm interested in ditching CardElement for PaymentElement. But, there's a bit of a nuance where I'm actually creating two Subscription objects and two Charges currently in order to address some edge cases

compact cedar
#

I see. How exactly are you handling it today?

glacial python
#

I'm returning possibly two clientsecrets to the front end and just looping over them and calling stripe.confirmCardPayment(clientSecretValue, payment_method: {card: cardInstance}}) possibly twice

#

but I'd like Stripe to handle the redirect for me, and the default payment methods, two enticing benefits of the PaymentElement.

#

But if I used the PaymentElement, then it would possibly redirect before the second subscription is paid for

compact cedar
#

Have you thought about using SetupIntents to tokenize payment method and create the two subscriptions server-side?

That would save you the trouble of confirming an intent twice

glacial python
#

Hmm, not familiar with SetupIntents

#

Currently I am creating the Subscriptions server-side, in order to send the client secrets?

compact cedar
glacial python
#

Interesting. So I would still display a PaymentElements, but I wouldn't need to pass ClientSecrets to the front end. Then, I can listen for webhooks to actually create the Subscription object(s) and provision access?

compact cedar
#

Then, I can listen for webhooks to actually create the Subscription object(s) and provision access?
Correct

glacial python
#
  1. Is this compatible with allowing an existing customer to use default payment method in the PaymentElements?
  2. The docs seem to suggest going the async route and creating the Subscription via webhooks. But if I wanted to gaurantee that they can immediately access their SaaS after clicking "submit," I should create the subscriptions using the session_id in the GET request of success_url?
#

And I could do a single SetupIntent client-secret, I wouldn't need two for the even where I create two Subscriptions?

compact cedar
glacial python
#

Hmm. I'm realizing that a lot of complications could be addressed if we just provided the newsletter pdf subscription as a complimentary item when people subscribed to the data access.

I think I need to regroup a bit and discuss with others before progressing, but I appreciate your help and pointing me in the right direction!