I created a payment session with stripe with the AllowPromotionCodes option set to true. Once the payment is done, I would like to retrieve the associated discount coupon (if it exists) in the payment_intent.succeeded webhook. I have the impression that this is not possible and I don't understand why. If this is the case, is there a way to get around this problem?
Edit:
I think this link is part of the answer but I don't really understand what stripe proposes as a workaround.
If that's a Checkout Session, you should listen to the checkout.session.completed event and look at amount_discount for the discounted amount. Once the Checkout Session is discounted, everything on payment_intent.succeeded will be the post discounted value and doesn't contain coupon information.
Related
Quite suprisingly, it is not possible to automatically generate an invoice after as successfull checkout session with Stripe.
An invoice must always come before a payment in the stripe system.
I am left with having to recreate the invoice through a bunch of API calls fetching the PaymentIntent or the CheckoutSession that was just performed to recompute the data for the invoice and mark it as paid (not even sure I can retrieve everything I need)
This seems quite hacky... Is this the right way to do it or shall I just handle invoicing outside of stripe (quite annoying too) ?
just want clarify if you need Invoice or Receipt, because they are two different things
Invoice is something you send to customer to ask for payment (before payment)
Receipt is a proof of succeeded payment (after payment)
My understanding is that the payment is already collected upon a succeeded checkout session, so you probably want to send receipts to customers. To enable email receipts, you can go to Settings -> Emails and tick the Email customers about Successful payment box. Please note that emails won't be sent in test mode.
Let me explain a solution that you can use to generate invoices after payment in stripe. This solution is based on Zapier connectors.
There are three systems that we should connect.
Stripe
Zapier
Plumsail Documents
First, you have to set up a Stripe connection to Zapier. Go to Zapier, create a Zap, find the Stripe connection, and select "New Payment" as the trigger event. Then, connect your Stripe account with Zapier and make a test in Zap. If everything ok, go to the second step.
Second. After you have done the Zap connection for Stripe, go to Plumsail Documents, create the process, and make a template for your invoice.
Third. Set up a Plumsail Documents connection to Zapier. Go to your Zap (where you have made the connection to Stripe before), find the Plumsail Documents action, and set the Start Process as Action Event. Next, you have to select your process and match output data from Stripe payment with your invoice template in Plumsail Documents.
It seems a bit complicated, so you can read the article with a more detailed description of this solution. Also, there are screenshots for all processes.
As a result, you will get a fully automated custom invoice generation whenever you will get a payment in Stripe.
Max, product manager at Plumsail.
I am currently adding the Stripe checkout to my application. My goal is really to have at least as code as possible.
The documentation says I need to handle at least three different webhook types:
checkout.session.completed
invoice.paid
invoice.payment_failed
I try to avoid handling any customers in Stripe and I think it is not necessary with the checkout component.
However, I still need the user id in the webhooks to update the states accordingly.
When creating the session on the backend I'll add the field client_reference_id.
For the state checkout.session.completed I get this field and everything is fine.
For invoice.paid I don't get it and I need to use subscription_data.metadata in the session to get this data.
For invoice.payment_failed I don't know how to get it or how to test it with the CLI because I can't add metadata and I cannot add the client_reference_id.
Do you have an idea what the best practice here is and how I should implement that? Or should I really handle a customer in Stripe as well?
Thanks!
There's a couple different ways you can handle this -
If also set client_reference_id in subscription_data.metadata, you can still get it from the invoice.paid and invoice.payment_failed events by retrieving the Subscription found at subscription on the Invoice (see api ref).
You could change your database to store the relationship between a Stripe Customer and a client_reference_id. When you get an invoice.paid or invoice.payment_failed event you would grab the Customer ID and the information in your database would allow you to tie it back to the correct client_reference_id.
We are using the Stripe Checkout and setting our metadata when we create the Session. This allows us to catch the checkout.session.completed webhook and that webhook contains the metadata.
However, we also use Sources, like WeChat, and these are not handled by the Stripe Checkout. To use WeChat, we create a Source and when the user confirms via the QR code, we charge it.
We want to use the charge.succeeded webhook as a central place to fulfil orders, regardless of where they come.
The issue is that the charge.succeeded webhook generated from a successful Stripe Checkout does not contain any of the Session metadata we set, so we can't link it to a Checkout Session and hence have no idea what it relates to
The only way we can see how to do this is:
Stripe Checkout
Catch the checkout.session.completed webhook and use the included metadata to fulfil the order. For the customer details, we can call the Payment Intent
WeChat (And other sources)
Catch the charge.succeeded webhook which contains both the customer data and the Source, which contains the metadata.
The Charge object will have a payment_intent and you can list CheckoutSessions by that PaymentIntent's id.
Alternatively, you can also set the metadata directly on the PaymentIntent when creating the CheckoutSession.
I've been reading Stripe's api documentation (v3) and it's not apparent to me when to use Stripe's Invoice vs PaymentIntent objects. From reading the documentation, here's what I understand:
Stripe sees payment intents being the primary way of facilitating payments through their API going forward and Charges will be deprecated at some point.
Processing an Invoice creates a PaymentIntent under the hood and and initiates payment right away. What I don't understand is why is there no destination account field for the Invoice? If the Invoice is defaulted to be sent to the platform's Stripe account (this is an assumption I am making since there is no destination field), why there is an application_fee_amount field which is essentially the platform's "cut" of the transaction?
A PaymentIntent allow you to specify a destination account while taking an "application" or "platform" fee so you don't have to generate a transfer yourself.
A PaymentIntent and Invoice can be processed at time of creation or deferred until later in your payment lifecycle.
My use case requires me to conduct payments between two parties and take a "platform fee" for each transaction. I have successfully done this by creating a PaymentIntent and using the connected Customer account's credit card on file and populating the transfer_data field with the amount to send to the 2nd party involved in the transaction.
I started looking into Stripe's invoicing api since I am planning on building an invoicing solution for my platform and thought it'd be best to leverage what Stripe has to offer, but I'm failing to see a benefit for me to leverage it since I also need to keep track of transaction ids for the payment intents and taxes based on zip code (it looks like Stripe doesn't do this automatically so I might be out of luck here).
I couldn't find a way to get a transactionId for processing an Invoice but I see that the chargeId gets returned as part of the response when you confirm a PaymentIntent (https://stripe.com/docs/api/payment_intents/confirm).
So the questions I have are:
Why is there no destination account field for the Invoice? Does it automatically get send to the platform's Stripe account and require you to manually create a transfer?
Is there an easy way to get a transactionId from an Invoice?
Is there a way to get a transactionId when creating a PaymentIntent and setting the confirm=true so the PaymentIntent gets processed immediately?
For a platform that will have an invoicing flow and facilitate transactions on behalf of two parties, is it recommended to use payment intents, invoicing, or both?
What's the difference between a charge and transaction? When paying an Invoice, a charge id gets returned in the response but when paying a payment intent, a transaction id gets returned.
Thanks in advance!
You can think of invoices as subsets of payment intent, kind of the same way subscriptions are subsets of invoices.
What I don't understand is why is there no destination account field for the Invoice?
Actually there is one, but the field is transfer_data[destination]. Also, note that whenever an invoice is finalized, it will contain a payment intent, which is expandable, and with which you should be able to solve most of the issues you rose in your question.
To sum up:
Yes there is, as explained above.
Expand the invoice's payment intent object.
I'm not used to work with transactions, but I guess you could leverage their metadata to reference your invoice or vice verse to help you retrieve the need object in needed time.
As explained above, their is not dichotomy between those, if your invoicing your clients, the you should use stripe's invoicing system.
From what I see in the docs, transactions only concern purchase 'internal' to stripe, with issued cards. Charges are the attempts stripe will make to charge your bank account through the network, when a charge succeeds, the payment intent status is set to succeeded otherwise the payment intent might attempt more charges or stop trying at some point, and the payment intent will be set to canceled more about payment intent statuses here. In short payment intents are a subset of charges.
I hope this helped and didn't come too late, the answer might still be improve in the future, if others edit it or as I will learn more about stripe's issuing product.
There is the following event from Stripe that shows a charge has went through:
charge.succeeded
https://stripe.com/docs/api/events/types#event_types-charge.succeeded
From this I can generate an invoice receipt and email it to the customer. Easy enough. However, there is zero information about what is charged in that item -- it only shows the amount. More importantly, it doesn't tell me when the subscription start/end is, which I need to tell the customer in the invoice receipt.
I need to get the different items in the subscription that were charged. It seems like I can use this item instead:
invoice.payment_succeeded
https://stripe.com/docs/api/events/types#event_types-invoice.payment_succeeded
This gives the items in the subscription and also the amount_paid, however it doesn't reference the charge object or anything. I'm also concerned that this event seems a bit more abstracted than the charge.succeeeded/refunded event, so it possibly may not capture anything (please correct me if I'm wrong).
For a subscription, which of the above two methods should I use to trigger when I send an invoice email? Why would one be preferred over the other?
For a subscription, which of the above two methods should I use to trigger when I send an invoice email? Why would one be preferred over the other?
You should prefer the invoice.payment_succeeded event, because as you noticed, it refers directly to the invoice from the subscription and thus has much more of the information that you would need to build a receipt email for the payment.
however it doesn't reference the charge object or anything
The event payload is an Invoice object, which has a charge field with the charge ID for the most recent charge on the invoice(which will be what caused the invoice.payment_succeeded event to trigger). You can retrieve that charge to get further information from that if needed.