#BidBird®
robust linden
stark anchor
Hello! There's no way to apply a Coupon object directly to the a PaymentIntent - Coupons are meant to be used with things like Checkout/Invoices/Subscriptions, not directly with PaymentIntents
stark anchor
Checkout and Invoices (which both use PaymentIntents under the hood) would allow for one-off charges with coupons. It's just that you can't directly use PaymentIntents with Coupons
If you're interested, this quick article (https://dev.to/stripe/single-slider-payment-objects-overview-a0d) touches on the relationship between PaymentIntents and other solutions (like Checkout/Invoices)
ruby matrix
I see. I vaguely remember the card element not able to accept coupons. So I wired up something on my end which calculated the discounted amount.
Right now I'm migrating/ed to the newest payment element.
I guess I can store a coupon code in metadata
stark anchor
Yeah, if you want to accept coupons in your own UI you'd need to build if yourself and update the PaymentIntent amount to reflect the discount
ruby matrix
Just watched that video, thank you.
I wish the PI had coupons. Anyhow, at least the code I did before can still work with PI.
How about tax? Can taxes be used/applied to PI? I don't see an object attribute for that?
stark anchor
It's a similar thing with Tax - you can update the amount of PI to include Tax, but there is no specific attribute or anything that is dedicated to tax on the PI
stark anchor
I know it's a pain - the idea is that PaymentIntent is supposed to be a super flexible object that will work for users who have their own logic that they want to layer on top
But if you want to leverage other Stripe features like coupons and tax, it's really much easier to use things like Checkout or Invoices
ruby matrix
ha. jeez just spent a ton of time updating to PI.
Do you think Checkout and Invoices are more appropriate for one-off charges? Or perhaps a payment method stored on file?
stark anchor
If you want to be able to charge payment methods that are on file then Invoices would be the better solution
But I'd also checkout https://stripe.com/docs/tax/custom-payment-flows and contact them to see if that beta will maybe be helpful for you
ruby matrix
yea, I had created a tax table in the db. We're a marketplace so, after a threshold in sales each jurisdiction would require it's own tax. Which could be like 50 states x X counties! Let me check that link.
Appreciate it
stark anchor
👍
ruby matrix
signed up!
ruby matrix
where's the best place to get the STRIPE_WEBHOOK_SECRET on the dashboard theres a shorter whsec_ but stripe cli is much longer in characters?
stark anchor
Are you trying to get the secret for your CLI local listener or for an actually webhook endpoint?
ruby matrix
not sure. I know when we're working on middleware:
try { WebhookSignature::verifyHeader(
$request->getContent(),
$request->header('Stripe-Signature'),
config('services.stripe.webhook.secret'),
config('services.stripe.webhook.tolerance')
the one needed for middleware. It seems like when we create an endpoint theres a Signing secret but also a we_1IB.... on the dashboard...
stark anchor
When you look at your webhook endpoints on the dashboard you should be seeing this "reveal" text and that's where you'd get it from
ruby matrix
ok, perfect. So those are created for each webhook route we create?
stark anchor
Yup!
ruby matrix
I was curious about the PI. Are charge.succeeded and charge.failed part of the old charges api? Or it is correct that these events are created?
I was receiving these on the webhooks endpoint for PIs.
stark anchor
PaymentIntents create charges under the hood - previously (before PIs) we just had the Charges API and users would create those directly