#greggles_integration-subscription

1 messages · Page 1 of 1 (latest)

craggy pythonBOT
wet harnessBOT
#

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.

craggy pythonBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1257736673094139967

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

late pawn
#

looking

quaint agate
#

Hi, one thing I've been confused about is that it's been suggested that I render the payment element after finalizing the invoice, but I need to render the address element first in order to set up the invoice so I don't have the client secret at that point.

Would this imply I need a multi-page checkout?

late pawn
#

greggles_integration-subscription

quaint agate
#

Thank you, that's pretty much the integration I'm using but it's limiting the payment elements that can be used to credit card, Google Pay, US Bank Account, and CashApp. We'd like to use the full range available to us and we'd like to take advantage of automatic payment methods.

late pawn
quaint agate
#

I did confirm that, yes but the only payment methods that show are the ones I listed above.

late pawn
#

So what payment methods are you missing? Can you give me a concrete example of one you expect to show for your exact mode, currency and amount?

quaint agate
#

Alipay and Wechat pay are two that don't show.

#

In my conversation yesterday with TwoShoes, they suggested

I'd recommend switching to creating/finalizing the Invoice before rendering the Payment Element, that way you can pass its client secret in with the Payment Element and use whatever your Invoice's billing settings are.

Right now I'm having to specify the 4 payment methods above explicitly because not specifuing them produces errors when using some of the automaticly generated ones.

#

Which brings me back to my original question. I need to render the address element first in order to create the customer object and the invoice for the products. Creating the invoice produces the payment intent and client secret, right?

late pawn
#

Yes in that case you would have to

quaint agate
#

have to use a multi page check out?

late pawn
#

I don't think we care much about whether you do a multi-page check out or not. That's really up to you. But yes you need to render things sequentially

quaint agate
#

Let me be more explicit. In the docs instantiating stripe elements looks like this

const options = {
  appearance: appearance,
  'mode': 'payment',
  amount: 9995,
  'currency': 'usd'
};
const addressOptions = {
  mode: 'billing',
};
const elements = stripe.elements(options);
const paymentElement = elements.create('payment');
const addressElement = elements.create('address', addressOptions);

So you'd instantiate elements first using whatever options we'd need, then render the element. However I don't have the client secret to use in the options when instantiating const elements when I need to create the address element. Follow?

late pawn
quaint agate
#

So I can add the client secret using elements.update?

#

The doc doesn't mention that as a parameter.

late pawn
#

No sorry in that case do a separate elements. Sorry I know you're looking for firm guidance but I've never seen anyone do what you are trying to do. Right now you're just testing so try to iterate quickly for a few minutes to get to the result you are after

quaint agate
#

OK, sorry, let me start over and go back to my original question. I'm selling both subscriptions and one-off products, separately on different pages. I'm looking for a step-by-step integration guide. I'm happy to use what most people do if it makes it easier.

craggy pythonBOT
late pawn
#

We have no step by step integration guide that works for your specific use-case sorry. That's what I explained earlier. So you have to adapt for the Subscription part and do it differently to match your needs

#

@lethal lantern is taking over if you have a follow up question!

lethal lantern
#

👋

quaint agate
#

No one uses the address and payment elements to collect information and pay for subscription products? I don't understand.

#

What is a typical use case? Only collecting payments but not connecting those payment to products? Sorry, not trying to be flippant or dense.

#

@here anyone there?

lethal lantern
#

Sorry, was reading the thread.

#

I didn't want to cover what's already been covered.

#

No one uses the address and payment elements to collect information and pay for subscription products?
Yes, they do, but we don't have a specific end-to-end guide for it. People build custom solutions for this using various parts of Stripe.

#

What is a typical use case? Only collecting payments but not connecting those payment to products? Sorry, not trying to be flippant or dense.
The most typical use case would be to send your customer to Checkout and have Checkout collect all the information required and create a Subscription, but it sounds like you want a much more custom solution than that.

#

If I understand correctly, you want to collect address details with the Address Element, then create a Subscription with those address details, then have your Customer pay for the Subscription's first Invoice with the Payment Element, and you want all of that to happen on a single payment page. Is that correct?

quaint agate
#

Thanks, and sorry to @ ya.

That's mostly correct. We'd prefer a single page but if a multi page solution opens up more payment methods for us we're flexible.

quaint agate
lethal lantern
#

One thing I'm specifically wondering about is if you must use the Adress Element? It seems like it would be easier for you to collect the address info you want using regular HTML form fields, then pass that data to the API.

quaint agate
#

While not necessary, I used it to leverage Stripe's validation and autofill features. It seemed designed to work well with the payment element. Now it seems really difficult.

lethal lantern
#

It's difficult for your specific use case, because you have the requirement of using the elements out of their intended order.

#

The Payment Element and Address Element at designed to be shown on the same page at the same time under a single Elements instance, and all of the information is intended to be gathered and used at the same time.

quaint agate
#

Yes. We need address information first to be able to determine if tax is needed or not. I wouldn't think that is out of the ordinary.

lethal lantern
#

You want to break that up, and gather the address info first, then use that to create the Subscription/Invoice/Payment Intent that will be used by the Payment Element.

#

Your use case is not out of the ordinary. Using the Address Element and Payment Element for this use case in this way is out of the ordinary.

quaint agate
#

Sorry, I think I'm dense. What would be a typical checkout process? I'm sure I can adapt our flow to what's ordinary if I had a step-by-step guide.

lethal lantern
#

It depends on what you mean by "typical checkout process". Do you mean a typical checkout process for Subscription payments or something else?

quaint agate
#

Yes, let's start with that.

lethal lantern
quaint agate
#

That is exactly what I'm looking for.

#

And to sell a one-off payment product? I'd need to use invoicing, correct?

lethal lantern
#

You can use a one-off Invoice, but you don't need to. You could bypass Invoices entirely and create a Payment Intent directly.

quaint agate
#

We have our products and prices already defined in the dashboard.

lethal lantern
#

Or you could create a Checkout Session.

quaint agate
lethal lantern
quaint agate
#

Thank you for this. Can you keep the channel open while I digest this?

lethal lantern
#

We close idle threads after about 15 minutes or so, but if you come back and this thread is closed you can always ask a new question using the buttons in #help.

quaint agate
#

roger. thanks