#aaron_webhooks
crimson trailBOT
👋 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/1273821474863583232
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
white flowerBOT
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.
- aaron_subscription-applicationfee, 3 hours ago, 21 messages
- aaron_app-connect, 4 hours ago, 29 messages
- aaron_stripe-app-application-fee, 5 hours ago, 15 messages
craggy maple
We receive events for both payment_intent.succeeded and customer.subscription.created and want to record this in our database. For one_time, and for the first billing cycle of a new subscription.
It was my understanding that payment_intent.succeeded is sent either way, whether its one time or subscription.
But when we go to create a new Checkout Session as a subscription, it doesn't allow us to save metadata to the payment_intent because that's not allowed when the type is "subscription".
So my question is, what's the best way to record first billing data on subscriptions? And do we need to also check that we don't duplicate record a payment_intent event coming in as well?
We need the metadata for our recording
high bay
When you retrieve the PaymentIntent, expand its invoice to see the full Invoice object. There you can look at the Invoice's billing_reason of subscirption_create: https://docs.stripe.com/api/invoices/object#invoice_object-billing_reason
You can furthermore expand until the Subscription object like expand: ['invoice.subscription']
high bay
You would need to make a Retrieve PaymentIntent request
craggy maple
is this appropriate at scale? what are the rate limits
high bay
It shouldn't be that much for 1 more request. It's a common appraoch by many other merchant
craggy maple
Hey @high bay, it won't let me create another thread so I wanted to ask here.
^ We will implemenet this, this is a different question
high bay
Sure
craggy maple
I have a checkout session created in test mode and we get this error upon attempted checkout
I imagine our Stripe App is missing a read_write on some permission, but not sure which
This is a checkout session created on an account with our app installed
we have checkout session read and write already in our permissions
craggy maple
So the acct_1Pen... is the installed account, correct?
indeed
this is also in test mode if that matters
but we wanted to test the webhooks of a successful purchase
its a checkout session to purchase a subscription item
craggy maple
Dod you have the `checkout_session_read` and `checkout_session_write`?
we do yes
might it be something about payment intents?
i imagine that's the next step of a session?
we don't have permissions specified for charges or payment intents or subscriptions, but i kind of thought those were implied if we have permission to to create checkout sessions
{
"permission": "checkout_session_read",
"purpose": "Allows your customers to purchase plans through Priceable pricing tables."
},
{
"permission": "checkout_session_write",
"purpose": "Allows your customers to purchase plans through Priceable pricing tables."
},
{
"permission": "product_read",
"purpose": "To show your products in your pricing table."
},
{
"permission": "plan_read",
"purpose": "To show your prices in your pricing table."
},
{
"permission": "promotion_code_read",
"purpose": "Apply coupons to your pricing table (optional)."
},
{
"permission": "customer_portal_read",
"purpose": "For buttons that send your customer to their billing portal."
},
{
"permission": "coupon_read",
"purpose": "Apply coupons to your pricing table (optional)."
},
{
"permission": "event_read",
"purpose": "Allows reading event data from the Priceable Stripe App"
}
],```Yeah I believe Payment Intent or Charge permissions are also required, as it would be created alongside the Checkout Session
craggy maple
Should we request ALL of those (charge read_write, payment intent read_write)?
In terms of good practice, is it a bad look when requesting this many permissions for a user installing our app?
high bay
Yeah I know but you are still testing, so let's require them
Generally PaymentIntent and Charge are fundamental objects and will be needed anyway
craggy maple
alright, we'll add them all and see what's up. is there a way to see later if they're still needed or do we need to re-submit our app each time and get the users to re-auth their accounts each time
thats another question, if we update perms, is there an elegant way to get our users to update their permissions or is that something we have to handle in our app logic. hey your key doesn't have perm for this, please reauth our app: here?
high bay
Good question. I think you would need to ask again (that's the whole point of permissions)
craggy maple
makes sense - okay awesome.
i thought there might possibly be a dashboard prompt or something but this works
i appreciate your help a bunch!
high bay
Np and good luck!
craggy maple
Hey @high bay, just ran into a weird issue I wanted your thoughts on.
We changed perms, and when getting our user to re-auth, it totally fails. It just loads forever, no redirect back to our app, and in the network request tab we can see the ?authorize endpoint fails for 403 forbidden with error code "app_reauth_required".
Uninstalling and reinstalling fixed it but not sure if a regular user would be able to figure this out. Have you seen this before?
Also we think it turned out to be payment_methods permissions. Thats the endpoint thats failing for 403 in the network tab! In case someone else hits this issue I guess hahahaha. testing now
high bay
Oh I see !?
So let's require the payment_method as well
Well I believe PaymentIntent and Charge are essential anyway
craggy maple
yeah i imagine those would've errored out too
any way I can submit a bug request on this re-auth flow?
i think most users will not be able to troubleshoot that they actually need to fully uninstall the app and reinstall
(this is happening every time we update permissions and try to re-auth)
crimson trailBOT
silk forge
👋 Taking over this thread, catching up now
When there is a change in permission, the user will have to re-authorise the permission changes again. Are you facing error when attempting to re-authorise the permission changes?
craggy maple
Exactly yes.
So when they go back to re-auth, this is what happens
- they're brought to the stripe page to select their account
- account shows already installed (ex: "Priceable App -> Already installed in test mode"). makes sense, all good here
- you click that account and click Authorize
- It shows a loading indicator and just loads infinitely
This is where it hits that ?authorize endpoint (i forget its actual path) and when it succeeds it redirects you back to your redirect URI
But in this case hitting that endpoint fails with error 403, but there's no UI indicator this is happening, it just loads forever
and in the network requests tab you can see that endpoint returns { error: "app_reinstall_required" } or app_reauth_required or something along those lines
