#jamie_97274
brittle basinBOT
Hello! We'll be with you shortly. 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.
- jamie_97274, 2 days ago, 5 messages
dapper kelp
No it's a custom subscription implementation
We have a referral system, so we have a single coupon, with thousands of promotion codes connected to that coupon
it would be great if I could simply check on a succeeded payment intent which promotioncode was used
pulsar dome
you can find the promotion code on the discount.promotion_code of the subscription https://docs.stripe.com/api/subscriptions/object#subscription_object-discount-promotion_code
dapper kelp
So not on a payment intent?
pulsar dome
in all cases you shouldn't be listening to the payment_intent.* events
instead you should be listening to the invoice.* events
pulsar dome
in all cases!
dapper kelp
Nope
pulsar dome
even if you use whatever payment method
dapper kelp
sorry to say but I've had bad support regarding iDeal/SEPA and I've been in contact with premium support regarding this, the flow is often incorrectly suggested in this channel for iDeal
because iDeal payments starting a subscription can be up to 21 days before we know if payment has come through
so what you are saying is simply incorrect
dapper kelp
incorrect
pulsar dome
you will receive the invoice.paid event
dapper kelp
because the proper way to start a subscription with iDeal is to make a single payment, then add balance to the customer for the first invoice of the subscription you create off it
the payment for the first month has already come through via the payment intent, before any invoice
either way as Stripe is not totally up to date on how iDeal or SEPA works depending on who you speak to, I am asking if there is a way to get the promotion code used via a payment intent?
astral mantle
well promo codes/coupons don't apply to PaymentIntents, which just process raw amounts, they apply to Invoices. So instead you would do like payment_intent->invoice->discount
https://docs.stripe.com/api/payment_intents/object#payment_intent_object-invoice
https://docs.stripe.com/api/invoices/object#invoice_object-discount-promotion_code
dapper kelp
That's great thanks @astral mantle
though there is no invoice there in my case yet
so looks like I will have to use the subscription object
pulsar dome
I was able to find the previous conversations that we had and yes it was@astral mantle and myself that gave you the idea to implement it this way
so let's go one step back
and try to address your current issue now that I have the bigger picture
dapper kelp
yes and I have confirmed it via email with our stripe consultant, because before other suggestions were made multiple times that had other edge cases that weren't considered by support
a lot of times incorrect sepa/ideal flows get suggested
but it's fine, I will have to do it with subscription object as you initially mentioned, because I understand PI does not have coupons basically
I have access to the subscription object in the succeeded payment intent event already so I can hook into it easily enough just initially thought there must be an easy way to get coupon from PI, but we also adjust the amount of the first PI ourselves and add the coupon id to its metadata to start the subscription with the right discount
so thought about it incorrectly, thanks for your help
pulsar dome
let me just suggest something here
dapper kelp
as long as it doesn't completely change our flow which is working without any issues now
pulsar dome
yes yes
it's more about the webhooks and how/what to use
so whenever a user has one-off and recurring payments
they are obliged to listen to payment_intent.* and invoice.* events
because as I said earlier for subscriptions we recommend using invoices events
dapper kelp
yeh I understand but it's somewhat unnecessary, every invoice creates a payment intent and I can easily see if it's a recurring payment or not by checking if a subscription exists
pulsar dome
that's the problem
with PaymentIntents you don't have enough information to know what to do about the subscription and you would end up having to go back to the invoice
and if for some reason the invoice is 0 (a special discount or something) then there won't be any payment intent generated
and then your integration would break
so to go back to my suggestion, what I advise users to do is to listen to both and when you receive payment_intent.* events you check the payment_intent.invoice and if it's not null, you just ignore the event
because it will be handled elsewhere (in the invoice.paid)
dapper kelp
"and if for some reason the invoice is 0 (a special discount or something) then there won't be any payment intent generated"
This is crucial information thank you, and relevant with our new referral system - I will simulate this and likely refactor a little bit for the invoice event
though payment_intent.succeeded is necessary to listen to for the start of an ideal subscription
but I appreciate telling me this
pulsar dome
I totally agree
but the first one wouldn't have the invoice ID which means you need to treat it there
I think whenever you come back to discord, you can always reference this thread #1182270547636260974 message
so we could have some context and be able to understand your integration choices
dapper kelp
appreciate you going beyond the basic answer here
pulsar dome
you have a particular use-case, and we really can't always remember every single use case that we come across