#geo_api

1 messages Ā· Page 1 of 1 (latest)

somber skyBOT
#

šŸ‘‹ 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/1313626704383709275

šŸ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

amber dock
#

Hi there

lone cove
#

Hi!

amber dock
#

Hm, this sounds like the opposite order of things

#

Typically, you'll create a Customer, then create a Subscription for that Customer. You'll use the PaymentIntent on the latest Invoice to collect payment details. Confirming the PaymentIntent will automatically attach the PaymentMethod to the Customer

lone cove
#

the first payment, as in they just purchased the subscription

#

I can create a loom video if you'd like

amber dock
#

No need

#

If this should be the first payment on their Subscription, you shouldn't create the PaymentIntent yourself

#

Instead, you should create a Subscription then use the latest_invoice.payment_intent.client_secret to collect payment details

lone cove
#

hmm that kinda goes against our current flow, we essentially list them as a price our system, when the use checks out we listen for the payment_intent.succeeded and then we were thinking of actually creating the subscription after

Screenshot_2024-12-03_at_5.17.00_PM.png
#

we were hoping to reuse the same flow we use for other products we sell on site

lone cove
amber dock
#

Hm

#

It's still the wrong pattern to process a payment independent of the Subscription if your goal is to have that payment be the charge for the first billing period

#

Taking a step back, is your real goal to be able to collect payment details and then determine whether to use those payment details for a PaymentIntent (for a one-off payment) or a Subscription (for a recurring payment)?

lone cove
#

We do payment intents as our main product is selling tickets, which we sort of need to cancel if needed. In this case, I wanted to use the payment_intent.succeeded as the customer purchased the subscription so now since the payment is successful I should create the actual subscription product in stripe

#

not sure if I'm making sense?

#

I can totally make that loom if that helps

#

Also on payment_intent.succeeded I have the customer's information and on the payload I get the the payment method

#

so a payload would look like this
{
"invoice_settings": {
"default_payment_method": "pm_1QS3oIDY3BzcP9iqyEikWJNj"
},
"address": {
"line1": "",
"state": "",
"postal_code": "",
"city": "",
"line2": ""
},
"email": "geo+20241203@onthestage.com",
"payment_method": "pm_1QS3oIDY3BzcP9iqyEikWJNj",
"phone": "",
"name": "testwith newemail"
}

#

but this is where I'm running into issues

amber dock
#

So you can still use payment_intent.succeeded if you create the Subscription first. We'll still emit that event type

#

Let's say you don't run into that error and you're able to create a customer and then a Subscription. When you create the Subscription, we'll immediately create a non-zero Invoice and attempt to pay it automatically for the first billing period, which will ultimately double charge your customers

#

If the $156.30 amount is intended to be the first charge for this annual Subscription, you should create the Customer and Subscription first, and then use the PaymentIntent that's automatically created for the first invoice to collect payment

#

If you want to integrate directly with PaymentIntents and manage subscription cycles on your end (i.e., create a PaymentIntent every year on your own/directly vs having Stripe auto charge), you don't have to create Subscriptions at all. What you should do instead is create a Customer, then create the PaymentIntent with setup_future_usage: 'off_session

lone cove
amber dock
#

Kind of but it's more a hacky way of doing this

#

You could introduce a trial period on the first Subscription so the first invoice will be a zero-amount invoice

#

Note that this might mess with any revenue recognition reports you have

lone cove
#

I see, so I need to create the customer first, then the subscription then listen to payment_intent.succeeded for any post purchase action I need to do in my system?

#

and definitely can't use my current flow of payment intent charged seperatly and then create the customer and subscription

amber dock
#

Correct. If you use your current flow, you would end up either double charging customers (when you create the Subscription) or would have to add a trial period to the Subscription

lone cove
#

would that non-zero Invoice be created as soon as the payment intent succeeds or does it take some time to generate?

amber dock
#

Give me a few minutes to pull this up on my end

#

Ah, you wouldn't see the double charges since none of your calls to create Subscriptions have succeeded

#

actually, I see one

lone cove
#

I've also created some subscription using my flow and the payments seem right to me as in there is a payed invoice and the next invoice seems right sub_1QS2tDDY3BzcP9iqAObNHtGP

amber dock
lone cove
#

yep

#

It looks like there was an immediate payment of 163.80 and the next invoice is scheduled for Dec 3, 2025 which makes sense since this is supposed to be a 1-year recurring subscription

amber dock
#

The PaymentMethod used for this Customer was added via the Dashboard though

#

so I don't think it was tested in the same way

lone cove
#

yep but other than that I've purchased it via my current flow which is why the only missing piece was creating the customer and attaching the payment method but that error is preventing me from doing so

#

I had to add the payment method via the dashboard to work around the error

amber dock
#

Right, understood. Integrating with PaymentIntents directly when you intend to use Subscriptions is the wrong flow to use though

lone cove
#

Flow aside, what could be the root cause of the original error?This PaymentMethod was previously used without being attached to a Customer or was detached from a Customer, and may not be used again.'

somber skyBOT
spare gale
#

Hello! I'm taking over and catching up...

lone cove
#

Hi! Thank you!

spare gale
#

To clarify, you're asking where the This PaymentMethod was previously used without being attached to a Customer or was detached from a Customer, and may not be used again. error comes from?

lone cove
spare gale
#

Ah, the cause for that error in that request is that you're trying to attach a Payment Method to that Customer, but that Payment Method has already been consumed and can't be used again for anything.

#

Payment Methods are, by default, single-use only. That single use can be for a payment, or that single use can be to set it up for future use and save it to a Customer which enables it to be reused.

#

In this particular case you already used this Payment Method for a payment, so that used it up, and it can never be used again for anything else.

lone cove
#

I see, could I use something from payment_intent.succeeded to attach to customer as their payment method or would I have to create the user while the payment method is still "active"?

spare gale
#

If your use case is Subscriptions you wouldn't typically don't interact directly with the Payment Intent at all. The Subscription will create an Invoice, and the Invoice will create a Payment Intent, and that Payment Intent will have setup_future_usage and a customer set, so when the payment succeeds the Payment Intent will also set it up for future use and attach it to the Customer for future use for you.

#

I really want to stress that you are going about this from the wrong end. Payment Intents are low-level payment objects, and are the foundation higher-level objects like Subscirptions and Invoices are built on.

#

You need to think mostly in terms of Subscriptions and Invoices rather than Payment Intents, unless you're doing something unusual.

lone cove
#

I understand but unfortunatly that is the way we have this set up so I need to find a way to make it work with what I have šŸ˜¦

spare gale
#

What do you mean? You can't change it?

lone cove
#

Give me a sec let me make a loom with our current flow, maybe that would help?

spare gale
#

Sure.

lone cove
#

hope this makes sense

spare gale
lone cove
#

I see, I will follow that. Thank you!